Re: [Python-Dev] Goals for patch selection for 2.1.2
"Fred L. Drake, Jr." wrote Since the point of a strictly bug-fix release is to fix bugs, I would not tie the 2.1.2 release to 2.2 in any way. The 2.2 developments remain a cheap source of bug fixes, though, so anything that was an actual bug fix should be considered for 2.1.2. If an alternate fix is needed because the codebase changed too much (which may be very possible this time), a completely new patch may be needed.
I agree - there's also the possibility that there will be additional patches needed to fix a bug in code that's just not relevant for 2.2 (this is less likely), or an alternate fix might be needed that's not as thorough as one in 2.2 (where there's a large fix, a smaller workaround might be more appropriate for 2.1.2) -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
I agree - there's also the possibility that there will be additional patches needed to fix a bug in code that's just not relevant for 2.2 (this is less likely), or an alternate fix might be needed that's not as thorough as one in 2.2 (where there's a large fix, a smaller workaround might be more appropriate for 2.1.2)
Yup -- this was the case for the profile.py patch (which took a life of its own in 2.2 :-). --Guido van Rossum (home page: http://www.python.org/~guido/)
I agree - there's also the possibility that there will be additional patches needed to fix a bug in code that's just not relevant for 2.2 (this is less likely), or an alternate fix might be needed that's not as thorough as one in 2.2 (where there's a large fix, a smaller workaround might be more appropriate for 2.1.2)
Then I come back to my original question: What is your schedule for 2.1.2 then? I don't mind if it is either very tight or very lose, but I think there should be a schedule (which can be adjusted as needed). I think the following milestones should appear: - deadline for contributing new patches - deadline for selecting and integrating CVS mainline patches - release of a release candidate - release IMO, it isn't important that *all* patches that are desirable for 2.1.2 really get integrated by the second deadline. Instead, what gets done is done, everything else is for 2.1.3 (if there is interest in such a release). E.g. I wouldn't delay the release indefinitely just because somebody promised to indicate all, say, pyexpat patches, and never did. Regards, Martin P.S. Although I certainly do promise to indicate all pyexpat patches that should go into 2.1.2 :-)
Martin von Loewis wrote:
I think the following milestones should appear: - deadline for contributing new patches - deadline for selecting and integrating CVS mainline patches - release of a release candidate - release
I can't remember whether it was Tim or Guido, but it has been suggested that a true bugfix release shouldn't need a release candidate. Me, I'm always in favor of release candidates. [skip this next bit if you don't want an anecdote] (Back when I knew less about Unix than I do now, I was two weeks into a new job, dealing with a customer who was complaining about being unable to install the latest release of our software. I tracked it down to a syntax error in the install shell script -- proving that *NOBODY* from QA had bothered to do an actual test install with the released CD.) -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista We must not let the evil of a few trample the freedoms of the many.
"AM" == Aahz Maruch <aahz@rahul.net> writes:
AM> I can't remember whether it was Tim or Guido, but it has been AM> suggested that a true bugfix release shouldn't need a release AM> candidate. Me, I'm always in favor of release candidates. Possibly me, because I don't think release candidates on micro-releases are that important. If you royally screwed up 2.1.2 it should be low-cost to turnaround and do another 2.1.3 release very quickly. I'd rather opt for quick, low-overhead micro/patch releases. -Barry
[Aahz]
... (Back when I knew less about Unix than I do now, I was two weeks into a new job, dealing with a customer who was complaining about being unable to install the latest release of our software. I tracked it down to a syntax error in the install shell script -- proving that *NOBODY* from QA had bothered to do an actual test install with the released CD.)
In my Cray Research days, releases were shipped on magnetic tape. A day after one major release, customers started to report that the tapes they got were blank -- the tape unit write head was in fact utterly dead, but nobody had bothered to even trying reading the release media, let alone install from it. PythonLabs has also shipped damaged tarballs. The only thing we haven't done is ship an empty Windows installer <wink>.
On Mon, 2001-10-22 at 13:10, Tim Peters wrote:
[Aahz]
... (Back when I knew less about Unix than I do now, I was two weeks into a new job, dealing with a customer who was complaining about being unable to install the latest release of our software. I tracked it down to a syntax error in the install shell script -- proving that *NOBODY* from QA had bothered to do an actual test install with the released CD.)
In my Cray Research days, releases were shipped on magnetic tape. A day after one major release, customers started to report that the tapes they got were blank -- the tape unit write head was in fact utterly dead, but nobody had bothered to even trying reading the release media, let alone install from it.
PythonLabs has also shipped damaged tarballs. The only thing we haven't done is ship an empty Windows installer <wink>.
Myself, I'll never admit anything in public. --david
On Mon, 2001-10-22 at 13:56, Tim Peters wrote:
[David Ascher]
Myself, I'll never admit anything in public.
Of course, but we have to: it's the difference between working for an Open Source company and working for Microsoft <wink>.
Yowza! If I were working for Microsoft, I wouldn't be dealing with GTK+ issues these days =). --david
participants (7)
-
aahz＠rahul.net -
Anthony Baxter -
barry＠zope.com -
David Ascher -
Guido van Rossum -
Martin von Loewis -
Tim Peters