On Wed, Nov 13, 2013 at 03:32:38PM -0500, Barry Warsaw wrote:
> On Nov 13, 2013, at 11:32 AM, Steve Langasek wrote:
> >But I think it would be more interesting to get a permanent fix for this
> >bug:
> > https://bugs.launchpad.net/udd/+bug/714622
> >This accounts for the problem people have mentioned, that core packages are
> >much more likely to have failed imports. The importer badly needs fixed to
> >not throw up its hands when the revision ID of a tag has changed; it should
> >only care about this when the branch contents are wrong.
> >This single bug accounts for just under half of all importer failures, and
> >is a failure scenario that the importer *could*, with sufficient smarts,
> >resolve automatically.
> This may be controversial, but (except for trying to fix error
> conditions), I think we should disallow all developer pushes to UDD
> branches and only let the importer write to them. It's simply too error
> prone otherwise, and there's no good reason for it.
I disagree 100%. To me, this is the only reason to *have* UDD branches. If
we're never going to push to the branches, then the whole thing is a futile
exercise. Being able to use bzr blame / bzr diff to traverse history at
per-upload granularity is not sufficiently interesting to justify the effort
of supporting UDD.
As long as there are other VCS branches for core packages that are richer
and more authoritative with finer-grained history, UDD branches will
continue to be confusingly redundant. If we've resigned ourselves to the
notion that they will never be a suitable replacement for maintainer
branches, then we should kill UDD off entirely instead of continuing to
invest time and hardware resources in giving developers a poor VCS
experience that requires you to play a game of 20 questions to figure out
the "right" place to get the package's source.
> One possible reason for developers to push to UDD branches is to share the
> code with other people, or to avoid the lag in importer runs.
The reason for pushing to the UDD branches is so that changes to the package
are grouped logically, and you can use the branch history as a useful
forensic tool, or as a source for cherry-picking changes. Having UDD
branches that exist but are *not* an authoritative source for this
information is actively harmful. At the time UDD was conceived. this was
considered an acceptable temporary downside on the path to a full
branch-based workflow. Now that it's clear that having imports of full
upstream history into UDD is not on the horizon, we should work out what to
do to avoid continuing to provide UDD as a bad service.
> Of course the former can be easily handled by pushing to a personal
> branch. The latter? Oh well, I can live with that for error-free
> branches. ;)
This error is not with the branches, but with the importer for imposing
unnecessary constraints on the branches. In nearly all of the cases where
that bug hits us, the branch *contents* are identical to what the importer
would have generated, which means the importer should accept the ID change
and move on. In cases where the contents don't match, the importer should
win and move the branch aside - in fact, it's supposed to already do this.
But if we no longer have anyone who can fix this importer problem, then we
should admit defeat and scrap UDD altogether.
> A long time ago I decided never to push UDD branches and always let the
> importer update them. I've never regretted that or encountered problems
> with that discipline.
That works ok for packages that are only touched once in a blue moon. But
making this a policy means that UDD is no longer useful for core packages
like upstart, and all our rich branch history is going to go somewhere else.
This doesn't solve the problem that people are actually complaining about,
namely that UDD branches are not useful for packages that are actively
maintained - it merely codifies it, and exacerbates the related problem that
UDD branches only sometimes provide a useful workflow for outside
contributors.
--
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@ubuntu.com vorlon@debian.org
