Release management thoughts for Dapper Drake

[Sivan Green]

On 09:52, Mon 17 Oct 05, Martin Pitt wrote:
> Frankly, I do not believe that the majority of breakage that users see
> was introduced by Debian bug fixes and server/base package syncs; it's
> the desktop, user profile migration, and hardware support that cause
> the major breakage, so we should concentrate on fixing those instead
> of spending a lot of work in reviewing Debian revisions (we should
> automatically sync those and only take a look in the changelog if
> there is a new upstream version).

Again, I'd like to second that. In my network of enterprise
contacts who have been using Ubuntu due to my
recommendations, have seen more breakage on the desktop
side, while their "server" oriented setups (Apache,VMWare,
MySQL etc..)  sustained and continued working with small or 
no effort at all.

> 
> From my experience, a lot of effort that was spent for Breezy went in
> (1) the gcc transition, which should not be an issue for Dapper, and
> (2) implementing a really high number of specifications. So I feel
> that if we want to get something more stable than Breezy in Dapper, we
> should completely avoid implementing specs and rather concentrate our
> full development capacity on bug fixing. If we also narrow down the
> window for autosyncs and new upstream versions, we have much more time
> for bug fixing than we had for Breezy.

Not devoting resources for implementing new goals and
features at all sounds to me a bit harsh. Maybe a good
tradeoff could be to do define irreversible freeze points 
for the desktop crack that have been known to cause breakage 
and drain resources.  This would allow us to concentrate on
stabilization rather then cope with newest GNOME tarballs as
we attempt to make them in for release.

So basically, that's suggesting being a little bit more
conservative on the desktop side. 

Comments?

Sivan

> -- 
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel