[IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release

Bernie Innocenti bernie at codewiz.org
Sat Jan 24 04:42:39 EST 2009


Martin Langhoff wrote:
> On Sat, Jan 24, 2009 at 6:39 AM, Bernie Innocenti <bernie at 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/


More information about the IAEP mailing list