[ubuntu-marketing] Making Canonical's/Ubuntu's contributions more visible

[Bryce Harrington]

On Wed, Jun 04, 2008 at 11:11:05PM +0800, John McCabe-Dansted wrote:
> On Tue, May 27, 2008 at 6:20 PM, Bryce Harrington <bryce at canonical.com> wrote:
> >> It could perhaps make things even easier for developers, but thats
> >> another kettle of fish.
> >
> > I'd be interested in hearing your further thoughts on this.  (I've had
> > my own thoughts on this, but would love to see other's ideas.)
> 
> Well the development aspects of Ubuntu aren't as polished as the
> end-user facing applications. Unlike firefox and OO, pbuilder and
> make-kpkg don't really "just work".
> 
> In principle, developing could be as simple as doing "dev edit
> <package-name>" finding whatever you wanted to change, perhaps
> changing a constant like MAX_COL from 80 to 160 in your favourite
> editor, doing a "dev test-sandbox", and perhaps a "dev install".
> Perhaps then there could be
> run a simple "dev share" command which would the developer to, at
> their leisure, annotate each of their patches and upload them
> somewhere others could re-use and comment on them.

I think you're onto some good ideas here.

This probably sounds odd, but the thing that "sold" me on Ubuntu/Debian
over gentoo and emerge was of all things 'apt-get source'.  I use that a
gazillion times a month, and I love how easy it makes it to get in and
poke at stuff.

You're definitely right that the steps involved in creating a package
once you've got the source is not as straightforward as it could be for
a newb (I've got it in finger muscle memory now, but the first few weeks
were tough).  It would be awesome if there was a simplified workflow
something like: 

1.  $ apt-get source foo

2.  $ cd foo; #hack hack

    Allow the user to edit the code tree directly, no worries about
    patch systems, etc.

3.  $ sudo apt-get build

    Run from within the source tree, this wrappers all the work of
    generating a patch from the current source tree's changes and adding
    it to the package's patch management system (or adding a patch
    management system if one doesn't exist), running debuild, set up a
    pbuilder environment if needed, run pbuilder to produce the
    (unsigned) debs, and place them in the parent directory.

    Would be nice to not have to run it as root, but not sure that
    there's an easy way of running pbuilder as non-root.

4.  $ apt-get share [bug id | package-name]

    Like you mention, presents user with a list of their outstanding
    patches applicable for the given bug or package (or all in the
    system), prompts for annotation, allows gpg-signing, and uploads to
    the appropriate place.  Maybe a PPA, or maybe sending directly to a
    Launchpad bug ID, with request to add to ubuntu and/or debian.

Of course, the above paints over a huge amount of implementational
complexity.  Perhaps this could only be achieved for certain well-formed
packages. 

Bryce