Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
Martin Langhoff wrote: On Sat, Jan 24, 2009 at 6:39 AM, Bernie Innocenti ber...@codewiz.org wrote: I meant it should have been optional, but if we switch to using the Closes: header in the body, where we have no size constraints, then we could has well use the prefix consistently. One important note WRT 'Closes'... Code hits git way earlier than it hits the package. So in most projects where I work, people will put in the commit msg a bugnumber, meaning that it's _related_ to that bug. To say it 'closes' the bug denotes a confidence I rarely have when working with the SCM. Well, it's customary to introduce an additional state where the bug is fixed in the developer's intentions, but not yet QA'd: NEW - ASSIGNED - FIXED - CLOSED However, I'm not advocating for this just yet. Turn our quality knob up too much while our codebase is still a little immature and needs to change rapidly might even be counter-productive (i.e. project takes longer to reach stability). What's interesting about a Closes: (or Fixes:) tag, is that it could be used to automatically close the bug in trac from the post commit hook, thus saving some precious time to our developers. Once it's tested, and everyone's happy, the new release gets packaged, and we can say - with more confidence - that it closes some bugs. For example I have done series of 100+ patches related to one bug. None of them closed it, but once the new (major) release was ready, the package changelog did say Closes: #123. What's good for packaging... is good for packaging! Right, but who prepares the package changelog? If we're going to come up with something like the detailed Changelog that GNU coding practices demand, it's a lot of burden for very little value. The humanized release notes that Simon prepares, with reference to important bugs and new features, is ideal. A simple query in trac should be enough to find out what bugs were fixed between 0.42.1 and 0.42.2 if we care to add and maintain a target milestone field. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Sat, Jan 24, 2009 at 10:42 AM, Bernie Innocenti ber...@codewiz.org wrote: Well, it's customary to introduce an additional state where the bug is fixed in the developer's intentions, but not yet QA'd: NEW - ASSIGNED - FIXED - CLOSED Bernie, 99% of my commits are working on it, mate ;-) It's not about turning the quality knob, is about claiming that I fix or close something way before I know whether this commit fixes it or not. To recap: writing the commit msg happens very early in the process. Claiming to fix or close a bug at that time is... preposterous. I'll normally have tested it on my machine, but will ask the bug reporter to confirm it works for them and ask him/her to close the bug if they are happy with the fix. The Debian workflow, specially Closes, is geared for the work of a _packager_, who is likely to be applying a well known and tested patch from upstream. So the packager can say with decent confidence Closes. A packager that merges in new code and puts closes immediately in the changelog is acting blinded by his own ego. Given the track record of Debian, that is unlikely to happen :-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
Jonas Smedegaard wrote: Use the recommended style as mentioned in Git documentation somewhere: First line a summary of at most 40 chars, then empty line, then optional detailed commit message (which is stripped by git-shortlog). Also, I'd suggest mentioning ticket numbers at end instead, in the style used by Debian. Example: Fix foobar - barbaz. Closes: SL#1234, OLPC#1235. The logic is to always prepend Closes: and then either SL# or # for each comma-separated ticket closed, or prepend OLPC# for tickets closed at the laptop.org bugtracker. Some thoughts: - Because the commit message summary appears in the shortlog, it should be kept below 74 characters to avoid ugly wrapping. - Given the above, the word Closes: steals precious characters, and is rather easy to deduce, therefore I'd opt it out. - The leading dot at the end should not be included because it looks super ugly in the subject of an email. - To reduce clutter, I'd make the SL prefix implied, and leave other prefixes such as OLPC#123 and RH#456 explicit. Do we have a wiki page where we can document these practices? -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
Marco Pesenti Gritti wrote: On Fri, Jan 23, 2009 at 10:45 AM, Bernie Innocenti ber...@codewiz.org wrote: Some thoughts: - Because the commit message summary appears in the shortlog, it should be kept below 74 characters to avoid ugly wrapping. - Given the above, the word Closes: steals precious characters, and is rather easy to deduce, therefore I'd opt it out. - The leading dot at the end should not be included because it looks super ugly in the subject of an email. - To reduce clutter, I'd make the SL prefix implied, and leave other prefixes such as OLPC#123 and RH#456 explicit. Do we have a wiki page where we can document these practices? Perhaps http://sugarlabs.org/go/DevelopmentTeam/Git Marco Thanks for all your comments. I have put up http://sugarlabs.org/go/DevelopmentTeam/Git#Git_commit_message_guidelines reflecting the discussion. Nothing set in stone yet, feel free to comment or change in the next days - otherwise it will become mandatory ;) Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jan 23, 2009 at 10:45:15AM +0100, Bernie Innocenti wrote: Jonas Smedegaard wrote: Use the recommended style as mentioned in Git documentation somewhere: First line a summary of at most 40 chars, then empty line, then optional detailed commit message (which is stripped by git-shortlog). Also, I'd suggest mentioning ticket numbers at end instead, in the style used by Debian. Example: Fix foobar - barbaz. Closes: SL#1234, OLPC#1235. The logic is to always prepend Closes: and then either SL# or # for each comma-separated ticket closed, or prepend OLPC# for tickets closed at the laptop.org bugtracker. Some thoughts: - Because the commit message summary appears in the shortlog, it should be kept below 74 characters to avoid ugly wrapping. Git prepends commit hashes, which is the reason for keeping it even shorter. I do not remember where I read it but am pretty sure their recommendation is to keep first line at most 40 chars. - Given the above, the word Closes: steals precious characters, and is rather easy to deduce, therefore I'd opt it out. It really makes better sense to me to not squeeze bug hints into that first line at all, but instead include them in a later line of the commit. Dropping the leading Closes: makes it harder to rely on for automated bug closing. You might not care about that, but I must say that I find that mechanism pretty cool on Debian. - To reduce clutter, I'd make the SL prefix implied, and leave other prefixes such as OLPC#123 and RH#456 explicit. You mean that you agree with my proposal of having SL _optional_ or you mean that it must never be there? Imagine a future fork of Sugarlabs. Let's call it Suguntu to hint at where I am going with this. Suguntu has their own bug tracking system, and some Sugarlabs developers gets hired to work on both systems in parallel. In the beginning Suguntu acts as downstram to Sugarlabs, but over time some parts of Sugar then gets primarily maintained at Suguntu so some changelog entries close Suguntu bugreports and not Sugarlabs ones. I'd say it makes sense to allow SL as a hint, but just have it be optional so that for packages only maintained upstream at Sugarlabs there is no need to add it to eah and eery bug hint. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl6DCsACgkQn7DbMsAkQLgoMQCfdkb5ic6AZh0qcgWwKW6uJscy rtgAmQFGsA8+aqVq/NARmOj1LrMd0dN0 =51oi -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
Jonas Smedegaard wrote: - Given the above, the word Closes: steals precious characters, and is rather easy to deduce, therefore I'd opt it out. It really makes better sense to me to not squeeze bug hints into that first line at all, but instead include them in a later line of the commit. Dropping the leading Closes: makes it harder to rely on for automated bug closing. You might not care about that, but I must say that I find that mechanism pretty cool on Debian. If the Closes: line is going to be part of the long description, then I totally agree we should use it. I'd even propose the adoption the other conventional headers used by the Linux kernel community: Signed-off-by: Random J. Hacker r...@example.org Reviewed-by: Random J. Reader r...@example.org Tested-by: Random J. Tester r...@example.org Ack-by: Random J. Approver r...@example.org Cc: Random J. Developer r...@example.org The semantics are described here: http://lxr.linux.no/linux+v2.6.28.1/Documentation/SubmittingPatches#L377 - To reduce clutter, I'd make the SL prefix implied, and leave other prefixes such as OLPC#123 and RH#456 explicit. You mean that you agree with my proposal of having SL _optional_ or you mean that it must never be there? Imagine a future fork of Sugarlabs. Let's call it Suguntu to hint at where I am going with this. Suguntu has their own bug tracking system, and some Sugarlabs developers gets hired to work on both systems in parallel. In the beginning Suguntu acts as downstram to Sugarlabs, but over time some parts of Sugar then gets primarily maintained at Suguntu so some changelog entries close Suguntu bugreports and not Sugarlabs ones. I'd say it makes sense to allow SL as a hint, but just have it be optional so that for packages only maintained upstream at Sugarlabs there is no need to add it to eah and eery bug hint. I meant it should have been optional, but if we switch to using the Closes: header in the body, where we have no size constraints, then we could has well use the prefix consistently. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Sat, Jan 24, 2009 at 6:39 AM, Bernie Innocenti ber...@codewiz.org wrote: I meant it should have been optional, but if we switch to using the Closes: header in the body, where we have no size constraints, then we could has well use the prefix consistently. One important note WRT 'Closes'... Code hits git way earlier than it hits the package. So in most projects where I work, people will put in the commit msg a bugnumber, meaning that it's _related_ to that bug. To say it 'closes' the bug denotes a confidence I rarely have when working with the SCM. Once it's tested, and everyone's happy, the new release gets packaged, and we can say - with more confidence - that it closes some bugs. For example I have done series of 100+ patches related to one bug. None of them closed it, but once the new (major) release was ready, the package changelog did say Closes: #123. What's good for packaging... is good for packaging! cheers, martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
Walter Bender wrote: Wow!! We have great release notes lately. To credit authors, I'd also append the patch summary by author, Linus-style. It can quickly be obtained this way: git log v0.83.3..HEAD | git-shortlog -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
Bernie Innocenti wrote: Walter Bender wrote: Wow!! We have great release notes lately. To credit authors, I'd also append the patch summary by author, Linus-style. It can quickly be obtained this way: git log v0.83.3..HEAD | git-shortlog Excellent, will do that for the next release. So the command for sugar for this release would be (no-merges to get rid of the messages when you merge the master tree Merge branch 'master' of gitori...@git.sugarlabs.org:sugar/mainline): git log v0.83.4..v0.83.5 --no-merges | git-shortlog That will encourage people to write nice commit messages :) I would suggest to put up some guidelines (no rules), so a reader can more easily parse them. For example: - ticket number always at the beginning of the commit message - Start message with a capital letter - For typo fixes use: _Typo - For pylint fixes use: _Pylint More thoughts? Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jan 22, 2009 at 09:54:36AM +0100, Simon Schampijer wrote: So the command for sugar for this release would be [...]: git log v0.83.4..v0.83.5 --no-merges | git-shortlog That will encourage people to write nice commit messages :) I would suggest to put up some guidelines (no rules), so a reader can more easily parse them. For example: - ticket number always at the beginning of the commit message - Start message with a capital letter - For typo fixes use: _Typo - For pylint fixes use: _Pylint Use the recommended style as mentioned in Git documentation somewhere: First line a summary of at most 40 chars, then empty line, then optional detailed commit message (which is stripped by git-shortlog). Also, I'd suggest mentioning ticket numbers at end instead, in the style used by Debian. Example: Fix foobar - barbaz. Closes: SL#1234, OLPC#1235. The logic is to always prepend Closes: and then either SL# or # for each comma-separated ticket closed, or prepend OLPC# for tickets closed at the laptop.org bugtracker. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl4irQACgkQn7DbMsAkQLgCDQCbBObD5vCNDLrGX3HNLNK1RvFg vokAniZd0hz/KXxZ2JhUf1Fr8s6me++e =4VCG -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
