CGIHTTPServer should support all CGI scripts, not only Python ones.

I suspect this bug will sit here languishing without action, for various reasons:

1) From other doc discussion, I assume you won’t be able to propose a patch.

2) There is no dedicated maintainer for http or cgi.

3) CGI is a low-level, archaic, inefficient interface.

4) The cgi server has grave bugs like this one (from the doc):
“CGI scripts run by the CGIHTTPRequestHandler class cannot execute redirects (HTTP code 302), because code 200 (script output follows) is sent prior to execution of the CGI script.”

Forgot the conclusion: I suspect noone will want to work on that.

(I removed 2.7 since it’s feature frozen.)

On Wed, Jun 16, 2010 at 12:16:38PM +0000, Éric Araujo wrote:
> Forgot the conclusion: I suspect noone will want to work on that.

Nope, please don't come to that conclusion soon. It is a valid
request. It is not that only maintainers listed will work on those.

> (I removed 2.7 since it’s feature frozen.)

This is fine.

Sorry, somehow I forgot the ton of work you’ve been putting into
urlparse and urllib :)

Note that I never said or thought it was an invalid request.

> I suspect this bug will sit here languishing without action, for various reasons:

I suspect this kind of discussions piss off readers of tickets, but
I'll continue, as I do not see any other useful public medium at hand
right now.

-- start offtopic --

> 1) From other doc discussion, I assume you won’t be able to propose a patch.

Right. I do not feel comfortable with Python workflow - now that I
have several dozens of unfinished patches - they start to conflict
with changes in repository. Conflict resolution takes a lot of time
and I can't afford maintaining a separate copy of Python checkout for
every patch. It also takes too long to setup test environment and
execute tests. There is a lot of yak shaving involved between:
1. make ticket
2. find source
3. make patch
4. test patch
5. attach patch
6. refresh patch
7. test patch
8. attach patch
...

I've already explained it somewhere in more detail. A pity it is lost.

I am waiting for Mercurial 1.6 to try anchored MQ. Perhaps then I will
be able to revisit Python contribution process.

> 2) There is no dedicated maintainer for http or cgi.

I can not be. pydotorg tools suxx tremendously and I do not feel
inspired by wasting time trying to fish required information. To be a
maintainer I need:
1. separate commit notifications for the module with ability to reply
to dedicated review group
2. separate bug tracker category for my module with giving users
ability to change every property of it
3. bug tracker timeline for the module that includes ticket changes,
wiki edits, commits and everything else. Filtered.
4. roadmap page with Google Wave content for collaborations
5. dashboard page with links to all the above

Look at Trac Hacks for a minimum acceptable example of a tool that is
able to persuade me to become a stdlib module developer. Sorry for not
able to compile this into a report for EuroPython.

> 3) CGI is a low-level, archaic, inefficient interface.

stdlib doesn't propose anything better.

-- end offtopic --

> 4) The cgi server has grave bugs like this one (from the doc):
> “CGI scripts run by the CGIHTTPRequestHandler class cannot execute redirects (HTTP code 302), because code 200 (script output follows) is sent prior to execution of the CGI script.”

It would be nice if this also clarify if it is the bug of Python class
or a limitation of CGI protocol.

> Conflict resolution takes a lot of time
> and I can't afford maintaining a separate copy of Python checkout for
> every patch

Then try various hg features such as named branches, or bookmarks, or mq, or pbranch, etc.
(or any SVN-facing tool you would like, including git-svn, bzr-svn, etc.)

> To be a maintainer I need:
[snip]

Most people in most open source projects seem perfectly content without such an artillery of sophisticated tools/gadgets. While the workflow can always be improved, it is not obvious to me that your requirements are in any way reasonable, or even serious ("serious" as in "this is the only reasonable way one can work efficiently on Python" -- plenty of people, almost all of them unpaid volunteers, seem to disagree).

By the way, the first thing needed to qualify as a maintainer would be to *prove* that you are up to the task. Not to have a bunch of nifty tools. In other words, you can't just come and say "hey, I'd like to be a maintainer" and expect this request to be granted automatically.

>> Conflict resolution takes a lot of time
>> and I can't afford maintaining a separate copy of Python checkout for
>> every patch
>
> Then try various hg features such as named branches, or bookmarks, or mq, or pbranch, etc.
> (or any SVN-facing tool you would like, including git-svn, bzr-svn, etc.)

pbranch is the next in my list, still do not have time to dig all these tools.
For now I have these unsolved workflow problems:
1. patches are not tied to specific bug ticket (can only be manually uploaded)
2. I would like to receive feedback on patches inline (like in Mercurial list)
3. I would like to see all the code related to patch (source, tests,
docs) in one place
4. Edit, preview and update docs patches online
5. Download patched source and test in one step, execute in the other

>> To be a maintainer I need:
> [snip]
>
> Most people in most open source projects seem perfectly content without such an artillery of sophisticated tools/gadgets.

You account only people who found they way to be able to contribute.
Most people didn't. If you can calculate an average indicator of
active Python contributors, I will say that it can be improved by 50%
only by means of well aligned toolset.

> While the workflow can always be improved, it is not obvious to me that your requirements are in any way reasonable, or even serious ("serious" as in "this is the only reasonable way one can work efficiently on Python" -- plenty of people, almost all of them unpaid volunteers, seem to disagree).

I never said "this is the only reasonable way one can work efficiently
on Python". I said that "there is no  reasonable way one can work
efficiently on Python and I am trying to find one". Feel the
difference.

> By the way, the first thing needed to qualify as a maintainer would be to *prove* that you are up to the task. Not to have a bunch of nifty tools. In other words, you can't just come and say "hey, I'd like to be a maintainer" and expect this request to be granted automatically.

Ok. Let me try to express it in English once more:
search: To be a maintainer I need:
replace: To be willing to become a maintainer I need:

> pbranch is the next in my list, still do not have time to dig all these tools.
> For now I have these unsolved workflow problems:
> [...]

That's a lot of things which others do not perceive as important or even
desireable. Chances are you are going to have to implement them yourself
if you really want them. In any case, just complaining won't change
anything.

> Ok. Let me try to express it in English once more:
> search: To be a maintainer I need:
> replace: To be willing to become a maintainer I need:

Nobody proposed you to become a maintainer, so this is still besides the
point. First contribute significantly, and then we'll see.

> That's a lot of things which others do not perceive as important or even
> desireable. Chances are you are going to have to implement them yourself
> if you really want them. In any case, just complaining won't change
> anything.

I am just trying to answer why I can't contribute patches myself. Hope
the idea to put workflow first after getting enough experience over
past year was clear. I work on this workflow alone. If smb. would also
feel that is it a more important problem than immediate patch - I'd be
glad to collaborate.

>> Ok. Let me try to express it in English once more:
>> search: To be a maintainer I need:
>> replace: To be willing to become a maintainer I need:
>
> Nobody proposed you to become a maintainer, so this is still besides the
> point. First contribute significantly, and then we'll see.

Can you estimate my contributions so far?
I suspect I should stop wasting time if there are aren't any.

Le jeudi 17 juin 2010 à 13:22 +0000, anatoly techtonik a écrit :
> 
> > That's a lot of things which others do not perceive as important or even
> > desireable. Chances are you are going to have to implement them yourself
> > if you really want them. In any case, just complaining won't change
> > anything.
> 
> I am just trying to answer why I can't contribute patches myself.

Thank you, I think you have made your point.
Now I suggest you propose patches to improve the workflow on the
relevant mailing-list(s) or issue tracker.

I’m sorry to have launched this thread. I hadn’t thought that Senthil
is doing a lot of good work on HTTP and URI-related modules, and I wanted
to express my feeling that this bug would not get fixed without someone
proposing a patch. I didn’t want to imply that the request was not valid
nor to discourage bug reporters. If I did, I sincerely apologize.

To address the issues Anatoly raised before I stop being off-topic:

1) Patch submission: You can already use Mercurial to prepare patches
(bare Mercurial, MQ or pbranch, on top of a Subversion checkout or
Mercurial clone (code.python.org/hg, kindly maintained by Antoine).

2) No maintainer for CGI: The term “maintainer” is explained at the top of
the Misc/maintainers.rst file, it means a core developer taking special
care of one area or module. All core developpers are collectively
maintaining the whole stdlib; a module without a dedicated maintainer is
*not* unmaintained.

3) Nothing better than CGI in stdlib: BaseHTTPServer is handy for quick
testing; wsgiref is okay for quick testing of WSGI applications.
Third-party servers have different design goals and advantages for various
classes of users.

4) The header thing is a bug; I’ll search whether it’s already reported.

5) Current workflow seems good to the vast majority of contributors. I’ve
been contributing for a few months and found the workflow reasonable and
working, like a lot of people. That said, a Web UI for doc changes with
live preview may be a good way to let non-programmers propose fixes;
please open a feature request on Sphinx’ tracker (on Bitbucket) or ask for
opinions on docs@python.org. Again, we’re all volunteers here, so “you
should do X” works a lot less than “I want to do X”.

I hope I have provided some hints and data points; I do not wish this
off-topic discussion to continue. Like Antoine said, we now understand your
viewpoint, and your suggestions for improvement would be more fruitful on
relevant mailing lists. Regards

@Senthil Kumaran/orsenthil can you pick this up as implied in msg107919?