Request for more organize feature request lists...

[Jason Brower]

Can we use launchpad to keep try of bugs and feature requests? I love
to post ideas that come to my mind, but putting to a list with a project
this large makes the features melt into the intertube.
Regards,
Jason Brower

[Yarko Tymciurak]

I would point this out:

It is better to START with requests and bugs here....

If there are bona-fide or accepted (that is "good idea; we'll do it!"; or "we have enuogh information that we can reproduce, but not sure how to approach it...  please log a bug..."), then it makes sense to put in the tracker.

Unfortunately - the way Massimo works (hahaha!)  many features are immediately implemented (small enough to do that) and he "prototypes" to the list -- e.g.  "Here, see if this is what you meant to ask for, see if this works for you"  --- and if no one complains, it becomes part of the tree --- no need to put reports in.

Also, same with bug fixes.

But you are right - if anything passes the "acceptance test" here on list, and is not "just immediatly put into trunk"  then it should go on the buglist.

I hope this logic makes sense.

Regards,

Yarko

[Fran]

On Apr 18, 4:52 pm, Jason Brower <encomp...@gmail.com> wrote:
> Can we use launchpad to keep try of bugs and feature requests?  I love
> to post ideas that come to my mind, but putting to a list with a project
> this large makes the features melt into the intertube.

Issue Tracker is here:
http://code.google.com/p/web2py/issues/list

Although, as Yarko says, this group is different from normal in that
issues are better posted to the listed first...

F

[mikech]

I would like to report that on the edit page of the administrative
interface the word
previous is misspelled after the revert button.

Mike

[Yarko Tymciurak]

:-)   I can "reproduce" this!

"[revert] to previour page"  !!! :-)

Can you supply a patch?  (just kidding - if Massimo doesn't fix this this weekend, would you post to 

AND, ALL:  PLEASE NOTE CORRECTION TO BUGS LINK:

https://bugs.launchpad.net/web2py

(The one Fran reported is not used - SVN is just a convenience mirror of the launchpad repository;  for now, Launchpad is the official repository of web2py)

Regards,

- Yarko

[Jason Brower]

There are many times I report a bug or feature, in other projects, and
the main developers are working too hard on other parts of the project.
(Openoffice is just not working on a feature I requested 3 years ago.)
The biggest reason I see a tracker as useful is because I want to
contribute. I can see a list of bugs, and can contribute by helping
triage and report on them. I can report a bug and see when it really is
fixed, or when it needs to be tested. It's so much more organized, and
most OSS contributers don't sign up for the emailing list of all
software they have bugs in and use, they report the bugs, as they have
to pick and choose the projects they can fully contribute to. Many
people have to focus on using the product so much they must have a quick
way to contribute the bug report or they simple can't do it at all.
To me, this is part of the maturing OSS project.
---
Jason Brower

[Yarko Tymciurak]

You are right, Jason...

But still, I think putting a bug in the group list first serves a purpose:  it validates that others can reproduce....

When that happens (or when you get no response) then this serves as a useful pre-requisite before putting in a bug tracker.

I have spend many a weekend removing bugs from issue trackers which did not have enough information to reproduce (that is - someone was convinced they found a bug, and maybe they did - but it was useless because others could not easily produce the problem).

It makes sense to validate that you have a problem with the community before reporting it as a tracked problem, don't you agree?

Regards,

- Yarko

[mdipierro]

I agree with yarko and for one more reason: The processing of
accessing lanchpad to close a bug usually takes longer than fixing the
bug (assuming it is a real bug).

Massimo

On Apr 19, 1:12 am, Yarko Tymciurak <yark...@gmail.com> wrote:
> You are right, Jason...
> But still, I think putting a bug in the group list first serves a purpose:
>  it validates that others can reproduce....
>
> When that happens (or when you get no response) then this serves as a useful
> pre-requisite before putting in a bug tracker.
>
> I have spend many a weekend removing bugs from issue trackers which did not
> have enough information to reproduce (that is - someone was convinced they
> found a bug, and maybe they did - but it was useless because others could
> not easily produce the problem).
>
> It makes sense to validate that you have a problem with the community before
> reporting it as a tracked problem, don't you agree?
>
> Regards,
> - Yarko
>

[Jason Brower]

I guess I see the checking-for-valid-bug phase a step that others can do
to help lift some of the load off of members that can code. But your
right, there is a lot of garbage reports out there.
I just wish there was a way, that when I have the time, I can sit down
and start to sift through reports and start solving them all from one
place. I can see a list of bugs and even sort them to my liking. Pick
out the ones I think I can help fix and proceed from there.
At some point I think we should consider moving bugs to an area that can
be better delegated. But for now, as you know, this project has been
doing a great job helping fix issues in the system.
Thanks,
Jason Brower

[Douglas Soares de Andrade]

Em Domingo 19 Abril 2009, às 03:23:03, mdipierro escreveu:
> I agree with yarko and for one more reason: The processing of
> accessing lanchpad to close a bug usually takes longer than fixing the
> bug (assuming it is a real bug).
>
> Massimo

I agree with you all and im very happy with the development cycle i see in
web2py, as it helps us to improve and learn new features just by seeing the
threads.

I think we can work as we are doing now, and think in something when we cant
manage to read the list properly - when it reach the python main list traffic
=).

Btw, you all have been doing a great job, it has been inspiring to see web2py
envolving with all the talks and discussions without losing what makes it be
"the" framework for me... its ease of use/learn.

Thanks a lot

[Jason Brower]

Alright, being your the one that closes and fixes most of these bugs, I
will leave it to you. But don't be afraid to assign things to us. :D
Regards,
Jason Brower

[mdipierro]

Thank you for the availability. I have done so some times and I will
do so more in the future.

Massimo

[Tim Michelsen]

> I guess I see the checking-for-valid-bug phase a step that others can do
> to help lift some of the load off of members that can code. But your
> right, there is a lot of garbage reports out there.
> I just wish there was a way, that when I have the time, I can sit down
> and start to sift through reports and start solving them all from one
> place. I can see a list of bugs and even sort them to my liking. Pick
> out the ones I think I can help fix and proceed from there.
> At some point I think we should consider moving bugs to an area that can
> be better delegated. But for now, as you know, this project has been
> doing a great job helping fix issues in the system.

What about entering a request at Launchpad and then post it at the
mailing list for discussion.
What I can see from the short time I am following this project I get the
impression that:
* a lot of useful tips get burried in the mailing list
* some mails are left unanswered
* the documentation in the manual is good for learning but getting outdated.

So, to my opinion, it could be useful for tracking purposes to keep docs
and issues at a central place.

Thanks for your work on this smart app,
Timmie

[Yarko Tymciurak]

On Mon, Apr 20, 2009 at 12:49 PM, Tim Michelsen <timmic...@gmx-topmail.de> wrote:

> I guess I see the checking-for-valid-bug phase a step that others can do
> to help lift some of the load off of members that can code.  But your
> right, there is a lot of garbage reports out there.
> I just wish there was a way, that when I have the time, I can sit down
> and start to sift through reports and start solving them all from one
> place.  I can see a list of bugs and even sort them to my liking.  Pick
> out the ones I think I can help fix and proceed from there.
> At some point I think we should consider moving bugs to an area that can
> be better delegated.  But for now, as you know, this project has been
> doing a great job helping fix issues in the system.

What about entering a request at Launchpad and then post it at the
mailing list for discussion.

You create a lot of work for someone then (Massimo or me, or someone else) since:

[1]  If issue is not sufficient or not a bug, it has to be closed (or ignored);
[2]  either way, it has to be discussed on list;
[3]  documentation should go to the wiki:  https://www.web2py.com/wiki, NOT bug list

What I can see from the short time I am following this project I get the
impression that:
* a lot of useful tips get burried in the mailing list

Search - if you think it is generally useful, add to wiki!
 

* some mails are left unanswered

Rarely... people usually post again to remind;
 

* the documentation in the manual is good for learning but getting outdated.

True enough;  wiki is there, and sphinx docs should get started this summer.  Massimo may also have plans for a revision of the book too.

For sphinx-doc, best way to start contributing is in the wiki - please join in!
 

So, to my opinion, it could be useful for tracking purposes to keep docs
and issues at a central place.

Note that is you create issues that are not valid, they will either be ignored or will create more work - please post to list first to see if you have a valid issue.

Thanks,
Yarko

[Tim Michelsen]

Thanks for the discussion.

> What I can see from the short time I am following this project I get the
> impression that:
> * a lot of useful tips get burried in the mailing list
>
>
> Search - if you think it is generally useful, add to wiki!

> Rarely... people usually post again to remind;

If that is allowed I am fine with this. Some list really dislike this...

> * the documentation in the manual is good for learning but getting
> outdated.
>
>
> True enough; wiki is there, and sphinx docs should get started this
> summer. Massimo may also have plans for a revision of the book too.

Let me add this:

* there are many places to search for documenations
* google group
* new wiki
* PDFs on the doc page
* examples
* API doc
* why not add an custom search for all sources like:
http://www.rseek.org/ to the webpage?

>
> For sphinx-doc, best way to start contributing is in the wiki - please
> join in!

* many functions of the core are not documented with docstrings.

* would web2py community entertain a Sphinx effort?
* I have successfully documented my scripts with it!
I could help with my experiences. It's easy. I was using the numpy doc
standards
(http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines#docstring-standard)

* may you please use SEO URLs in the wiki?

BTW, I see that the wiki supports rst formatted text.
I have some questions on this:

* will the functionality be added to core?
http://bazaar.launchpad.net/~mdipierro/web2py-wiki/trunk/annotate/head%3A/models/rest.py
* why is this file in the models subdirectory?
* how do I parse the docstrings of a action with rst to document my
applications in view?
* I want to use this as http://en.wikipedia.org/wiki/Colophon_(publishing)
to document once and use twice (in internet and external
documentation)

For further rst integration please see also discussions at Sphinx list:
* further rst integration look at
* http://tosh.pl/gminick/gsoc/sphinx/#Techniques
*
http://thread.gmane.org/gmane.comp.python.sphinx.devel/1943/focus=1947

Kind regards,
Timmie

[Yarko Tymciurak]

Hi Tim -

On Mon, Apr 20, 2009 at 5:22 PM, Tim Michelsen <timmic...@gmx-topmail.de> wrote:

Thanks for the discussion.

*snip!*

>

> For sphinx-doc, best way to start contributing is in the wiki - please
> join in!

* many functions of the core are not documented with docstrings.

* would web2py community entertain a Sphinx effort?

We have decided on one - the general idea was:

- RST wiki (rst processing needs some help, but Massimo put it up quickly)
- Sphinx book, which would organize, take the best from Wiki (and have section leads)
- docstring updates of source tree (the next immediate step we have asked for)

PyCon sort of slowed me (at least) down.

web2py Sphinx doc I think will be hosted on bitbucket - we noticed the planned move of Python itself to mercurial, and this is where Sphinx and some sphinx books are.

We have discussed moving web2py and web2conf from launchpad to bitbucket also (I have eternal trouble uploading and downloading from launchpad - from behind a VPN, "nosmart+..."  protocol only occaisionally solves a problem; about 1/3 of the time I am still blocked from making downloads, and mostly I "live" behind a VPN.  For uploading, I can never get it to work from behind the VPN, and when I do get it to work otherwise, ... I won't even go into how much of a nusiance it is... I hate the experience, had a hard  time being able to upload anything for PyCon, so I am a BIG fan personally of moving to bitbucket).

I think I'll move web2conf first, then create a sphinx-doc repository.  We talked w/ Massimo about scheduling a web2py move after the semester is over (sometime early June).
 

    * I have successfully documented my scripts with it!
I could help with my experiences. It's easy. I was using the numpy doc
standards
(http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines#docstring-standard)

Glad to have you help!  Grab a copy of web2py, and start!  I suggest you keep a current copy on launchpad for now - make a branch - if you keep this current, others can pitch in easily.

If you prefer, you can just _start_ by doing this on bitbucket.   Send me an email and we can talk about it some more.
 

* may you please use SEO URLs in the wiki?

Good idea!  Can you send in a patch?
 

BTW, I see that the wiki supports rst formatted text.
I have some questions on this:

* will the functionality be added to core?

it might make it into gluon/contrib someday (as markdown is there)... but the simple rest.py module you point to needs some work first...  when it feels mature, it will be considered.
 

http://bazaar.launchpad.net/~mdipierro/web2py-wiki/trunk/annotate/head%3A/models/rest.py
* why is this file in the models subdirectory?

for convenience - each request loads all the model files, so rest is thus available for the controllers (along with the models).   It really could be in modules, and then imported everywhere it might be needed....
 

* how do I parse the docstrings of a action with rst to document my
applications in view? 

not sure - you might want to look at the sphinx autodoc extension; see
http://sphinx.pocoo.org/ext/autodoc.html

       * I want to use this as http://en.wikipedia.org/wiki/Colophon_(publishing)
            to document once and use twice (in internet and external
documentation)

Let us know - this would be useful to have in web2py/admin.
 

For further rst integration please see also discussions at Sphinx list:
* further rst integration look at
    * http://tosh.pl/gminick/gsoc/sphinx/#Techniques
    *
http://thread.gmane.org/gmane.comp.python.sphinx.devel/1943/focus=1947

Kind regards,

Timmie

Thanks for your comments, Timmie!

Regards,
- Yarko

[Yarko Tymciurak]

On Apr 20, 6:14 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
....

> web2py Sphinx doc I think will be hosted on bitbucket - we noticed the
> planned move of Python itself to mercurial, and this is where Sphinx and
> some sphinx books are.
>
> We have discussed moving web2py and web2conf from launchpad to bitbucket

> also.....

Related note:

In addition to what I'd mentioned before:
http://mail.python.org/pipermail/python-dev/2009-March/087931.html

there is now this also:
http://google-code-updates.blogspot.com/2009/04/mercurial-support-for-project-hosting.html