I would like to commit a couple of new feature patches in the next couple of days for #9299 (if no one else does it) and #10534 (working on that). It appears to be somewhat customary to follow such patches with 3.1/2.7 blocks, but Georg implied in another message that the process is obsolete in that no one is doing blind mass merges anymore, and I apparently cannot do blocks with TortoiseSvn. So is it alright if I make the commits and simply note in the commit messages that they are for a new feature and should not be merged backwards?
-- Terry Jan Reedy
On Wed, 01 Dec 2010 14:53:21 -0500, Terry Reedy <tjreedy@udel.edu> wrote:
I would like to commit a couple of new feature patches in the next couple of days for #9299 (if no one else does it) and #10534 (working on that). It appears to be somewhat customary to follow such patches with 3.1/2.7 blocks, but Georg implied in another message that the process is obsolete in that no one is doing blind mass merges anymore, and I apparently cannot do blocks with TortoiseSvn. So is it alright if I make the commits and simply note in the commit messages that they are for a new feature and should not be merged backwards?
I think that's fine. I'm not even sure it is necessary to mention that it is a feature and won't be backported, though certainly that can't hurt, and should be done if there could be any doubt.
My understanding of the current status of svnmerge block is that you should use it if it helps you and not worry about it otherwise. Georg and I and some others find it useful for managing our own patches, but otherwise I think that it isn't being used.
If I'm wrong I'm sure Benjamin, as the release manager whom this would affect, will chime in :)
--David
On Wed, Dec 1, 2010 at 3:48 PM, R. David Murray <rdmurray@bitdance.com> wrote:
.. So is it alright if I make the commits and simply note in the commit messages that they are for a new feature and should not be merged backwards?
I think that's fine. I'm not even sure it is necessary to mention that it is a feature and won't be backported, though certainly that can't hurt, and should be done if there could be any doubt.
+1
If the changeset that you are committing has a associated tracker issue, make sure it is mentioned in the log message. It is conventional to start log messages with "Issue #NNNN:". On the tracker, make sure that the issue is properly classified as a feature requests and closed after the commit. If it is a bug fix and needs to be backported, the issue should stay open until the backports are done.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/12/10 21:48, R. David Murray wrote:
My understanding of the current status of svnmerge block is that you should use it if it helps you and not worry about it otherwise. Georg and I and some others find it useful for managing our own patches, but otherwise I think that it isn't being used.
Remember that after 12th December, with Mercurial becoming the primary version system, the dynamic will change a lot.
Still 12 days to go. I will be very happy :).
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBTPa8xplgi5GaxT1NAQIkywP/fbMjh0+uz315oIACzU1rifMm+bRZph9A GkhrRupKpNBGQiEeguABlyL3Mk9jy2S2AI3p+HP9GNNXeWUf1atLIIiTBP541sJs 5q5Uevhc3A/HFpW38UFlWdL3ZzMkBgUEtDZdTGnuIkb74rQNNPPeSdyy4pDJkeNB GCBVNR37wc4= =ZOh8 -----END PGP SIGNATURE-----
On Wed, 01 Dec 2010 22:23:18 +0100, Jesus Cea <jcea@jcea.es> wrote:
On 01/12/10 21:48, R. David Murray wrote:
My understanding of the current status of svnmerge block is that you should use it if it helps you and not worry about it otherwise. Georg and I and some others find it useful for managing our own patches, but otherwise I think that it isn't being used.
Remember that after 12th December, with Mercurial becoming the primary version system, the dynamic will change a lot.
Still 12 days to go. I will be very happy :).
Mercurial can't become the primary version system until after we've had a test-and-work-out-the-bugs period, so IMO that schedule is going to have to be modified.
--David
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/12/10 22:47, R. David Murray wrote:
Mercurial can't become the primary version system until after we've had a test-and-work-out-the-bugs period, so IMO that schedule is going to have to be modified.
After two years since Mercurial decision was done, let me daydream a bit :-).
And I do actually have confidence that the people on charge of this migration have set a realistic milestone.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBTPcPk5lgi5GaxT1NAQKD9wP9GNBlpKK8P6ZkB/s13+mL7Fy4HT55sSiB 2OusKxJFoHAFXLQT34cvmJUpBSXAxIQenm7pgfiK2nHuyf+HaU6hMZA6UbUYcxOb /p+5IEW23OXmWidNtPCgNXGSToyoyrDZnRBGL+Gs40W8qqOOO1D95GKmduoPnhe1 BafE70AppU0= =L/RF -----END PGP SIGNATURE-----
Am 02.12.2010 04:16, schrieb Jesus Cea:
On 01/12/10 22:47, R. David Murray wrote:
Mercurial can't become the primary version system until after we've had a test-and-work-out-the-bugs period, so IMO that schedule is going to have to be modified.
After two years since Mercurial decision was done, let me daydream a bit :-).
And I do actually have confidence that the people on charge of this migration have set a realistic milestone.
I don't. We still don't have a conversion result to inspect, so we can't possibly make the switch in 8 days from now.
More likely, the switch will happen next year.
Regards, Martin
Am 04.12.2010 15:01, schrieb "Martin v. Löwis":
Am 02.12.2010 04:16, schrieb Jesus Cea:
On 01/12/10 22:47, R. David Murray wrote:
Mercurial can't become the primary version system until after we've had a test-and-work-out-the-bugs period, so IMO that schedule is going to have to be modified.
After two years since Mercurial decision was done, let me daydream a bit :-).
And I do actually have confidence that the people on charge of this migration have set a realistic milestone.
I don't. We still don't have a conversion result to inspect, so we can't possibly make the switch in 8 days from now.
More likely, the switch will happen next year.
As sad as it is, that's true. It's just unfair to developers and infrastructure providers to switch on such a short notice without a testing period.
Georg
On Sat, Dec 4, 2010 at 16:25, Georg Brandl <g.brandl@gmx.net> wrote:
As sad as it is, that's true. It's just unfair to developers and infrastructure providers to switch on such a short notice without a testing period.
Yeah, I'm very sorry. The last step in the conversion has proven pretty annoying to get right. I need to separate release maintenance branches from feature branches, and it turns out that due to the way we use SVN, we also have a bunch of tag-related branches. I only found out about the last part recently, and it looks fairly consistent, and therefore hard to script.
Georg, I guess we should get together in IRC and see what makes sense for a new schedule? Do we wait until after the 3.2 release now, or just until after the holidays?
I'll keep on working on finding out what's happening with the tag branches.
Cheers,
Dirkjan
On Sun, Dec 5, 2010 at 8:18 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Dec 5, 2010, at 2:14 AM, Dirkjan Ochtman wrote:
Do we wait until after the 3.2 release now, or just until after the holidays?
+1 for waiting until after the 3.2 release. It is just around the corner.
It would be nice to have the structure of the build information consistent across the whole 3.2.x series though.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Am 05.12.2010 11:26, schrieb Nick Coghlan:
On Sun, Dec 5, 2010 at 8:18 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Dec 5, 2010, at 2:14 AM, Dirkjan Ochtman wrote:
Do we wait until after the 3.2 release now, or just until after the holidays?
+1 for waiting until after the 3.2 release. It is just around the corner.
It would be nice to have the structure of the build information consistent across the whole 3.2.x series though.
That, and I'd like to not have to make another maintenance branch in SVN for 3.2.
Georg
Am 05.12.2010 12:11, schrieb Georg Brandl:
Am 05.12.2010 11:26, schrieb Nick Coghlan:
On Sun, Dec 5, 2010 at 8:18 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Dec 5, 2010, at 2:14 AM, Dirkjan Ochtman wrote:
Do we wait until after the 3.2 release now, or just until after the holidays?
+1 for waiting until after the 3.2 release. It is just around the corner.
It would be nice to have the structure of the build information consistent across the whole 3.2.x series though.
That, and I'd like to not have to make another maintenance branch in SVN for 3.2.
Then I'd like to repeat my request not to switch to Mercurial just before the release candidate - have at least one beta release before the Mercurial switch.
Personally, I'd still like to defer beta1 until after the Mercurial switch (or alternatively, do the final 3.2 release from subversion as Raymond suggested).
Regards, Martin
Le dimanche 05 décembre 2010 à 20:00 +0100, "Martin v. Löwis" a écrit :
Am 05.12.2010 12:11, schrieb Georg Brandl:
Am 05.12.2010 11:26, schrieb Nick Coghlan:
On Sun, Dec 5, 2010 at 8:18 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Dec 5, 2010, at 2:14 AM, Dirkjan Ochtman wrote:
Do we wait until after the 3.2 release now, or just until after the holidays?
+1 for waiting until after the 3.2 release. It is just around the corner.
It would be nice to have the structure of the build information consistent across the whole 3.2.x series though.
That, and I'd like to not have to make another maintenance branch in SVN for 3.2.
Then I'd like to repeat my request not to switch to Mercurial just before the release candidate - have at least one beta release before the Mercurial switch.
Personally, I'd still like to defer beta1 until after the Mercurial switch (or alternatively, do the final 3.2 release from subversion as Raymond suggested).
What would these proposed delayings / deferments achieve?
-On [20101205 20:07], Antoine Pitrou (solipsis@pitrou.net) wrote:
What would these proposed delayings / deferments achieve?
Peace and quiet for the release team during the release.
Why confound the situation by forcing a migration of the VCS in the middle of release time? It's not like postponing a month will cause issues aside from waiting a bit longer for the migration. It makes even more sense given December's nature of social visits, partying and whatnot.
Again, maybe I am missing something, but what is the rush?
-- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Life is just one damned thing after another...
Personally, I'd still like to defer beta1 until after the Mercurial switch (or alternatively, do the final 3.2 release from subversion as Raymond suggested).
What would these proposed delayings / deferments achieve?
They will prevent the mess from happening that would happen if we switch to Mercurial in the middle of release candidates. I expect the initial release using Mercurial to just not work, plus I plan to need several days to make the release. Doing so under the time pressure of a release candidate is not something I look forward to.
Regards, Martin
On Mon, Dec 6, 2010 at 5:49 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Personally, I'd still like to defer beta1 until after the Mercurial switch (or alternatively, do the final 3.2 release from subversion as Raymond suggested).
What would these proposed delayings / deferments achieve?
They will prevent the mess from happening that would happen if we switch to Mercurial in the middle of release candidates. I expect the initial release using Mercurial to just not work, plus I plan to need several days to make the release. Doing so under the time pressure of a release candidate is not something I look forward to.
This.
However, I also sympathise with Georg's desire to have both the original release and subsequent maintenance releases all on Mercurial rather than being stuck with releasing from a Subversion branch, or else trying to switch between Subversion and Mercurial for the 3.2.1 maintenance release.
Given that we don't have any strict external deadlines, the solution that seems to make the most sense is to:
- Feature freeze now (which has happened with 3.2b1 going out the door the other day)
- Work on the Mercurial transition over the next few weeks and do 3.2b2 from Mercurial early in the new year.
- Do b3/rc1/rc2 based on the mutually convenient b2 release date that is worked out between Georg, Dirkjan, Martin and Ronald.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12/5/2010 8:49 PM, "Martin v. Löwis" wrote:
Personally, I'd still like to defer beta1 until after the Mercurial switch (or alternatively, do the final 3.2 release from subversion as Raymond suggested).
What would these proposed delayings / deferments achieve?
They will prevent the mess from happening that would happen if we switch to Mercurial in the middle of release candidates. I expect the initial release using Mercurial to just not work, plus I plan to need several days to make the release. Doing so under the time pressure of a release candidate is not something I look forward to.
+1
Let's not *ask* for trouble.
regards Steve
Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon 2011 Atlanta March 9-17 http://us.pycon.org/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/12/10 20:00, "Martin v. Löwis" wrote:
Personally, I'd still like to defer beta1 until after the Mercurial switch (or alternatively, do the final 3.2 release from subversion as Raymond suggested).
I would vote +1 to deferral of beta1 until mercurial migration. Anything pushing mercurial migration would be good. But Beta1 is already out...
Would be shameful to manage 3.2.x using svn...
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBTP4ZkJlgi5GaxT1NAQKzCAQAh0Pg/SSg7IPiNZZM8/g1tKr70b/w7r1n OS+9tE2LNXFnlI7s2jpk2RfZXcNsj8As/v3VBAm4nk6Km5TIBZbaPnCpfIhUSbXF KbZU1eN7IThRkWyEqnUO9ZF48ji23jobaoRnHXf6Ak3CTkAKpzMLSNZgn8OXgpFM ux6kTe8P6do= =949r -----END PGP SIGNATURE-----
Am 07.12.2010 12:25, schrieb Jesus Cea:
On 05/12/10 20:00, "Martin v. Löwis" wrote:
Personally, I'd still like to defer beta1 until after the Mercurial switch (or alternatively, do the final 3.2 release from subversion as Raymond suggested).
I would vote +1 to deferral of beta1 until mercurial migration. Anything pushing mercurial migration would be good. But Beta1 is already out...
Would be shameful to manage 3.2.x using svn...
Please read the updated schedule. It is a good compromise between the desire to have a speedy migration and the strain on the developers involved in the release. These are not just the release manager and the binary builders, but also all those developers who need to commit bug fixes, not all of whom might be comfortable with using a new VCS during the beta or RC phase.
Georg
Le 01/12/2010 21:48, R. David Murray a écrit :
My understanding of the current status of svnmerge block is that you should use it if it helps you and not worry about it otherwise. Georg and I and some others find it useful for managing our own patches, but otherwise I think that it isn't being used.
There’s something I wanted to ask: Are you using some script or shell function to list the revisions that *you* committed that haven’t been merged or blocked yet?
Regards
On Thu, 02 Dec 2010 02:19:25 +0100, <merwok@netwok.org> wrote:
Le 01/12/2010 21:48, R. David Murray a écrit :
My understanding of the current status of svnmerge block is that you should use it if it helps you and not worry about it otherwise. Georg and I and some others find it useful for managing our own patches, but otherwise I think that it isn't being used.
There’s something I wanted to ask: Are you using some script or shell function to list the revisions that *you* committed that haven’t been merged or blocked yet?
svnmerge avail --log provides an svn log like output for the revisions that haven't been blocked. I just pipe that to less and search for my committer id.
--David
Am 02.12.2010 04:08, schrieb R. David Murray:
On Thu, 02 Dec 2010 02:19:25 +0100, <merwok@netwok.org> wrote:
Le 01/12/2010 21:48, R. David Murray a écrit :
My understanding of the current status of svnmerge block is that you should use it if it helps you and not worry about it otherwise. Georg and I and some others find it useful for managing our own patches, but otherwise I think that it isn't being used.
There’s something I wanted to ask: Are you using some script or shell function to list the revisions that *you* committed that haven’t been merged or blocked yet?
svnmerge avail --log provides an svn log like output for the revisions that haven't been blocked. I just pipe that to less and search for my committer id.
BTW, it's very useful to give it a revision range with -rOLDESTREVISIONYOUDIDNTMERGE:HEADREVISION (it wants actual numbers for both). Speeds up the process tremendously.
Georg
Thanks for the tips David and Georg (and Michael for trying :) I knew about svnmerge avail, my question was about filtering).
Cheers
2010/12/1 Terry Reedy <tjreedy@udel.edu>:
I would like to commit a couple of new feature patches in the next couple of days for #9299 (if no one else does it) and #10534 (working on that). It appears to be somewhat customary to follow such patches with 3.1/2.7 blocks, but Georg implied in another message that the process is obsolete in that no one is doing blind mass merges anymore, and I apparently cannot do blocks with TortoiseSvn. So is it alright if I make the commits and simply note in the commit messages that they are for a new feature and should not be merged backwards?
Please only use svnmerge if it helps you. I just use it to backport things from py3k because it provides commit messages.
-- Regards, Benjamin
participants (14)
-
"Martin v. Löwis" -
Alexander Belopolsky -
Antoine Pitrou -
Benjamin Peterson -
Dirkjan Ochtman -
Georg Brandl -
Jeroen Ruigrok van der Werven -
Jesus Cea -
Nick Coghlan -
R. David Murray -
Raymond Hettinger -
Steve Holden -
Terry Reedy -
Éric Araujo