James Westby and I had some time together in Portland to talk about UDD stuff.
We talked about a few things: * Looms, their use today and where they should go * The operational issues with the package importer and how the bzr team can help * analysed a few specific bugs and tried to come up with solutions. Firstly though, a couple of overview points: - the udd project has 200 bugs on it. While many of these are 'collision' reports many are not. The collision reports are currently overly noisy, so please ignore them for now. However, the other bugs are open season for people to fix - and every bug fixed there will streamline things for people using bzr to package in Ubuntu. - Measurement error: the hottest 100 has a fairly high error rate for package imports at the moment, OTOH its looking at precisely the packages most likely to fail. James says that overall 96% or so of packages import successfully. - Adoption. I spoke with pitti and seb128 about how the desktop team uses bzr. Mostly they use packaging-only branches, which they prefer precisely because they don't need to download all the history. A quick test showed them getting 2M of data for gnome-panel, and 14M when using the package-imported branch. So we need to do some things here for people that do many drive-by fixes... - make downloading only some history easier/possible - make it possible to be using a mirror of the VCS data so it doesn't have to go over the network (perhaps the Ubuntu mirror network could carry the packaging branches?) - make bzr saturate the network more effectively (the 14M above didn't download at wire speed as far as we could tell). I haven't made these into bugs as yet, pending some feedback from you! Ok, onto the fun stuff. While long term we want a Launchpad control panel for the package importer, James thinks its reasonable that folk helping with the operation of it should be able to directly kick it off - so he has filed an RT ticket to get more access to that machine. James, whats the RT ticket number? Opening this up will let us rerun imports more promptly that appear to have had only spurious failures. Bugs with the importer can and should be debugged on peoples development environment - there is an earlier mail from December documenting how to do this. We should put that in the Wiki I think think. The collisions that are reported as bugs can be divided into three broad groups: - impossible (a collision in debian: at least at the moment, we don't expect people uploading to Debian packaging-branches. Well, *generally speaking* we don't expect this). (Nb: I do it for stuff I maintain in Debian :) - spurious (its not a collision, and a bug caused it) - genuine (it is a collision and it should be a merge proposal) We have a few collision specific tasks: - James is rapidly making new collisions be filed as merge proposals (unless they are in Debian imports) - we need to write a script to analyse the nearly 200 collisions in the bug tracker to highlight the debian imports (must be bugs, might be fixed), and convert the ubuntu ones to merge proposals. - We should delete the stale branches for collisions that we decide are bogus. Membership in the magic group ubuntu-branches is needed for that, and that group needs to be kept locked down (as it is equivalent to upload rights to the archive). So - lets make a list somewhere if you determine a branch isn't needed, and ping James or anyone on the tech board to delete such a branch). We looked at the workflow involved in packaging, and I'm very happy that James has seen the light and will be implementing an 'import-upstream' command to import and make a tarball micro-branch but not do the debian metadata updates. This will be useful for looms, where the two steps occur on different threads. Finally we looked at Looms with mathiaz who is hoping to get the MySQL packages in Looms for both Debian and Ubuntu. We identified some rough spots and a missing command (import-upstream) but it seems doable, if not /nice/ today. After that we talked about a sparser loom merge graph. The basic idea I have is that while the stack seems essential to providing a simple UI, all the merge commits make a lot of noise. So if we only do a merge commit when a conflict has happened, and otherwise depend on 'record' telling us what is incorporated, we can save a lot of commits and make 'log' or 'bzr viz' clearer, as well as making it simpler to cherrypick patches. There seem to be several related issues that tie into this: * Should the ready-to-build on-disk image with patch files be something stored in the loom, or something the loom models *and exports*. * Should someone editing a patch see a working tree with all the lower patches combined, or only their patch (and how does this tie into what gets committed - hairy logic incoming!) * How do people migrate into using Looms? I don't have good answers for all of these, but I'll try and write them up in more detail once I'm a bit more caught up on DX team needs. Another open issue is how looms might look in a colocated branch world: would they be N branches with a metadata structure glueing them together, or still an all-in-one structure? Specifically it would be nice for threads to *version and propogate* some key concepts like 'bzr pull from lp:myupstream or lp:my-redhat-patch-branch-import'. And Looms need merge implemented. KThanks :) Oh, and something we didn't discuss: V3 source packages magically delete upstream debian dirs:- can we avoid this with package importer merge-upstream etc (because some upstreams collaborate ;)). -Rob
signature.asc
Description: This is a digitally signed message part
-- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
