FAI stable release 3.4.x management

[Michael Prokop]

* Michael Tautschnig <mt at debian.org> [Tue Aug 17, 2010 at 01:00:53PM +0200]:

> > > 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?

> Well, not out of the box I think or rather: It will not produce meaningful
> changelog entries (but nobody will care about that anyhow, I guess). You can
> find the script in experimental/build-on-alioth, see the build_changelog()
> function. I'm absolutely fine with adapting that to make it work with git's
> format=email, if that is what you would prefer (and well, of course, you can
> just adapt it yourself if you want:-).

Ah ok, so it's just related to the patches in
branches/experimental/patches/? AFAICS those are feature-specific
patches and you're using the quilt header information of them. If so
this shouldn't be a problem at all:

What I'm suggesting is a workflow where my stable branch consists of
*existing* svn revisions and (usually) not the "please apply this
*patch*". It should be just a "mika, please cherry-pick from svn
revision(s) XX into the stable branch". This should give us a decent
commit history and nice tracking of changes as git-svn provides
commit messages including stuff like:

  git-svn-id: svn://svn.debian.org/svn/fai/trunk@5928 ba5ec265-b0fb-0310-8e1a-cf9e4c2b1591

As soon as you consider one of the patches from
branches/experimental/patches/ as "stable" the patch could be
applied to a branch in svn and I could then use the given svn
revision and its commit message for my stable branch and release. So
basically it's one commit per patch/feature in $WHATEVER_BRANCH (and
as a result in my stable branch as well).

All I do care about regarding the commit message then is the one
you're actually using when finally commiting your quilt patch in
$WHATEVER_BRANCH of svn. Like:

  ,---- [ svn info ]
  | mika at lunge ~svn/fai/branches/experimental (svn)-[fai:6046] % svn log patches/grub-pc | head
  | ------------------------------------------------------------------------
  | r5929 | mt | 2010-08-01 08:54:44 +0200 (Sun, 01 Aug 2010) | 2 lines
  |
  | dhcp-transition patch has been merged into trunk
  |
  | ------------------------------------------------------------------------
  | r5909 | mt | 2010-07-29 18:32:48 +0200 (Thu, 29 Jul 2010) | 3 lines
  |
  | Merged most of the setup-storage related patches (+device2grub_stable_names)
  | into trunk, updated further patches to match current trunk
  `----

Whereas I don't care about this quilt header information:

  ,---- [ quilt header ]
  | mika at lunge ~svn/fai/branches/experimental (svn)-[fai:6046] % quilt header grub-pc
  | 2010-04-28  Michael Tautschnig  [snip mailaddr]
  |
  |         * simple example: Added class GRUB_PC that installs and uses grub-pc instead
  |                 of grub, following the suggestions of Jean Spirat [snip mailaddr].
  |                 Thanks Waldemar Brodkorb [snip mailaddr] for more info and
  |                 debugging.
  |         * setup-storage/Fstab.pm: BOOT_DEVICE contains physical disks only; logical
  |                 volumes and RAID volumes are resolved to underlying disks.
  |         * setup-storage.8: Documented this new behavior
  |         * Makefile: Make sure that all example scripts are executable
  `----

The approach:

* use first line for the summary of the commit in the svn commit message
* more details about the commit/change/feature/patch starting in 3rd line
  of the commit message

allows a nice workflow using git svn with git cherry-pick and
providing the debian/changelog file using
"git-dch --id-length=7 --meta --multimaint-merge --since=$LAST_RELEASE".

In combination with atomic and clean patches and avoiding to touch
debian/changelog with single commits IMHO this provides a nice way
to do proper release management; both for my stable 3.4 as well as
Thomas' trunk/devel (4.x) version and without much PITA for neither
Thomas nor me. So even though our debian/changelog files won't and
can't be the same for our different releases we actually *can* and
wil be able to share the same patches/bugfixes and work on the same
svn repository quite easily this way.

Is this correct? Does it sound reasonable and would be fine for you?
Hopefully I didn't mix up anything WRT
merging/commiting/rebasing/.... Please correct me if I mixed up
something. :)

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/41109d4b/attachment.bin