On Jul 19, 2010, at 05:59 PM, Francis J. Lacoste wrote: >My theory is that usage is increasing but among a core group of >people. So a few more people try it out, but haven't persisted in >making the switch. But the ~15-25 people how are really using it are >using it more. > >Does that seem consistent with your views of the current usage? What >is blocking more users from jumping on the UDD bandwagon?
I'm trying to use UDD as much as possible, so here are my thoughts. For someone like Scott, who is a very experienced and knowledgeable developer, UDD might be promising but isn't yet compelling enough to replace the tools and processes they've built up over the years. I don't want to put words in his mouth, but I suspect that UDD seems like just another of the many options for doing packaging. For someone like me, unburdened <wink> by previous packaging experience, UDD is very compelling but still has warts that make it painful at times. Creating packages feels just like upstream software development, with good practices for versioning, branching, diffing, and merging. Probably most interesting for me is that it presents a unified ui to all the underlying tools. To a new packager like me, the traditional tools seem like a random accretion of various commands, options, and magic. Having a consistent 'bzr' front end that helps support compliance with policy and best practices, feels very natural and much more discoverable. I had a great discussion with JAM and JamesW yesterday about some of the things that regularly bite me, and I plan on submitting bug reports[1] for the specific issues. There are a couple of larger themes I've noticed though. * When everything works, it's great for Ubuntu development. When the branch imports are up-to-date, you can branch source packages for PPA upload, merge proposals, patches, etc. very quickly and easily. Creating binary packages is slightly more work, but not so bad once your environment is set up. Failure modes are difficult to suss out, but with experience you learn workarounds (e.g. cryptic dpkg-buildpackage failure == build-deps missing). * UDD needs more support for integrating with Debian processes. For DPMT uploads at least, there are enough differences between Ubuntu and Debian best practices that the latter is considerably more time consuming and unnatural. * Looms[2] mostly rock, but need some improvement to better support common workflows. I really appreciate all the recent fixes and work toward making them first-class citizens, and more thought is needed to suss out the best way to support some of the workflows I (think I) want. * Better documentation. There are wiki pages, JamesW docs, and /usr/share/docs, but I think some consolidation and elaboration is still necessary. * More publicity and evangelizing. Some of these things aren't hard to address. For example, I've promised JAM and JamesW that I'll work on the documentation and write some blog posts in exchange for bug fixes :). Some things will need more discussion and experimentation. But I'm personally convinced that UDD is the future of Ubuntu development. -Barry [1] Just a summary of some of the bugs we identified: * increased verbosity so you can see exactly what is being called * debian/ directory export to svn for Debian submission * package-import.u.c status pages for every package * bzr branch ubuntu:<binary|source>pkgname * bzr branch reports when package imports have been failing * getting pristine-tar into workflow when necessary * loom thread reordering(?) * conversion from threads to patch system * bzr dput == bzr tag && dput blah * tags aren't versioned (JAM, JamesW, did I miss anything?) [2] I get that there is disagreement about whether looms or pipelines are the best technology to use. I still personally believe that looms are a more natural way to organize related changes. Perhaps it's "just" a ui issue, but I still like looms much better, and it's especially cool to be able to version the thread relationships, and push and pull them to Launchpad.
signature.asc
Description: PGP signature
-- ubuntu-distributed-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
