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/ [email protected] [email protected]
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
