build-from-branch into the primary archive

[Dave Walker]

On 24/02/11 00:09, Colin Watson wrote:
> On Thu, Feb 17, 2011 at 03:03:08PM -0500, Barry Warsaw wrote:
>> On Feb 17, 2011, at 10:33 AM, Steve Langasek wrote:
>>>   How do we distinguish commits that ought to be built from those that
>>>   don't?  One way is to say we'll rebuild on things that add a new debian
>>>   changelog (with a higher version.) Some people commit changes with a
>>>   series target of 'unreleased' and we could then just actually assemble the
>>>   package when that flips to be a real series.
>>>
>>> Either there needs to be a separate adjunct branch that gets pushed to
>>> *from* lp:ubuntu/$package to trigger builds, or this needs to only build
>>> when a new version (previously unknown to the archive) has been tagged on
>>> the branch.  A lot of time has been spent on socializing the idea that we
>>> can use the existing lp:ubuntu branches to stage changes, and upload to the
>>> archive for building only when we're ready; to have some branches diverge
>> >from this behavior and start building for the archive for each commit, even
>>> if someone has nominated the branch in question for some sort of whitelist,
>>> would result in a number of wrongly published packages.
>>>
>>> I think the 'bzr mark-uploaded' interface, which sets the appropriate
>>> version tag, is the natural fit for this.
>> Observing my recent use, I think there are two things that together indicate
>> that a particular source branch revision is ready to be uploaded.  First, the
>> changelog entry's series is correct (i.e. natty, -proposed, etc.), *and* the
>> version number does not have a ~ in it.
> I'm with others on this who find tagging a more explicit and safer
> interface.  ~ in changelogs isn't going to be a sufficient heuristic:
>
>    $ grep-aptavail -FVersion \~ -nsPackage | wc -l
>    1386
>
> Even if you exclude cases where ~ is part of the upstream version (a
> common way to indicate a pre-release):
>
>    $ grep-aptavail -rFVersion '.*-.*\~' -nsPackage | wc -l
>    39
>
> ~ was introduced so that it could be used in real versions in the
> archive - it wasn't meant as just an unreleased marker.
>
> Cheers,
>
Yes, I've been following this convention where:

$UPSTREAM-VERSION~bzr$(bzr revno)-0ubuntu1
     == Upstream snapshot, before version is released.

$UPSTREAM-VERSION-0ubuntu1
     == Upstream released version.

$UPSTREAM-VERSION+bzr$(bzr revno)-0ubuntu1
   == Upstream released version, plus some some commits - but not yet 
near new upstream version.

For projects that maintain a 'fixes' branch for a released version:
's/+bzr/+fixes/'


On another note, might it be a good idea to add build-from-branch 
support initially as PPA functionality?  This enables people to trial it 
on /any/ package, identify goofs, make mistakes, try and break it, then 
give reasoned feedback without any concern of destabilizing the real 
archive.

Perhaps create a project called build-from-branch and use a convention 
of lp:build-from-branch/$LPID, where I could then propose a merge from 
lp:~davewalker/build-from-branch/$SOMETHING (or push directly), and 
every user which requests to trial it gets a PPA called their LPID under 
~build-from-branch-testers or similar.

It would be /nice/ if every bzr push to LP required the topmost commit 
to GPG signed or at least present who pushed a commit to a branch based 
on SSH key.  I find it somewhat odd that i can:
bzr branch lp:~someoneelse/+junk/their-scratching-area
bzr push lp:somewhere-serious

... and the result appears that ~someonelese pushed their rough code 
somewhere serious, which to the best of my knowledge cannot be linked to 
myself without someone grepping logs.  I feel the UI should at least 
present that it was me that pushed their commit somewhere.  This concern 
becomes more important when pushing bzr to archive becomes involved.

Kind Regards,
Dave Walker