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
