[buildd-tools-devel] Offer my help

[Wookey]

+++ Roger Leigh [2014-09-28 09:45 +0100]:
> 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

OK. that's exactly what I've been doing, so that's good.
 
> 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.

Yes - that's what I meant by 'upstream'. What exactly is the .orig a
tarball of, in relation to the various git branches?
If I do 'git-buildpackage' on master it says:
"upstream/0.64.3 is not a valid treeish"
which perhaps means I am using the wrong git-buildpackage runes (are
the right ones recorded somewhere?) or there should be some kind of
'upstream' branch (but I don't see any in git branch -va), or maybe 
that there is some tagging procedure required before trying a build?
 
> > 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.

OK. I talked at debconf and Phil Kern was happy for me to add the
multiarch-build changes to the version in use. It seemed best to do it
upstream first then branch that version, as you describe.

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

That would be nice, but let's ignore that for now :-) 

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

OK. That helps. Cheers. If you can just clarify the 'orig' and tagging
thing I reckon I should be able to push and upload what I have now (+
fixing Dima's odd commit messages) without making too much of a mess :-)

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/