Patch management (was: Warnings in pythonrun.c)
On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote:
"TP" == Tim Peters <tim_one@email.msn.com> writes: TP> + This mailing list doesn't work. At least the SourceForge I agree that it's a complete mess, though.
While you're all admiring the difficulty of the problem, how about actually checking in the pythonrun.c patch, assuming it's reasonable? <flame> Frankly, I don't think the current mailing list is broken, *as long as patches are handled with reasonable speed* so that the backlog doesn't build up. That hasn't been done, and I don't understand why. Obviously the CNRI->BeOpen transaction resulted in some downtime for everyone, but now it's a month later and there's still stagnation. Why aren't incoming patches being handled now? It's not like there are very many patches per day; an hour or two should suffice to keep the queue from growing. At this point, the best fix is to do two things: 1) Someone downloads the mbox archives of the patches list, and goes through all the past patches: apply them, discard them, send them back for revision. 2) Commit to handling new patches that arrive, and either apply/discard/revise them. 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. </flame> -- A.M. Kuchling http://starship.python.net/crew/amk/ I couldn't think of one clever way to stop this guy, so I just trusted to mindless violence. -- Cliff Steele in DOOM PATROL #21
[Andrew M. Kuchling]
While you're all admiring the difficulty of the problem, how about actually checking in the pythonrun.c patch, assuming it's reasonable?
I can't yet. Be my guest!
<flame>
Frankly, I don't think the current mailing list is broken, *as long as patches are handled with reasonable speed* so that the backlog doesn't build up.
Andrew, this is saying that if it didn't display all the symptoms of illness, it wouldn't be sick. The consistent (this started long before Guido's honeymoon!) lack of timely action here *is* the brokenness.
That hasn't been done, and I don't understand why.
Why didn't you check in the pythonrun.c patch? Multiply by 10 people and 100 patches. There are no mechanisms in a mailing list for assigning, recording or checking responsibility, neither for recording or querying disposition status. Nobody owns any part of the problem now, and it's extraordinarly difficult to determine the status of any particular patch you may be interested in via this mish-mash of archived all-topic email scattered across patches and python-dev. Prior to this mailing list, Guido owned every problem and the database was in his head. I think it's the lack of the "owned" and "database" parts we're suffering from here, not especially the lack of the "Guido" part. SourceForge provides rudimentary mechanisms for both of the former; a Python replacement for Guido is one of BeOpen's highest secret priorities <wink>.
... 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>. the-only-one-working-on-the-move-is-me-and-i-haven't-done-a-checkin- yet-anyway-ly y'rs - tim
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/
On Fri, Jun 23, 2000 at 10:03:41AM +0200, M.-A. Lemburg wrote:
A gateway from the patch manager to the patches list would solve this nicely.
According to what was said to me, it's thought that mailing new patches to an e-mail address is supported, and therefore setting up a 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! 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. --amk
[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
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). 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. 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! --Guido van Rossum (home page: http://www.python.org/~guido/)
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/
M.-A. Lemburg writes:
Will there be a list which gets the patches mailed to it by SF ?
patches@python.org should get messages of patch manager activity (at least certain actions; not sure which ones yet, but at least additions).
I'm just asking because the current setup of having the patches available through mail really helps in discussing patch details.
Yes! I'd really hate to lose notifications! -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member
[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
Tim Peters writes:
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
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. -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member
[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
[Fred]
patches@python.org should get messages of patch manager activity (at least certain actions; not sure which ones yet, but at least additions).
[Tim]
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.
Yes, it's hidden, and Fred had to show me too. First, login to SourceForge. Then, go to the Python Project. In the left sidebar, under Project: Python, go to Project Admin. Near the top, you now see some navigation links; go to Edit Public Info. At the very bottom there are three text fields for email addresses. The address for New Patches (a misnomer -- it's really all changes made to the Patch Manager) says patches@python.org. 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? We're not using the Support manager yet. --Guido van Rossum (home page: http://www.python.org/~guido/)
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
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
OK, you're back! --Guido van Rossum (home page: http://www.python.org/~guido/)
[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
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.
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 --Guido van Rossum (home page: http://www.python.org/~guido/)
[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:
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.
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.... -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski
[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/)
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. That said: it would still be a good thing to have export capabilities. I recall that certain portions of the data (the Trove map?) can be exported in XML format. I don't recall the magic URL for that, however. Cheers, -g On Wed, Jun 28, 2000 at 10:16:45AM -0700, Paul Prescod wrote:
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....
-- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://www.python.org/mailman/listinfo/python-dev
-- Greg Stein, http://www.lyra.org/
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>
On Thu, Jun 29, 2000 at 07:51:32PM +0200, Fredrik Lundh wrote:
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...
Different problem space. They weren't holding people's data. If SourceForge were ever to close, then I have 100% faith that they would make sure to provide a way for everybody to get their data off the machines. Worrying about it is a useless exercise, IMO. Cheers, -g -- Greg Stein, http://www.lyra.org/
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>
"FL" == Fredrik Lundh <effbot@telia.com> writes:
FL> btw, has anyone checked what's in: FL> http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz I suck down nightly copies of that file and the corresponding Mailman tarball. I looked at them when I first set up my script, but haven't checked them lately. -Barry
[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/)
[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 agree -- SF isn't (yet) good for patch discussions. Plugging away, but haven't yet figured out exactly when or how SF decides to send email. In particular, don't yet know how (or whether it's possible) to trick current SF into populating a mailing list.
[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.
On Mon, Jun 26, 2000 at 02:41:12PM -0400, Tim Peters wrote:
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]
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.
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]
I like the separation of python-dev and patches, but it is not a biggie for me.
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.
Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the person responsible for later taking to patch out of 'postponed' status. Trent -- Trent Mick trentm@activestate.com
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
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.
Good idea. The PM clearly needs work. I see two places where you could submit feature requests: (1) the "Report SF Bug" item in the left side bar; (2) the "Feature Requests" discussion forum (http://sourceforge.net/forum/forum.php?forum_id=4&et=0)
I like the separation of python-dev and patches, but it is not a biggie for me.
For me it's just an annoyance, especially when cross-posting is used. --Guido van Rossum (home page: http://www.python.org/~guido/)
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
[Trent Mick Sent: Tuesday, June 27, 2000 1:17 PM]
What are the chances of getting other meta data fields on patches, i.e. changes to the patch manager?
A question for SourceForge.
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.
There's already a "Category" field on SF patches, but the main view doesn't show it (you have to look at an individual patch to see it) and there's apparently no way to filter on it either. Also think you have to be an admin to create a new category. I'll confess in advance, though, that I expect each additional field will just be one more field set incorrectly on the vast minority of patches.
... Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the person responsible for later taking to patch out of 'postponed' status.
Yes; thank you; I'll post a revision later today. The intent was always that "assigned to" be the most likely person to take action next.
participants (13)
-
Andrew Kuchling -
Andrew M. Kuchling
-
bwarsaw＠beopen.com -
Fred L. Drake, Jr. -
Fredrik Lundh -
Greg Stein -
Guido van Rossum -
Guido van Rossum -
Ka-Ping Yee -
M.-A. Lemburg -
Paul Prescod -
Tim Peters -
Trent Mick