[buildd-tools-devel] Offer my help

[Roger Leigh]

On Thu, Sep 25, 2014 at 10:10:30PM +0100, Wookey wrote:
> +++ Benjamin Drung [2014-09-25 16:50 +0200]:
> > Hi,
> > 
> > due to some bugs (#700522, #714883, #756265), I like to offer my help to
> > maintain sbuild. Do you have any rules for committing to the git
> > repository and for doing releases?
> 
> I'd like some advice on procedure too.

I'll add notes on how to make a release to git, i.e. what to tag,
test and run to make the release tarball.  It's not too involved,
but it probably needs writing down.

There aren't currently any rules on committing other than generally
being sensible.  There's a rough coding and commit message style,
which isn't specified but is basically, copy what's in use.  We can
change that if there's a need for something more clearly defined.

> I've made local topic branches for the 3 issues I am working on right
> now, as discussed in other mails
>  hook-command changes
>  multiarch-builds
>  build-profiles
> 
> I've gone back and forth tidying and testing those until happy then
> made neat one-patch-per-topic merges into master and am testing that
> now. (Actually just first two for now as 3rd not suitable for backporting).
> 
> Should I be pushing topic branches upstream _before_ merging to
> master? (Or maybe do this for major work, but not minor fixes?) Should
> I in fact be merging to upstream/<version> rather than master. I'm not
> sure what 'upstream' means for sbuild as it's a debian-only package.

I'm not sure what you mean by "upstream" here.  Is this a git remote
name, or something different?  For me it's called "origin" and I would
conceptually do this to merge a branch:

git fetch origin
git checkout master
git reset --hard origin/master
git merge $mytopicbranch
git push origin master

WRT the package being "Debian-only" it's actually using proper
upstream versioning so we have a regular .orig. and .diff.gz like
for any other package.  Not sure if that's related, just not
entirely clear on the specific question.

> Is the procedure different for the special buildd-team version?

They are both just regular git branches if I understand the question.
I'd generally avoid making any changes on the buildd branches unless
you branch a new one from a new release and cherry-pick all the
changes off the previous buildd branch.  But that might also be
best left to the buildd maintainers.

> Do we have any rules about what constitutes a major or minor
> version-number bump?

Not really, that could also be better defined.  The minor has been
increased when significant changes/new features were made, but what
was considered such was also not entirely defined either.  Ideally
it wouldn't have a useless "0." major either.  I was hoping we might
have a 1.0 at some point once it was sufficiently cleaned up, but
since it's Perl that is looking like an unattainable goal!

> Or maybe there is a shortage of hard-and-fast rules and 'don't make a
> mess' is sufficient guidance :-)

I think that's pretty much the status quo at present!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800