Re: UDD health check?
On Tue, 13 Jul 2010 16:44:34 -0400, Barry Warsaw wrote: > >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. It is true that this is recommended practice. However, this is mainly due to the fact that while the Debian package format keeps your changes separate from the upstream source, it is very hard to review and modify multiple patches that aren't in a patch system. I was very strongly in favour of this approach until I had better tools available. Tools such as looms promise to allow the best of both worlds, managing the patches to upstream, while still giving you the full source in version control for things like... > > 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). ... that. Being able to "bzr blame" a file and see when a change was introduced, regardless of whether it is a patch or an upstream change is great. I think that a lot of people don't see that yet as they either avoid the type of work where this action is necessary, or they have ingrained workarounds due to the difficulties and inconsistencies we have now. > 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. Agreed, and I would love to have this too. Maybe you'd like to chat on list or in person next week and see if there are some easy things we can do to move us in that direction? Thanks, James -- 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 Tue, 13 Jul 2010 22:27:52 +0100, Dmitrijs Ledkovs wrote: > On 13 July 2010 18:23, Elliot Murphy wrote: > > On Tue, Jul 13, 2010 at 11:08 AM, Martin Pool wrote: > >> I asked Barry how he was finding the UDD experience > > > >> Any other suggestions/wishes/hates? > > > > I have found UDD very pleasant for doing merges from debian to ubuntu, > > and I *love* using merge proposals to ask for changes to be sponsored > > into Ubuntu. When I want to put a python or erlang package into Ubuntu > > via debian, I end up needing to use SVN and svn-buildpackage which is > > a completely different world/workflow from UDD and that difference can > > be a bit overwhelming at first. > > > > Why not checkout debian/ dir using bzr-svn and add a local > bzr-builddeb config to use this checkout in merge-mode? =) YMMV. Actually, Jelmer made it such that bzr-builddeb will detect this and so it /should/ do the right thing if you just run "bzr bd" in your SVN checkout of DPMT. Bugs welcome if it doesn't, or if there are other things we can do to make this work easier. I'm all for getting collaboration with Debian to the same point as we are at with UDD just targetting Ubuntu. I think one issue is that I only really considered "Ubuntu developer that just sends patches to Debian" and "Ubuntu developer that can upload the package to Debian," not "Ubuntu developer that can commit to Debian SVN." Thanks, James -- 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 13 July 2010 18:23, Elliot Murphy wrote: > On Tue, Jul 13, 2010 at 11:08 AM, Martin Pool wrote: >> I asked Barry how he was finding the UDD experience > >> Any other suggestions/wishes/hates? > > I have found UDD very pleasant for doing merges from debian to ubuntu, > and I *love* using merge proposals to ask for changes to be sponsored > into Ubuntu. When I want to put a python or erlang package into Ubuntu > via debian, I end up needing to use SVN and svn-buildpackage which is > a completely different world/workflow from UDD and that difference can > be a bit overwhelming at first. > Why not checkout debian/ dir using bzr-svn and add a local bzr-builddeb config to use this checkout in merge-mode? =) YMMV. > When/where to use the bzr mark-uploaded command when sponsoring > someone elses work is a bit mysterious to me. > > Overall UDD just works for me and generally stays out of my way. > -- > Elliot Murphy | https://launchpad.net/~statik/ > > -- > 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 > -- 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 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: UDD health check?
On Tue, Jul 13, 2010 at 4:04 PM, Barry Warsaw wro > but it seems to have some advantages for the way I work. This is cool, thanks for 'splaining. > Where does your debian/ directory live in the dvcs cloud? IOW, do you have a > separate unrelated branch that just includes debian/ and do you push that to > LP? Or does that live only in Debian's svn once you've injected it (i.e. you > only make packaging changes to that directory). The latter, I only make packaging changes in that directory, I don't bother with a DVCS cloud version. I have contemplated using bzr-svn to pull the DPMT SVN repository so that I can diff things without hitting the network, but haven't done it yet. > Do you spin PPAs from that > same debian/ directory or do you make a branch of that to do the PPA changelog > dance? I just edit the changelog revision number to put the PPA ~lucid1/~maverick1 style suffixes, build/test/sign/upload, and then svn revert. > The debian/ directory is certainly separate, but it's also related. E.g. when > you branch an Ubuntu source package, e.g. `bzr branch lp:ubuntu/simplejson` > what do you get? A sourceful layout with an embedded debian/ directory. 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). -- Elliot Murphy | https://launchpad.net/~statik/ -- 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 03:26 PM, Elliot Murphy wrote: >On Tue, Jul 13, 2010 at 2:47 PM, Barry Warsaw >wrote: >> As an example: I'm trying to get two of my spinoff Python packages >> into Ubuntu, via Debian. They are packaged in neither atm. I'm the >> upstream maintainer and the projects are hosted on Launchpad, so it >> starts off easy enough by creating a branch of trunk, and loomifying >> the work branch. I create a thread for Debian development, use >> stdeb to create the initial debian/ directory, then create a thread >> for Ubuntu. This latter is what I build the source package for the >> PPA from. >> >> This is a nice arrangement because as I modify the trunk (and make >> non-Debuntu releases), I can pull the trunk into the bottom thread, >> up-thread --auto and be ready to spin a new PPA (yes, I know, I >> haven't yet started to use build-from-branch). >> >> The debian thread is less useful though, because what the DPMT wants >> is *just* the debian/ directory in their svn, and that workflow is >> completely different. The last update I made, I resorted to >> rsync'ing the debian directory to an svn checkout from alioth. Not >> fun. > >This is fascinating to me. I still can't quite grok the reason for >using bzr at all in this case, and I'd be interested in understanding >what it gives you. I don't understand how you are able to work from a >bzr branch when packages want orig tarballs. I have been working >exclusively from tarballs that I upload to launchpad/pypi, then >copy/paste/edit a debian/ directory with a watch file, build the >initial source package, and svn-inject it. Then I sync to ubuntu and >would use UDD if I needed to do an Ubuntu specific patch only after >the importer set up all the branches. I don't claim any brilliance or efficiency in the way I have things set up, but it seems to have some advantages for the way I work. The first thing is that everything I do lives under subdirectories in my ~/projects directory. If a package is maintained under bzr subdirectories under that will be shared repos. So for example, all my work on flufl.enum, be it as the upstream maintainer, packager, whatever, will live under ~/projects/flufl.enum (well, tbh, I tend to throw all namespace package under an umbrella shared lib, e.g. ~/projects/flufl/flufl.enum will be the trunk of that package's upstream code). I like to use stdeb to create the initial debian directory for Python packages, because it understands distutils-isms and will initialize things like the control file from setup.py. So `python setup.py debianize` makes it really easy to get a functional, nearly complete packaging layout. Yes, you've got the source and no tarball, but still, you're pretty close to a useable package right at that point. stdeb has a few bugs and annoyances, so you still have to manually edit things, but you're darn close already. I also have a debian/watch file pointing to my Cheeseshop tarball (automating this is something I want to add to stdeb). Almost always the next thing I want to do is throw the package in my PPA, so it's pretty easy at that point to `bzr bd -S`, and dput the results to my PPA. The fact that the source, while unnecessary, is still there, can be helpful if I need to consult say the NEWS file or other changes for updating debian/changelog. I do sometimes want to just pdebuild (`bzr bd`) a .deb right there and then. Also, if I find that I need to make changes in the upstream source in order to improve the packaging in my PPA, I've got everything I need right there (in that case, a `python setup.py sdist` gives me a tarball that can substitute for the watched upstream release). Plus now I've got my dvcs tools available to merge any of those relevant changes back into my trunk. Having the debian/ directory living in a sourceful branch also gives me a little more comfort than a lone debian/ directory just floating out there. This is probably just a crutch from years of wanting everything for a project under one roof. This arrangement is also kind of nice when I push the branch and pull it from another machine, which I do often. Having everything living in a loom (now that these can be pushed and pulled from LP without loss of fidelity) means I can really keep everything together and just hop around, branch one thing and get all my work back. Where does your debian/ directory live in the dvcs cloud? IOW, do you have a separate unrelated branch that just includes debian/ and do you push that to LP? Or does that live only in Debian's svn once you've injected it (i.e. you only make packaging changes to that directory). Do you spin PPAs from that same debian/ directory or do you make a branch of that to do the PPA changelog dance? The debian/ directory is certainly separate, but it's also related. E.g. when you branch an Ubuntu source package, e.g. `bzr branch lp:ubuntu/simplejson` what do you get? A sourceful layout with an embedded debian/ directory. So in that sense,
Re: UDD health check?
On Tue, Jul 13, 2010 at 2:47 PM, Barry Warsaw wrote: > As an example: I'm trying to get two of my spinoff Python packages into > Ubuntu, via Debian. They are packaged in neither atm. I'm the upstream > maintainer and the projects are hosted on Launchpad, so it starts off easy > enough by creating a branch of trunk, and loomifying the work branch. I > create a thread for Debian development, use stdeb to create the initial > debian/ directory, then create a thread for Ubuntu. This latter is what I > build the source package for the PPA from. > > This is a nice arrangement because as I modify the trunk (and make non-Debuntu > releases), I can pull the trunk into the bottom thread, up-thread --auto and > be ready to spin a new PPA (yes, I know, I haven't yet started to use > build-from-branch). > > The debian thread is less useful though, because what the DPMT wants is *just* > the debian/ directory in their svn, and that workflow is completely > different. The last update I made, I resorted to rsync'ing the debian > directory to an svn checkout from alioth. Not fun. This is fascinating to me. I still can't quite grok the reason for using bzr at all in this case, and I'd be interested in understanding what it gives you. I don't understand how you are able to work from a bzr branch when packages want orig tarballs. I have been working exclusively from tarballs that I upload to launchpad/pypi, then copy/paste/edit a debian/ directory with a watch file, build the initial source package, and svn-inject it. Then I sync to ubuntu and would use UDD if I needed to do an Ubuntu specific patch only after the importer set up all the branches. -- Elliot Murphy | https://launchpad.net/~statik/ -- 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 01:23 PM, Elliot Murphy wrote: >On Tue, Jul 13, 2010 at 11:08 AM, Martin Pool >wrote: >> I asked Barry how he was finding the UDD experience > >> Any other suggestions/wishes/hates? > >I have found UDD very pleasant for doing merges from debian to ubuntu, >and I *love* using merge proposals to ask for changes to be sponsored >into Ubuntu. When I want to put a python or erlang package into Ubuntu >via debian, I end up needing to use SVN and svn-buildpackage which is >a completely different world/workflow from UDD and that difference can >be a bit overwhelming at first. Contrary to what my morning irc ranting might imply, I have to echo Elliot's enthusiasm for UDD, in the context of Ubuntu development. For me, it's an absolute joy to bzr branch lp:ubuntu/whatever, hack, commit, push, mp, review, etc. There are a few rough edges of course, but they're not insurmountable. I do intend to submit bugs on them, but just haven't gotten 'round to it yet. I would love to get the loom/pipeline story nailed down. I still find looms a more natural ui to work with, even though I can appreciate Aaron et al's preference for the pipeline model. Similar to Elliot, where UDD breaks down is in interfacing with Debian development, which I find I have to do quite often. I suppose that's understandable given the leading 'U' in the acronym, but it would still be nice if things could be easier. As an example: I'm trying to get two of my spinoff Python packages into Ubuntu, via Debian. They are packaged in neither atm. I'm the upstream maintainer and the projects are hosted on Launchpad, so it starts off easy enough by creating a branch of trunk, and loomifying the work branch. I create a thread for Debian development, use stdeb to create the initial debian/ directory, then create a thread for Ubuntu. This latter is what I build the source package for the PPA from. This is a nice arrangement because as I modify the trunk (and make non-Debuntu releases), I can pull the trunk into the bottom thread, up-thread --auto and be ready to spin a new PPA (yes, I know, I haven't yet started to use build-from-branch). The debian thread is less useful though, because what the DPMT wants is *just* the debian/ directory in their svn, and that workflow is completely different. The last update I made, I resorted to rsync'ing the debian directory to an svn checkout from alioth. Not fun. In summary: UDD is awesome, and I hope you keep making it awesomer. :) -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 health check?
On Tue, 13 Jul 2010 13:23:27 -0400, Elliot Murphy wrote: > When/where to use the bzr mark-uploaded command when sponsoring > someone elses work is a bit mysterious to me. When you upload the package to it's destination (Ubuntu in this case); you "mark" the package as "uploaded." > Overall UDD just works for me and generally stays out of my way. Great! Thanks, James -- 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 Tue, Jul 13, 2010 at 11:08 AM, Martin Pool wrote: > I asked Barry how he was finding the UDD experience > Any other suggestions/wishes/hates? I have found UDD very pleasant for doing merges from debian to ubuntu, and I *love* using merge proposals to ask for changes to be sponsored into Ubuntu. When I want to put a python or erlang package into Ubuntu via debian, I end up needing to use SVN and svn-buildpackage which is a completely different world/workflow from UDD and that difference can be a bit overwhelming at first. When/where to use the bzr mark-uploaded command when sponsoring someone elses work is a bit mysterious to me. Overall UDD just works for me and generally stays out of my way. -- Elliot Murphy | https://launchpad.net/~statik/ -- 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 health check?
I asked Barry how he was finding the UDD experience so far and this is what he said: poolie: there are several things, from small to large poolie: i haven't had much time to file bugs on bzr-builddeb, but there are a few things that always get me poolie: the much bigger issue is how to better integrate with e.g. the way debian developers want to do things poolie: for example, i'm working on a couple of python packages which i'd like to get into ubuntu. but i'm supposed to go through debian first. only dd's have a much different workflow that does not play well at all with ubuntu poolie: that kind of thing i think will take some f2f discussions poolie: on the simpler side, one of the things that always hits me is trying to use 'bzr bd -S' and getting nailed by not having the .orig.tar.gz poolie: and looms (or pipelines with looms nice ui :). would love to get that settled Any other suggestions/wishes/hates? -- Martin -- 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
