[IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release
bernie at codewiz.org
Sat Jan 24 00:39:08 EST 2009
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
> 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 <rjh at example.org>
Reviewed-by: Random J. Reader <rjr at example.org>
Tested-by: Random J. Tester <rjt at example.org>
Ack-by: Random J. Approver <rja at example.org>
Cc: Random J. Developer <rjd at example.org>
The semantics are described here:
>> - 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/
More information about the Devel