[Aptitude-devel] hacking aptitude/release process

[Daniel Hartwig]

On 22 January 2012 23:12, Axel Beckert <abe at debian.org> wrote:
> Hi,
>
> Daniel Hartwig wrote:
>>  $ git checkout master
>>
>>  [hacking ...]
>>
>>  $ git tag NNN
>>  [produce ../aptitude_NNN.orig.tar.gz]
>>  $ git checkout debian
>>  $ git-import-orig ../aptitude_NNN.orig.tar.gz
>>  [update changelog for changes in master -- git-dch or similar]
>>  [update packaging files if needed]
>>  $ git-buildpackage --git-tag
>
> Hrm, I would have expected that git-import-orig automatically tags the
> upstream version and that git-buildpackage --git-tag is only necessary
> in the debian branch.

Correct.  My intent was to illustrate the 'git-buildpackage' is called
on the debian branch, although I am not 100% sure which branch
import-orig leaves checked out.  In any case, buildpackage only works
from the debian branch.

>
>> The merge and changelog updating can all be automated through the
>> git-buildpackage suite of tools.
> [...]
>> git-dch is an excellent tool for updating the changelog with all
>> changes since the last merge/git-import-orig, so keeping track
>> of this should not be a hassle.
>
> In my experience the changelog entry nevertheless needs some manual
> fine tuning after git-dch is run anyway.

Agreed -- manual tuning is a must, otherwise there will be quite a bit of fluff.


> I rather write the changelog
> manually (and commit it together with the changes).

Fine for changes to the debian packaging.

When changes are committed to master it becomes hairy, with
simultaneous commits on separate branches with different changesets
but similar description -- it becomes hard to see what is going on.
Which is why I will now save my changelog updates until after each
master->debian merge.

Of course, as you state later, this is not an issue for native packages...

> This brings up something about which I wondered already for quite a
> while: Why is aptitude not a native package. In that case these
> problems would just be gone.
>

I have wondered this myself.  I don't see any reason why it needs to
remain that way, though the current process does work.

There were some comments this month on debian-devel about why a native
package format might not be preferred... one of the points I recall is
that minor updates to non-native packages generate less activity in
the archives (because .orig.tar.gz stays the same).

> Or asked the other way round: If aptitude is a non-native package,
> then why do we need upstream changes in the Debian changelog?
>
> (Of course I think that major changes in aptitude itself should be
> mentioned in the debian/changelog, but for me, that's a sign that the
> package should rather be a native package.)

Yes, only major changes need be mentioned in debian/changelog.  The
details can always be retrieved from the git logs anyway.

>
>> The shortlog for the debian branch will also be more concise, with
>> full documentation in the changelog and on the master commit log.
>
> Hrm. Now I'm confused. I'd expected you talk about the
> debian/changelog all the time. But now it sounds like the upstream
> changelog.

By "shortlog for the debian branch" I mean the output of "git log" on
that branch.  Using the git-import-orig method, this is just a few
messages per release.

"changelog" is debian/changelog.

And "master commit log" is the output of "git log" on the master branch.

>
> Oh, and btw. I think the outcome of this thread, i.e. the preferred
> workflow should be added to at least the VCS, maybe as README.source
> or somewhere in the doc directory

Definately.


>> Production of the .orig.tar.gz is a bit hairy.  It contains files
>> which do not appear in a clean tree of branch master (generated by
>> autogen.sh):
...

I had started writing a response to this when ...

>
> Usually you use the upstream Makefile and a target called "dist" or
> so.
>

Voila!  There is such a target and it does precisely what one expects.
 Thanks :-)

It only need be updated for some new files and the google-mock
changes, not too hard to tackle.

Now I feel rather silly for not recalling this standard method
*before* spending the time comparing the tarball and git file trees!