I think this could be a great feature. It might also allow us to have a more fine-grained control over who can upload/push new packages, although I agree with others that we have to think carefully about how those permissions are expressed.
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. For example, I'm right now working on some computer-janitor fixes. It's trunk actually *is* the source branch. When I merged in pitti's and lool's merge proposals, I change the version number to `whatever~ppa0` first for local testing, then for dput upload to my PPA. Once I'm done with testing, I remove the ~ppa suffix, do a final commit and push, then `bzr bd -S` and dput the results to the real archive. So I think 1) a valid series; and 2) a non-~ version number are enough to indicate (for me) that the tip is ready to be built and uploaded. -Barry
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
