[Pkg-parrot-devel] Packages files for Parrot 3.[03].0 imported in git

[Alessandro Ghedini]

On Tue, May 03, 2011 at 11:21:22AM +0200, Allison Randal wrote:
> 
> 
> On 04/30/2011 03:39 PM, Alessandro Ghedini wrote:
> >On Wed, Apr 27, 2011 at 02:18:56PM +0200, Dominique Dumont wrote:
> >>Le dimanche 24 avril 2011 22:29:31, Alessandro Ghedini a écrit :
> >>>git-import-dscs (note the final 's') imports all the versions of a package
> >>>but it does not preserve changelog messages, it only saves e.g.
> >>>"Imported Upstream version X.Y.Z" and "Imported Debian patch X.Y.Z".
> >>>
> >>>You can try this with:
> >>>
> >>>     $ git import-dscs --pristine-tar --debsnap parrot
> >>
> >>Thanks for the tip.
> >>
> >>I've used git-import-dscs --pristine-tar to import both parrot packages (3.0.0
> >>and 3.3.0)
> >
> >Given that Allison merged only some parts of the 3.3.0 changes we'll have
> >to redo the import (no need to rush, we can wait untill 3.3.0 gets uploaded)
> >maybe including also all the previous parrot versions. IMHO the cleanest
> >solution would be to re-start with a blank repository, so that unused
> >changes does not float around in the repository.
> >
> >We should also arrange some sort of policy on how to interact with the
> >repository (e.g. [0], [1] and [2]) in order to avoid future problems.
> 
> Aye, I figured we might restart a time or two on the git repo and
> processes. I'd like to draft our own workflow documents and put them
> up on the pkg-parrot alioth pages.
> 
> FYI, this is the current process for packaging Parrot, which we'll
> be migrating from to the new git-based process:
> 
> https://github.com/parrot/parrot/blob/master/docs/project/debian_packaging_guide.pod
> 
> My main thought at this point is that the 'master' branch in the
> pkg-parrot git repo should only be packages that were actually
> released (i.e. skip 3.0.0 because it was never released), and
> approved changes. So, proposed changes should always be made on
> branches, and then cherry-picked into the master.

The git workflow could look like:

1. Clone/pull the package git repository:

  $ gbp-clone --pristine-tar git+ssh://git.debian.org/git/pkg-parrot/pkg-parrot.git

If the repository already exists locally, just do:

  $ git pull

Create a sid chroot (to be done once) with pbuilder(8) [0]:

  # pbuilder --create --distribution sid

2. Upgrade to the latest upstream release:

  $ git import-orig --pristine-tar --uscan   # update repository
  $ dch -v X.Y.Z-1 -m 'New upstream release' # add new changelog entry
  $ git add debian/changelog && git commit   # commit the changelog
  $ git buildpackage --git-builder pdebuild  # try to build the new release
  $ git push --all                           # push the new release
  $ git push --tags                          # push the tags

This should always be done in the 'master' branch.

3. Do some changes in a separate branch:

  $ git checkout -b username/some_changes master  # create a new branch
  $ ...                                           # do some changes
  $ git add ... && git commit                     # commit the changes

The changes should not involve debian/changelog (it will be updated later),
and if a patch is added to debian/patches/ it should be committed unapplied 
(quilt pop -a) to ease the merge of the changes into 'master'.

4. Build the package:

  $ git buildpackage --git-debian-branch=username/some_changes \ 
                     --git-builder pdebuild    # build with pbuilder
  $ lintian -IE --pedantic ../parrot*.changes  # check with lintian

If everything went fine, push the changes:

  $ git push origin username/some_changes

And ask someone to review the changes and merge them.

5. Build and release the package:

  $ git dch --auto --release                    # finalize the changelog
  $ git add debian/changelog && git commit      # commit the changelog
  $ git buildpackage --git-builder pdebuild     # build with pbuilder
  $ lintian -IE --pedantic ../parrot*.changes   # check with lintian
  $ dupload ../parrot*.changes --to mentors     # upload the package


Another thing that I'm thinking about is the integration of the git 
repository with the mailing list, so that when someone makes a change to the
repository, it is aknowledged to the team via a mailing list (that's done 
with a git hook). The ideal setup would be to have a -commits mailing list
so that the -devel one is not "polluted". Of course there is no need to 
hurry, we can wait to do that when the development workflow will be fluid 
enough.

> We may also want to change the ports/debian directory in the Parrot
> github repository to a git submodule pointing to the alioth
> pkg-parrot master. That would guarantee that the two stay in sync
> (but may be more difficult for Parrot core developers making updates
> to the debian package files).

I do not think that's doable in a "sane" way. I mean, git-buildpackage(1)
keeps both upstream sources and debian/ stuff merged into master. If we are 
going to add a submodule to the upstream repo there will be duplicated 
sources, on / and on ports/debian/.

According to the git history of ports/debian/ [1], there have not been much
changes by upstream developers apart from you and few others, hence I think
we could just keep the debian stuff on git.d.o (maybe with a link from the
upstream docs) without affecting the upstream repository.

Just my 2¢ :)

Cheers

[0] http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html
[1] https://github.com/parrot/parrot/commits/master/ports/debian

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'