Re: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Nov 13, 2013, at 10:48 PM, Stéphane Graber wrote: I push those commits to the main branch (ubuntu:package) as I go. It's true that the head of the branch doesn't reflect the source package, however the latest tag does, so that's not a real concern. What I like is that when I have a few simple changes or fixes that don't seem to warrant an upload on their own either because of a very long build time or because I know someone else is going to merge the package from Debian in the next few days, I can just commit stuff in there, add an UNRELEASED changelog entry and let whoever does the next major change, just pick up my changes at the same time. That also means people don't need to go looking for MP before uploading something as the change is already right there in the branch, all they need to do is to add theirs and upload. I've noticed that I'm not the only one doing that, I know that at least Steve is doing something similar with some packages ;) Thanks for the workflow explanation - this is really interesting. It seems to me like you're using the UDD branches in a very similar way as say Debian Python uses its svn branches, as the primary location to make incremental packaging changes in preparation for upload. I.e. it's your main location for doing package development. I think I better understand yours, Steve's, and others objections to my suggestion. It's not how I think of the UDD branches but I'll retract my suggestion because I wouldn't want to prohibit your workflows. But this *is* getting off-topic from the original request, which is: how can we empower developers to fix their own broken UDD branches? Let's leave the future of UDD, and the reality of the given resources to improve the situation and get closer to our dream world, for another day. -Barry signature.asc Description: PGP signature -- 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
Re: Patch Pilot Report bzr workflow used.
On Jan 16, 2013, at 12:58 AM, Dmitrijs Ledkovs wrote: I did quite a few bzr merge proposals. The workflow I used was this: bzr branch lp:~logan/ubuntu/raring/rbbr/0.6.0-6 cd 0.6.0-6 bzr bd -S sbuild ../build-area/*.dsc bzr diff -rtag:last-ubuntu | filterdiff -x .pc* bzr diff -rtag:last-debian | filterdiff -x .pc* debsign ../build-area/*_source.changes dput ../build-area/*_source.changes bzr mark-uploaded bzr push lp:ubuntu/rbbr Good tips. Could you add them to https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews One thing I'd like to encourage is for folks to edit this page as they are doing their piloting, so that over time it gathers other good tips and tricks and becomes generally more helpful about best practices. Cheers, -Barry signature.asc Description: PGP signature -- 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
Re: Fixing import errors and discouraging pushes
On Dec 03, 2012, at 09:56 PM, Steve Langasek wrote: On Mon, Dec 03, 2012 at 06:14:19PM -0500, Barry Warsaw wrote: On Mon, Dec 03, 2012 at 04:07:47PM -0500, Barry Warsaw wrote: I think we should (almost) never allow users to push to ubuntu: or debianlp: branches, or at least, highly discourage it. Just do the upload and let the importer create the new revisions and it seems like that avoids a lot of headaches and failures. If we're not going to allow pushing to the branches, then I don't think they're useful at all. It's *only* for having rich branch history that I use these branches, and if they're not going to be usable that way I would discontinue my use of them altogether, moving the packages I maintain somewhere else for their primary VCS. That's interesting, because I think source branches have a lot of benefit over apt-get source by themselves. They do, but those aren't actually the options I'm picking between. I'm picking between being able to use lp:ubuntu/$package as the VCS for the packages I maintain, and having to maintain the VCS elsewhere. Gotcha, yes in those cases, I definitely agree with you! I was thinking about purely packaging branches which don't also serve as upstream. Cheers, -Barry signature.asc Description: PGP signature -- 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
Fixing import errors and discouraging pushes
pykde4 is currently failing: http://package-import.ubuntu.com/status/pykde4.html#2012-11-22 08:40:00.891722 I'd like to learn how to fix this in such a way that I can add some suggestions to https://wiki.ubuntu.com/DistributedDevelopment/UnderTheHood/Importer/CommonFailures This way, folks can fix problems for packages they care about. What I did: $ bzr branch ubuntu:pykd4 raring # This results in an out-of-date branch $ bzr branch raring fiximport $ chdist apt-get raring source pykde4 $ cd fiximport $ bzr import-dsc ../pykde4_4.9.80-0ubuntu2.dsc Now, is this enough to bzr push the fiximport branch to ubuntu:pykd4 and will that fix the importer for subsequent runs? Is there anything else I need to do to the branch first? Do I need to `push --overwrite`? Is this much harder than it seems? I think we should (almost) never allow users to push to ubuntu: or debianlp: branches, or at least, highly discourage it. Just do the upload and let the importer create the new revisions and it seems like that avoids a lot of headaches and failures. I'm not sure if there's anything more we can do except to document this properly in the Ubuntu Developer Guide. Cheers, -Barry signature.asc Description: PGP signature -- 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
Re: Fixing import errors and discouraging pushes
On Dec 03, 2012, at 03:04 PM, Steve Langasek wrote: On Mon, Dec 03, 2012 at 04:07:47PM -0500, Barry Warsaw wrote: I think we should (almost) never allow users to push to ubuntu: or debianlp: branches, or at least, highly discourage it. Just do the upload and let the importer create the new revisions and it seems like that avoids a lot of headaches and failures. If we're not going to allow pushing to the branches, then I don't think they're useful at all. It's *only* for having rich branch history that I use these branches, and if they're not going to be usable that way I would discontinue my use of them altogether, moving the packages I maintain somewhere else for their primary VCS. That's interesting, because I think source branches have a lot of benefit over apt-get source by themselves. For example, I like branching ubuntu:foo in a local shared repo, then doing further branches for various bug fixes or other development. Letting the package importer update the branch seems akin to rebasing on the current source branch once you've done the upload. -Barry signature.asc Description: PGP signature -- 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
Re: Upgrading pristine-xz on jubany
On Jun 13, 2012, at 05:25 PM, Dmitrijs Ledkovs wrote: I heavily rely on package-import. It's no longer 'a demo' but really the only way I develop for ubuntu or debian (to have a nice debdiff). Here, here. -Barry -- 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
Repairing a broken package import
Today I wanted to work on the apport packaging branch, but the importer has been failing on this package: http://package-import.ubuntu.com/status/apport.html#2012-01-26 06:59:16.573850 I took a look at bug 494481, which is referenced by the importer failure package, but I didn't see anything that exactly matched the traceback. Still, on the theory that I probably can't break this package any worse than it already is, I did the following: bzr tag -r martin.p...@canonical.com-20100624133714-tp43iqk10jzt7ftp \ upstream-1.14.1 -d :parent Two questions: - Did I do the right thing to fix this particular crash? - Do I need to do anything else explicitly to get this package to start importing again (i.e. requeue the package)? We've talked about adding some remediation hints to the wiki page but have yet to do so. As a result of this thread, I'll write something up for https://wiki.ubuntu.com/DistributedDevelopment Cheers, -Barry signature.asc Description: PGP signature -- 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
Switching over to Quantal
Now that Quantal is open for development, what do we need to do to get things
switched over, and UDD all happy-like?
$ bzr branch ubuntu:precise/debootstrap precise
bzr: ERROR: Revision
{package-imp...@ubuntu.com-2021132053-gkdptiozkkmpd7p4} not present in
Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)],
[].
$ bzr branch ubuntu:debootstrap precise
Most recent Ubuntu version: 1.0.40
Packaging branch version: 1.0.38
Packaging branch status: OUT-OF-DATE
-Barry
signature.asc
Description: PGP signature
--
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
Re: UDD importer making a nuisance of itself with v3 source format branches
On Apr 13, 2012, at 01:13 AM, Max Bowsher wrote: I've just had a conversation with cjwatson and slangasek on #ubuntu-release about the importer making a nuisance of itself by declaring a perfectly reasonable commit to be a collision / difference, and replacing it with one of its own. The key pain point here is the .pc/ directory. The sad fact is that for a while now, I've simply stopped pushing to the ubuntu: branch when I add quilt patches. I just don't trust myself to get it right (if it's even possible ;). I'll always upload the new package and let the importer deal with the fallout. The .pc/ directory is a constant source of pain when using UDD+quilt. Some things did get better last cycle, but I think a lot more needs to be done to make this really smooth and usable for UDD+quilt. Cheers, -Barry signature.asc Description: PGP signature -- 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
UDD breakdown when building orig.tar.gz from upstream VCS
I just want to put this out there for the historical record. I think this is a rare enough use case that UDD doesn't need to address, certainly not any time soon, if ever. OTOH, maybe there's an easy workaround. I was working on an NBS for the fgfs-atlas package (LP: #903225). The solution was straightforward enough: upstream had all the necessary fixes in their CVS repository, but hadn't done a release in a long time. I twiddled the packaging to build an orig.tar.gz from CVS, and the googlez helped find some good general packaging information on how to do this. Unfortunately, UDD is essentially useless here. The problem is that after creating the tarball from CVS, `bzr bd -S` can't be used because dpkg-source will complain too much about deltas between the tarball and the source tree. It'll warn about a lot of stuff, but then fail with some unrepresentable changes to source. I worked around this by unpacking the new orig.tar.gz and `cp -a` the debian/ directory from the precise version of the package (with my changes) over into the unpacked tarball. After a few rounds of tweaking, and using `debuild -S -sa`, I had a debian/ that built locally, so I uploaded it and will let the importer (hopefully) sort out the mess. I still did all my changes to debian/ in a source branch though, because that made it easier to get a diff for the linked Debian bug. Is there's a magical udd switch or config setting that would have helped me keep all the changes in the source branch? It seems like this is somewhat similar to the merge-upstream issue when upstream has a rather large released tarball delta. Cheers, -Barry signature.asc Description: PGP signature -- 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
Re: UDD breakdown when building orig.tar.gz from upstream VCS
On Feb 15, 2012, at 04:35 PM, Jelmer Vernooij wrote: bzr merge-upstream should help here. You can pass it a tarball and a version. Of course, these will have to be different than the previous release (since it's a new upstream version). In your case, I would imagine something like: $ cvs export -d :pserver:... fgfs-atlas-20120209.tar.gz $ cd packaging-branch $ bzr merge-upstream --version 0.3+cvs20120209 ~/fgfs-atlas-20120209.tar.gz This will import the pristine tar data into the packaging branch as a new revision, merge the changes into the packaging branch and add a new changelog entry 0.3+cvs20120209-0ubuntu1. Yeesh, why did I not think of that?! That totally makes sense, and I'll try it if the same situation comes up again (or I need to update the package to a newer CVS). Thanks! -Barry signature.asc Description: PGP signature -- 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
Re: Updates to the UPG for UDD
On Feb 01, 2012, at 02:10 PM, Martin Pool wrote: I think messages like yours might as well be sent to say ubuntu-devel-discuss (too). Good idea. I'll send an announcement when the new pages are published. Thanks for the review; I'm going to merge the branch now and then dpm will publish the pages (hopefully in time for my class today at 1900 utc :). -Barry signature.asc Description: PGP signature -- 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
Re: Improved quilt patch handling
On Jan 19, 2012, at 01:30 AM, Jelmer Vernooij wrote: We've done some testing of it, as well as running through a package merge involving patches with Barry, but none of us do package merges regularly. If you do run into issues or if you think there are ways we can improve the quilt handling further, please follow up to this email or file a bug report against the UDD project (https://launchpad.net/udd/+filebug). We tested this out on brasero at the recent engineering rally and it looked fantastic. It was an amazingly smooth and easy merge. Now, I'm sure there'll be all kinds of weird corner cases, but I have to say I am *really* impressed, and it will allow us to greatly simplify the documentation and workflow. Great job! -Barry signature.asc Description: PGP signature -- 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
Re: Another quilt use case
On Nov 09, 2011, at 10:52 PM, Martin Packman wrote: Sticking any funky branches like this up somewhere may be useful for later reference. See if lp:~barry/ubuntu/precise/claws-mail/udd helps -Barry signature.asc Description: PGP signature -- 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
bzr bd -S --package-merge
How exactly does --package-merge calculate the version it passes to dpkg-genchanges -v? I'm wondering because it doesn't seem to be doing what I'd expect it to do, and I'm reluctant to use it. Latest case in point: I'm merging boost1.46 from testing into precise, so I do the following: $ bzr branch ubuntu:boost1.46 precise $ cd precise $ bzr merge-package debianlp:boost1.46 Most recent Debian version: MISSING Text conflict in debian/control 1 conflicts encountered. The merge resulted in 1 conflicts. Please resolve these and commit the changes with bzr commit. resolve conflict $ bzr diff debian/changelog === modified file 'debian/changelog' --- debian/changelog2011-06-03 20:28:58 + +++ debian/changelog2011-10-27 01:57:00 + @@ -1,3 +1,35 @@ +boost1.46 (1.46.1-7ubuntu1) precise; urgency=low + + * Merge with Debian testing. Remaining Ubuntu changes: +- Detect gcc atomic intrinsics, needed for arm spinlock (LP: #513721) +- Drop libboost-mpi, libboost-mpi-python, and libboost-graph-parallel (and + related -dev packages): we don't want to pull all of the mpi packages + into main. These are provided in a separate boost-mpi-source1.46 + package +- Drop libboost1.46-all-dev and provide from boost-mpi-source1.46 +- Adjust debian/rules and debian/control + + -- Barry Warsaw ba...@ubuntu.com Wed, 26 Oct 2011 21:56:45 -0400 + +boost1.46 (1.46.1-7) unstable; urgency=low + + * control: Fix ungrammatical description for iostreams packages. +Closes: #633865. + + * rules: Dump boostrap log file if bootstrapping fails. + + * libboost-doc.README.Debian: Remove reference to packages bjam and +boost-build; now only need boostX.YZ-dev. Closes: #630529. + + -- Steve M. Robbins s...@debian.org Wed, 17 Aug 2011 23:18:52 -0500 + +boost1.46 (1.46.1-6) unstable; urgency=low + + * control(libboost-mpi-python1.46.1, libboost-python1.46.1): Suggests a +python interpreter. Closes: #620775. + + -- Steve M. Robbins s...@debian.org Sun, 12 Jun 2011 00:37:42 -0500 + boost1.46 (1.46.1-5ubuntu2) oneiric; urgency=low * No change rebuild to drop Python 3.1 support. looks good $ bzr bd -S --package-merge If I now look at boost1.46_1.46.1-7ubuntu1_source.changes I see *all* the version entries from 1.46.1-7ubuntu1 all the way back to 1.21.1-1, the first in the changelog. If I drop the --package-merge option, I get a much trimmer changes file, with just the last changelog entry in it. That's not right either though. I'd expect to see entries for -6, -7 and -7ubuntu1. I've pushed the branch to lp:~barry/ubuntu/precise/boost1.46/debian-merge in case you'd like to take a look at see what's going on. I'll hold off on uploading for a bit in case there's something obvious going on. Cheers, -Barry signature.asc Description: PGP signature -- 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
Re: bzr get-orig-source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Oct 04, 2011, at 12:30 PM, Jelmer Vernooij wrote: I think Jonathan means that if you use -nc (no cleanup of build directory), you have to cd ../build-area/mypkg-1.0 to get to the build directory. Since I usually use sbuild or pbuilder directly to build the binary package, I `cd ..` to run the build (or more usually, open a different shell). Still, I think `bzr get-orig-source` is a nice addition. Personally, I just use bzr bd / bzr pbd, then fixup whatever is wrong, then bzr bd again - no changing of directories involved. % bzr pbd --help bzr: ERROR: unknown command pbd - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJOixG/AAoJEBJutWOnSwa/cgAP/0sUDi1FwkE+d5kRULEPn8p9 o4M4R+2ic0jVh2iJUsPuWGLmSgQrHvt6re4RetiC4r8tviz2SPGT42YyDt0Q/5A7 H9MJKvrKfyU+Ambs6/AnmMYMnFvGjR0/mhoPrTLuMTiFBx1NkcOgtmn9nWsxNU7u 3dWAyTUu5dUctsTFntH+mwu350h0Nv8lp2/UmgEi3tH7ty9QDO221f2mnkI5eWRb sT8BvXX5n3das4Vp3v6t3ZoqDLaYp03AjaoEZ6pdxKiazcUd7WG+VedEcOfw3POP 9vDrJMoI8k0KpWEXyzZVI42tRVufvC1ZRWb+MRGm8O+XfWkZH3vLeiA8GstxK0pX tnENFSkXZHXPcwq6ZPN5NBP7fJ5+1KlCc5lENcbl90SdKfzPKvW489646w7BtKOx NDEG28MZWVy2LMWbxIz+UxObDCDHEfyCHYvbYst301NSIdXH78GEFuQqWvrgQ23B DR6xXWvVjl6nVSaS3svLBxoiuHgieZp6bdCqYU5PiSeY+RhGuqI7dDNorhzr9AVY M86T9990sRV0dzX+m9fr5PiuBhbsGRIXXIK2FBBXa18HizlCflwZK1Txj2AgO4LX N/p7FOZFyNitUvWg6IDhZBL9+prvrT50xRlix3RLDIHxLwSIgOHkNMk1M11KZfFI vwrXmiTB92stZ3Lix68I =ML9I -END PGP SIGNATURE- -- 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
Re: ubuntu: branches lacking history with upstream branches
On Sep 23, 2011, at 12:42 AM, Jelmer Vernooij wrote: On 09/22/2011 05:14 PM, Barry Warsaw wrote: It would certainly be more useful to have ubuntu:gtimelog share history with lp:gtimelog, but I think it would be best in that case if ubuntu:gtimelog only version controlled the debian directory. Why would this be better than actually having all of the history there? It seems to me like that would mostly just add extra overhead because you have to fetch two branches rather than one. Right, I was thinking something like svn:externals where you wouldn't have an explicit second checkout, it would just happen automatically. But you're right that this still makes things more complicated, and I guess the effect of sharing history and having the full source would be the same, without the extra complication. I use bzr merge-upstream to merge new upstream versions into the packaging branches of bzr, samba4, heimdal and various other projects . See for example the ubuntu:bzr branch (although that seems to be out of date at the moment). Yep, I do the same thing. The nice thing there is that I don't have to worry about packaging unreleased changes. The downside is that I have to do an upstream release to test some new packaged version. And that there's no shared history. :) The practice of versioning debian/ only mostly seems to happen if the VCS used is SVN. Even then, there are a couple of teams that import the full upstream source into SVN. I think I've seen more Git repositories that include the full source than repositories that don't. I just want to blink my eyes, click my heels, wave my wand and make those git repositories speak bzr instead. :) -Barry signature.asc Description: PGP signature -- 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
Re: ubuntu: branches lacking history with upstream branches
On Sep 22, 2011, at 07:08 PM, Martin Pool wrote: lp:indicator-power is one example, and the desktop team actually maintain an unofficial packaging branch that does share history: lp:~ubuntu-desktop/indicator-power/ubuntu At the moment, gtimelog is another. What I've done recently is to first do a release from trunk, i.e. lp:gtimelog, push the new tarball to Launchpad and PyPI, then in ubuntu:gtimelog, I do `bzr merge-upstream` and build the Ubuntu release from that. It's not perfect, but it works. One problem seemed to be a weird lag in the debian/watch url between what I was seeing in my browser, where the 0.7.0 release was visible, but uscan took a while before it saw the new tarball. I didn't quite understand that, but wasn't in a desperate hurry to push the new Ubuntu version anyway, so I just waited a bit. It would certainly be more useful to have ubuntu:gtimelog share history with lp:gtimelog, but I think it would be best in that case if ubuntu:gtimelog only version controlled the debian directory. This would more closely mirror how packages are managed in Debian. However, I'd *still* want `bzr branch ubuntu:gtimelog` to give me the full source. I wonder if nested branches are the answer here. One trick would be that I'd only want the source from the upstream branch based on a particular tag. E.g. I might have unreleased changes in lp:gtimelog, but I want to base ubuntu:gtimelog (and the source package built from it) to work off the 0.7.0 tag or some such. -Barry -- 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
Re: Our biweekly meetings
Apologies for the delayed response. Note that we ended up not meeting on Wednesday because it was only Jelmer and myself. ;) Maybe the thing to do is to suspend the meetings until we have a clear agenda for them moving forward. Note that I don't think this is necessarily a bad thing! While there are some big ticket items that really need addressing (e.g. the quilt story), for me, UDD is a huge success. Despite the warts, I personally can't imagine working any other way. On Sep 06, 2011, at 03:12 PM, Jelmer Vernooij wrote: The main thing I appreciated about the meetings was hearing what other people had done towards UDD. A common theme these days: let's celebrate your successes! One possible change in format would be to do a lightning round, and just go around the table with each person identifying one or two items they've run into, fixed, hacked on, or have a wild idea about. I would certainly love to hear about what you guys are excited about that might be coming soon. If there was some new feature, I'd be happy to run a dev branch for a bit to try things out. A great example is the branch status messages that bzr now gives. The original status lines needed a bit of tweaking, but now that it's landed, I am absolutely ecstatic about the feature. JAM, you nailed it! I think a part of this is also that UDD as a project doesn't really have releases - and no really visible changelog. So despite a lot of things getting done, we normally wouldn't hear about them. Agreed. The lightning round might do the trick there. Another thing that was occasionally useful was discussions about particular problems, like what to do about the project branch and packaging branch for a native package. The mailing list seems to work reasonably well for that sort of discussion too though, when it happens to come up. What do you think about this: after the lightening round, we can have one or two brief discussions on any particular design or implementation point for which the higher bandwidth would be useful? Mostly, I want to cut out the boring parts of the meeting, or anything we can do just as well over email. Let's make the meetings fun and interesting to participate in, and maybe we'd get more than just us chiming in. :) Cheers, -Barry signature.asc Description: PGP signature -- 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
Our biweekly meetings
At our last meeting, we talked about starting up the UDD bi-weekly meetings again this week (Wednesday Sept 7 @ 1100 UTC). However, both Martin and I are pretty tired of the old format, so let's think about how we can restructure the meeting to be most effective for everyone. If we really don't think we *need* them anymore, that's fine too. What would *you* like to get out of these meetings? -Barry signature.asc Description: PGP signature -- 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
UDD stakeholders meeting minutes, and schedule update
New minutes are posted for the last two UDD stakeholder meetings: https://wiki.ubuntu.com/DistributedDevelopment/20110713 https://wiki.ubuntu.com/DistributedDevelopment/20110727 Also, because of typical (northern hemisphere) summer vacation schedules, we're suspending the meetings through August. The current plan is to next meet again on September 7th at 1100UTC. Martin is going to verify the meeting time with the Google Calendar event. Cheers, -Barry signature.asc Description: PGP signature -- 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
Re: Package branch freshness
On Jul 18, 2011, at 10:17 PM, John Arbash Meinel wrote: I have a branch in PQM now that adds a version check whenever you access a Launchpad packaging branch (http://pad.lv/609187). I have the feeling there is still a bit of polish needed, but I would like to get some feedback from people actually using it. I grabbed lp:bzr and played with it a little bit. In general, I really appreciate you adding this. Package import failures will probably never be exactly zero, and the less users expects an import to be out of date, the more important I think it will be to warn them when that does happen. (If you agree, that could influence the default output choices.) I tried it with ubuntu: branches, and it works the same way as lp:ubuntu branches (as expected). Yay! I also tried it with debianlp: branches and it kicks in there too. Yay! The output could be a little clearer I think, and here are just some random thoughts based on quick tests. - The output is a little too verbose. - the version numbers are a bit difficult to pick out in the output. Suggestions follow. Case 1: everything is up-to-date 1.4.1-4 is CURRENT in Oneiric Case 2: packaging branch is out-of-date 1.0.2-0ubuntu1 is OUT-OF-DATE (Ubuntu Oneiric has: 1.0.4-0.1) If you want to expose a configuration/cli knob, then the above would be less verbose output, with more verbose output possibly being: Case 1: Most recent Oneiric version: 1.4.1-4 Packaging branch status: CURRENT Case 2: Most recent Oneiric version: 1.0.4-0.1 Packaging branch version: 1.0.2-0ubuntu1 Packaging branch status: OUT-OF-DATE I thought about not even printing a status report in case 1 for less verbose output, but I think it's still useful to print the version number and status in that case. I suppose a quiet option would only print a warning when the published version isn't available. I noticed a *very* slight additional delay for `bzr branch` but I can certainly live with it for the additional information! I'm a little worried it will be too verbose, or ignored or confusing, so any feedback is useful. Even better if you can use it for a while and see how it feels. This landed as bzr.dev 6033, so it should get built into the dailies soon. I'll continue to use lp:bzr for the next few days packaging work. Cheers, -Barry signature.asc Description: PGP signature -- 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
Re: packaging guide
On Jul 14, 2011, at 05:26 PM, Jonathan Riddell wrote: I've been looking over the packaging guide for what needs done to it and issues with UDD it reveals. Thanks very much for your great work on this Jonathan. Daniel asked me to review your branches, which I did, although one of them needs an update to its dependent branch so the diff isn't so huge. Of the other two, I marked one as approved (with consideration of some minor comments), and the other one needs more information. Cheers, -Barry signature.asc Description: PGP signature -- 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
UDD meeting change
Please note the following time change: At least for the rest of the northern summer, we're bumping the UDD meetings up by one hour. They will now be held at 1200 UTC. See you on 13-July. Cheers, -Barry signature.asc Description: PGP signature -- 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
Vcs branches, debcheckout, and UDD
There was a discussion today on #ubuntu-devel about some changes I'd made to a few packages for bug 788514 (switch to dh_python2). gedit is a good representative example of the basic issue. What I did was to `bzr branch ubuntu:gedit`, then make the changes to that branch, `bzr bd -S`, and dput the resulting .dsc file. All well and good I thought, but actually this caused some trouble because gedit has a Vcs-Bzr branch: $ debcheckout -p gedit bzr https://code.launchpad.net/~ubuntu-desktop/gedit/ubuntu which is *not* the UDD branch, even if we substitute bzr+ssh for http. I just spent an hour manually copying the diff from several UDD branches to their Vcs branches, because 1) I'd already uploaded the change, and 2) the branches share no history so you can't merge between them. I think this is somewhat related to the native package discussion we've had w.r.t. software-center, but it's also somewhat different. Or maybe not: $ debcheckout -p software-center bzr https://code.launchpad.net/~software-store-developers/software-center/trunk A couple of things bother me here: * We shouldn't be suggesting to people to use the UDD branch if the Vcs branch is preferred. * We probably don't want to suggest that any Vcs branch, or even any Vcs-Bzr branch should automatically use the Vcs branch instead of the UDD branch, since Debian packages can specify either, and for those, the UDD branch would still be appropriate. * Should debcheckout be taught about UDD branches and rules, or should bzr be taught about Vcs-Bzr branches? * Using an unmodified Vcs-Bzr url isn't ideal, since we'd almost always prefer the bzr+ssh version (i.e. `debcheckout -a`) over the https version. * tumbleweed, seb128 and others suggested some mungification of Vcs-* into an XS-$Vendor-Vcs-* field, possibly by update-maintainer, but I don't grok all the details of what that would mean. * I can see how `debcheckout` is pretty useful, but I don't much like it better than normal UDD workflows. * There's no foolproof rule to know when to use the Vcs branch over the UDD branch. Maybe, a heuristic would be, look for a Vcs-Bzr header matched with a -0ubuntuX version number and/or ubuntu in the branch url. In those cases maybe `bzr branch ubuntu:foo` would complain, or just do the moral equivalent of `debcheckout -a foo`. Or maybe, what we've talked about for software-center applies here. E.g. ask Launchpad to essentially make the UDD branch and the Vcs-Bzr branch one and the same, so either approach will work. This seems trickier since the UDD branch has the full source code, while the Vcs-Bzr branch has only the debian/ directory (and apt-gets the source). You guys are way smarter about this stuff than me, so I hope you'll have some awesome suggestions. :) Even if it's not solvable right now, I think it's important to get it on the UDD radar since debcheckout is how a lot of folks work, and I'd like to save future developers the wasted effort of changing the wrong branch. Cheers, -Barry signature.asc Description: PGP signature -- 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
Re: lp:ubuntu/euca2ools import failure
On Jun 14, 2011, at 10:54 AM, Scott Moser wrote: I am the cause of the euca2ools import failure http://package-import.ubuntu.com/status/euca2ools.html . I'd like to have all the lp:ubuntu/suite/euca2ools branches up to date. I really like the functionality that udd provides, but have apparently been at odds with the importer in some situations. I *think* that its valid to push to those branches with 'UNRELEASED' versions, to provide for better logging, right? Ie, I would make a change, debcommit it, push it, then repeat, and then eventually debcommit -r and push and upload. That is valid, right? One way or another, I'd like to have the branch fixed. I can live without any intermediate commit messages that caused problems. Don't forget to `bzr mark-uploaded` when you dput, and before you push the branch. That adds a tag taken from debian/changelog and helps the importer know what's going on. It might be nice to have debcommit do that automatically, but I don't know if that's feasible or wise. -Barry signature.asc Description: PGP signature -- 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
Re: Ubuntu Packaging Guide
On Jun 03, 2011, at 10:07 AM, Mackenzie Morgan wrote: From what I understand, there are people doing things all sorts of ways with quilt, and I really don't want to have to learn all the ways people are using quilt with bzr and try to figure out *which* way any particular package is using that combination. I'll stick to apt-get source for those. I've successfully used the guidelines on this page for several quilt packages: http://people.canonical.com/~dholbach/packaging-guide/html/udd-patchsys.html By no means is it perfect, which everyone acknowledges. Depending on your level of pain tolerance, you don't necessarily have to punt on UDD right away when working on a quilt3 package. Still have to dput anyway... For now... :) -Barry signature.asc Description: PGP signature -- 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
Re: Status of documentation
On May 20, 2011, at 05:33 PM, Jelmer Vernooij wrote: On Fri, 2011-05-20 at 11:46 -0400, Barry Warsaw wrote: A couple of quick notes on UDD documentation. At UDS-O, we agreed that the current wiki documentation should be deleted, with pointers added to Daniel's Ubuntu Packaging Guide. Even though the latter is currently only available via a temporary link, it's better not to have multiple versions of the UDD documentation floating around. Thanks for removing those wiki pages, I guess you've already met Jorge's quota for this cycle ;) As soon as Jorge issued his challenge, I knew I'd have no trouble meeting it this cycle! :) This is now done. When Daniel gets a permanent URL for the docs, I will of course update the links. Here's the current URL: http://people.canonical.com/~dholbach/packaging-guide/html/knowledge-base.html This also means that if you want to make changes to the docs, you should branch the UPG's trunk and do a merge proposal. The trunk is at lp:ubuntu-packaging-guide Any other suggestions for improving, reorganizing, or expanding on the UDD bits of the packaging guide documentation are welcome! What releases of Ubuntu is the packaging guide aimed at? There are some things in the documentation that are available in reasonably new versions (Maverick, Natty) but the packaging guide still describes alternatives for older releases. Yep, and I'd like to phase those out. My own preference would be to target at least Natty for now because I think this was the first cycle where serious development could be done with UDD. Perhaps once 12.04 is out, we should target the LTS and relegate alternatives to an older distroseries section. -Barry signature.asc Description: PGP signature -- 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
Re: UDD with new upstream version
On Apr 14, 2011, at 03:29 PM, Scott Kitterman wrote: the bzr-builddeb in natty can use the watch file. If you have a watch file it will use the watch file to download the upstream release. The --version argument is also optional if you have a watch file; it will default to the latest upstream version. That sounds good. Could you update the wiki page then so it's documented? I'll do that. The wiki is semi-obsolete. As soon as the new Ubuntu packaging guide gets a URL, I'll be removing the wiki pages and pointing to it (which contains the latest content, and which I'll also update). BTW, watch file support rocks! -Barry signature.asc Description: PGP signature -- 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
Re: UDD with new upstream version
On Apr 14, 2011, at 03:51 PM, Barry Warsaw wrote: I'll do that. The wiki is semi-obsolete. As soon as the new Ubuntu packaging guide gets a URL, I'll be removing the wiki pages and pointing to it (which contains the latest content, and which I'll also update). Looks like Jelmer already did \o/. I'll update the packaging guide. -Barry signature.asc Description: PGP signature -- 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
Re: discussion of ubuntu-desktop packaging branches
On Apr 11, 2011, at 10:42 AM, Martin Pitt wrote: We could do that. I actually usually do bzr bd -S first, and only debcommit -r once that was successful, but I can just ignore the warning :) I usually do things this way too. -Barry signature.asc Description: PGP signature -- 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
Re: Meeting minutes and possible meeting time change
On Apr 13, 2011, at 11:26 AM, Martin Pool wrote: On 13 April 2011 01:24, Barry Warsaw ba...@ubuntu.com wrote: Martin, I think you own the gcal event. Can you make the change so that we're meeting at 1100 UTC for the next meeting (20-Apr)? OK, done, that's next Wednesday: morning in the US, lunch time in the EU, and evening in Australia. Fantastic, thanks Martin. Two weeks after that, the 4th of May, I'll be travelling for so I for one can't attend, but I think you should meet without me. Then the 18th of May I'll be in London but that time still works. Cool. Many of us will also be at UDS, so we can at least touch base and see if the new time works for everyone. I've updated the wiki pages. -Barry signature.asc Description: PGP signature -- 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
Re: Meeting minutes and possible meeting time change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Apr 12, 2011, at 01:29 PM, John Arbash Meinel wrote: 1100 UTC is excellent for me :). 2100UTC is about 11pm for me, which is possible, but a bit unlikely. My family is certainly usually asleep before 10, but lately so am I. If there are no objections, I'm certainly willing to give it a shot. I know that Scott K said the time will be less convenient for him, which is unfortunate, but I still think we should run an experiment with the new time. If we don't like it, we can change it back. Or perhaps we'll want to alternate to get better coverage. Martin, I think you own the gcal event. Can you make the change so that we're meeting at 1100 UTC for the next meeting (20-Apr)? Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJNpG6iAAoJEBJutWOnSwa/5pgP/0KiJf1TiiwD8tvuTgPgX5ez ETnqRPeU2q36/69EiMs6ivRn+yo2H4eivGnKoNl33kIIBqaKEc5aJKxIiPRqtTJw OtLX3IcOAp9IBpB26DsVPsDfRHvtZNpRPa8M9LzM7+wYHyxvnTkIdondXe5e8loV r+EP5y7tYSnsnXzBgzQb5Rw/1TAmv0WhPd3ekeXORSKeh97eUiyhekL6p4A/Q1KL jsUsGM16YtbX5PvdRAYlTYa3ATDGMBZi+Ms6BNFGn5H4g12405Z2HSz5sS0rV44w mkiAlelhddyMWTm/5oFQxG5sT9SGM0lYwmpCl6pr11yWqOLuiyfNHtXPKwSfUodp Iuwto5E1/t1Fxh2VNPSvdssrQSCKm1HOVrnOMnBtiLiswaQGbt+NQo0/OQwtN+Js rTiU24YUtdC7LCJjzNj5w1cv9Iu+5uAbFnapd6Y8CIa2NkMhESUvemATNU7Xazd+ Np++5PSBa6TWpiuP6z9ZwNCCESa3JicWETdlBGwKlCnu5+lKKPxCkqNi/P84Jmqz lKcRP3gJC6EZWuyjSQo2nox855t2n7KxS2MqPEBT7/y91DZpYzRy1wPwF8FVFDNS tTpGq/ZWJg4GtVqWW/bM/zhV/lAZJyYV93b3vqNuCyy1aUtwtKD5q/jgRQlNoNSY JBehOjNzdD/rn5UgYhoV =9trP -END PGP SIGNATURE- -- 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
Re: Summary from UDD meeting 2011-03-23
On Mar 26, 2011, at 09:10 AM, Robert Collins wrote: We have in the past fallen into a trap of aiming for 100% in each step *before* we move onto the next one. That means we're well past the point of getting a net benefit (think 80-20 rule) by the time we start moving on. These import problems have a viciously long tail : isn't it better to be making things a lot better *most* of the time? I agree that you're not going to get 100% importer success, but attacking say the top 5 common importer failures could knock off maybe 50% of the current failures. That'd be a huge improvement without even stepping onto that long tail. That, and solving bug 609187 would really help. With that bug fixed, we could at least tell people just do bzr branch and if that fails, fallback to apt-get source instead of all the LBYL checking we currently have to recommend (see step 0 in the wiki docs). I acknowledge the psychological impact of 'if it doesn't work always its hard to remember' - but we're already well past the common working set of any one developer, and Martin isn't suggesting that imports be abandoned, just that closing the loop is *as* important as improving the import story. I agree that I'd love to see the loop closed! Do you think the team can make the above top priority, and still have resources for BFBIP? -Barry signature.asc Description: PGP signature -- 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
Re: missed meeting
On Feb 24, 2011, at 06:11 PM, Jelmer Vernooij wrote: The meetings have been at 10 CET here, so it's not quite as late as midnight, but it is well past the work day. The meetings are at 1600 EST so I could easily go earlier, though I'm often slammed with meetings on Wednesdays until about 1200 EST. The problem is that we're now pretty early in the morning in Australia. This is depressing: http://www.timeanddate.com/worldclock/meetingtime.html?month=2day=24year=2011p1=0p2=179p3=16p4=240 As Homer Simpson might say: stupid rotating earth -Barry signature.asc Description: PGP signature -- 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
Re: Import layout of Quilt v3 packages
On Feb 09, 2011, at 07:57 AM, Reinhard Tartler wrote: meaning all patches are already applied in the source branch. -1 You can maintain the property as well by adding a hook that applies the patches at checkout time. (Even that hook is not strictly necessary, as debuild will automatically apply patches at build time as necessary.) Actually, if the branch were converted to loom format, then all patches already applied would simply mean that a checkout would leave you at the top thread. -Barry signature.asc Description: PGP signature -- 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
Re: Import layout of Quilt v3 packages
On Feb 08, 2011, at 06:00 PM, Martin Pool wrote: At the moment it seems to me we need to either: import to looms and mandate using looms; or check in things with everything expanded and provide glue that will keep the quilt data up to date with the wt. (Perhaps they should be considered derived data and updated from a hook.) One other use case to keep in mind: it's sometimes necessary to remove quilt patch files. One of the things you do when you merge in a new upstream is to review the current set of patches to see what's been applied upstream. You'll delete those patches, and of course may need to resolve conflicts in subsequent patches that touch the same code. I think that would correspond to a combine-thread in the loom that throws away the changes in one thread. -Barry signature.asc Description: PGP signature -- 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
Re: Import layout of Quilt v3 packages
On Feb 08, 2011, at 02:23 PM, Max Bowsher wrote: I think we should go ahead and change the package importer _now_ to revert to importing 3.0 (quilt) source packages with patches *not* applied. When it does so, it should probably write a debian/source/local-options file containing unapply-patches. This will give us import branches that are actually usable for UDD-style development *now*, which I think we currently do not have for 3.0 (quilt) packages. Once the problems surrounding ubiquitous looms have been solved, we can think about switching the import format again, but at least we will then have usable UDD between now and when we reach that point. It's not entirely unusable now. It's also not entirely awesome either. https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem Discovered with much experimentation. -Barry signature.asc Description: PGP signature -- 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
UDD stakeholders meeting minutes 2011-01-26
Minutes of the UDD stakeholders meeting 2011-01-26 2100 UTC are now available here: https://wiki.ubuntu.com/DistributedDevelopment/20110126 There's been lots of excellent progress, so please do read the page. And remember, all are welcome to join us in #ubuntu-meeting. -Barry signature.asc Description: PGP signature -- 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
Making bzr commit more like debcommit
We have 'bzr commit' and we have 'debcommit'. Currently, the UDD guidelines talk about both, but for consistency, I'd like to standardize on recommending 'bzr commit'. One feature that debcommit has: DEBCOMMIT(1) DEBCOMMIT(1) NAME debcommit - commit changes to a package ... VCS SPECIFIC FEATURES ... bzr If the changelog entry used for the commit message closes any bugs then --fixes options to bzr commit will be generated to associate the revision and the bugs. I know we can just do 'bzr commit --fixes lp:12345', though I often forget to do that until after my last commit, so I tend to add --unchanged, which leads to an empty revision. What do you think about making 'bzr commit' act more like debcommit when there's a new debian/changelog entry? -Barry signature.asc Description: PGP signature -- 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
UDD stakeholders meeting minutes 2010-12-01
https://wiki.ubuntu.com/DistributedDevelopment/20101201 -Barry signature.asc Description: PGP signature -- 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
Re: udd at uds-n
Hi Martin, thanks for posting this update, and apologies for taking so long to get around to reading it. On Nov 17, 2010, at 08:06 PM, Martin Pool wrote: At the end of that discussion we picked two specific items for the bzr team: * speed * loom support, on lp and within bzr, and connecting them to packaging patches and for Launchpad * build from branch into the main archive * actually execute a merge from a merge proposal * through launchpad. merge from a debian branch into an ubuntu udd branch I think we also have to address the package import failure issues. I see two parts to that. First, we need to make sure that if someone branches lp:ubuntu/foo (or ubuntu:foo wink) on a branch that has had import failures, that some very prominent warning is displayed. Perhaps the branch fails unless a --force flag or something is given. I'm not sure exactly, but I'm fairly confident that silently producing a branch that's out-of-date is *not* a good thing. :) Second would be to address the issues actually causing the failures, but that's a longer term project. -Barry signature.asc Description: PGP signature -- 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
Re: UDD survey results
First of all, thanks Martin for conducting the poll and collating the results. It'll be an interesting baseline to compare against at future UDS's. On Nov 18, 2010, at 06:23 PM, Martin Pool wrote: Bottom line: *Heaps* to do, but some encouraging feedback. The priorities I draw from this are that we should work on * speed of branching/merging from Launchpad * keeping import branches reliably up to date * removing small-medium disconcerting bugs then * getting branches to current formats, without orphaning old clients * supporting v3 packages this is fairly consistent with what was said at UDS-N, which is nice. I completely agree! -Barry signature.asc Description: PGP signature -- 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
Re: UDD survey results
Oh, sorry, one other thing. Would it be useful to link to the survey results and your summary from https://wiki.ubuntu.com/DistributedDevelopment ? -Barry signature.asc Description: PGP signature -- 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
Re: Quilt artefacts in source package branches (was Re: Upstream in Launchpad adds confusion)
On Nov 05, 2010, at 10:38 AM, Max Bowsher wrote: Either people should not remove it (and furthermore keep it up to date) or the UDD importer ought to not place it in the branches in the first place. Probably both! It's probably good practice to revert any changes to the .pc directory that might have snuck in. I've added that recommendation to: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem I've also filed this bug to request that the UDD importer not include the .pc directory: https://bugs.launchpad.net/udd/+bug/672740 Thanks, -Barry signature.asc Description: PGP signature -- 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
UDD stakeholders meeting minutes 2010-11-03
The minutes of this week's UDD stakeholders meeting is now available: https://wiki.ubuntu.com/DistributedDevelopment/20101103 -Barry signature.asc Description: PGP signature -- 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
Upstream in Launchpad adds confusion
So, I made a patch against ubuntu:python-distutils-extra and submitted a merge proposal. https://code.launchpad.net/~barry/ubuntu/natty/python-distutils-extra/670188-ftbfs/+merge/39993 A few interesting things happened. As part of my branch, I removed the .pc directory from bzr. IIUC, that quilt3 artifact should not have been under version control. Still, that does distract from the important part of my change. In the review, Martin suggests that the change really should have been submitted against lp:python-distutils-extra (i.e. the upstream rather than the source branch). This is a confusion that has come up a few times for packages that are upstream hosted on Launchpad. In those cases we can have several branches of the code, upstream, perhaps a debianized branch of upstream, and all the source branches. Now, I don't mind redoing the patch for the upstream branch, but I'm wondering if there's something we - or Launchpad - can do to make that less wasteful of a developer's time. I don't have any bright ideas, except perhaps something on the source branch page that a maintainer could set to redirect folks to the upstream branch. Thoughts? -Barry signature.asc Description: PGP signature -- 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
Stakeholders meeting minutes for 2010-10-20
Minutes from the yesterday's UDD stakeholders meeting are now available: https://wiki.ubuntu.com/DistributedDevelopment/20101020 Don't forget to that we have three sessions scheduled for UDS-N. Looking forward to seeing you there. Cheers, -Barry signature.asc Description: PGP signature -- 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
Re: Please check my thinking on bug 646979
On Oct 05, 2010, at 09:16 AM, John Arbash Meinel wrote: I've been thinking about it, and I'm pretty confident that what you are trying to do is inherently criss-cross. Specifically consider a semi-ideal case: This is all fascinating, and while I have nothing constructive to add, I wonder: does it make life any easier if you were only considering the debian/ directory? I'm not sure that's even possible or desirable, but it seems like that would at least take upstream out of the picture. -Barry signature.asc Description: PGP signature -- 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
Re: Please check my thinking on bug 646979
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Oct 05, 2010, at 09:37 AM, John Arbash Meinel wrote: Now, I would imagine that the *interesting* merges are not clean like this. Why would you really care about merging if debian isn't adding patches to the upstream code? (Other than procedurally being the right thing to do, it doesn't seem *interesting*.) Won't all the patches Debian (or Ubuntu) adds be in patch system files living in debian/? Of course, the looms-patchsystem idea kind of blurs that, but ultimately the packaging directory should fully contain any downstream changes Ubuntu or Debian would add. (I think. ;) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJMqzsgAAoJEBJutWOnSwa/ukMP/0UINcLP07Q3B61re6TnyEu4 1tDQJDHHAoZMnSTX/VpoRtxU6txhRuxEYKDdUZNQ2SGTC4pFlp4KZzy8tOrwanCO jK+r4ohzoh/k7VTLvdX4y6IuMm2r7q7XNX5vvt/HeeDQUreDJp6BwwXpmZSVs+gw 6eI2ZtWioeNHa+enaY99thfYcECPKkJf1M1SPy7V5lDCj1hngxhvQo3SnlWBfOIs ljOOAa1QLKJ/YP++/1KPcLsA8fr5RJwAcKuYxTZclS4NPBsfKdOc1s+h2JeCtOiW WhTl79MBcudmlBXae4vC57t4iwCL8vPQHjrN9/6SJl/AeQyX2+h2JMm01njUM0aU ekaaXepRQ5h47vgRjdMOJkckwO+WJlSFxXpqBxrsS8RW7d1Kfch5L5RSHPpUgotf P7cuvTmjhGL0ybnfBMI5786BmGH9iN8MTaSOmTAFEISWXQoE8hGqWEfffGpyP4oP GLYUkQamH91VWkDCbbecRhvjsdsEk2xLTVx4kkgM6HmJrBdDxQIghziUf8z2Syb0 yJ/Wr/owqmCuiFVLeIMzQMFudUPAkWHVCBE2amVsiz4ohMaehUOr5kg9gfZzIhiR 9uCmYa78Dr7Wkii/ND1WAlF9JzTdORjbyjnLOJLx+CfS/xi50wxAlHqbUhBxySRq efRwBfVQGSOrdTg8mmEI =RZPy -END PGP SIGNATURE- -- 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
Re: UDD health check?
On Jul 13, 2010, at 04:20 PM, Elliot Murphy wrote: On Tue, Jul 13, 2010 at 4:04 PM, Barry Warsaw ba...@canonical.com wro but it seems to have some advantages for the way I work. This is cool, thanks for 'splaining. Thanks to you too. It's great to get another perspective on things. Yes, and I'm not supposed to directly edit any of the source outside of debian/, which is why the layout used by svn-buildpackage with only debian/ in VCS resonates with me. Having said that, the full extracted source is incredibly useful when I'm debugging - it's nice to be able to diff a given source file between different package versions which sometimes don't line up in a meaningful way with upstream VCS (because they can be patched in the debian package). This leads to my last comment. While you're not *supposed* to touch anything outside of debian/, I think that if there were nice tools to convert back and forth from dvcs-lingo to patch-system-lingo, we'd have an even more powerful development system. -Barry signature.asc Description: PGP signature -- 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
Re: [Launchpad-users] upstream + packaging + looms + lp != happiness
On May 28, 2010, at 05:17 PM, James Westby wrote: All the threads disappeared when the branch was pulled to machine heresy. Maybe Launchpad doesn't support looms yet? Maybe the stacking is messing things up? Any other suggestions or comments? No idea, sorry. Have you filed a bug for tracking purposes? Cool. Thanks for the feedback everyone. Since I wasn't exactly sure where to file the bug, I've filed it against launchpad-code, but 'also affects' udd and bzr-loom. https://bugs.edge.launchpad.net/bzr-loom/+bug/587058 Cheers, -Barry signature.asc Description: PGP signature -- 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
upstream + packaging + looms + lp != happiness
Computer Janitor is my poster child for the UDD use case where the upstream is
also the packaging branch. lp:computer-janitor has the debian/ directory in
it but that's unsatisfying for several reasons. So I wanted to experiment
with using a loom to manage several threads (from bottom to top):
* trunk - This would be the undebianized upstream source thread. It would
have a sane setup.py and everything necessary to build and run the
application the way a Python developer would expect. IOW, it would be
virtualenv-friendly, be able to be 'python setup.py install'd and 'python
setup.py test'd, etc. It would know nothing about how to package it for any
distro.
* debian - This would be trunk + the debian/ directory, but specifically it
would be tuned for Debian. 'head -1 debian/changelog':
computer-janitor (2.0.3-1) unstable; urgency=low
* ubuntu - This would just be the changelog tuned to Ubuntu. head sez:
computer-janitor (2.0.3-0ubuntu1) maverick; urgency=low
I would probably separate out the trunk into a separate branch, so that other
people could easily hack on upstream, and only when we're happy with the state
of the app would we pull it into the loom's trunk thread, auto-merge upwards,
and push changes to Debian and Ubuntu from the respective threads.
I would generate PPA source packages from the `ubuntu` thread, or I might
branch the loom for lp:~barry/computer-janitor/whatever and add a thread above
that for my PPA.
This is the sanest way I can currently think of for organizing the upstream
and packaging branches for two distros and a PPA. If it works, it seems like
a nice way to manage things.
Unfortunately, this doesn't work because round tripping the branch through
Launchpad throws away all the loom information. Here's the transcript from
two different machines ('bzr looms' is an alias for 'bzr show-loom'; the
'split' thread is an artifact that will go away).
limelight% bzr looms
=ubuntu
debian
split
trunk
limelight% bzr record
Loom recorded.
limelight% bzr push lp:~barry/computer-janitor/loomified
Using default stacking branch /~computer-janitor-hackers/computer-janitor/trunk
at lp-69637584:///~barry/computer-janitor
Created new stacked branch referring to
/~computer-janitor-hackers/computer-janitor/trunk.
heresy% bzr branch lp:~barry/computer-janitor/loomified
Branched 240 revision(s).
heresy% cd loomified/
heresy%
All the threads disappeared when the branch was pulled to machine heresy.
Maybe Launchpad doesn't support looms yet? Maybe the stacking is messing
things up? Any other suggestions or comments?
Cheers,
-Barry
signature.asc
Description: PGP signature
--
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
Re: UDD @ Portland
On Feb 11, 2010, at 02:57 AM, James Westby wrote: On Thu, 11 Feb 2010 13:33:27 +1100, Martin Pool m...@canonical.com wrote: I'd like to let looms progress, but not (unless james or others feel differently) add them into the dependency chain for getting UDD going. No, we don't have to add it to the chain to get it going, but I think it's one ingredient of having a great system. I agree. Looms help both the developer and reviewer focus in on the parts that they really care about, and I think could help manage mostly boring bookkeeping details (such has how to play nicely in whichever patch system is being used). Looms probably aren't essential for udd, but seem very important for really fantastic (and fun!) opportunistic hacking. -Barry signature.asc Description: PGP signature -- 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
Re: Feedback on merging via bzr
On Jan 20, 2010, at 11:10 AM, Michael Hudson wrote: This can probably be arranged, I guess. File a bug. Patches likely welcome :-) For now: https://bugs.edge.launchpad.net/launchpad-code/+bug/509901 -Barry signature.asc Description: PGP signature -- 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
Re: Feedback on merging via bzr
On Jan 17, 2010, at 10:45 PM, Scott Kitterman wrote: I spent some time over the holidays giving merging via bzr and the UDD tools. I understand that development of the tools to support this is still a work in progress and the much of this feedback probably represents work that you already know needs doing. This mail is based on notes I took recently while doing a merge of regina-normal. As merges go, it was not a complex one. This is good stuff Scott. It mirrors some of my recent experience using UDD to do various kinds of development. Of course, my packaging experience is weeks old, not years old :), so I don't have much comparison of the traditional way to draw on. The UDD equivalent seems to be: $bzr branch lp:ubuntu/regina-normal regina-normal $password for ssh key ssh-agent helps here so that you only have to enter this once. $cd regina-normal $bzr merge-package lp:debian/squeeze/regina-normal Text conflict in debian/changelog 1 conflicts encountered. The merge resulted in 1 conflicts. Please resolve these and commit the changes with bzr commit. This gives me the proposed merge. The conflict in this case seems to occur with every merge I try. The most recent Debian and Ubuntu debian/changelog entries conflict with each other and the file has to be edited to move the most recent Debian entry above the most recent Ubuntu entry. Yep, I noticed exactly the same thing. To get ready to start to work on the actual merge, I need to also do: $ vim debian/changelog (re-arrange as described) $ bzr resolve All conflicts resolved. Emacs to the rescue here (for the crazy people who use it :). Emacs auto-resolves files when you save them. It's a nice convenience that hasn't bitten me yet :). Step 3 checking the package: At this point I want to check the package against the previous Debian and Ubuntu packages to make sure I have it correct. Traditionally, I would locally debdiff the proposed merge with both the previous Debian and Ubuntu packages to make sure I had documented all of the Ubuntu diff and not lost any needed changes in the merge. To do it the new way, I did: $bzr diff --old lp:debian/squeeze/regina-normal | less ssh key (repeat, including redownloading each time the diff is done) It would probably be better branch these locally if you're going to do a lot of diffing. I know a huge amount of work has gotten to getting things as far as they are. This feedback is not meant to miminize this accomplishment. I do not, however, feel like this facility is really ready for general use yet. I think it would make sense to submit bug reports to help streamline things, but I'm not sure where those bug reports would go. On the bzr-builddeb plugin on Launchpad? -Barry signature.asc Description: PGP signature -- 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
Re: Feedback on merging via bzr
On Jan 17, 2010, at 10:45 PM, Scott Kitterman wrote: I spent some time over the holidays giving merging via bzr and the UDD tools. I understand that development of the tools to support this is still a work in progress and the much of this feedback probably represents work that you already know needs doing. This mail is based on notes I took recently while doing a merge of regina-normal. As merges go, it was not a complex one. Oh, also, there are some interesting steps you took that I did not notice were documented on the wiki page. Maybe you can take a pass through them and update them with some of the things you learned (e.g. bzr mark-uploaded, diffing the Ubuntu and Debian sources). https://wiki.ubuntu.com/DistributedDevelopment/Documentation -Barry signature.asc Description: PGP signature -- 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
Building a new package the UDD way (was Re: First impressions (long))
On Dec 11, 2009, at 05:12 PM, Barry Warsaw wrote: I think I've actually patched my first Ubuntu package, with much thanks to Colin and James W for their help. Having done this from essentially no knowledge of how to do it, and no experience with the tools, James suggested I email this list with some feedback and suggestions. Remember, I'm a n00b so be gentle because I have No Idea What I'm Talking About. :) Well, now with a few more weeks under my belt, I decided to tackle packaging a brand new Python package which is not yet in Debian or Ubuntu. I still don't know what I'm talking about, but I took notes, so here now is my feedback on what I did. I think there is no wiki page yet on the workflow for brand new packaging the udd-way, but after getting some of your feedback I will add that page. (Side note: I've also now done a merge with sid to update the version of Python's distribute package in Lucid. That was a bit of a head-scratcher until James and Micah pointed me to the wiki page on 'bzr merge-package' which seemed to work perfectly, modulo the approval of my branch.) The package in question is http://launchpad.net/munepy, a Python enumeration package that I've refactored out of the Mailman 3 code base. This package only works with Python = 2.6. As the upstream maintainer of munepy, I'm pretty confident of its current quality. I decided to use bzr-pipeline to manage the changes. In addition to the bzr-builddeb tools, I found that python-stdeb was helpful, though not perfectly so. Actually, because of problems with the version of python-stdeb in Lucid, I had to grab the Debian source package, then build and install it locally. We should resync this to sid I think. Also, my goal was to get a PPA in Lucid munepy (and Karmic as a bonus but on this I failed). I next have to figure out how to propose the package for inclusion in universe and possibly also in Debian, but those (I think) are less important for this mailing list. I started out pretty simply: % bzr init-repo munepy % cd munepy % bzr branch lp:munepy munepy-2.0.1 % cd munepy % bzr reconfigure % bzr add-pipe debian At this point, because I had essentially the source layout for munepy, and not its tarball, I decided to use sdist_dsc to create the basic debian layout: % python setup.py --command-packages=stdeb.command sdist_dsc This command puts the new debian packaging content in a subdirectory called 'deb_dist'. However, I want 'debian' to be in the current directory, so: % mv deb_dist/munepy_2.0.1/debian . % rm -rf deb_dist % bzr add debian % bzr commit -m'Add debian directory' A couple of things: it would be nice if stdeb was able to write the 'debian' directory to the current working directory. Also, if I'm not mistaken, the package resulting from stdeb will use python-central. Should it use python-support instead? I'm still pretty unclear as to the differences, pros, and cons. But okay! Now I have a debian directory with some basic stuff, but those files do need some tweaking. One thing that's missing is the debian/copyright file. munepy is LGPL v3, but I could not find a straightforward way to add the proper debian/copyright file, short of doing a traditional unpacking of the original tarball somewhere, pushd'ing to munepy-2.0.1 and doing: % dh_make -c lgpl % popd % cp .../debian/copyright debian % bzr commit -m'add copyright file' I also had to hack debian/control to add/update the XS-Python-Version, Homepage, and Description headers. I sort of feel like with a little work, stdeb could probably get this information out of the setup.py or the package metadata files once the relevant PEPs are accepted. At this point, I'd forgotten my previous hacking and so tried to use dpkg-buildpackage to build my package, but this did not end well. It didn't respect my GPG keyid preferences and ultimately did not write a munepy_2.0.1.orig.tar.gz or munepy_2.0.1-1.diff.gz. I think remembered debuild, which was happier about my GPG key, but still not completely satisfying (my notes don't remind me why). Ah yes, 'bzr builddeb'! The interesting thing is that builddeb requires a debian/watch file so that it can grab the tarball. Well cool, I've uploaded the tarball to the Cheeseshop, so I just pointed debian/watch to that url and: % bzr add debian/watch % bzr commit -m'added debian/watch' % bzr bd -S Now, here's an interesting question: where do I push my branch to? I can't obviously push it to lp:~barry/ubuntu/lucid/munepy/something and lp:~barry/+junk/munepy-lucid doesn't seem right either. Hmm... % dput -f ppa:barry/python munepy_2.0.1-1_source.changes Now, modulo a detour to get python-distribute 0.6.10 built in my PPA, this actually built a suitable binary package. Yay, that's a good place to stop... for now. So, while it took me several days to figure out, I did manage to build a brand new package for Lucid. I'm sure there are easier ways to do what I did, and any feedback or advice you have would
Re: Recipes vs. Looms vs. pipelines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Resurrecting a thread from a few weeks ago... On Dec 17, 2009, at 01:26 PM, Aaron Bentley wrote: Barry Warsaw wrote: I like this because there are no extra directories to worry about, and I can delete the loom directory in one rm-rf and be completely done with it. This is actually co-location of trees with their branches. You can accomplish this with lightweight checkouts by putting the branch inside the .bzr directory of the branch. $ bzr init foo Created a standalone tree (format: 2a) $ bzr checkout foo bar $ mkdir bar/.bzr/branches $ mv foo bar/.bzr/branches/ $ cd bar $ bzr switch --force .bzr/branches/foo Tree is up to date at revision 0. Switched to branch: /home/abentley/sandbox/bar/.bzr/branches/foo/ Obviously, this is more steps than it should be, but it would be easy to turn into a reconfigure operation. Correct me if I'm wrong, but reconfigure-pipeline is actually pretty close to what I want, I think. 'bzr reconfigure-pipeline' will create a ./pipes directory in the current working tree, and all new pipes will go there. If this was named .bzr/pipes instead I think that would be perfect. I did a quick and dirty hack which seems to DTRT. https://bugs.edge.launchpad.net/bzr-pipeline/+bug/503006 https://code.edge.launchpad.net/~barry/bzr-pipeline/dotfile It does mean that instead of doing a lightweight checkout to start with, I would use a straight up 'bzr branch foo bar' then reconfigure. I could live with that. Maybe a better name for that would be 'init-pipes'. I'll just add that as the sixth essential pipeline alias. :) Hacking reconfigure to set up .bzr/pipes when run in a lightweight checkout might be a good idea too, but I don't think I'll tackle that one. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJLQhQKAAoJEBJutWOnSwa/w88QALxj61jvNuYI18lwRh86uked u/cSpGWFd7cd1lffmw8loFim8tfjUUBLHglMmmlyrIsl/6RCPGk7OhF6vymWWpSZ M1nQEJeUTK4XVzuwPynD5yq0YTNsH45YbNo+WZmAMghC9jFwFq4LM8vhVWf+uULa hwcCYwBYGQYncUTah9kllyjqpATX7Xk4H6tUy3H7EbTzFHoT6ma0WS4WOy62OPrr cqT4qBj0gFeWpcxq12T0Vhgzgvg0vvyh93YrM+A4CKB2jr754GhR+5f0H7oUp9ud 67w+RDzIQkyyWKWbHpyxDWe+VZY3O2jJm4/q431jiWKowEqCjQMxnxbBpq8xJVwE 3jgm0uEK4Vty+aBvDJKZPHOHJqvf1vw+nulps2qnzEzEWkjvKYL1gb2cJ+zcIPaV 5SsmuCsRG7x1UWUBDEbvNW8KuYMeCDqPVLEM3FssJuhu19FyF06FTG/QMDLM49GE JfwCXIvY1Dbujf3j7SHDMGCkOs3AVaBd0mx4UvLXtairklWpq0UPDWIo4ApxeOSm l2TDhpjLl4HbcZSAtcVeI0ezpd/VWK543BcfHs/zDYtgoY6vJQSCog1yuz7+Nf5M S/jqS1kjn1J+T2VApbuXxCR3FuftBHr5VEazC1LfIGVzSL/oyrYxsp8QChh2OnvI SV7HWknL1w2PBD5JSMcQ =Hz3A -END PGP SIGNATURE- -- 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
Re: Recipes vs. Looms vs. pipelines
On Dec 16, 2009, at 4:58 PM, Aaron Bentley wrote: There are a lot of similarities. Some more differences are: - - automatic storing/restoring of uncommitted changes with switch-pipe. - - uncommitted changes in another pipe can be merged. These are very definitely advantages of pipes. I think that there are significant improvements to the command set: In loom, up-thread and down-thread are asymmetric. The analogue of down-thread is switch-pipe, and the analogue of up-thread --auto is pump. The command for removing a pipe is called remove-pipe, whereas the command for removing a thread is called combine-thread. pipeline has lp-submit to submit a merge proposal for a pipe to Launchpad. It is impossible to submit a merge proposal for a thread to launchpad, because threads aren't addressable. pipeline provides pipe-patches, to export the pipeline as a series of patches. Ultimately what both pipes and looms gives me is a way to organize the subtasks I have to perform when developing a piece of software. They let me answer questions and produce output based on those subtasks instead of the more-granular revisions. Both looms and pipelines feel like bolt-ons to support this kind task-based workflow, so pulling those features and supporting those use-cases in core bzr would be a good long-term goal. -Barry -- 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
Re: Recipes vs. Looms vs. pipelines
On Dec 15, 2009, at 11:15 AM, John Arbash Meinel wrote: I would mention that for packaging, I think you really do want to have 'upstream' as the first thread, which doesn't work with the pipeline model, since a given branch can only participate in one pipeline. Not just for packaging. When I'm developing bug fix or feature branches, I always like to have the devel branch as the bottom thread in my loom. Note too though that I want control over when I update the bottom thread independently of when I update the devel branch. This is something that feels more natural to me in looms than in pipelines. Which (IMO) is something that pushes for having a real DAG in the loom state, rather than just a stack model. As it means you can push *just this thread* into upstream, and have them merge it, without them having to merge all of your other changes. Otherwise the loom is just there to help you develop the patch. And then you throw away all the history once the patch gets applied to upstream. I'm being more convinced of this as these discussions proceed. Having a DAG would, I think, resolve some of the trickier branches I've developed with looms. I agree with James that the ui is difficult though. -Barry signature.asc Description: PGP signature -- 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
Re: Recipes vs. Looms vs. pipelines
On Dec 16, 2009, at 01:28 PM, Aaron Bentley wrote: With looms, you get a huge proliferation of threads. I think the only real difference is that threads tend to be less visible than branches. For me, that was a big difference and one of the reasons I currently favor looms over pipelines. We talked in other threads about hiding those pipeline branches so they don't look like siblings in my shared repo directory. That would help a lot. -Barry signature.asc Description: PGP signature -- 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
First impressions (long)
Hi all, I think I've actually patched my first Ubuntu package, with much thanks to Colin and James W for their help. Having done this from essentially no knowledge of how to do it, and no experience with the tools, James suggested I email this list with some feedback and suggestions. Remember, I'm a n00b so be gentle because I have No Idea What I'm Talking About. :) As I understand it, there are essentially two approaches to submitting bug fixes for Ubuntu packages, the traditional way (of which there are some variants), and the Ubuntu distributed development (udd) way, which this list is interested in. I was keen to try both approaches, and kept notes of my steps, both what succeeded and what failed. I then wanted to be able to compare how easy I thought it was to accomplish the task using each approach. There are of course steps in common, like setting up ~/.devscripts and such. Colin found a good first bug for me: https://bugs.edge.launchpad.net/ubuntu/+source/system-config-lvm/+bug/390423 This was great because it's pure Python (something I'm familiar with, even if I didn't know much about the tool itself), there was already a patch attached to the bug, and there was good information and links back to the bug report in the Fedora tracker. So mostly I had to learn a bit of process and experiment with the tools. I won't talk too much about my experiences doing things the traditional way, except to say that I used the pbuilder approach on a kvm VM (host: karmic, guest: lucid). I went thorough a number of fits and starts, but eventually ended up with a debdiff that I could have submitted for sponsorship. I ultimately didn't submit this though, because I then wanted to see what it was like to develop the patch using Bazaar and bzr-builddeb. I'll go in to some detail in moment, but I have to say that for someone who is very comfortable with Bazaar for general software development, using bzr-builddeb was fantastic. Of course I have some suggestions for improvements. :) I /really/ like being able to do almost everything from within bzr because so much of the (seemingly) grunt work of the traditional way was just hidden from me. All I really had to worry about was making sure the patch was sane, testing, an submitting a merge proposal -- all things I already knew how to do. I had to learn a little bit of extra process to build the package the right way, but those were not overwhelming at all (perhaps in part because I had just gone through the exercise using the traditional way, where I did learn a lot). For packages that fit into a similar class as the one I worked on, bzr-builddeb was an easy win. I did go down one false path, and Colin had to teach me about patch systems and dpatch in particular. I think bzr-builddeb could actually help me not go down that path, or point me to the right path, so I'll make some concrete suggestions in a moment. So what did I do? Here are the steps I took (minus some machinations to get debsign to DTRT): * bzr init-repo system-config-lvm * cd system-config-lvm * bzr branch lp:ubuntu/system-config-lvm * bzr branch system-config-lvm 390423-ext4 * cd 390423-ext4 * (download patch from upstream tracker) * patch -p1 patch.txt * dch -i * (add changelog entry) * debcommit * bzr commit --fixes lp:390423 --unchanged * bzr builddeb * (win! or was it?) * (dpkg -i blah; test; confirm fix) * bzr push lp:~barry/ubuntu/lucid/390423-ext4 * bzr lp-open * (submit merge proposal) You probably saw immediately where I went wrong! I didn't know anything about patch systems at this point, so I just committed my changes to the source tree in place. Colin (politely and helpfully!) schooled me that I should have created a patch file instead, left the original source unchanged, and added my patch file to debian/patches/00list. My diff should have included just the new .dpatch file, along with the changes to the changelog and 00list. Instead of backing out my changes, I extracted them from the relevant revisions, doing something like this (at the time): * bzr diff -r6.. | dpatch patch-template -p ext4xfssupport blah debian/patches/ext4xfssupport.dpatch I had to hand edit edit ext4xfssuport.dpatch because it contained a diff to debian/changelog, and then I reverse-merged the relevant revisions to back out the changes to the package's source code. Then I ran 'bzr builddeb' again, but it failed! The problem I think was that dpatch expects to run 'patch -p1' or its moral equivalent on the files in debian/patches, but 'bzr diff' does not include the parent directory by default. Now I understand why 'bzr diff' has a --prefix option. :) So I ran this: * bzr diff -r6.. --prefix system-config-lvm.old/:system-config-lvm/ | dpatch patch-template -p ext4xfssupport blah debian/patches/ext4xfssupport.dpatch This time 'bzr builddeb' ran successfully. I installed the resulting package, tested again, committed my last change and pushed. I now await Colin's re-review. I
