On Mon, 21 Feb 2011 16:17:50 +1100, Martin Pool <m...@canonical.com> wrote: > 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.
Right, because it does not have a visible effect now. If it were to trigger a build (and given a different name) then I don't think it would be seen as extra weight. > 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? The only concern I have is that this would be changing the security model of the archive to some extent. Instead of GPG signed instructions to publish, we would have somewhat implicit SSH-key signed, or cookie/oauth signed (in the case of a "Land it!" button on merge proposals.) I don't know whether that is a change we want to make. If it isn't then we either need to use GPG with bzr in some arrangement, or have an out-of-band GPG signed instruction to build. Thanks, James -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
