build-from-branch into the primary archive

[Steve Langasek]

On Mon, Feb 21, 2011 at 04:17:50PM +1100, Martin Pool wrote:
> > 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.)

If DEBCHANGE_RELEASE_HEURISTIC=changelog were a default, I would find that
reasonable; but despite the fact that this has been best practice for years
when maintaining packages in any kind of multiple-committer VCS, it's /not/
the default, which means that plenty of people out there are going to be
generating merge requests that, with this proposal, would trigger autobuilds
when merged unless someone goes out of their way to explicitly reset the
changelog when merging.

For that matter, if DEBCHANGE_RELEASE_HEURISTIC=changelog were the default,
there would be an explicit "mark this ready for upload" step that typically
consists of 'dch -r && debcommit -r', which creates exactly the same tag as
'bzr mark-uploaded'.

Anyway, as James says, there's resistance to 'mark-uploaded' because it has
no clear benefit to the developer and only seems to benefit the branch
software.  If setting the tag were the way to mark the branch as
ready-for-build, I believe there would be much less friction - and that the
outcome would be far more satisfactory than having branches heuristically
detect that a package is "uploaded".

But maybe if it's ok to change the default behavior of dch in Ubuntu, then
this problem goes away because the differences in workflow go away?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20110221/af962de0/attachment.pgp>