build-from-branch into the primary archive

[Martin Pool]

On 18 February 2011 05:33, Steve Langasek <steve.langasek at ubuntu.com> wrote:

>> We have a Launchpad Enhancement Proposal (LEP) about this at
>> <https://dev.launchpad.net/LEP/BuildFromBranchIntoPrimary>.  I'd
>> appreciate hearing of
>
>>  * any problems you can spot in this
>>  * any missing constraints or likely snags we ought to consider
>>  * anyone or any packages who'd like to be first to try it
>
> I see discussion in the LEP of how to determine when to build from the
> branch:
>
>  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.

Thanks for that.  Clearly we do need to have a way for people to stage
changes before getting them actually built.

It seems like 'mark-uploaded' is causing a certain amount of friction
at the moment: cases where it's not run and the branch therefore gets
out of sync with the upload, and also just that it's an additional
step that weighs people down.

>From some discussions, it seems like a promising way to trigger
building would be by the presence of a changelog entry that has an
incremented version number and that has a real target series.  (As
mentioned in the LEP point you quote.)

To me this has the advantage that the decision 'please publish this'
is visible in the diff etc in what seems like an obvious place for the
packaging workflow.  It's also something that can be easily be tweaked
by editing.  It also seems attractively minimal in that something
targeted at 'unreleased' or without a whole new changelog entry just
cannot be built, so we can pun that with _should_ not be built.

bzr mark-uploaded sets a bzr tag which is editable and transparent,
but probably not quite so much so as file content.

Are there are problems with doing this?