Tim Peters wrote:

...

Worrying about patch management mechanism, while more patches pile up and are ignored in the meantime, is not going to help and will just results in continued stagnation.

At an all-hands PythonLabs group mtg today, it was decided to move patch activity to SourceForge and kill the patches list. I'll send more about that later. There is absolutely nothing new stopping checkins while the move to the SourceForge patch manager is in progress, so if the patches continue to pile up it's certainly not the move's fault. If the pythonrun.c patch is still sitting untouched after the move, I'll assign it to you <0.7 wink>.

But how are we going to discuss new patches from people outside python-dev then ? I do see the use of moving patch submission to SourceForge, but posting the patches on the list for revision by everyone who listens is certainly better than having to scan the patch manager entries... (push strategies usually produce more feedback than pull ones). A gateway from the patch manager to the patches list would solve this nicely. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

[Andrew Kuchling]

... So, I no longer have much of a problem with moving patches to SF, though I *still* think the mailing list would be sufficient with a bit more focused effort; sorry, Tim!

"Do something" to supply that focus on this mailing list, and then I can stop bothering with the move. That would be great. But repeating that if the list worked, it wouldn't be broken <0.7 wink>, has not proven sufficient to fix it.

But at least we're not going to burn weeks looking at different patch manager products, and then arguing about them, which is what I feared most.

Same here. well-actually-the-radio-on-the-drive-down-to-va-got-me-more-worried- about-lyme-disease-ly y'rs - tim

Guido van Rossum wrote:

It's official: I've changed the patch submission guidelines (http://www.python.org/patches/) to point to the patch manager at SourceForge. We are no longer bound by CNRI's legal department, so the requirement for disclaimers or wet signatures is gone.

We'll have to see how it works in practice. I've set the address where new patches are mailed to patches@python.org; this should send notifications to the patches list. We could change this to python-dev perhaps, so we can retire the patches address completely (giving it an auto-respond pointing to the SF patch manager, as barry suggested).

Will there be a list which gets the patches mailed to it by SF ? I'm just asking because the current setup of having the patches available through mail really helps in discussing patch details.

There are several tasks to be assigned now: we need a triage person who should go through the list of new patches regularly to assign them to developers; we need developers who are willing to have patches assigned to them.

I'll volunteer for the Unicode side of things :-)

We also need a consensus process to decide which patches will be allowed through. I'm hoping to experiment with SF in the coming days to come up with something.

Finally, we still need to do something about the existing backlog of patches. The PythonLabs team will try to do something reasonable here.

This is not the end -- it's the beginning!

-- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

[Fred]

patches@python.org should get messages of patch manager activity (at least certain actions; not sure which ones yet, but at least additions).

Fred, would you please explain how that works or where that was set up? I've puttered away many hours now playing with the SourceForge facilities (alas, most of that time waiting for web pages to load), but haven't stumbled into anything that hints the patch manager knows anything about patches@python.org. so-stupid-in-so-many-ways-ly y'rs - tim

[Fred L. Drake, Jr.]

From the "project page", go to "Project Admin" on the left navigation bar, then "Edit Public Info" at the top of the page. There are places to edit some email addresses near the bottom of the page.

Aha! The one & only link I had never clicked -- I bet I could have figured that out myself in another week or two <wink>. Thank you. Now why do we have "Use Bug Tracker" checked? If nobody objects, I'll turn that off -- we're still doing bugs w/ Jitterbug on python.org. ten-stop-shopping-ly y'rs - tim

SPeaking of surprising little SourceForge things: I just made the mistake of clicking on the little garbage can beside "Python" in "My Projects". I seem to have booted myself from the Python project. Can I put myself back on? or can one of you with admin status please do that for me? my SourceForge username is: tmick Sorry and thanks, Trent -- Trent Mick trentm@activestate.com

[Guido van Rossum]

... The address for New Bugs is currently set to guido@beopen.com. I suppose I should set it to pythoneers@beopen.com or even to python-dev@python.org?

Since we (PythonLabs, last week) decided to continue using Jitterbug (on python.org) for now, should the SF Bug Manager even be enabled? If it is enabled, and we are using Jitterbug, then someone has to own reentering SF bugs into the Jitterbug system. obviously y'rs - tim

[Guido]

OK, I've disabled the SF bugs manager. There were two bugs submitted so far. I've assigned one to you (about os.listdir on Windows) and one to MAL (about -U vs. exec/eval). You two can take care of entering these into JB. You can still access the bugs database via this URL:

https://sourceforge.net/bugs/?group_id=5470

I moved "my" bug to Jitterbug, and moved Marc-Andre's too to save him the bother. Marked them "Closed" and "Duplicate" on SourceForge, so that if we reenable bug management there someday they won't confuse us.

[PP]

I don't want to be paranoid, but are we putting any important information into SourceForge that we are not backing up elsewhere? I mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust suit...) would we have backups of our patches, bugs, wish lists and so forth? I hope that's a criteria in deciding what services to move to SourceForge. I am in the business of preserving investments in data and of telling customers to avoid software that does not keep them in complete control of their data. SF makes me nervous that way....

Good point. SF has a way to get a nightly snapshot of the CVS tree. We should suggest that they provide snapshots (in XML of course!) of the bugs database too. Note that I have no bandwidth left to communicate to SF folks so this is up to the user community. (I'm also very optimistic and trusting in nature. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

greg wrote:

I think you are being paranoid :-)

Consider that this same issue applies to all 5900 projects and 38000 developers at SourceForge. VA Linux has a brand identity entirely built on the trust and support of the Linux (and Open Source) communities. If they blow away that trust, they are simply screwed.

on the other hand, lots of people thought that dejanews would store usenet postings forever... http://salon.com/tech/log/2000/06/20/deja/index.html </F>

greg wrote:

...

on the other hand, lots of people thought that dejanews would store usenet postings forever...

Different problem space. They weren't holding people's data.

well, they dropped a few thousand eff-bot postings ;-)

Worrying about it is a useless exercise, IMO.

well, I'm not worried. but in the internet universe, strange things happen all the time... (checked out http://www.fuckedcompany.com/ lately?) ... btw, has anyone checked what's in: http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz (with ping times somewhere around one second, it's too large for me to check out...) </F>

[MAL]

Will there be a list which gets the patches mailed to it by SF ?

I'm just asking because the current setup of having the patches available through mail really helps in discussing patch details.

I don't think this feature is part of the SF Patch Manager just yet. You could submit it as a request to the SF PM developers though -- apparently they're still working on it. --Guido van Rossum (home page: http://www.python.org/~guido/)

[Guido]

It's official: I've changed the patch submission guidelines (http://www.python.org/patches/) to point to the patch manager at SourceForge. We are no longer bound by CNRI's legal department, so the requirement for disclaimers or wet signatures is gone.

Yay! Wonder how long that will last <wink>. Attached is a first cut at documenting the intended use of SourceForge's patch status tags, and the workflow associated with patch status changes. The areas in need of fleshing out are marked with "[xxx ...]". Gripe at will. I don't think anyone expects this to work smoothly at first. Strive for patience, and let's work to make SF a really *good* place for patches! never-thought-i'd-actually-miss-lotus-notes-ly y'rs - tim PS: I'll move this (& related info) to a reasonable place eventually, so don't bother griping about email for now. Intended use of SourceForge patch status tags --------------------------------------------- revision 1 26-Jun-2000 Open The initial status of all patches. The patch is under consideration, but has not been reviewed yet. The status will normally change to Accepted or Rejected next. The person submitting the patch should (if they can) assign it to the person they most want to review it. Else the patch will be assigned via [xxx a list of expertise areas should be developed] Discussion of patches is carried out via [xxx Python-Dev? patches list? without a mail gateway, the SourceForge patch interface looks too clumsy to use for controversial patches] Accepted The powers that be have accepted the patch, but it has not been applied yet. [xxx flesh out -- Guido Bottleneck avoidable here?] The status will normally change to Closed next. The person changing the status to Accepted should, at the same time, assign the patch to whoever they believe is most likely to be able & willing to apply it (the submitter if possible). Closed The patch has been accepted and applied. The previous status was Accepted, or possibly Open if the submitter was Guido (or moral equivalent in some particular area of expertise). If possible, the submitter should apply the patch and change the status to Closed. Else anyone with sufficient power should feel encouraged to do these on the submitter's behalf. Rejected The patch has been reviewed and rejected. When the objections are addressed, the status may change to Open again. Note that SourceForge allows the submitter to overwrite the patch with a new version. Out of date Previous status was Open or Accepted or Postponed, but the patch no longer works. Please enter a comment when changing the status to "Out of date", to record the nature of the problem and the previous status. Postponed The previous status was Open or Accepted, but for some reason (e.g., pending release) the patch should not be reviewed or applied until further notice. The status will normally change to Open or Accepted next. Please enter a comment when changing the status to Postponed, to record the reason, the previous status, and the conditions under which the patch should revert to Open or Accepted. Deleted Bit bucket. Use only if it's OK for the patch and its SourceForge history to disappear. As of 26-June-2000, SF does not actually throw away Deleted patches, but that may change.

Trent Mick writes:

Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the person responsible for later taking to patch out of 'postponed' status.

Agreed; assignment should be changed whenever the next person required to deal with it changes. -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

Fredrik Lundh wrote:

someone really needs to fuse the patch manager with roundup (that we should use roundup for bug tracking goes without saying...)

How sweet! Why, thank you. :) Trent Mick wrote:

What are the chances of getting other meta data fields on patches, i.e. changes to the patch manager? Categorizing patches could really help as a filter. For instance, I may be a Unicode genius and would like to see the patches associated with it.

I agree that doing that kind of filtering is very useful. I have a discussion thingie (based on Roundup) at http://headspaces.com/. (Also prototype -- very prototype.) I hacked out the "status" and "fixer" fields and added a "keywords" field. Not much volume yet, but i think it will work well. Perhaps something like that for discussing patches? Jeremy Hylton wrote:

Maybe the right solution is to work with the SourceForge maintainers to make roundup part of the standard support software.

Hmmm... maybe i should look into that after i've figured out how super-Roundup is going to work. -- ?!ng