Re: [python-committers] Misc/NEWS entries added to released versions
On 13.09.2009 18:07, Gregory P. Smith wrote: On Sun, Sep 13, 2009 at 8:54 AM, Matthias Klose wrote: On 06.04.2009 00:33, Matthias Klose wrote: While looking at the diffs between the 261 release tags and the 26 branch, I noticed many items in Misc/NEWS appearing in the 2.6.1 or even 2.6 sections. I moved all of these to 2.6.2, after checking some of them, and found all of the checked ones be backported after the 2.6.1 release. Is there anything what could be done to avoid these wrong merges? I plan to check the items on the 3.0 branch soon. done again for the 2.6.3 (2.6 branch) and 3.1.2 (3.1 branch) entries. I didn't check if these were inserted to earlier entries by intent except for the removal of the entry for issue #2522. Matthias Thanks. One reason this happens is that our NEWS file is very difficult to navigate. svnmerge rarely works on it because the context is often different in the branch file but figuring out which version's section of the bazillion line file you are currently in is very tedious in a text editor. brainstorm: another idea: have a pre-commit hook, which rejects modifications to this file to entries for a released version, which can be overwritten by some keyword in the commit message. Matthias ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Adding a hidden field to BaseException going to break the ABI?
On Sun, Sep 13, 2009 at 13:30, Benjamin Peterson wrote: > 2009/9/13 Brett Cannon : >> issue6844 wants to stop a warning from being raised when someone >> accesses a 'message' attribute on an exception when it is set by the >> user (currently any usage of the 'message' attribute raises a >> warning). To do this properly is going to require some state flag on >> BaseException's struct. But I don't know if that constitutes breaking >> the ABI during a micro release or not. I figure no but I wanted to >> double-check. > > Is the BaseException struct public? Only in so far as PyExc_BaseException is documented for use with PyErr_*() and inheritance. -Brett ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Misc/NEWS entries added to released versions
Le dimanche 13 septembre 2009 à 13:27 -0700, Brett Cannon a écrit : > > Right, which is why only the first line would be used. All the other > usual detail can be there, just do it on another line. But if that line is longer than 80 characters, your $EDITOR may split it automatically and it'll break the generated NEWS. (either that, or you'll want to split it manually to make editing more comfortable) ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Adding a hidden field to BaseException going to break the ABI?
2009/9/13 Brett Cannon : > issue6844 wants to stop a warning from being raised when someone > accesses a 'message' attribute on an exception when it is set by the > user (currently any usage of the 'message' attribute raises a > warning). To do this properly is going to require some state flag on > BaseException's struct. But I don't know if that constitutes breaking > the ABI during a micro release or not. I figure no but I wanted to > double-check. Is the BaseException struct public? -- Regards, Benjamin ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Misc/NEWS entries added to released versions
On Sun, Sep 13, 2009 at 13:26, Antoine Pitrou wrote: > Le dimanche 13 septembre 2009 à 13:15 -0700, Brett Cannon a écrit : >> >> Or simply take the first line of each commit? I mean why do we enter >> it twice? If we have a commit that is unimportant we could come up >> with some convention to make it as such or simply have the comment >> start with a blank line. > > The NEWS file is often more carefully, or differently, worded than > commit messages are. Right, which is why only the first line would be used. All the other usual detail can be there, just do it on another line. > Trying to generate it automatically would probably involve some a > posteriori maintenance, and I doubt it's really worth it (at worse, you > save a copy / paste in the cases where the commit message is perfectly > adequate as a NEWS entry). I suspect we would have to start either at some golden revision or not until a release happens. -Brett ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
[python-committers] Adding a hidden field to BaseException going to break the ABI?
issue6844 wants to stop a warning from being raised when someone accesses a 'message' attribute on an exception when it is set by the user (currently any usage of the 'message' attribute raises a warning). To do this properly is going to require some state flag on BaseException's struct. But I don't know if that constitutes breaking the ABI during a micro release or not. I figure no but I wanted to double-check. -Brett ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Misc/NEWS entries added to released versions
On Sun, 13 Sep 2009 at 13:15, Brett Cannon wrote: On Sun, Sep 13, 2009 at 09:07, Gregory P. Smith wrote: Thanks. ??One reason this happens is that our NEWS file is very difficult to navigate. ??svnmerge rarely works on it because the context is often different in the branch file but figuring out which version's section of the bazillion line file you are currently in is very tedious in a text editor. brainstorm: It'd be nicer if we could generate the file from another source, perhaps keep each releases news in its own file and merge it all together at release time? Or have a NEWS.latest file that contains only updates since the previous release (part of making a release would be to prepend NEWS.latest to the NEWS file and truncate NEWS.latest)? Or simply take the first line of each commit? I mean why do we enter it twice? If we have a commit that is unimportant we could come up with some convention to make it as such or simply have the comment start with a blank line. I think it is often good to put more information into the commit message than should go into the NEWS entry. But having a way to mark up the NEWS entry inside the commit message might work. We'd need a volunteer to implement it, though :) --David___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Misc/NEWS entries added to released versions
Le dimanche 13 septembre 2009 à 13:15 -0700, Brett Cannon a écrit : > > Or simply take the first line of each commit? I mean why do we enter > it twice? If we have a commit that is unimportant we could come up > with some convention to make it as such or simply have the comment > start with a blank line. The NEWS file is often more carefully, or differently, worded than commit messages are. Trying to generate it automatically would probably involve some a posteriori maintenance, and I doubt it's really worth it (at worse, you save a copy / paste in the cases where the commit message is perfectly adequate as a NEWS entry). ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Misc/NEWS entries added to released versions
On Sun, Sep 13, 2009 at 09:07, Gregory P. Smith wrote: > On Sun, Sep 13, 2009 at 8:54 AM, Matthias Klose wrote: >> On 06.04.2009 00:33, Matthias Klose wrote: >>> >>> While looking at the diffs between the 261 release tags and the 26 branch, >>> I >>> noticed many items in Misc/NEWS appearing in the 2.6.1 or even 2.6 >>> sections. >>> I moved all of these to 2.6.2, after checking some of them, and found all >>> of the >>> checked ones be backported after the 2.6.1 release. Is there anything what >>> could >>> be done to avoid these wrong merges? >>> >>> I plan to check the items on the 3.0 branch soon. >> >> done again for the 2.6.3 (2.6 branch) and 3.1.2 (3.1 branch) entries. I >> didn't check if these were inserted to earlier entries by intent except for >> the removal of the entry for issue #2522. >> >> Matthias > > Thanks. One reason this happens is that our NEWS file is very > difficult to navigate. svnmerge rarely works on it because the > context is often different in the branch file but figuring out which > version's section of the bazillion line file you are currently in is > very tedious in a text editor. > > brainstorm: > > It'd be nicer if we could generate the file from another source, > perhaps keep each releases news in its own file and merge it all > together at release time? > > Or have a NEWS.latest file that contains only updates since the > previous release (part of making a release would be to prepend > NEWS.latest to the NEWS file and truncate NEWS.latest)? Or simply take the first line of each commit? I mean why do we enter it twice? If we have a commit that is unimportant we could come up with some convention to make it as such or simply have the comment start with a blank line. -Brett ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Misc/NEWS entries added to released versions
On Sun, Sep 13, 2009 at 8:54 AM, Matthias Klose wrote: > On 06.04.2009 00:33, Matthias Klose wrote: >> >> While looking at the diffs between the 261 release tags and the 26 branch, >> I >> noticed many items in Misc/NEWS appearing in the 2.6.1 or even 2.6 >> sections. >> I moved all of these to 2.6.2, after checking some of them, and found all >> of the >> checked ones be backported after the 2.6.1 release. Is there anything what >> could >> be done to avoid these wrong merges? >> >> I plan to check the items on the 3.0 branch soon. > > done again for the 2.6.3 (2.6 branch) and 3.1.2 (3.1 branch) entries. I > didn't check if these were inserted to earlier entries by intent except for > the removal of the entry for issue #2522. > > Matthias Thanks. One reason this happens is that our NEWS file is very difficult to navigate. svnmerge rarely works on it because the context is often different in the branch file but figuring out which version's section of the bazillion line file you are currently in is very tedious in a text editor. brainstorm: It'd be nicer if we could generate the file from another source, perhaps keep each releases news in its own file and merge it all together at release time? Or have a NEWS.latest file that contains only updates since the previous release (part of making a release would be to prepend NEWS.latest to the NEWS file and truncate NEWS.latest)? ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Misc/NEWS entries added to released versions
On 06.04.2009 00:33, Matthias Klose wrote: While looking at the diffs between the 261 release tags and the 26 branch, I noticed many items in Misc/NEWS appearing in the 2.6.1 or even 2.6 sections. I moved all of these to 2.6.2, after checking some of them, and found all of the checked ones be backported after the 2.6.1 release. Is there anything what could be done to avoid these wrong merges? I plan to check the items on the 3.0 branch soon. done again for the 2.6.3 (2.6 branch) and 3.1.2 (3.1 branch) entries. I didn't check if these were inserted to earlier entries by intent except for the removal of the entry for issue #2522. Matthias ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
