On Wed, Nov 13, 2013 at 04:19:19PM -0500, Barry Warsaw wrote:
> On Nov 13, 2013, at 03:43 PM, Stéphane Graber wrote:
> >Hmm, so if we can't planned changes to UDD branches and have to use a
> >separate user-owned branch for that, then what's the use of the UDD
> >It sounds to me like it'd then be much easier for me to just maintain my
> >own branch on the side and upload from there, ignoring UDD entirely,
> >which surely isn't what we want there.
> We're all familiar with workflows where landings to the master branch are
> guarded by robots like Jenkins or Tarmac. I think of this exactly the same
> way, with the 'bot being the importer.
Sure, except that for those projects, there's an incentive to push a MP
and wait for the bot to process it as otherwise the change won't land.
For UDD, if we can't commit to the branch, then there's zero benefit in
even using it as the source branch as I could just as well use apt-get
source, which will get me the current package from the archive (which
UDD doesn't necessarily give me...), then apply changes and push that.
Not having commit rights to the UDD branch would make UDD a simple
archiving service and based on its current state, a pretty bad one at
To clarifiy my position, I really like UDD and I think that kind of VCS
integration is what we want for the distro, but it's never been working
reliably enough to gain sufficient momentum.
In a perfect world, I'd have a VCS repository containing branches for
all Ubuntu series and pockets, for the various Debian releases and for
the upstream code, making any rebase/cherry-pick trivial and having LP
trigger builds on either a special signed commit or a signed tag.
Also in that perfect world, the inner workings of our upload process
would be tied to that, so that it wouldn't be possible for the branch to
be out of sync with the archive. This could be achieved by either making
this the only way to upload or making the "legacy" upload path, commit
to the branch and export from there prior to processing.