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 10-02-2011, 06:36 AM
Manjul Apratim
 
Default On Sid and Experimental

Hi All!

I have been a long-time Debian user/lurker and this is my first time walking in here. Debian was THE distro that made me begin to love GNU/Linux after having a love/hate relationship with Red Hat and Mandriva - starting with a taste through Knoppix, and then an introduction to Etch. Due to various issues I encountered with iwlwifi - then not yet merged into the kernel, I had taken a break from Lenny for about a year and begun to use Ubuntu as my primary system, until I decided it was folly on my part to not actively experience Debian, and since two years I maintain (at least try to) a quintuple boot with Debian Sid as one of my systems, switching between all of them on a whim.



My reason for harassing the venerable Debian developers on here is probably not new and discussed time and again given the thoroughness with which Debian does everything: the time that I was not following Debian has witnessed the creation of the Experimental branch (pray correct me if I am wrong - in the sense that it did not exist before?). I knew the software offerings in Stable were older than latest, so out of nine parts greed and one part necessity, I had installed Testing first, but then Testing was also quite old (not to mention also quite stable), so I had upgraded to Sid. And I must say (as well as marvel at/commend the developers for the same) that not once has Sid broken for me, particularly thanks to tools like apt-listbugs. The opinion before used to be that Sid was an excursion in the "latest
and greatest FOSS software", and that it breaks frequently and should be
used at one's own peril. Such seems to not be the case anymore, as I am
sure many would concur, including Raphael Hertzog - Sid is pretty much "stable" for everyday use, at least as stable as an unbiased user might expect the "testing" branch of a distribution to be like. And now a lot of software in Sid is no more the latest that the FOSS world has to offer - to cite a few, Sid still has rhythmbox-0.12 while I have been using rhythmbox-2.90 in both Ubuntu and Arch without problems for quite some time and needless to say it is present in Experimental, and Sid still does not have gnome-shell, which has also been present in Experimental for quite some time (I concede the need to build on all architectures and not just selfishly on mine, but isn't that the purpose of Testing?). Therefore, from purely a user's perspective, I wonder about the daunting task of maintaining Testing/Sid/Experimental separately - with due respect, if Sid was itself Experimental, and Testing the stabler version of that (but < Stable) which would eventually mature into the next release, would that have been an inadequate scenario? Currently, if I wish to use software from Experimental, I would have to resort to apt-pinning, and I (personally of course) find that to be almost as dangerous as running Sid or using the actual software from Experimental itself; even as Monsieur Hertzog himself states in his blog, "apt-pinning for the brave" - I cannot help but view too many apt pins as an intentional recipe for disaster!



I am sure a lot of the discussion/explanation of this overlaps with the "Continuously Usable Testing" scenario and I apologize for the abject ignorance regarding past issues as well as the process of development, but I feel that Sid, as it stands, is pretty much a Continuously Usable Testing. So would it be unacceptable if Debian had, beyond Stable, just a "Continuously Usable Testing" and a Sid (which was itself Experimental)? Then, users wanting a mix of new software and stability will be able to use the CUT, while though Sid may break a little more than it does now (which has in my experience been never yet if one is careful), it would, aside from continuing to offer the latest and greatest from the FOSS world, be merely living up to its reputation


--
Manjul Apratim
 
Old 10-02-2011, 09:10 AM
Colin Watson
 
Default On Sid and Experimental

On Sun, Oct 02, 2011 at 02:36:03AM -0400, Manjul Apratim wrote:
> My reason for harassing the venerable Debian developers on here is probably
> not new and discussed time and again given the thoroughness with which
> Debian does everything: the time that I was not following Debian has
> witnessed the creation of the Experimental branch (pray correct me if I am
> wrong - in the sense that it did not exist before?).

experimental has existed for longer than I've been involved with Debian,
which is well before the time period you quoted. Perhaps you're simply
observing it being used more for things you care about.

Cheers,

--
Colin Watson [cjwatson@debian.org]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111002091015.GA3855@riva.dynamic.greenend.org.uk ">http://lists.debian.org/20111002091015.GA3855@riva.dynamic.greenend.org.uk
 
Old 10-02-2011, 10:10 AM
Martin Bagge / brother
 
Default On Sid and Experimental

On Sun, 2 Oct 2011, Manjul Apratim wrote:


Therefore, from
purely a user's perspective, I wonder about the daunting task of maintaining
Testing/Sid/Experimental separately - with due respect, if Sid was itself
Experimental, and Testing the stabler version of that (but < Stable) which
would eventually mature into the next release, would that have been an
inadequate scenario?


The problem, as I see it, is that you are looking on the four
distributions as they would be delivered to you while debian as a project
sees them as parts of the release system. Unstable, Testing and Stable
form a chain that makes up the very foundation of the next Stable release.
When you forget that part and the logic behind them I can totally
understand why one would like to see Unstable as more true to the name
than it is today. On the other hand; quality and usability is as important
as new "upgraded" versions of the software. Not everyone was overly
pleased with the introduction of KDE 4 series when that happened. Ask
Canonical about the "upgrade" to Unity in Ubuntu 11.04 - I am sure not
everyone was pleased with that either.



Currently, if I wish to use software from Experimental,
I would have to resort to apt-pinning, and I (personally of course) find
that to be almost as dangerous as running Sid or using the actual software
from Experimental itself; even as Monsieur Hertzog himself states in his
blog, "apt-pinning for the brave" - I cannot help but view too many apt pins
as an intentional recipe for disaster!


Apt-pinning or installing things the old fashioned way by building from
source are more or less equallly bad in that sense, but we enable you to
do so. That's the nice thing about the universal operating system.


--
/brother
http://martin.bagge.nu
Bruce Schneier decrypted the Bible. The plaintext read, "Bruce Schneier".


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: alpine.DEB.2.00.1110021155460.3337@salyut.bsnet.se ">http://lists.debian.org/alpine.DEB.2.00.1110021155460.3337@salyut.bsnet.se
 
Old 10-02-2011, 10:37 AM
Jonathan Nieder
 
Default On Sid and Experimental

Hiya,

Manjul Apratim wrote:

> I cannot help but view too many apt pins
> as an intentional recipe for disaster!

If you really want to experience life on the edge, you can try this:

echo 'APT:efault-Release "experimental";'
>/etc/apt/apt.conf.d/preferexperimental.conf

Used in combination with apt-listbugs, the result generally pretty
pleasant and stable.

To piggy-back on what Martin said: the current suites all have release
management roles. See the suite update policy at
<http://release.debian.org/> for an overview.

stable:

the released OS distribution, which has received a lot of QA
work. Does not change except at point releases (every few
months) and major release (every couple of years or so).

stable-proposed-updates:

where the next minor update of stable cooks. People prepare
packages for here directly, and although the individual fixes
that get used are tested in unstable first, the reliability of
the final packages is mostly due to code review.

testing:

where the next major update of stable cooks. No package
should be missing dependencies, except occasionally when needed
to get through a transition. Packages come from unstable (with
a few exceptions) and get tested there first. The purpose of
the testing suite is to make sure packages work well together
and can function as a coherent distribution.

unstable:

where packages for testing get built and initially tested. No
package enters here unless the package maintainer is confident that
it or some later version will be suitable for the next stable
release. Build-time dependencies of packages in unstable are taken
from unstable, so maintainers exercise care before updating
ABI-incompatible new versions of libraries here --- and (at least in
simple cases) when library ABI changes happen, related packages get
rebuilt and accumulate here before they can move all at once to
testing. Nevertheless, unstable can be a site of rapid change. It
is normal for packages in unstable to be missing dependencies that
have not been built or uploaded yet.

experimental:

where packages are uploaded when either (a) they should not be
uploaded to unstable to avoid disrupting an ongoing interface
transition or (b) they are not ready for upload to unstable for some
other reason (maybe they need more testing before reaching a large
audience).

Much of GNOME 3 falls in category (a) --- these packages are moving
from experimental to unstable in small, coherent batches so they can
migrate to testing more efficiently.

If I understand its goals correctly, CUT would also play a release
management role. In addition to making it easier for people to test
that packages in testing work well together, it could provide the
raw material for making pre-releases of the next version of the
installation media.

Hope that clarifies a little.
Jonathan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111002103726.GA14294@elie">http://lists.debian.org/20111002103726.GA14294@elie
 
Old 10-02-2011, 11:16 AM
Josselin Mouette
 
Default On Sid and Experimental

Le dimanche 02 octobre 2011 * 02:36 -0400, Manjul Apratim a écrit :
> And now a lot of software in Sid is no more the latest that the FOSS
> world has to offer - to cite a few, Sid still has rhythmbox-0.12 while
> I have been using rhythmbox-2.90 in both Ubuntu and Arch without
> problems for quite some time and needless to say it is present in
> Experimental, and Sid still does not have gnome-shell, which has also
> been present in Experimental for quite some time (I concede the need
> to build on all architectures and not just selfishly on mine, but
> isn't that the purpose of Testing?).

So basically your mail boils down to “why isn’t GNOME 3 in sid yet?”.

It has absolutely nothing to do with the number of architectures we
support. You can see experimental is built for all of them, and that
includes GNOME 3 packages.

What you see is an unfortunate consequence of the way we manage
releases. New sets of packages that have to be introduced together
(these are called “transitions”) can only enter unstable when they are
ready to not break anything and migrate to testing. This is what ensures
the quality and stability of our releases.

Most of the time, this is not a problem. However, right after a freeze,
there is a backlog of packages that have not been uploaded, and the most
complex ones (here, the GNOME 2 → GNOME 3 transition, which involves
more than a hundred packages) get delayed, despite being ready in
experimental.

An obvious solution to that problem is to stop freezing testing at
freeze times, or at least to freeze it for a smaller amount of time. The
release team argues that people will stop working on stabilizing the
upcoming release if we do that, and you can’t blame them for being
afraid of such a situation.

Another thing that should help prepare transitions better is the
availability of a PPA-like solution. But I’m not sure it addresses this
specific bottleneck.

Cheers,
--
.'`. Josselin Mouette
: :' :
`. `'
`-
 
Old 10-02-2011, 03:32 PM
Manjul Apratim
 
Default On Sid and Experimental

On Sun, Oct 2, 2011 at 7:16 AM, Josselin Mouette <joss@debian.org> wrote:


Le dimanche 02 octobre 2011 * 02:36 -0400, Manjul Apratim a écrit :

> And now a lot of software in Sid is no more the latest that the FOSS

> world has to offer - to cite a few, Sid still has rhythmbox-0.12 while

> I have been using rhythmbox-2.90 in both Ubuntu and Arch without

> problems for quite some time and needless to say it is present in

> Experimental, and Sid still does not have gnome-shell, which has also

> been present in Experimental for quite some time (I concede the need

> to build on all architectures and not just selfishly on mine, but

> isn't that the purpose of Testing?).



So basically your mail boils down to “why isn’t GNOME 3 in sid yet?”.



It has absolutely nothing to do with the number of architectures we

support. You can see experimental is built for all of them, and that

includes GNOME 3 packages.



What you see is an unfortunate consequence of the way we manage

releases. New sets of packages that have to be introduced together

(these are called “transitions”) can only enter unstable when they are

ready to not break anything and migrate to testing. This is what ensures

the quality and stability of our releases.



Most of the time, this is not a problem. However, right after a freeze,

there is a backlog of packages that have not been uploaded, and the most

complex ones (here, the GNOME 2 → GNOME 3 transition, which involves

more than a hundred packages) get delayed, despite being ready in

experimental.



An obvious solution to that problem is to stop freezing testing at

freeze times, or at least to freeze it for a smaller amount of time. The

release team argues that people will stop working on stabilizing the

upcoming release if we do that, and you can’t blame them for being

afraid of such a situation.



Another thing that should help prepare transitions better is the

availability of a PPA-like solution. But I’m not sure it addresses this

specific bottleneck.



Cheers,

--

*.'`. * * *Josselin Mouette

: :' :

`. `'

*`-


Thank you everybody for the clarifications! I clearly understand now that the software transition from Experimental -> Sid has more to do with the way the release system works than all the architectures the packages are compiled for! As I said before, being completely agnostic about the level of work that goes into the development process and having but a vague idea, I was merely musing from my own perspective. It is indeed strange on my part that I had never before noticed the existence of Experimental, and I stand corrected! (I guess I was too happy running Etch, and subsequently Lenny). Certainly, the many layers of extensive testing that software in Debian goes through is the reason Stable turns out to be the rock-solid distribution it is. I don't really mind that gnome3 is not (at least completely) in Sid yet - for I know that when it shall be, it shall be of a quality I have come to expect from Debian.


At some point of time (after I am done wrapping up my thesis), I would like to get myself involved in the Debian development process. To do so it only fits/is necessary that my views and ideas are concurrent with Debian's philosophical views as well!



--
Manjul Apratim
 

Thread Tools




All times are GMT. The time now is 06:58 AM.

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