brainstorming for UDS-N - Application Developers

[Scott Kitterman]

On Friday, October 01, 2010 12:56:27 pm Evan Dandrea wrote:
> > On Tuesday, September 28, 2010 05:31:26 pm Rick Spencer wrote:
> > > We want to empower, engage and harness application developers to
> > > develop on and for Ubuntu. These sessions cover the many elements in
> > > achieving that goal.
> > > 
> > > What's high on your list for this area?
> > > 
> > > There are some existing conversations and threads that people should
> > > feel free to comment on in addition to any new areas:
> > > * Changes to the implementation of the New Apps on stable releases
> > > (suggestions have included changing the system to use backports as an
> > > avenue onto a stable release, for example).
> > > * Changes to the Application Review Board process (including, for
> > > example, eliminating it and replacing it with a streamlined backports
> > > process).
> > > * Enhancement, changes to tools such as Glade, Gedit, etc...
> > > * Anything about Quickly and/or Quickly Widgets, including new
> > > templates, improvements to the existing template, new widgets, etc...
> > > * Information Architecture for application developers, including a
> > > developers manual, etc...
> > 
> > If we are going to meet the goal of really streamlining the process for
> > developers to get their applications in front of users, then we need to
> > change what it is that is delivering the application.  I don't think
> > that a traditional Debian package is going to be able to support a truly
> > lightweight process.
> 
> Thank you.  This is something I've been thinking about for quite a while
> and it's comforting to know that I'm not alone in what entrenched minds
> must find to be very radical thinking.
> 
> I think our current architecture for packaging and delivery is built on top
> of some misconceptions.  Namely, that we can solve the problem of buggy
> software getting into Ubuntu by fixing bugs in applications on behalf of
> developers, that packaging needs to be complex, and that we should be and
> ultimately need to be doing the legwork to package these applications
> ourselves.
> 
> Buggy software is going to get into Ubuntu no matter what we do, /but
> that's okay/.  Equally, if we patch these applications ourselves, what
> kind of message is that sending to developers about our trust of them, and
> whose responsibility broken software is?
> 
> If we have to package the applications ourselves because it requires years
> of experience and understanding of an inordinate amount of complexity,
> what does that say about our package management system?
> 
> Instead of handicapping developers based on these misconceptions, we need
> to free them to deploy applications and make choices on their own, then
> deal with the repercussions themselves.  We need to empower our users to
> make the best decisions on what applications they should use without
> having to think hard about their options.  So lets introduce some new
> metrics in Ubuntu Software Center, and lets make it so that they are
> applied to the sorting automatically. We can start by lowering the page
> rank of applications that not only have low ratings or low download
> counts, but also have high bug counts, that have high crash reports, and
> that have a large time delta between bugs and their fixes.
> 
> Lets further build on this to create a tight feedback loop between
> developers and users.
> 
> We need to make it so that developers can quickly deploy an application
> that then appears in Ubuntu Software Center for anyone on that release of
> Ubuntu, regardless of where we our in our own cycle.  We need to make it
> so that users can very quickly provide valuable feedback on these
> applications *directly* to developers in the form of bug reports, crash
> reports, ratings, and reviews.
> 
> These bug and crash reports should be presented in Ubuntu through a common
> desktop interface, but ultimately hit a web API on the backend.  Let
> developers choose what bug tracker and project management system they want
> to use, be it Launchpad or something else.  The important thing is that we
> send bugs straight to them rather than expect users or an overburdened QA
> team to ensure that bugs filed in Ubuntu get back to the developers.  No
> longer will bugs fall into the void.  No longer will there be a separation
> between a packaging bug and a bug in the application.  A bug in the
> software you use is a bug in the software you use; it doesn't matter where
> it ultimately manifests.
> 
> This application deployment system I describe should at no point block on a
> human being from the Ubuntu project like our existing systems, both the
> regular archive and -extras, do.  These quite simply cannot scale. 
> Instead, lets create an automatic system that takes an application
> submission, runs its test suite, does some static analysis, and conducts
> any other sanity checks we can think of before letting it through to the
> archive.  If any of these tests fail, it simply rejects the application
> back to the developer.  Let them worry about fixing it.  Let them take
> complete ownership of their work.
> 
> This system wont catch everything and we shouldn't ever operate on the
> false hope that it will.  All it's meant to do is filter out the very
> worst that we can catch, and leave the rest up to the users to try and
> report back on.
> 
> We should also give the developers flexibility in the way in which they
> stage out these deployments.  We should allow them to offer an application
> to say, 5% of the Ubuntu audience, wait for feedback, and if it doesn't
> have any grave bug reports coming in, push it to the remaining 95%.
> 
> I believe that in order to do this properly, we need to massively simplify
> our packaging model.  Anything that makes a package non-atomic (hello
> maintainer scripts) should be thrown out.  Anything that adds needless
> complexity, equally so.  Packaging needs to be the least important part of
> the puzzle, not the most difficult, and most certainly not at the core of
> our own development efforts.
> 
> We need to make it our goal that any software developer should be able to
> package their application without difficulty and without causing harm to
> the system.
> 
> Most importantly, unlike -extras, we shouldn't restrict this to just
> packages that do not already exist in Ubuntu.  To tell developers that we
> will not let them use this system just because we packaged their software
> first is ludicrous.

This opens up the question of what is Ubuntu delivering?  Should be be 
evolving towards something more like BSD with a base OS and all applications 
are layered on top?  How would we draw the line between what is Ubuntu and 
what is on Ubuntu in this paradigm?

Scott K