On Mar 13, 2010, at 07:11 PM, Georg Brandl wrote:

No need to file a new issue -- I've promoted 8111 to release blocker. I've added an explanation and a collective diff. No further RC is needed.

Thanks; I've accepted and closed the issue.

Sorry for directly committing this, but I felt it was within my disgression as Documentation Expert and just fair -- after all PEP 101 states you have to get my approval during the release process, which I didn't see for these RCs :)

This is true. :) I really appreciate the fix, and you're definitely right that it's your discretion to make these commits. I'm just being overly paranoid during rc2->final because I'm really hoping to avoid an rc3. For me, your bug report was perfect because it explained what and why you were doing it, and that you're confident an rc3 isn't needed. But I want to make sure that you're cool with the process, so let me know if you think I went too far.

-Barry

Am 14.03.2010 00:35, schrieb Georg Brandl:

Am 14.03.2010 00:08, schrieb Barry Warsaw:

...

On Mar 13, 2010, at 07:11 PM, Georg Brandl wrote:

...

No need to file a new issue -- I've promoted 8111 to release blocker. I've added an explanation and a collective diff. No further RC is needed.

Thanks; I've accepted and closed the issue.

...

Sorry for directly committing this, but I felt it was within my disgression as Documentation Expert and just fair -- after all PEP 101 states you have to get my approval during the release process, which I didn't see for these RCs :)

This is true. :) I really appreciate the fix, and you're definitely right that it's your discretion to make these commits. I'm just being overly paranoid during rc2->final because I'm really hoping to avoid an rc3. For me, your bug report was perfect because it explained what and why you were doing it, and that you're confident an rc3 isn't needed. But I want to make sure that you're cool with the process, so let me know if you think I went too far.

No, I don't -- I quite understand that you want to know what's going on in "your" branch so close to the final, and I should have known that. I'll be in the same position soon for 3.2. So, thanks for bringing it up.

Thinking of that a bit more: after the Hg transition, shouldn't we be able to really freeze a branch that is in pre-release approval-needed mode? It is trivial for anyone to commit a fix to their own branch, and then instead of pushing they'd have to notify the release manager to pull from them, as the only person who can push to the frozen branch.

Dirkjan, is that feasible?

Georg

-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

Am 14.03.2010 00:53, schrieb "Martin v. Löwis":

...

Thinking of that a bit more: after the Hg transition, shouldn't we be able to really freeze a branch that is in pre-release approval-needed mode? It is trivial for anyone to commit a fix to their own branch, and then instead of pushing they'd have to notify the release manager to pull from them, as the only person who can push to the frozen branch.

FWIW, it would be possible to freeze a branch also in subversion, today.

Yes, but I'm sure we don't want to bother setting that up so close to the switch :)

As for pulling from committer branches: that would require that committers host their branches somewhere.

Yes. But that's no big deal, isn't it? They can use a public hg hoster like bitbucket, or we can have a facility on hg.python.org -- it doesn't really matter where, it is always very easy to publish a hg branch.

Georg

-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Sun, Mar 14, 2010 at 00:40, Georg Brandl g.brandl@gmx.net wrote:

Thinking of that a bit more: after the Hg transition, shouldn't we be able to really freeze a branch that is in pre-release approval-needed mode?  It is trivial for anyone to commit a fix to their own branch, and then instead of pushing they'd have to notify the release manager to pull from them, as the only person who can push to the frozen branch.

Sure, that should be easy. We could also contemplate Mozilla's model here: they have a hook that disallows all commits, but you can override it by having a specific keyword in the commit message (so the guy who broke the build can push his fix whoever he is, and everyone else will know not to push).

Cheers,

Dirkjan