FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-02-2011, 11:31 AM
Lucas Nussbaum
 
Default Debian rolling: tentative summary

Hi,

Since I already sent too many mails in the 'rolling' discussion, I
decided to send one more. Here is an attempt at a summary of what was
said so far. It might not be complete, it's probably a bit biased, but I
hope that it's still better than nothing. When replying, please try to
focus on specific points, and change the subject accordingly.

Motivations
===========
There's some user demand for rolling releases[1]. For evidence, one
can look at the usage of Debian testing or unstable which clearly
goes further than the Debian development community. Or at the
quickly growing market share of ArchLinux. Or at the interest in
LinuxMint and Aptosid. Or at the DPL's report of his
interactions with the press[2].

Debian's only official product is its stable releases. While it's a
clearly great and useful product, many users and developers don't
recognize themselves in it: it contains software that is too old for
their needs. The success of Ubuntu is related to this problem:
Ubuntu proposes a different compromise between stability and
up-to-date-ness.

While concurrencing Ubuntu with more frequent stable releases
(released every 6-months, for example) doesn't look like the right
thing to do, Debian is in a perfect position to provide a rolling
release with marginal additional work, since Debian already has
testing (and unstable) to build on.

The rolling discussion investigates how we could endorse the concept
of a rolling release, provided as a product in addition to stable
releases. This rolling release would be based on the current testing
branch.

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.

* Get back some attention that is currently taken away from Debian
by derivatives. This is important to carry our political or
technical messages, which are not necessarily carried out by our
derivatives.

Current proposed plan for rolling
=================================
(Disclaimer: this is mostly my view. It is shared by others, but
some details might not be)

rolling is mostly about (external) communication. It is not expected
to change our development processes fundamentally.
It would be a statement by the project (through a GR, for example).
A very preliminary draft was proposed by Raphael Hertzog[3]:

Title: Debian endorses usage of testing by end-users, and renames
it to rolling

The Debian project recognizes that the Debian testing
distribution-initially created to make it easier to prepare and
test the next stable release-has become a useful product of its
own. It satisfies the needs of users who are looking for the
latest stable versions of software and who can cope (or even
appreciate) a system that's constantly evolving.

The Debian project decides to endorse this usage and will strive
to provide a good experience to users of "testing". To better
communicate this policy change to our users, "testing" will be
renamed "rolling".

Yes, it's mostly "PR bullshit", and I don't expect it to
significantly change Debian development processes. However,
communication is necessary if we want to attract new users. What
would change is more attention from developers to what happens in
testing/rolling, which is a good thing since a better
testing/rolling makes it easier to create stable releases from it.

Open questions
==============
Most of the discussion is about the influence of the introduction of
`rolling' on Debian development processes, and in particular, on the
painful process resulting in stable releases. Many fear that, with
`rolling', it will be harder to get stable releases out.

The root question is: if we do `rolling', what do we do during
freezes? Several options have been mentioned in the thread:

1. We could decide not to do anything special: just freeze rolling
for ~6 months, as we used to freeze testing. That might bore
people who like the constant flux of new upstream releases, but
if we decide that it's the only way to ensure high-quality
stable releases, so be it.
2. We could decide to fork a frozen branch when we freeze, and
continue to manage rolling using migrations from unstable.
3. We could mix both solutions: freeze rolling for 3 months, so
that most of the stabilization work occurs with a single active
branch, and then, for the final release preparation, fork frozen
off rolling, and unfreeze rolling.

Two kinds of objections have been raised:

* Those against the rolling concept:
* "It's only about PR, Debian isn't about PR." Answer: PR
does matter sometimes, especially if we want to attract
users.
* "There's usually no installer for it, other than installing
the latest stable release and dist-upgrading, which doesn't
always work." Answer: True; but it sounds like an
acceptable problem. And if upgrades from the latest stable
fail, it's an RC bug, so we would like to know. And if we
do get d-i betas, it's a great way to get user testing for
them.
* It will split the developers base between supporting
`rolling' and supporting stable releases (which also need
to be supported after they have been released). Answer:
already the case today.
* Testing is not targeted at end users, but is a tool for the
release team to create stable releases. It needs to stay
that way. Answer: really, can't we do both?
* Renaming testing to rolling will require changes in many
parts of Debian infrastructure. Answer: some problems can
be mitigated by keeping a testing symlink. The remaining
impact needs to be evaluated.

* Those against the "two development branches during freezes"
problem:
* It splits the users and developers base between two
branches (less users means less bug reports ; less
developers means less bug fixing). Answer: true.
* It requires the use of two different entry points for
packages (unstable for packages targeted at rolling,
frozen-proposed-updates for packages targeted at frozen).
Answer: true.
* All in all, huge overhead for the release team. Answer:
true.
* Overhead for developers, who need to support two targets.
Answer: true.
* Just after a stable release, we would start the next
release from rolling, instead of stable. So we would start
from a "less clean" base. Answer: true.
* It's even worse if you consider staged freezes (freezing
base packages earlier than the rest of the distribution,
for example). Answer: true; but is it really a problem if
some base packages are frozen in rolling for a few months?

Other things that were discussed:
* possible changes to processes around testing to make it more
usable (reduce the set of architectures required for migration
to testing ; allow/encourage usage of t-p-u to rebuild unstable
packages that are ready to transition except for the fact that
they are entangled in a transition ; have different level of RC
bugs: there are RC bugs that are acceptable in rolling that are
not acceptable in stable)
* PPAs for Debian
* Developer activity during freeze (developer temporarily stopping
to work on Debian during freezes)
* Let's improve our packaging process or reduce the duration of
our freezes before introducing rolling. Answer: but then,
shouldn't we also stop doing stable releases for a while?
* Setting up an official "rolling instance". Answer: that can't
work. detailed answer[4]
* Using unstable instead of testing as the basis for rolling.
Answer: there seems to be more demand for something similar to
testing, than for something similar to unstable.

Tentative personal conclusion
=============================
I have the impression that advertising testing as a rolling release
usable by end-users is generally considered a good thing.
The renaming of testing to rolling is not as consensual, but most
opponents have a "whatever ; if you want" position.

How we deal with freezes is the hard point in this discussion. I'm
personnally in favor of the "freeze rolling for 3 months, then fork
frozen and unfreeze rolling" plan, though it has some problems too
(it is not clear whether the required manpower really decreases at
the end of freezes).

Where do we go from there? After another round of discussion, we
might postpone the "how to deal with freezes" question to later, and
proceed with a GR to measure the support for the "testing for
end-users + s/testing/rolling/" proposal.

[1] http://en.wikipedia.org/wiki/Rolling_release
[2] http://article.gmane.org/gmane.linux.debian.devel.general/161527
[3] http://raphaelhertzog.com/2011/04/29/do-we-need-project-wide-support-for-debian-rolling/
[4] http://article.gmane.org/gmane.linux.debian.devel.general/161517

- Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110502113131.GA18413@xanadu.blop.info">http://lists.debian.org/20110502113131.GA18413@xanadu.blop.info
 
Old 05-02-2011, 11:42 AM
Samuel Thibault
 
Default Debian rolling: tentative summary

Lucas Nussbaum, le Mon 02 May 2011 13:31:31 +0200, a écrit :
> How we deal with freezes is the hard point in this discussion. I'm
> personnally in favor of the "freeze rolling for 3 months, then fork
> frozen and unfreeze rolling" plan, though it has some problems too
> (it is not clear whether the required manpower really decreases at
> the end of freezes).

And what I'm afraid of is that a lot of developers will see this
switching point as "ok, now it's debian-release's matter, I can again
focus on rolling only"...

Samuel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110502114205.GJ5781@const.bordeaux.inria.fr">htt p://lists.debian.org/20110502114205.GJ5781@const.bordeaux.inria.fr
 
Old 05-02-2011, 12:42 PM
Pierre Habouzit
 
Default Debian rolling: tentative summary

On Mon, May 02, 2011 at 01:31:31PM +0200, Lucas Nussbaum wrote:
> Hi,
>
> Since I already sent too many mails in the 'rolling' discussion, I
> decided to send one more. Here is an attempt at a summary of what was
> said so far. It might not be complete, it's probably a bit biased, but I
> hope that it's still better than nothing. When replying, please try to
> focus on specific points, and change the subject accordingly.

That's a decent summary of what was said I think.

Though I feel that to make the discussion more solid, the following is
missing:

- What are the problems you try to address with rolling? And no "the
users want it" isn't an answer, I'd reply "why do they want it" if
that's the answer I get.

- Are we sure that rolling is the best way to address those problems?

- What is rolling exactly ?


I'd add a few questions:
- we acknowledged that some derivatives (e.g. aptosid) are doing the
work of stabilizing unstable. Isn't it a better way of doing things
in the sense that it doesn't harm testing a bit? IOW wouldn't it be
a better idea to somehow (with their consent) swallow a derivative
that seems to do what you want to instead of suffering NIH and
reinvent something a derivative does?

- I'll stress again that testing is a release tool, and sometimes to
unblock large transitions it's easier to remove a package from the
distribution so that it doesn't block thousands of other, or because
the breakage it introduces is too large. This practice is very
important, and I remember the release team having strong
altercations with other DDs at the time whereas testing wasn't
targeted at users. What would it be if testing becomes more user
targetted? Should the removal policies be amended ? Beware, I think
it's a huge no-go for the release team.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110502124205.GE23327@madism.org">http://lists.debian.org/20110502124205.GE23327@madism.org
 
Old 05-02-2011, 03:48 PM
Scott Kitterman
 
Default Debian rolling: tentative summary

On Monday, May 02, 2011 07:31:31 AM Lucas Nussbaum wrote:
...
> How we deal with freezes is the hard point in this discussion. I'm
> personnally in favor of the "freeze rolling for 3 months, then fork
> frozen and unfreeze rolling" plan, though it has some problems too
> (it is not clear whether the required manpower really decreases at
> the end of freezes).
...

There is a ton of complexity hidden under these simple words. There is also
(that I can immediately think of):

- How do we provide a reliable path for fixes to Testing once Unstable/Rolling
have moved on?

- How do we stitch Testing/Rolling back together after a release into the new
Rolling?

- How do we allow for more parallel transitions so that rolling can actually
roll.

The first two points have gotten a lot of discussion. The third one, not so
much.

The Debian archive has gotten large enough with enough non-trivial
intersections between groups of packages that transitions of almost any size
need coordination and analysis to find an appropriate time to land in order to
minimize deadlocks in Unstable -> Testing (or whatever you call it)
transitions.

If you view this exercise as primarily a PR move to make Testing seem more
attractive to users that want a rolling distribution, then I suggest we
arrange things so it can actually roll.

As an example, my desktop environment of choice (KDE) is still a year (and two
major releases) out of date in Debian Unstable/Testing. Current packages
exist in Experimental, but can't get to Unstable let alone some theoretical
Rolling because there's no transition window.

I don't think that someone who is attracted to the idea of a Rolling release
to get the latest and greatest would find this met their expectations.

Without solving the problem of the need to serialize transitions, I doubt
Rolling will match the expectations such a change would engender and while
there would no doubt be publicity, I'm skeptical it would be the good kind.

Scott K


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201105021148.28250.debian@kitterman.com">http://lists.debian.org/201105021148.28250.debian@kitterman.com
 
Old 05-02-2011, 04:23 PM
Jan Hauke Rahm
 
Default Debian rolling: tentative summary

On Mon, May 02, 2011 at 02:42:05PM +0200, Pierre Habouzit wrote:
> On Mon, May 02, 2011 at 01:31:31PM +0200, Lucas Nussbaum wrote:
> > Hi,
> >
> > Since I already sent too many mails in the 'rolling' discussion, I
> > decided to send one more. Here is an attempt at a summary of what was
> > said so far. It might not be complete, it's probably a bit biased, but I
> > hope that it's still better than nothing. When replying, please try to
> > focus on specific points, and change the subject accordingly.
>
> That's a decent summary of what was said I think.
>
> Though I feel that to make the discussion more solid, the following is
> missing:
>
> - What are the problems you try to address with rolling? And no "the
> users want it" isn't an answer, I'd reply "why do they want it" if
> that's the answer I get.

Not that I don't understand your asking for reasons but... doesn't look
having a large user base look somehow appealing to you? I think many DDs
care for such since working on Debian brings more fun if someone's
actually using it.

Anyways...

> I'd add a few questions:
> - we acknowledged that some derivatives (e.g. aptosid) are doing the
> work of stabilizing unstable. Isn't it a better way of doing things
> in the sense that it doesn't harm testing a bit? IOW wouldn't it be
> a better idea to somehow (with their consent) swallow a derivative
> that seems to do what you want to instead of suffering NIH and
> reinvent something a derivative does?

How does such swallowing look like? Add a suite 'aptosid' or 'ubuntu'?

> - I'll stress again that testing is a release tool, and sometimes to
> unblock large transitions it's easier to remove a package from the
> distribution so that it doesn't block thousands of other, or because
> the breakage it introduces is too large. This practice is very
> important, and I remember the release team having strong
> altercations with other DDs at the time whereas testing wasn't
> targeted at users. What would it be if testing becomes more user
> targetted? Should the removal policies be amended ? Beware, I think
> it's a huge no-go for the release team.

I think, those in favor of advertising testing or rolling or whatever
you call it have explained repeatedly that stable is still the primary
target for Debian. If at some point that may change, things can be
rethought but until then I don't think any such policy needs changing.

Hauke

--
.'`. Jan Hauke Rahm <jhr@debian.org> www.jhr-online.de
: :' : Debian Developer www.debian.org
`. `'` Member of the Linux Foundation www.linux.com
`- Fellow of the Free Software Foundation Europe www.fsfe.org
 
Old 05-02-2011, 04:27 PM
Martin Wuertele
 
Default Debian rolling: tentative summary

* Jan Hauke Rahm <jhr@debian.org> [2011-05-02 18:23]:

> Not that I don't understand your asking for reasons but... doesn't look
> having a large user base look somehow appealing to you? I think many DDs
> care for such since working on Debian brings more fun if someone's
> actually using it.

Why do you believe that this will increase our user base? It might, in
case less focus is put on stable, even reduce our user base (on the
coporate and server environment).

Yours
Martin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110502162702.GD26067@anguilla.debian.or.at">http ://lists.debian.org/20110502162702.GD26067@anguilla.debian.or.at
 
Old 05-02-2011, 04:31 PM
Jan Hauke Rahm
 
Default Debian rolling: tentative summary

On Mon, May 02, 2011 at 06:27:02PM +0200, Martin Wuertele wrote:
> * Jan Hauke Rahm <jhr@debian.org> [2011-05-02 18:23]:
>
> > Not that I don't understand your asking for reasons but... doesn't look
> > having a large user base look somehow appealing to you? I think many DDs
> > care for such since working on Debian brings more fun if someone's
> > actually using it.
>
> Why do you believe that this will increase our user base? It might, in
> case less focus is put on stable, even reduce our user base (on the
> coporate and server environment).

Firstly, I'm not saying that. Secondly, that's one of the main arguments
to introduce said changes. The argument was (not that it wasn't written
out often enough) that derivatives provide something we don't: more
current software; some as rolling releases, some on scheduled releases
etc. The idea is, if we provide something similar, not the same of
course, users who care for such come to us. It's as simple as that.

Hauke

--
.'`. Jan Hauke Rahm <jhr@debian.org> www.jhr-online.de
: :' : Debian Developer www.debian.org
`. `'` Member of the Linux Foundation www.linux.com
`- Fellow of the Free Software Foundation Europe www.fsfe.org
 
Old 05-02-2011, 04:44 PM
Martin Wuertele
 
Default Debian rolling: tentative summary

* Jan Hauke Rahm <jhr@debian.org> [2011-05-02 18:31]:

> On Mon, May 02, 2011 at 06:27:02PM +0200, Martin Wuertele wrote:
> > * Jan Hauke Rahm <jhr@debian.org> [2011-05-02 18:23]:
> >
> > > Not that I don't understand your asking for reasons but... doesn't look
> > > having a large user base look somehow appealing to you? I think many DDs
> > > care for such since working on Debian brings more fun if someone's
> > > actually using it.
> >
> > Why do you believe that this will increase our user base? It might, in
> > case less focus is put on stable, even reduce our user base (on the
> > coporate and server environment).
>
> Firstly, I'm not saying that. Secondly, that's one of the main arguments
> to introduce said changes. The argument was (not that it wasn't written
> out often enough) that derivatives provide something we don't: more
> current software; some as rolling releases, some on scheduled releases
> etc. The idea is, if we provide something similar, not the same of
> course, users who care for such come to us. It's as simple as that.

I've read that arguement over and over. However the resources are
limited and I have not yet read an actual proposal or plan how to do
that without reducing the resources for the stable releases.

yours,
Martin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110502164411.GF26067@anguilla.debian.or.at">http ://lists.debian.org/20110502164411.GF26067@anguilla.debian.or.at
 
Old 05-02-2011, 04:51 PM
Jan Hauke Rahm
 
Default Debian rolling: tentative summary

On Mon, May 02, 2011 at 06:44:11PM +0200, Martin Wuertele wrote:
> * Jan Hauke Rahm <jhr@debian.org> [2011-05-02 18:31]:
>
> > On Mon, May 02, 2011 at 06:27:02PM +0200, Martin Wuertele wrote:
> > > * Jan Hauke Rahm <jhr@debian.org> [2011-05-02 18:23]:
> > >
> > > > Not that I don't understand your asking for reasons but... doesn't look
> > > > having a large user base look somehow appealing to you? I think many DDs
> > > > care for such since working on Debian brings more fun if someone's
> > > > actually using it.
> > >
> > > Why do you believe that this will increase our user base? It might, in
> > > case less focus is put on stable, even reduce our user base (on the
> > > coporate and server environment).
> >
> > Firstly, I'm not saying that. Secondly, that's one of the main arguments
> > to introduce said changes. The argument was (not that it wasn't written
> > out often enough) that derivatives provide something we don't: more
> > current software; some as rolling releases, some on scheduled releases
> > etc. The idea is, if we provide something similar, not the same of
> > course, users who care for such come to us. It's as simple as that.
>
> I've read that arguement over and over. However the resources are
> limited and I have not yet read an actual proposal or plan how to do
> that without reducing the resources for the stable releases.

And I among others think that it won't affect stable as much as you
fear. There is already a bunch of DDs who don't care about servers and
use testing and/or unstable on all their systems. The mere fact that
Debian says "we care for stable" doesn't make anyone work for it. Just
like the mere saying that "testing/rolling is now supported as a rolling
release" doesn't make anyone care for it. There is just one way out: try
it and see if it works, of people care -- for both stable and rolling.

Improvement always means some risks of failure. Some are willing to take
that risk. Some aren't. What we need to see is whether there are enough
to go for it.

Hauke

--
.'`. Jan Hauke Rahm <jhr@debian.org> www.jhr-online.de
: :' : Debian Developer www.debian.org
`. `'` Member of the Linux Foundation www.linux.com
`- Fellow of the Free Software Foundation Europe www.fsfe.org
 
Old 05-02-2011, 05:31 PM
Goswin von Brederlow
 
Default Debian rolling: tentative summary

Pierre Habouzit <madcoder@madism.org> writes:

> On Mon, May 02, 2011 at 01:31:31PM +0200, Lucas Nussbaum wrote:
>> Hi,
>>
>> Since I already sent too many mails in the 'rolling' discussion, I
>> decided to send one more. Here is an attempt at a summary of what was
>> said so far. It might not be complete, it's probably a bit biased, but I
>> hope that it's still better than nothing. When replying, please try to
>> focus on specific points, and change the subject accordingly.
>
> That's a decent summary of what was said I think.
>
> Though I feel that to make the discussion more solid, the following is
> missing:
>
> - What are the problems you try to address with rolling? And no "the
> users want it" isn't an answer, I'd reply "why do they want it" if
> that's the answer I get.

I think "why do they want it" is the most important question.

As mentioned many users feel that the software in stable is too old. On
the other hand many users praise Debian for their long release cycle and
stable/old-stable support. Those two groups are clearly expressing
contradictory wishes. And maybe trying to find a solution that fits both
isn't the right thing.

To those users that want newer software my next question would be "What
software?". My feeling there is that it is only some software, allways
the same software and used for the same use case: KDE / Gnome /
Multimedia stuff for the Desktop.

Looking at the other group, those that cherish the slow release cycles
and excelent stability and security support, shows a a large bias
towards servers that are either completly headless or where people don't
care about the latest sparkly desktop hype. They need to run and keep
running without having to upgrade them every 6 month.


If my impression is right then maybe there is something to say for
having a desktop and a server flavour like other distributions. It would
be wastefull to have a rolling release with all sources included if the
users only need a subset. The desktop users only want the new sparkly
KDE / Gnome / Multimedia stuff. They do not care about the latest
coreutils or latest postgresql.

So my idea would be to split pakages into 3 groups: core, desktop and
server. We could then have "full" releases that update all sources
(core+desktop+server) and "sparkly" releases that only update desktop
[OK, so only 2 groups: long-term and short-term]. The desktop packages
for sparkly releases would be build against the core packages from the
last full release. They could be done as rolling releases or not. That
option remains open. The point would be to greatly reduce the number of
package updates involved in a sparkly release, to reduce it to those
packages that matter, and therefore reduce the work needed to pull it
off.

Note: yes, this isn't exactly like other distributions having a desktop
and server flavour. You would still have all the packages available in
every release. The up-to-date-ness would differ, not the amount of
installable packages.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87r58huhz4.fsf@frosties.localnet">http://lists.debian.org/87r58huhz4.fsf@frosties.localnet
 

Thread Tools




All times are GMT. The time now is 10:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org