On Mon, 2011-05-02 at 13:31 +0200, Lucas Nussbaum wrote:

> Benefits for Debian:
> 
>   * Attract users who think that testing is only a development
>     branch, and want newer software than what one finds in stable.
>     Those users are likely to be rather advanced users (free
>     software developers and contributors), thus interesting to work
>     with (able to submit good-quality bug reports, etc). Some of
>     them could also become Debian contributors. And even if they
>     don't, more users of testing/rolling means more testers of the
>     next stable release [remember how the bug reporting rate of
>     Ubuntu is higher than Debian's -- some areas of Debian could use
>     more testers].
> 
>   * Give back to the free software world by providing a platform
>     where new upstream releases would quickly be available to users.
>     Since users would be able to test new upstream releases earlier,
>     they would be able to provide feedback to upstream devs earlier,
>     contributing to a shorter feedback loop. Debian is often
>     identified by upstream developers as the platform with releases
>     from two years ago. I would love to see Debian in a position to
>     contribute more to improviing the quality of the Free Software
>     world.

Hi all,

First, thank you for this message which summarizes huge mail thread. I
didn't personally read most of the mails, as these are hundreds. So,
please excuse me if I'm repeating something that was already said.

What about keeping the same schema, which is working well
(unstable==>testing==>stable), and just adding a new kind of parallel
release path (unstable==>testing==>desktop) which is a kind of short
cycle release targeting the desktop/laptop market.

Today, testing is quite good quality, but sometimes it get stuck and
cause headaches for a few days rendering PC non usable. So filtering
this kind of things should be easy especially for stable lesser quality
release.

I like Debian's logo quality's first and think we should keep this even
when going to the desktop market. So maybe we need to focus on this way
based on short cycle releases (in addition to the regular release
cycle).

One way is to have a second release team for this purpose. An maybe the
release team could monitor these desktop release in order to decide, the
best time, to base stable on a giver desktop version 


unstable==>testing==>desktop
                      ||==>frozen==>stable

Just my two cents,

Cheers,

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to