FAI stable release 3.4.x management
Michael Prokop
mika at grml.org
Tue Aug 17 12:47:52 CEST 2010
* Michael Tautschnig <mt at debian.org> [Mon Aug 16, 2010 at 01:01:33PM +0200]:
> > if anyone wants to see patches included (which Thomas and me
> > consider for inclusion in Debian squeeze) or you notice that we
> > forgot anything in the 3.4.x release please let me know.
> > It would be great if you could provide your patches through the svn
> > in people/experimental or otherwise just mail them to me (I'll take
> > care of proper applying and forwarding to Thomas).
> I guess you meant branches/experimental!?
A right, sorry - I meant people _or_ branches/experimental.
As long as I can access it through a specific svn revision inside
the FAI svn repostiroy (using git-svn) it's fine for me. :)
> > Please make your patches atomic (so as small as possible and just
> > one feature per commit) and try to NOT touch debian/changelog when
> > commiting. Instead make the first line as meaningful as possible (it
> > is meant for inclusion in debian/changelog then) and write further
> > comments starting in the third line of the commit message, so Thomas
> > and me have better options for the 3.4.x vs. 4.x release management
> > handling.
> That proposal for patch-comment formatting clashes a bit with automated builds
> on alioth: The script on alioth expects the patch author's name in the first
> line and a detailed explanation to be given only afterwards (both of which go in
> the changelog); essentially this is standard GNU changelog format (cf. [1]). If
> you think we should change this, that's fine with me, please just let me know so
> I can update the build script and fix the existing patches.
Ah, thanks for bringing that up. You are absolutely right and I
wasn't specific enough. :)
What I meant with "make the first line as meaningful as possible"
was meant for just the *descriptional* part of the patch, sorry - my
fault.
The patch layout I'm suggesting should look like that:
http://git.grml.org/?p=grml-live.git;a=commitdiff_plain;h=47b72a3112de901274859c9608beededb37cc9dd
Is this what would work for the automated builds as well without the
need for any changes inside the script on alioth, right?
regards,
-mika-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.uni-koeln.de/pipermail/linux-fai-devel/attachments/20100817/1e98e224/attachment.bin
More information about the linux-fai-devel
mailing list