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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel