Release Cycle

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Release Cycle

Koh Choon Lin-8
Dear all

Anyone has an idea what is the release cycle for Debian? I understand
six months is the standard for Ubuntu.

Also, when can binary for 4.0r6 be expected to be released?



--
Regards
Koh Choon Lin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Douglas A. Tutty-2
On Tue, Dec 23, 2008 at 08:28:43PM +0800, Koh Choon Lin wrote:
> Dear all
>
> Anyone has an idea what is the release cycle for Debian? I understand
> six months is the standard for Ubuntu.
>

When its ready.  Generally every couple of years or so.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Mark Allums
In reply to this post by Koh Choon Lin-8
Koh Choon Lin wrote:
> Dear all
>
> Anyone has an idea what is the release cycle for Debian? I understand
> six months is the standard for Ubuntu.
>
> Also, when can binary for 4.0r6 be expected to be released?
>
>
>

Binary for 4.0r6 should be out any day now.  Might already be out.

Release schedule for Debian seems to be, whenever they feel like it.
Something like twelve-eighteen months, but can stretch out.

Ubuntu is pushing it, releasing every six months.  In the opinion of some.

As a rule, Debian Testing is pretty usable six months after a new Stable
release.  So, if you are considering using Debian, go ahead.  Then
consider switching from the major release to the testing distribution
after a suitable interval.

Mark Allums


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Mark Allums
In reply to this post by Douglas A. Tutty-2
Douglas A. Tutty wrote:

> On Tue, Dec 23, 2008 at 08:28:43PM +0800, Koh Choon Lin wrote:
>> Dear all
>>
>> Anyone has an idea what is the release cycle for Debian? I understand
>> six months is the standard for Ubuntu.
>>
>
> When its ready.  Generally every couple of years or so.
>
>

Mark Allums wrote:

 > Release schedule for Debian seems to be, whenever they feel like it.
 > Something like twelve-eighteen months, but can stretch out.



Generally, our two answers are not really at odds.  Twenty-four months
is the usual stretch.  Seems like.

Mark Allums




--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Paul E Condon-2
In reply to this post by Koh Choon Lin-8
On Tue, Dec 23, 2008 at 08:28:43PM +0800, Koh Choon Lin wrote:
> Dear all
>
> Anyone has an idea what is the release cycle for Debian? I understand
> six months is the standard for Ubuntu.
>

The operative rule for all recent releases is that each release
happens when the release manager decides that the code is ready for
release, and not a minute before.

The Biref History of Debian lists all releases and their dates. The last
release that did not have a code name from Toy Story was in Nov,
1995. The most recent named release is Etch which happened on Apr 8,
2007. This is an interval of 11.5 years, or 138 months. There have
been 8 named releases. The mean interval between releases is 138/8
months, i.e. 17.25 months per release.

With a history of eigth releases, it is beginning to be meaningful to
calculate a variance of the release interval, but I'm too lazy to do
it. ;-)

--
Paul E Condon          
[hidden email]


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Andrei POPESCU-2
In reply to this post by Mark Allums
On Tue,23.Dec.08, 07:37:18, Mark Allums wrote:

> Release schedule for Debian seems to be, whenever they feel like it.

Maybe it's because I'm not a native speaker, but this sounds to me as if
Debian Developers would release according to their mood :)

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Daryl Styrk
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrei Popescu wrote:
> On Tue,23.Dec.08, 07:37:18, Mark Allums wrote:
>
>> Release schedule for Debian seems to be, whenever they feel like it.
>
> Maybe it's because I'm not a native speaker, but this sounds to me as if
> Debian Developers would release according to their mood :)
>
> Regards,
> Andrei


Suppose that could be correct.  When Steve McIntyre feels the release is
at a point he will sign his name to then its released?




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklSp+UACgkQejxzjThnMmJSCgCdFSx4YfA4P/HK4bbvaD/k0Kik
fuEAoIiftPV/rDkr2IizU7gjq1NSh4gk
=XDDr
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Andrei POPESCU-2
On Wed,24.Dec.08, 16:21:41, Daryl Styrk wrote:
> Andrei Popescu wrote:
> > On Tue,23.Dec.08, 07:37:18, Mark Allums wrote:
> >
> >> Release schedule for Debian seems to be, whenever they feel like it.
> >
> > Maybe it's because I'm not a native speaker, but this sounds to me as if
> > Debian Developers would release according to their mood :)
 
> Suppose that could be correct.  When Steve McIntyre feels the release is
> at a point he will sign his name to then its released?

Steve McIntyre is the Debian Project Leader. The Release Manager (Marc
Brockschmidt) is the one responsible for the release :)

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Mark Allums
In reply to this post by Andrei POPESCU-2
Andrei Popescu wrote:
> On Tue,23.Dec.08, 07:37:18, Mark Allums wrote:
>
>> Release schedule for Debian seems to be, whenever they feel like it.
>
> Maybe it's because I'm not a native speaker, but this sounds to me as if
> Debian Developers would release according to their mood :)
>
> Regards,
> Andrei

Well, yes.  :)

It is a kind of a reference to Dilbert comic creator, Scott Adams, who
would release a newsletter, "aprroximately whenever I feel like it."

'Twas meant humorously.

Mark Allums



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Mark Allums
In reply to this post by Andrei POPESCU-2
Andrei Popescu wrote:
> On Tue,23.Dec.08, 07:37:18, Mark Allums wrote:
>
>> Release schedule for Debian seems to be, whenever they feel like it.
>
> Maybe it's because I'm not a native speaker, but this sounds to me as if
> Debian Developers would release according to their mood :)


It means that literally, but I was using it figuratively.  It is a bit
of humor.

Mark Allums


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Charlie-67
On Thu, 25 Dec 2008, Mark Allums engaged keyboard and shared this with us all:

>--} Andrei Popescu wrote:
>--} > On Tue,23.Dec.08, 07:37:18, Mark Allums wrote:
>--} >
>--} >> Release schedule for Debian seems to be, whenever they feel like it.
>--} >
>--} > Maybe it's because I'm not a native speaker, but this sounds to me as
> if --} > Debian Developers would release according to their mood :)
>--}
>--}
>--} It means that literally, but I was using it figuratively.  It is a bit
>--} of humor.
>--}
>--} Mark Allums


It's brilliant isn't it?

All the software there if you want to use it, try it, or whatever and released
when it's ready and not a moment before.

Brilliant - no other word for it I reckon.

Thank you to all who are responsible for all this software.

Be well,
Charlie

--
Registered Linux User:- 329524
***********************************************
All wisdom is rooted in learning to call things by the right name. When things
are properly identified, they fall into natural categories and understanding
becomes orderly. ....................Confucius

***********************************************
Debian, just the best way to create magic
_______________________________________________


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

s. keeling-2
In reply to this post by Koh Choon Lin-8
Koh Choon Lin <[hidden email]>:
>
>  Anyone has an idea what is the release cycle for Debian? I
>  understand six months is the standard for Ubuntu.

Why?  What's wrong with Etch and Lenny?  They're both well usable now,
yes?  Are you looking for Lenny features in a "stable" release?
Debian *takes its time and does it right* (generally speaking).
That's what Debian's always been about.  That's why *buntu exists.

>  Also, when can binary for 4.0r6 be expected to be released?

When it's right.  This is *basic* Debian philosophy.  If this doesn't
work for you, you're either doing it wrong or you're in the wrong
place.

IMO.


--
Any technology distinguishable from magic is insufficiently advanced.
(*)    http://blinkynet.net/comp/uip5.html      Linux Counter #80292
- -    http://www.faqs.org/rfcs/rfc1855.html    Please, don't Cc: me.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Daniel Barclay
Re: Release Cycle

s. keeling wrote:
> Koh Choon Lin <[hidden email]>:
>>  Anyone has an idea what is the release cycle for Debian? I
>>  understand six months is the standard for Ubuntu.
>
> Why?  What's wrong with Etch and Lenny?  They're both well usable now,
> yes?  Are you looking for Lenny features in a "stable" release?
> Debian *takes its time and does it right* (generally speaking).
> That's what Debian's always been about.  That's why *buntu exists.
>
>>  Also, when can binary for 4.0r6 be expected to be released?
>
> When it's right.  This is *basic* Debian philosophy.  If this doesn't
> work for you, you're either doing it wrong or you're in the wrong
> place.

Why do so many defenses of Debian's release cycle length seem to ignore or
skirt the issue of _how_ _much_ is planned to be in each release?  (Saying
"when it's right" still depends on what "it" is--which set of features/
changes are involved.)

If there's only one feature or thing to do, it's easy to say whether
it's done (right) or not.

However, when you're releasing N thousand changes every 18 months or so,
it's arguable that maybe you should be releasing N/2 thousand changes every
9 or 10 months.

Obviously, not everything is simply divisible like that--e.g., a big change
that takes many months to design, implement, and test.


Is Debian's stable release cycle relative long because Debian releases
typically involve big changes that set the minimum time between releases,
or is it because Debian not really attempt to design and make smaller, more
frequent increments in order to keep Debian stable releases from getting so
(relatively) old (while maintaining quality standards)?

Daniel

--
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]


Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Ken Teague
Barclay, Daniel wrote:
> Why do so many defenses of Debian's release cycle length seem to ignore or
> skirt the issue of _how_ _much_ is planned to be in each release?  (Saying
> "when it's right" still depends on what "it" is--which set of features/
> changes are involved.)

How much of what?  If I'm understanding this correctly, it would depend
on each individual package and the features each of those packages have.
 It sounds like you answered your own question in the tail end of the
paragraph.

> If there's only one feature or thing to do, it's easy to say whether
> it's done (right) or not.
>
> However, when you're releasing N thousand changes every 18 months or so,
> it's arguable that maybe you should be releasing N/2 thousand changes every
> 9 or 10 months.

Debian is a package-based distribution.  Mentioning the changes in N
thousand packages is not only very time consuming, but it doesn't apply
to each individual user.  As such, I don't think the majority of us
would want to weed through a long list of changes to find out what has
changed.

Also, with the way Debian is released (when it's ready), there's a time
when the testing tree is put into a "freeze".  This means that the
version of the package itself doesn't change and only bug fixes are
implemented at this point.  At this point, you can check for yourself
which changes are in the packages you plan to use.

> Obviously, not everything is simply divisible like that--e.g., a big change
> that takes many months to design, implement, and test.

Changes to the way Debian functions are mentioned in the mailing lists
and is updated in its documentation.  For example, changes to the Debian
Installer or whatnot.

> Is Debian's stable release cycle relative long because Debian releases
> typically involve big changes that set the minimum time between releases,
> or is it because Debian not really attempt to design and make smaller, more
> frequent increments in order to keep Debian stable releases from getting so
> (relatively) old (while maintaining quality standards)?

Debian doesn't have a set release cycle, as you've noticed.  It's long
because they want to produce a distribution that's very stable and
contains little or no bugs.  Bugs that are submitted after a release are
found after the release is launched and they're normally not something
that's easily found/reproducable or system-breaking.

- Ken


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Raquel Rice
On Tue, 30 Dec 2008 15:38:41 -0800
Ken Teague <[hidden email]> wrote:

> > Is Debian's stable release cycle relative long because Debian
> > releases typically involve big changes that set the minimum time
> > between releases, or is it because Debian not really attempt to
> > design and make smaller, more frequent increments in order to
> > keep Debian stable releases from getting so (relatively) old
> > (while maintaining quality standards)?
>
> Debian doesn't have a set release cycle, as you've noticed.  It's
> long because they want to produce a distribution that's very stable
> and contains little or no bugs.  Bugs that are submitted after a
> release are found after the release is launched and they're
> normally not something that's easily found/reproducable or
> system-breaking.

I, for one, am very thankful for Debian and the way that it
releases.  I run a couple of servers that I would just as soon "just
ran", instead of having to tinker or fix things all the time.  I have
more to do.

Thank you, Debian!!

--
Raquel
http://www.byraquel.com
============================================================
Censorship ends in logical completeness when nobody is allowed to
read any books except the books nobody reads.

  --George Bernard Shaw


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Ken Heard
In reply to this post by Koh Choon Lin-8
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Funny.  I always thought that latest "testing" was anointed "stable" by
the release panjandrum when - and only when -- the latter determined
that the relative positions of the planets were such to guarantee
complete freedom of the new release from bugs.

Ken Heard

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJXUJ6lNlJzOkJmTcRAtYkAJ4j2nWsruQisjMtt5tpjqnEzrjjRgCfWKl2
auDTtuMytrSo31JqMC7W/B8=
=1rsN
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

kamaraju kusumanchi-2
In reply to this post by Koh Choon Lin-8
Koh Choon Lin wrote:

> Dear all
>
> Anyone has an idea what is the release cycle for Debian? I understand
> six months is the standard for Ubuntu.
>

Look in http://bugs.debian.org/release-critical/ . The current number of
bugs affecting the next release is 92 (the green line). When this bug
number is 0 (or very close to it) then Lenny will be released.

raju
--
Kamaraju S Kusumanchi
http://malayamaarutham.blogspot.com/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

deloptes
In reply to this post by Raquel Rice
Raquel wrote:

>
> I, for one, am very thankful for Debian and the way that it
> releases.  I run a couple of servers that I would just as soon "just
> ran", instead of having to tinker or fix things all the time.  I have
> more to do.
>
> Thank you, Debian!!
>

Yes, me too. I'm also using debian because of the release management.
I appreciate the fact that stable is really stable.

regards


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Daniel Barclay
In reply to this post by Ken Teague
Re: Release Cycle

Ken Teague wrote:
> Barclay, Daniel wrote:
>> Why do so many defenses of Debian's release cycle length seem to ignore or
>> skirt the issue of _how_ _much_ is planned to be in each release?  (Saying
>> "when it's right" still depends on what "it" is--which set of features/
>> changes are involved.)
>
> How much of what? 

How much change (new features, re-implementations, new packages); how much
work.


>  It sounds like you answered your own question in the tail end of the
> paragraph.

How?  (How does it sound like that?)  People rarely address how the length
of Debian's release cycle is affected by how much change Debian tries to
incorporate into each release.


>> If there's only one feature or thing to do, it's easy to say whether
>> it's done (right) or not.
>>
>> However, when you're releasing N thousand changes every 18 months or so,
>> it's arguable that maybe you should be releasing N/2 thousand changes every
>> 9 or 10 months.
>
> Debian is a package-based distribution.  Mentioning the changes in N
> thousand packages is not only very time consuming, but it doesn't apply
> to each individual user.  As such, I don't think the majority of us
> would want to weed through a long list of changes to find out what has
> changed.

Why are you about mentioning individual changes?  I didn't say or mean to
imply anything like that.

If Debian set a shorter target release interval, each individual package
maintainer would implement (and test and debug) a smaller set of features
and changes (for that package) for each (more frequent) release.  I don't
think there's any need for listing all the changes.  What were you thinking
about?  (Why would listing be or have been needed?)


> Also, with the way Debian is released (when it's ready)

Your saying that seems to indicate that you're still missing my point (that
people seem unaware of the quantity aspect when mentioning the quality
aspect).

Debian's long release cycle is not a result of _just_ Debian's quality.
It's _also_ a result the "chunk size," the quantity of change collected
together before freezing, testing, debugging, re-testing, etc. until it's
up to Debian quality standards for releasing.


Consider making two changes.  You could implement, test, debug, and re-test
both before making a release containing both.  Alternatively, you could
implement one, then test/debug/re-test it fix it, and then make a release
containing just that first change before starting to implement the second
change.

Doing it the second way does _not_ have to compromise any quality standards.
(Why do you (seemingly) think it does?)

Doing it the second way would mean that each release is not as old (as they
are currently) when it is released and does not get as old (as they do
currently) before the next release is released.  (E.g., the first change
doesn't have wait for the release containing the second change.)

Doing it the second way does likely take slightly longer (since part of
the quality-checking process and the release process itself happen multiple
times).

Except when changes can't be divided into two chunks like that, making two
smaller releases rather than one big one would very likely let Debian releases
be more current, with no loss of quality.  The cost would be some decrease
in average development speed of Debian.


The question, of course, is whether shortening Debian's release cycle length
by a factor of, say, 2 or 1.5 (from the current length), would cost only a
very small relative amount of time and effort, small enough to be worth
doing so that Debian stable releases wouldn't initial be or become so
old, or would be a significant drain.

That's the topic I'm having trouble getting to, because people think I'm
saying Debian should reduce its quality and because many people can't seem
to see that the release cycle length is not determined _only_ by Debian's
quality standards.



 > , there's a time
> when the testing tree is put into a "freeze".  This means that the
> version of the package itself doesn't change and only bug fixes are
> implemented at this point.  At this point, you can check for yourself
> which changes are in the packages you plan to use.

I don't follow; when does checking for changes have to do with the
discussion (about the "chunk size" of changes and releases)?


>
>> Obviously, not everything is simply divisible like that--e.g., a big change
>> that takes many months to design, implement, and test.
>
> Changes to the way Debian functions are mentioned in the mailing lists
> and is updated in its documentation.  ...

True, but, again, how does that relate?


>> Is Debian's stable release cycle relative long because Debian releases
>> typically involve big changes that set the minimum time between releases,
>> or is it because Debian [does] not really attempt to design and make smaller, more
>> frequent increments in order to keep Debian stable releases from getting so
>> (relatively) old (while maintaining quality standards)?
>
> Debian doesn't have a set release cycle, as you've noticed.  It's long
> because they want to produce a distribution that's very stable and
> contains little or no bugs.

No.  Again, it's long because of that AND because of the chunk size.
How do you (and others that replied to my message) keep missing that?





Daniel
--
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]


Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle

Daniel Barclay
In reply to this post by Raquel Rice
Re: Release Cycle

Raquel wrote:
> On Tue, 30 Dec 2008 15:38:41 -0800
> Ken Teague <[hidden email]> wrote:
>
>>> Is Debian's stable release cycle relative long because Debian
>>> releases typically involve big changes that set the minimum time
>>> between releases, or is it because Debian not really attempt to
>>> design and make smaller, more frequent increments in order to
>>> keep Debian stable releases from getting so (relatively) old
>>> (while maintaining quality standards)?
>> Debian doesn't have a set release cycle, as you've noticed.  It's
>> long because they want to produce a distribution that's very stable
>> and contains little or no bugs.  Bugs that are submitted after a
>> release are found after the relea...
>
> I, for one, am very thankful for Debian and the way that it
> releases.  I run a couple of servers that I would just as soon "just
> ran", instead of having to tinker or fix things all the time.  I have
> more to do.

Why do you (seemingly) think I'm saying Debian should reduce its quality
level?

As I wrote in my other message, I'm talking about changing the "chunk size"
of releases, not the quality.


Daniel
--
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]


12