subject:"problems with the concept of unstable \- testing"

Christian Perrier wrote:
 (…)
 So, I had another idea: open foo-backports at the moment foo is
 frozen so that maintainers can upload the latest bleeding edge
 versions of their packages there, when using experimental is not
 possible for some reasons.

And make backports an official service of Debian?

 Hopefully, that discussion (in backports-us...@lists.b.o) could lead
 to somethingwe'll see.

Yes. Hopefully. But maybe after Lenny's release (and parties ;) ).

-- 
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread John Goerzen

On Mon, Dec 15, 2008 at 10:52:53PM +0100, Bastian Venthur wrote:
 Didier Raboud schrieb:

  ?
 
 Something like that, I don't really care about the name. The important
 thing is, that unstable is never frozen, but temporarily disconnected
 from the unstable  testing  stable flow.
 
 Another way to see it is that unstable is constantly flowing and we're
 just forking a stable distribution from it from time to time.

That sounds like ubuntu.  But speaking of them, how come they are able
to do this so much more frequently than we are?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Mike Hommey

On Tue, Dec 16, 2008 at 08:58:40AM -0600, John Goerzen jgoer...@complete.org 
wrote:
 On Mon, Dec 15, 2008 at 10:52:53PM +0100, Bastian Venthur wrote:
  Didier Raboud schrieb:
 
   ?
  
  Something like that, I don't really care about the name. The important
  thing is, that unstable is never frozen, but temporarily disconnected
  from the unstable  testing  stable flow.
  
  Another way to see it is that unstable is constantly flowing and we're
  just forking a stable distribution from it from time to time.
 
 That sounds like ubuntu.  But speaking of them, how come they are able
 to do this so much more frequently than we are?

Freezing is called releasing, for Ubuntu, and the first point release, or
second one, is the actual release.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Holger Levsen

Hi,

On Dienstag, 16. Dezember 2008, Lucas Nussbaum wrote:
 I agree. It's clear that most people don't work on RC bugs instead of
 working on their packages: during freezes, they just stop working on
 Debian, since it's judged socially incorrect to work on one's packages
 in unstable or experimental during the freeze.

 We should really think of ways to allow people to continue improving
 unstable during freezes, while making sure that this doesn't affect the
 release (ie, lower buildd priority for unstable packages, for example).

Besides what Neil said, I disagree with your conclusion. IMO we should make 
more people work on finishing the release, so that we then all can move on in 
unstable.

That some people are not interested in making the release happen, is a real 
problem IMO. We shouldnt encourage such behaviour ;-)


regards,
Holger

P.S.: /me throws in a herding cats and we are all volunteers for 
completion.


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

Re: problems with the concept of unstable - testing

2008-12-16 Thread Clint Adams

On Tue, Dec 16, 2008 at 05:13:59PM +0100, Holger Levsen wrote:
 That some people are not interested in making the release happen, is a real 
 problem IMO. We shouldnt encourage such behaviour ;-)

Then why are you posting to mailing lists instead of releasing lenny?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Sven Joachim

On 2008-12-16 15:58 +0100, John Goerzen wrote:

 On Mon, Dec 15, 2008 at 10:52:53PM +0100, Bastian Venthur wrote:
 Another way to see it is that unstable is constantly flowing and we're
 just forking a stable distribution from it from time to time.

 That sounds like ubuntu.  But speaking of them, how come they are able
 to do this so much more frequently than we are?

I'm not involved with them, but I guess the reasons are:

- Reduced number of supported architectures

- Reduced number of supported packages

- No notion of release-critical bugs -- release when the deadline
  comes, no matter what.  In other words, reduced quality standards.

Especially the last point is important and probably shared by other
distros that also have fixed release schedules (e.g. Fedora).  For
users, the rule of thumb is don't touch this in the first six weeks
after the release if you're prudent because many severe bugs are
discovered and/or fixed _after_ the release, not before it.

Whether Debian's higher quality standards really compensate for the lack
of up-to-dateness is another question, of course.

Sven


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Mike O'Connor

On Tue, Dec 16, 2008 at 02:21:09PM +0100, Bastian Venthur wrote:
 
 I think this question is nonsense. While the bug-fix rate was more or
 less the same since the last two releases,

What was the bug-fix rate for the last two releases?  I thought that the
bug fix rate for etch was faster than the rate for sarge.  I also
thought that we've been fixing them faster during this freeze than
during etch.

 it looks like in this release
 we actually started the freeze with much more RC-bugs than before. So it
 was foreseeable that the freeze will take longer this time. We can't
 solve the problem by fixing bugs faster (that won't work anyways).

Why won't fixing bugs faster work?

stew


signature.asc
Description: Digital signature

Re: problems with the concept of unstable - testing

2008-12-16 Thread Rene Engelhard

Hi,

Bastian Venthur wrote:
 Holger Levsen schrieb:
  Hi,
  
  On Montag, 15. Dezember 2008, Bastian Venthur wrote:
  Something like that, I don't really care about the name. The important
  thing is, that unstable is never frozen, but temporarily disconnected
  from the unstable  testing  stable flow.
  
  That's the way it is. 
  
  Have you fixed an RC bug today or at least this week? I mean, are you 
  contributing that this _temporarily disconnect_ is really temporarily?
 
 To be honest, I'm actually counterproductive by developing reportbug-ng,
 a tool which helps users to write bugreports instead of fixing them...
   ^ bad

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

On 16/12/08 at 14:21 +0100, Bastian Venthur wrote:
 I think this question is nonsense. While the bug-fix rate was more or
 less the same since the last two releases, it looks like in this release
 we actually started the freeze with much more RC-bugs than before. So it
 was foreseeable that the freeze will take longer this time. We can't
 solve the problem by fixing bugs faster (that won't work anyways). So
 what's the point of asking how many RC-bugs one has fixed? Does that
 mean only those are allowed to make suggestions, who fixed an RC bug?

I agree. It's clear that most people don't work on RC bugs instead of
working on their packages: during freezes, they just stop working on
Debian, since it's judged socially incorrect to work on one's packages
in unstable or experimental during the freeze.

We should really think of ways to allow people to continue improving
unstable during freezes, while making sure that this doesn't affect the
release (ie, lower buildd priority for unstable packages, for example).
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Bastian Venthur

Holger Levsen schrieb:
 Hi,
 
 On Montag, 15. Dezember 2008, Bastian Venthur wrote:
 Something like that, I don't really care about the name. The important
 thing is, that unstable is never frozen, but temporarily disconnected
 from the unstable  testing  stable flow.
 
 That's the way it is. 
 
 Have you fixed an RC bug today or at least this week? I mean, are you 
 contributing that this _temporarily disconnect_ is really temporarily?

To be honest, I'm actually counterproductive by developing reportbug-ng,
a tool which helps users to write bugreports instead of fixing them...

Sarcasm aside, that is a question I hear very often when speaking about
Lenny's release. It's like the sledgehammer argument, to silence those
who dare to criticize.

I think this question is nonsense. While the bug-fix rate was more or
less the same since the last two releases, it looks like in this release
we actually started the freeze with much more RC-bugs than before. So it
was foreseeable that the freeze will take longer this time. We can't
solve the problem by fixing bugs faster (that won't work anyways). So
what's the point of asking how many RC-bugs one has fixed? Does that
mean only those are allowed to make suggestions, who fixed an RC bug?

 I find it very strange to see people complaining about the long freeze, 
 instead of working on making it shorter.

I actually made a suggestion how to avoid a freeze in unstable, since
looking at the length of the freeze times of the last two releases and
the current one it seems that this model doesn't scale very well.

I'm not going around, telling people hurry up, fix your bugs so we can
release! I know that it will take a certain time to fix the current
number and that's ok. I just don't want unstable to be frozen during
this time.

 If we decouple the freeze from development in unstable, the result will that 
 less people will be working on releasing, thus the freeze will take even 
 longer.

I don't know if that will happen, but I'm pretty sure that if we get an
even longer unstable-freeze period in our next release, users will just
walk away to a more modern distro.


Cheers,

Bastian


-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

On 16/12/08 at 09:46 -0500, Mike O'Connor wrote:
 What new graphics cards are supported by xorg 7.4 that arean't already
 supported by unstable?  the intel, ati, radio, nv drivers don't support
 any newer cards afaict. 

Intel GM45 (found in laptops shipped since ~ september 2008) is
unsupported in unstable/testing, works fine with experimental's X.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: problems with the concept of unstable - testing

On 16/12/08 at 14:34 +, Neil McGovern wrote:
 On Tue, Dec 16, 2008 at 03:07:12PM +0100, Lucas Nussbaum wrote:
  On 16/12/08 at 14:21 +0100, Bastian Venthur wrote:
   I think this question is nonsense. While the bug-fix rate was more or
   less the same since the last two releases, it looks like in this release
   we actually started the freeze with much more RC-bugs than before. So it
   was foreseeable that the freeze will take longer this time. We can't
   solve the problem by fixing bugs faster (that won't work anyways). So
   what's the point of asking how many RC-bugs one has fixed? Does that
   mean only those are allowed to make suggestions, who fixed an RC bug?
  
  I agree. It's clear that most people don't work on RC bugs instead of
 ^
  working on their packages: during freezes, they just stop working on
  Debian, since it's judged socially incorrect to work on one's packages
  in unstable or experimental during the freeze.
  
 
 Could you justify those two please? I've seen no evidence, let alone
 any degree of clarity that supports the statement.

clear that most people don't work on RC bugs instead of working on their
packages: I don't have any data on that, it's mostly based on
perception. Let's try to gather data on something relevant:

Number of distinct posters per month on debian-bugs...@lists.d.o:
200801 944
200802 997
200803 1390
200804 1238
200805 1070
200806 1013
200807 1068
200808 1032
200809 975
200810 946
200811 724
200812 401 (partial results, obviously)

So, the number of people working on RC bugs has significantly decreased
since the beginning of the freeze.


it's judged socially incorrect to work on one's packages in unstable or
*experimental* during the freeze.
I'm not sure if a difference is made between unstable and experimental
by people complaining about people doing something else than fixing RC
bugs. Is the concern purely technical, ie working on unstable packages
makes thing harder for the release? Or social, ie you should work on
the release instead of doing $FOO.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Neil McGovern

On Tue, Dec 16, 2008 at 03:07:12PM +0100, Lucas Nussbaum wrote:
 On 16/12/08 at 14:21 +0100, Bastian Venthur wrote:
  I think this question is nonsense. While the bug-fix rate was more or
  less the same since the last two releases, it looks like in this release
  we actually started the freeze with much more RC-bugs than before. So it
  was foreseeable that the freeze will take longer this time. We can't
  solve the problem by fixing bugs faster (that won't work anyways). So
  what's the point of asking how many RC-bugs one has fixed? Does that
  mean only those are allowed to make suggestions, who fixed an RC bug?
 
 I agree. It's clear that most people don't work on RC bugs instead of
^
 working on their packages: during freezes, they just stop working on
 Debian, since it's judged socially incorrect to work on one's packages
 in unstable or experimental during the freeze.
 

Could you justify those two please? I've seen no evidence, let alone
any degree of clarity that supports the statement.

Neil
-- 
Yoe is _that_ gunnar?
weasel yes
Yoe what happened to his tires?
towersbe He's shrunk. I think his wife washed him at too high a temperature.


signature.asc
Description: Digital signature

Re: problems with the concept of unstable - testing

2008-12-16 Thread Alexander Reichle-Schmehl

Hi!

Bastian Venthur schrieb:
 Another way to see it is that unstable is constantly flowing and
 we're just forking a stable distribution from it from time to time.

Sounds like what was done before testing was introduced, which worked even
less, with even longer freeze periods, where you couldn't even upload to
experimental.  How does your proposal solve the issues we had back then?


Best Regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Christian Perrier

Quoting Bastian Venthur (vent...@debian.org):

 Is that important? Unstable is frozen for nearly 1/2 year now, that's a
 problem we should try to solve if we don't want to degrade ourselves to
 a server-only distribution.


While I don't see such a big issues in this, there is maybe room for
improvements for sure.

It could be by promoting experimental a different way we are doing it
right now...or by adding an intermediate stage between unstable and
experimental. For that latter case, I somewhat fear the (human) resource
problem we would end up with as it would need more people to take care
of the whole mess^W organization.

What I wanted to add also is that the problem pointed here does not
only affect desktop environments as most contributors pointed. For
instance, the samba packaging team is currently facing an interesting
dilemna:

- our upstream is now providing 3 different branches (3.0, 3.2, 3.3)
- we have upstream 3.3.* series in experimental since upstream
  published the first pre-releases. This helps both our users
  and upstream to fiddle with brand new shiny features. As this
  is the version we'll want to ship with squeeze, it helps preparing
  the work.
- we have upstream 3.2.* series in unstable/testing, as the normal
  path to have it in lenny. We will stop at 3.2.5, which is the
  version that will be shipped with lenny

However, upstream released 3.2.6 a few days ago and will release more
and more 3.2.* bugfixes only versions. Those however introduce too
many changes for us to safely consider this for lenny.

So, where could we upload up-to-date 3.2.* packages for the benefit of
our users who prefer having the last bug fix releases?

We can't do it in experimental as 3.3 is already using it.

When lenny is released, backports.org is the appropriate place for
this, imho. However, lenny-backports will only open when lenny is
released and should indeed have packages backported from unstable at
that moment. For us, that will be 3.3.*

So, I had another idea: open foo-backports at the moment foo is
frozen so that maintainers can upload the latest bleeding edge
versions of their packages there, when using experimental is not
possible for some reasons.

Hopefully, that discussion (in backports-us...@lists.b.o) could lead
to somethingwe'll see.





signature.asc
Description: Digital signature

Re: problems with the concept of unstable - testing

2008-12-16 Thread Thomas Viehmann

Hi,

Bastian Venthur wrote:
 What I'd like to see is a solution where unstable is *never* frozen,
 maybe by replacing the current frozen unstable with something temporary
 and putting it between unstable and testing, where all the fixes go
 while all the new stuff can still go into unstable but cannot enter the
 next step while we're in the freeze:

Bastian, this is a brilliant idea!! Debian needs those excellent people
like you who have splendid ideas and all ready to implement them!!! You
are the most valuable person in Debian right now! Because you
contribute a lot!!! You should start this super-unstable
today!!! When it works out later, Debian should integrate it as
official repository! Do not delay starting
it! No one else in Debian has your brains, so no one
else can do this!!!

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Miriam Ruiz

2008/12/16 Bastian Venthur vent...@debian.org:

 I actually made a suggestion how to avoid a freeze in unstable, since
 looking at the length of the freeze times of the last two releases and
 the current one it seems that this model doesn't scale very well.

I share your concerns and I support your position too. I know many sid
users that we must also care about, not only those using stable. Your
proposal would help us to please both groups.

Greetings,
Miry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

Thomas Viehmann wrote:

 Hi,
 Bastian Venthur wrote:
  What I'd like to see is a solution where unstable is *never* frozen
 
 Bastian, this is a brilliant idea!! Debian needs those excellent people
 like you who have splendid ideas and all ready to implement them!!! You
 are the most valuable person in Debian right now! Because you
 contribute a lot!!! You should start this super-unstable
 today!!! When it works out later, Debian should integrate it as
 official repository! Do not delay starting
 it! No one else in Debian has your brains, so no one
 else can do this!!!
 
 Kind regards
 
 T.

Thomas,

Many thanks for this constructive answer. I really appreciate the tone used
and the fact that you seem to belittle the fight of ideas.

No really, I love how people seem to think that if you think you can't work
and if you work, you can't think.

Or s/think/communicate your ideas/g

Indulgent regards, 

OdyX
-- 
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

On Tue, Dec 16, 2008 at 06:48:08PM +0100, Thomas Viehmann wrote:
 Bastian, this is a brilliant idea!! Debian needs those excellent people like
 you who have splendid ideas and all ready to implement them!!! You are the
 most valuable person in Debian right now! Because you contribute a
 lot!!! You should start this super-unstable today!!! When it works
 out later, Debian should integrate it as official repository! Do
 not delay starting it! No one else in Debian has your brains,
 so no one else can do this!!!

The strength of a community rests in its ability to work together as a group.

I wish we could all show a bit more respect for each other on the mailing lists.

-- 
Noah Slater, http://tumbolia.org/nslater


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Miriam Ruiz

2008/12/16 Thomas Viehmann t...@beamnet.de:
 Hi,

 Bastian Venthur wrote:
 What I'd like to see is a solution where unstable is *never* frozen,
 maybe by replacing the current frozen unstable with something temporary
 and putting it between unstable and testing, where all the fixes go
 while all the new stuff can still go into unstable but cannot enter the
 next step while we're in the freeze:

 Bastian, this is a brilliant idea!! Debian needs those excellent people
 like you who have splendid ideas and all ready to implement them!!! You
 are the most valuable person in Debian right now! Because you
 contribute a lot!!! You should start this super-unstable
 today!!! When it works out later, Debian should integrate it as
 official repository! Do not delay starting
 it! No one else in Debian has your brains, so no one
 else can do this!!!

I don't think this kind of attitude helps anyone. Harassing people for
having ideas different than yours will only make people to stop
sharing them. We should seriously reconsider what kind of Debian we
want. Seriously.

On the proposal's side, I DO think it's a good idea, and it would be
good to discuss it after the release, as someone proposed.

Greetings,
Miry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Frank Lin PIAT

On Tue, 2008-12-16 at 13:38 +0100, Holger Levsen wrote:
 Hi,
 
 On Montag, 15. Dezember 2008, Bastian Venthur wrote:
  Something like that, I don't really care about the name. The important
  thing is, that unstable is never frozen, but temporarily disconnected
  from the unstable  testing  stable flow.

 Have you fixed an RC bug today or at least this week? I mean, are you 
 contributing that this _temporarily disconnect_ is really temporarily?

+1

 /me shakes head.

+1

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

Johannes Wiedersich wrote:
 Didier Raboud wrote:
 Yes. But there is a bunch of non-DD people that strongly want to use
 Debian and prefer the recent software over the stabilized one.
 
 These are called 'users of unstable' or 'users of testing'.

Fair enough.

 With the new
 laptops coming out every two weeks, having the latest kernel, Xorg or hal
 is no caprice, it's neededâŠ
 
 I think that the three existing flavours of debian already provide more
 than is needed to offer comfort for both users with stability needs and
 users with desire for new software.

Actually, I would agree if you consider the 4th flavour: experimental.

Just to name some important ones which are only there: OpenOffice.org,
amarok, openjdk, vlc, wine, samba. The list is ever-growing (during the
freeze).

Having the latest OO.o is more than confort…

 At the times of a freeze, I guess the available resources would be
 better spent on trying to keep that time as short as possible, instead
 of having to explain to users that there is one more section that they
 could use in their sources.list.

I don't think that it only helps geeky users ot have one more section. My
guess is that it'll help keeping the fun for the Developers as well…

 It would be great, if the remaining RC bugs were solved faster so that
 lenny could be released sooner, allowing newer versions in squeeze
 faster, allowing earlier testing of newer software, speeding up the
 release of squeeze, leading

I agree that with a shorter freeze it would solve it all. Just don't forget
that the amount of packages is growing faster than the number of workers
(DD's) [not counting how many users flew to Ubuntu and that don't report
and fix in Debian…].

So, the potential source of bugs is becoming bigger, while the forces to
solve the issues is not (at least not fast enough). Thus the bigger freeze
time.

Another solution would be to reduce the number of packages, but this is
reducing the fun (and the _universal_ity) too…

 With a less jungle experimental which you could trust as the unfrozen
 unstable or with a constantly unfrozen unstable, this would not be an
 issue.
 
 With a faster fixing of RC bugs and a faster release, all this would not
 be an issue.

Agreed.

But fixing RC bugs faster is not possible. You can't ask people to work more
than their fun threshold.

And with the low rate of new DD's compared to the high rate of new upstreams
and ITP's and so the growing rate of new packages, and so the rate of bugs,
I think that reducing the freeze time is not possible.

So there is a need for something else.

 Cheers,
 
 Johannes
 
 - -- speaking as a user, who believes that debian's way is close to
 perfect for _both_ stability and new software.
 
 Thanks to all for their great work!

Regards, 

OdyX

-- 
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Frank Lin PIAT

On Tue, 2008-12-16 at 18:07 +0100, Lucas Nussbaum wrote:
 On 16/12/08 at 14:34 +, Neil McGovern wrote:
  On Tue, Dec 16, 2008 at 03:07:12PM +0100, Lucas Nussbaum wrote:
   On 16/12/08 at 14:21 +0100, Bastian Venthur wrote:
I think this question is nonsense. While the bug-fix rate was more or
less the same since the last two releases, it looks like in this release
we actually started the freeze with much more RC-bugs than before. So it
was foreseeable that the freeze will take longer this time. We can't
solve the problem by fixing bugs faster (that won't work anyways). So
what's the point of asking how many RC-bugs one has fixed? Does that
mean only those are allowed to make suggestions, who fixed an RC bug?
   
   I agree. It's clear that most people don't work on RC bugs instead of
  ^
   working on their packages: during freezes, they just stop working on
   Debian, since it's judged socially incorrect to work on one's packages
   in unstable or experimental during the freeze.
   
  
  Could you justify those two please? I've seen no evidence, let alone
  any degree of clarity that supports the statement.
 
 clear that most people don't work on RC bugs instead of working on their
 packages: I don't have any data on that, it's mostly based on
 perception. Let's try to gather data on something relevant:
 
 Number of distinct posters per month on debian-bugs...@lists.d.o:
 200801 944
 200802 997
 200803 1390
 200804 1238
 200805 1070
 200806 1013
 200807 1068
 200808 1032
 200809 975
 200810 946
 200811 724
 200812 401 (partial results, obviously)
 
 So, the number of people working on RC bugs has significantly decreased
 since the beginning of the freeze.

Or there are fewer and fewer bugs in Lenny ?
Or have we returned to [winter|regular] bug rate ?

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Cyril Brulebois

Lucas Nussbaum lu...@lucas-nussbaum.net (16/12/2008):
 Number of distinct posters per month on debian-bugs...@lists.d.o:
 [ figures ]
 So, the number of people working on RC bugs has significantly
 decreased since the beginning of the freeze.

The less RC bugs, the less people working on it. Nice point you made.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: problems with the concept of unstable - testing

Romain Beauxis wrote:
 
 Honnestly, this discussion takes place at every freeze.

As many others: firmware, dfsg-freeness, … ;)

 First of all, you probably should propose such thing *after* the release,
 not now.
 
 Secondly, I'm still wondering what new arguments were brought here. For
 instance, if you want to do a serious proposal, you probably could come up
 with links to previous discussions on the topic, and explain how that
 changed and how your point differs from the point already mentioned in the
 previous discussions.
 
 Until then, I don't really see the point in discussing this...
 
 Romain

Agreed. That's what I think too :
http://lists.debian.org/debian-devel/2008/12/msg00599.html

Regards,

OdyX
-- 
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Mike O'Connor

On Mon, Dec 15, 2008 at 10:16:05PM +0100, Bastian Venthur wrote:
 
 I support that request. Not only is unstable quite outdated already
 (bleeding edge?) it also becomes more and more a problem since the
 kernel and Xorg aren't updated anymore in unstable. That means that
 newer hardware (especially Laptops) don't fully work anymore (WLAN,
 Graphic, Sound).

The latest alsa source is in unstable.  'm-a a-i alsa' would install it.

What new graphics cards are supported by xorg 7.4 that arean't already
supported by unstable?  the intel, ati, radio, nv drivers don't support
any newer cards afaict. 

 
 Since we're making it very hard for our users to get their new hardware
 working seamlessly, unstable becomes more and more unattractive compared
 to other distributions.

Is attracting users with brand new hardware to use unstable a goal of
ours?

 
 Some suggest to cherry pick packages from experimental, but first some
 packages like the kernel aren't even available there

The kernel is available elsewhere: http://kernel-archive.buildserver.net/

 and second, since
 experimental is not part of the unstable  testing  stable flow, it has
 the aura of sandbox/playground/if-your-box-breaks-its-your-own-fault.
 And officially we don't even recommend using unstable, aren't we? So for
 me that argument is invalid.

If we don't recommend using unstable, doesn't that make YOUR argument
invalid?

stew


signature.asc
Description: Digital signature

Re: problems with the concept of unstable - testing

2008-12-16 Thread Johannes Wiedersich

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Didier Raboud wrote:
 Romain Beauxis wrote:
 You can't get both recent *and* stabilized software. For a solid release
 to be done, one needs to hold new improvements for a while.
 
 Yes. But there is a bunch of non-DD people that strongly want to use Debian
 and prefer the recent software over the stabilized one. 

These are called 'users of unstable' or 'users of testing'.

 With the new
 laptops coming out every two weeks, having the latest kernel, Xorg or hal
 is no caprice, it's needed…

I think that the three existing flavours of debian already provide more
than is needed to offer comfort for both users with stability needs and
users with desire for new software.

At the times of a freeze, I guess the available resources would be
better spent on trying to keep that time as short as possible, instead
of having to explain to users that there is one more section that they
could use in their sources.list.

Just one example: IMHO it might be better to speed up the testing and
fixing of bugs in the present kernel versions, instead of adding one
more kernel version to the archives, that will have to be tested and
fixed as well.

I don't imply here that the kernel team or anyone else is doing a bad
job. I just feel that if there is anything to improve it would be more
efficient to just speed up existing work flows instead of _adding_ to
the existing ones.

 That's not a problem from Debian stable users, who need a stable before
 all release. But for the FLOSS community and the geeky users, I guess that
 it is in fact a problem.

It would be great, if the remaining RC bugs were solved faster so that
lenny could be released sooner, allowing newer versions in squeeze
faster, allowing earlier testing of newer software, speeding up the
release of squeeze, leading

 With a less jungle experimental which you could trust as the unfrozen
 unstable or with a constantly unfrozen unstable, this would not be an
 issue.

With a faster fixing of RC bugs and a faster release, all this would not
be an issue.

Cheers,

Johannes

- -- speaking as a user, who believes that debian's way is close to
perfect for _both_ stability and new software.

Thanks to all for their great work!

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

iEYEARECAAYFAklHqdoACgkQC1NzPRl9qEXL3wCfQFo2ETzA5VeEasWgOwiQRa1D
5okAn1ol9z5Ff0htx5FLgTYSF2UZU/s8
=rOcY
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Holger Levsen

Hi,

On Montag, 15. Dezember 2008, Bastian Venthur wrote:
 Something like that, I don't really care about the name. The important
 thing is, that unstable is never frozen, but temporarily disconnected
 from the unstable  testing  stable flow.

That's the way it is. 

Have you fixed an RC bug today or at least this week? I mean, are you 
contributing that this _temporarily disconnect_ is really temporarily?

I find it very strange to see people complaining about the long freeze, 
instead of working on making it shorter.

If we decouple the freeze from development in unstable, the result will that 
less people will be working on releasing, thus the freeze will take even 
longer.

/me shakes head.


regards,
Holger


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

Re: problems with the concept of unstable - testing

On 16/12/08 at 19:15 +0100, Frank Lin PIAT wrote:
 On Tue, 2008-12-16 at 18:07 +0100, Lucas Nussbaum wrote:
  clear that most people don't work on RC bugs instead of working on their
  packages: I don't have any data on that, it's mostly based on
  perception. Let's try to gather data on something relevant:
  
  Number of distinct posters per month on debian-bugs...@lists.d.o:
  200801 944
  200802 997
  200803 1390
  200804 1238
  200805 1070
  200806 1013
  200807 1068
  200808 1032
  200809 975
  200810 946
  200811 724
  200812 401 (partial results, obviously)
  
  So, the number of people working on RC bugs has significantly decreased
  since the beginning of the freeze.
 
 Or there are fewer and fewer bugs in Lenny ?

You might not be aware that debian-bugs-rc@ includes bugmail for all RC
bugs, not just lenny's. Also, it's true that there are fewer RC bugs in
lenny, but they are likely to be harder to fix, thus requiring more
discussion.

 Or have we returned to [winter|regular] bug rate ?

2007 doesn't exhibit a similar behaviour.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Romain Beauxis

Le Tuesday 16 December 2008 14:55:29 Didier Raboud, vous avez écrit :
  I think that the three existing flavours of debian already provide more
  than is needed to offer comfort for both users with stability needs and
  users with desire for new software.

 Actually, I would agree if you consider the 4th flavour: experimental.

 Just to name some important ones which are only there: OpenOffice.org,
 amarok, openjdk, vlc, wine, samba. The list is ever-growing (during the
 freeze).

 Having the latest OO.o is more than confort…

Honnestly, this discussion takes place at every freeze.

First of all, you probably should propose such thing *after* the release, not 
now.

Secondly, I'm still wondering what new arguments were brought here. For 
instance, if you want to do a serious proposal, you probably could come up 
with links to previous discussions on the topic, and explain how that changed 
and how your point differs from the point already mentioned in the previous 
discussions.


Until then, I don't really see the point in discussing this...


Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Thomas Viehmann

Miriam Ruiz wrote:
 I don't think this kind of attitude helps anyone. Harassing people for
 having ideas different than yours will only make people to stop
 sharing them. We should seriously reconsider what kind of Debian we
 want. Seriously.
Yeah, my post was more than inappropriate.

But while you bring it up: I want a Debian where every Developer can
cough up a minimal commitment to help with releasing. That is what Have
you fixed an RC bug today is about?. If all developers had fixed one RC
bug in the months that we have been frozen, we would have run out.

The other way round works, too: Removing people who don't have that
minimal commitment from the project and their packages from the archive
would also allow us to release (a lot less) in a timely fashion.

Bastian's contributions have a theme of telling other people how to do
work that he does not want to do: What information they should want in
their bug reports, how to release, how negligent the assistant secretary
is and why he is even doing the secretary's, and now what to do with
unstable in the meantime (as other's have pointed out, not a new idea,
so the contribution is rehasing of the idea). To be honest, I'd prefer
if Bastian applied his skills to helping a project I'm not a member of.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Romain Beauxis

Le Tuesday 16 December 2008 20:30:22 Thomas Viehmann, vous avez écrit :
 But while you bring it up: I want a Debian where every Developer can
 cough up a minimal commitment to help with releasing. That is what Have
 you fixed an RC bug today is about?. If all developers had fixed one RC
 bug in the months that we have been frozen, we would have run out.

 The other way round works, too: Removing people who don't have that
 minimal commitment from the project and their packages from the archive
 would also allow us to release (a lot less) in a timely fashion.

I think you completely forgot about the fact that this project is run by 
people who aren't payed for that.

And, yes I didn't fix any RC bug today, nor yesterday. I even have now 3 on 
mediawiki for which I won't be able to take much time. 

And I won't explain my reasons, it is private for me. However the packages are 
open for any contribution. Maybe yours ?

 Bastian's contributions have a theme of telling other people how to do
 work that he does not want to do: What information they should want in
 their bug reports, how to release, how negligent the assistant secretary
 is and why he is even doing the secretary's, and now what to do with
 unstable in the meantime (as other's have pointed out, not a new idea,
 so the contribution is rehasing of the idea). To be honest, I'd prefer
 if Bastian applied his skills to helping a project I'm not a member of.


I don't agree with Bastian on his proposal but I would never express myself in 
that way.


I won't fall into the easy agressive answer, but your attitude is clearly 
inapropriate.


Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Steve McIntyre

Alexander wrote:
Hi!

Bastian Venthur schrieb:
 Another way to see it is that unstable is constantly flowing and
 we're just forking a stable distribution from it from time to time.

Sounds like what was done before testing was introduced, which worked even
less, with even longer freeze periods, where you couldn't even upload to
experimental.  How does your proposal solve the issues we had back then?

I'm curious about that myself. We've tried that in the past, and a
3-year release cycle was what happened. Experience tells us that we
have much too big a system to suddenly one day declare release
without a lot of preparation beforehand.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site... -- Simon Booth


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Steve McIntyre

Bastian Venthur wrote:
Holger Levsen schrieb:

 I find it very strange to see people complaining about the long freeze, 
 instead of working on making it shorter.

I actually made a suggestion how to avoid a freeze in unstable, since
looking at the length of the freeze times of the last two releases and
the current one it seems that this model doesn't scale very well.

I'm not going around, telling people hurry up, fix your bugs so we can
release! I know that it will take a certain time to fix the current
number and that's ok. I just don't want unstable to be frozen during
this time.

I'm curious - why do you think that our process can't scale for fixing
bugs and releasing? There's plenty of scope for more people to join in
and help fix them. Many people have, in fact, done so. I have a great
deal of sympathy for Holger's attitude - an important part of Debian
for me is achieving releases and I'd *hope* that most people would
agree with that.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop -- Vivek Dasmohapatra


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Bastian Venthur

Steve McIntyre schrieb:
 Alexander wrote:
 Hi!

 Bastian Venthur schrieb:
 Another way to see it is that unstable is constantly flowing and
 we're just forking a stable distribution from it from time to time.
 Sounds like what was done before testing was introduced, which worked even
 less, with even longer freeze periods, where you couldn't even upload to
 experimental.  How does your proposal solve the issues we had back then?
 
 I'm curious about that myself. We've tried that in the past, and a
 3-year release cycle was what happened. Experience tells us that we
 have much too big a system to suddenly one day declare release
 without a lot of preparation beforehand.

Actually, I don't know since I'm not long enough involved to know what
happened back then. Did testing at some point in time fork from
unstable and developed slowly into stable while unstable was still
developing concurrently? Did uploads go directly to testing or to
something before testing (like the current frozen unstable)? What was
the problem that lead to a slow development back then? Was it that it
was still possible to upload into unstable and so noone was actually
interested in fixing RC bugs?

What I see *now* is that the freezes during the last two and the current
release are getting longer and longer (~1,5 months, ~4 months and for
Lenny at least 5 months). For me this seems to be a serious problem we
should not ignore. Important software is outdated in unstable and
current hardware doesn't work anymore without resorting to grab packages
from experimental or unofficial sources.


Cheers,

Bastian

-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Thomas Viehmann

Romain Beauxis wrote:
 I think you completely forgot about the fact that this project is run by 
 people who aren't payed for that.
 
 And, yes I didn't fix any RC bug today, nor yesterday. I even have now 3 on 
 mediawiki for which I won't be able to take much time. 

How about once per year?

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

On Tue, Dec 16, 2008 at 08:30:22PM +0100, Thomas Viehmann wrote:
 But while you bring it up: I want a Debian where every Developer can cough up
 a minimal commitment to help with releasing. That is what Have you fixed an
 RC bug today is about?. If all developers had fixed one RC bug in the months
 that we have been frozen, we would have run out.

Regardless of your wishes, the attitude you displayed in your previous email is
actually detrimental to Debian and the community that other people work so hard
to foster. I cannot see how you would think one justifies the other.

 The other way round works, too: Removing people who don't have that minimal
 commitment from the project and their packages from the archive would also
 allow us to release (a lot less) in a timely fashion.

I think you need to read some of the stuff by Clay Shirky. He demonstrates that
the power of new media and Internet based organisations such as the Linux
developers, Debian, Flickr, Digg, and Wikipedia actually gain their massive
organisational power by having close to zero barrier to entry for contributions
from occasional users. When you look at the statistics for these groups you see
majority overwhelming amount of work consists of one-time contributions, and the
frequency of contribution increases in ever smaller amounts.

By trying to artificially raise the barrier to entry for contributions to
Debian, you would be inadvertently crippling one of the most crucial parts to
its continued success.

 Bastian's contributions have a theme of telling other people how to do work
 that he does not want to do: What information they should want in their bug
 reports, how to release, how negligent the assistant secretary is and why he
 is even doing the secretary's, and now what to do with unstable in the
 meantime (as other's have pointed out, not a new idea, so the contribution is
 rehasing of the idea). To be honest, I'd prefer if Bastian applied his skills
 to helping a project I'm not a member of.

I am not going to comment on his behaviour, your comments may very well be
justified. But I do think it would do the project some good if we all learnt to
embrace each others commitment levels, attitudes and opinions -- without
resorting to rudeness, unkindness, or personal attacks.

-- 
Noah Slater, http://tumbolia.org/nslater


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Kevin Mark

On Tue, Dec 16, 2008 at 09:34:39PM +0100, Thomas Viehmann wrote:
 Romain Beauxis wrote:
  I think you completely forgot about the fact that this project is run by 
  people who aren't payed for that.
  
  And, yes I didn't fix any RC bug today, nor yesterday. I even have now 3 on 
  mediawiki for which I won't be able to take much time. 
 
 How about once per year?
 
 Kind regards

people can decide to not contribute to a volunteer project for many
reasons:  hostile work environment, discouragement when expressing ideas are 2.
A project as huge as Debian has a hard enough time keeping the 'fun' but
making the atmostphere for people unplesent will not only discourage
current people but also future contributer.
-K
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|  my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to help Debian!  |
|___  Unless I ask to be CCd, assume I am subscribed ___|


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Ana Guerrero

On Tue, Dec 16, 2008 at 12:29:21AM +0100, Didier Raboud wrote:
 
 Look for example at the upcoming KDE4.2 : KDE4.0 (public beta) went out in
 january 2008. Since then and 'because' of the unstable-to-testing pipe,
 KDE4.0 has only lived in experimental with the big fat blinking
 red WARNING sign above.
 
 KDE4 was then hard to test for testing users that don't play with
 apt-pinning and KDE4 will not be part of Lenny (even if it could…), roughly
 15 months after its release.
 
 That's not a problem from Debian stable users, who need a stable before
 all release. But for the FLOSS community and the geeky users, I guess that
 it is in fact a problem.
 
 With a less jungle experimental which you could trust as the unfrozen
 unstable or with a constantly unfrozen unstable, this would not be an
 issue.


Please, next time pick up an example you know better.

KDE 4.0 totally belonged to experimental, 4.1 has never been uploaded to 
unstable because lenny was planned to be released with KDE 3.5, and even 
there was an update to this series a few months ago.  Furthermore, Lenny 
users can test it from http://kde4.debian.net
KDE 4.2 has not being release *yet*. 

I encourage you to (co)maintain packages in Debian. It will give you a better
idea of how some stuff works and I think it could change some of the points of
view I have read from you in this thread.

Ana


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Michael Banck

On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote:
 Actually, I don't know since I'm not long enough involved to know what
 happened back then. 

It's called research.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

On Tue, Dec 16, 2008 at 10:17:13PM +0100, Michael Banck wrote:
 On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote:
  Actually, I don't know since I'm not long enough involved to know what
  happened back then.

 It's called research.

It's called manners.

-- 
Noah Slater, http://tumbolia.org/nslater


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Mark Brown

On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote:
 Steve McIntyre schrieb:

  I'm curious about that myself. We've tried that in the past, and a
  3-year release cycle was what happened. Experience tells us that we
  have much too big a system to suddenly one day declare release
  without a lot of preparation beforehand.

 Actually, I don't know since I'm not long enough involved to know what
 happened back then. Did testing at some point in time fork from
 unstable and developed slowly into stable while unstable was still

Pretty much.  What used to happen was that at some point the release
manager decided to freeze unstable, creating a new distribution called
frozen.  This was a straight fork of unstable, there was no technical
link between them once the fork was done.

 developing concurrently? Did uploads go directly to testing or to
 something before testing (like the current frozen unstable)? What was

Uploads were done directly to frozen.  Uploads could be done
simultaneously to both (ie, you could upload to frozen unstable -
you'll see such uploads in older changelogs) or to one distribution
only.

 the problem that lead to a slow development back then? Was it that it
 was still possible to upload into unstable and so noone was actually
 interested in fixing RC bugs?

Well, one of the problems was that you could end up with substantial
divergence between the two distributions which tended to end up causing
breakage so there was still some attempt to keep things broadly in sync.
A search through the list archives from the time AJ introduced testing
and after the first release using it should turn up plenty of discussion
around the issue.

 What I see *now* is that the freezes during the last two and the current
 release are getting longer and longer (~1,5 months, ~4 months and for
 Lenny at least 5 months). For me this seems to be a serious problem we
 should not ignore. Important software is outdated in unstable and
 current hardware doesn't work anymore without resorting to grab packages
 from experimental or unofficial sources.

Of course, these problems would all also apply to a frozen distribution
like we used to have.  My recollection of those times is that the long
freezes we had back then had pretty similar effects on general
development - the win from testing is in theory that testing should be
in much better shape at any given moment than a random snapshot of
unstable would be so we should have much more chance of getting the
freeze over quickly.

I certainly agree that we should be looking at ways of reducing the
freeze time but I'm not sure that the freeze mechanism is an important
factor in this.  In terms of reducing the freeze time I think things
like the availability of people willing to work on core packages is more
of a limiting factor than anything else.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Neil Williams

On Tue, 16 Dec 2008 15:55:40 -0500
Kevin Mark kevin.m...@verizon.net wrote:

On Tue, Dec 16, 2008 at 09:34:39PM +0100, Thomas Viehmann wrote:
Romain Beauxis wrote:
I think you completely forgot about the fact that this project is
run by people who aren't payed for that.

And, yes I didn't fix any RC bug today, nor yesterday. I even
have now 3 on mediawiki for which I won't be able to take much
time.

How about once per year?

Kind regards

people can decide to not contribute to a volunteer project for many
reasons: hostile work environment, discouragement when expressing
ideas are 2. A project as huge as Debian has a hard enough time
keeping the 'fun' but making the atmostphere for people unplesent
will not only discourage current people but also future contributer.

That works both ways - those who do contribute and help Debian across a
wide range of areas should be valued and supported, even if they show
that frustration from time to time. Everyone makes mistakes but why
must the most active contributors be the first target of criticism when
they criticise others who do little to help Debian? What about those who
simply obstruct other developers? Isn't there any wider consideration
that uploading packages that are unfit for purpose and refusing to fix
problems identified by more active, more respected members is only
going to frustrate those who do care? Those who criticise Thomas'
reaction need to also consider the causes instead of only blaming one
side of the issue. There are two sides to the argument and I've made my
position clear already. [0]

Where's the criticism of the original post that brings nothing useful
or new to the discussion and comes from someone who has done nothing
positive to further the release of Lenny? It's laughable. Why must we
always blame the responder and not the initiator?

Don't criticise unless you've done something positive - don't pick
holes unless you have at least some *original* ideas that could help -
don't pretend that you thought of something that has been discussed to
death in the past.

I get criticised for being rude or direct - well here's the news: I
don't care if people think I'm rude, deal with it. At least I do what I
can to fix stuff, I apologise when I do make mistakes and I do not
recommend something I have not done myself. Would that more
contributors were as active.

BTW, I'm perfectly happy with the concept of unstable-testing with the
ability to upload to experimental during the freeze. [1] Now is not the
time to deal with the actual details but equally, now is the time
everyone needs to support those who are actually doing the work, not
those who just complain and obstruct those who would improve things.
Maybe it is the people who only complain who should be criticised and
thinking about retirement themselves.

Overly long freezes are a pain but the solution is not to complain, the
solution is to fix the RC bugs, help with the debian-installer, help
with the translation team and get the release finished. That's what I'm
trying to do, that's what Thomas was doing. Stop moaning.

[0]
http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/119-reportbug-ng-unfit-for-purpose-Absolutely..html

(hmm, must do something about those extra long URLs!)

[1] http://lists.debian.org/debian-mentors/2008/12/msg00180.html

Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

pgpULJXSQ98h7.pgp
Description: PGP signature

Re: problems with the concept of unstable - testing

2008-12-16 Thread Neil Williams

On Tue, 16 Dec 2008 21:41:58 +
Noah Slater nsla...@tumbolia.org wrote:

 On Tue, Dec 16, 2008 at 10:17:13PM +0100, Michael Banck wrote:
  On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote:
   Actually, I don't know since I'm not long enough involved to know
   what happened back then.
 
  It's called research.
 
 It's called manners.

Yes, manners relating to actually thinking whether the idea has been
considered before and typing something into Google? How hard is that?
Manners involves consideration for others - that includes what is
likely to have happened before some arbitrary point in time and
considering that people more knowledgeable than yourself may just have
considered the problem at some point before you became aware of the
problem, maybe?

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgp5SpVqelzyO.pgp
Description: PGP signature

Re: problems with the concept of unstable - testing

On Tue, Dec 16, 2008 at 09:57:15PM +, Neil Williams wrote:
 On Tue, 16 Dec 2008 21:41:58 +
 Noah Slater nsla...@tumbolia.org wrote:

  On Tue, Dec 16, 2008 at 10:17:13PM +0100, Michael Banck wrote:
   On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote:
Actually, I don't know since I'm not long enough involved to know
what happened back then.
  
   It's called research.
 
  It's called manners.

 Yes, manners relating to actually thinking whether the idea has been
 considered before and typing something into Google? How hard is that?  Manners
 involves consideration for others - that includes what is likely to have
 happened before some arbitrary point in time and considering that people more
 knowledgeable than yourself may just have considered the problem at some point
 before you became aware of the problem, maybe?

Of course! I'm not going to argue with that. However, just because one person
has made a faux pas, does not give blanket permission for other people to follow
suit. This inevitably causes a chain reaction of rudeness and flames. As a
community, we would do well to be a little more tolerant of others, and that
includes their mistakes.

-- 
Noah Slater, http://tumbolia.org/nslater


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Steve Langasek

On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote:

 What I see *now* is that the freezes during the last two and the current
 release are getting longer and longer (~1,5 months, ~4 months and for
 Lenny at least 5 months). For me this seems to be a serious problem we
 should not ignore. Important software is outdated in unstable and
 current hardware doesn't work anymore without resorting to grab packages
 from experimental or unofficial sources.

Like your regression analysis of the bug closure rates, this is a facile
analysis of the release process that shows you're lacking even a reasonable
amount of historical context for the past two releases, let alone going back
far enough to understand how the release process worked before testing was
instituted.

In particular, by looking only at the length of the full archive freeze, you
have ignored:

- the length of the release cycle as a whole
- the length of the base freeze
- the rate of RC bug churn - because the rate at which the RC bug count is
  reduced != the rate at which RC bugs are closed
- the degree to which a freeze is effective at containing new RC bugs in
  unstable where they don't impact the upcoming release

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Jan Hauke Rahm

On Tue, Dec 16, 2008 at 09:46:41PM +, Mark Brown wrote:
 Of course, these problems would all also apply to a frozen distribution
 like we used to have.  My recollection of those times is that the long
 freezes we had back then had pretty similar effects on general
 development - the win from testing is in theory that testing should be
 in much better shape at any given moment than a random snapshot of
 unstable would be so we should have much more chance of getting the
 freeze over quickly.

Reading this (and following the idea of not introducing new stuff or
archives but releasing faster) it sounds as simple as testing needs
to be more strict and rigorous in accepting packages to be *indeed*
always in a seriously better shape than unstable so that releases can be
done with shorter freeze times, right?

 I certainly agree that we should be looking at ways of reducing the
 freeze time but I'm not sure that the freeze mechanism is an important
 factor in this.  In terms of reducing the freeze time I think things
 like the availability of people willing to work on core packages is more
 of a limiting factor than anything else.

Yep, maybe it's not the freeze time to be improved but the time before
that... But to be clear, I don't have any suggestions for new rules for
packages to get into lenny, unfortunately.

Hauke


signature.asc
Description: Digital signature

Re: problems with the concept of unstable - testing

2008-12-16 Thread Neil Williams

On Tue, 16 Dec 2008 21:58:52 +
Noah Slater nsla...@tumbolia.org wrote:

 On Tue, Dec 16, 2008 at 09:53:58PM +, Neil Williams wrote:
  I get criticised for being rude or direct - well here's the news: I
  don't care if people think I'm rude, deal with it. At least I do
  what I can to fix stuff, I apologise when I do make mistakes and I
  do not recommend something I have not done myself. Would that more
  contributors were as active.
 
 I think you should care about upsetting people, and so should others.

Well, that's your viewpoint - mine is different. I care about getting
things done and helping people who are motivated, not those who only
ever complain and obstruct wider development.

 When you work for an organisation like Debian,

work? We're all volunteers and we have to motivate ourselves. People
like Thomas motivate me to continue contributing.

 the community is the
 most valuable asset it has going for it. Rude and abrasive characters
 who contribute a lot of code, but who upset the community, waste time
 by drawing fire or starting flame wars, or scare away new
 contributers do not deserve to be excused for such behaviour.

There has to be some support for those who come under fire despite
being active contributors. If the community is left with inactive and
inoffensive members who make no positive contributions, Debian itself
will dissolve from the inside. Debian exists because things get done -
eventually.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpvPb6sT3qV9.pgp
Description: PGP signature

Re: problems with the concept of unstable - testing

2008-12-16 Thread Julien BLACHE

Noah Slater nsla...@tumbolia.org wrote:

Hi,

 suit. This inevitably causes a chain reaction of rudeness and flames. As a
 community, we would do well to be a little more tolerant of others, and that
 includes their mistakes.

And that includes cutting some slack to people when they vent off, as
people occasionally do.

BTW, that community thing is really overrated and totally
overinflated these days. Everybody refers to the community all the
time for everything. It doesn't mean anything anymore.

JB.

-- 
 Julien BLACHE - Debian  GNU/Linux Developer - jbla...@debian.org 
 
 Public key available on http://www.jblache.org - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Steve Langasek

On Tue, Dec 16, 2008 at 03:55:40PM -0500, Kevin Mark wrote:
 On Tue, Dec 16, 2008 at 09:34:39PM +0100, Thomas Viehmann wrote:
  Romain Beauxis wrote:
   I think you completely forgot about the fact that this project is run by 
   people who aren't payed for that.

   And, yes I didn't fix any RC bug today, nor yesterday. I even have now 3 
   on 
   mediawiki for which I won't be able to take much time. 

  How about once per year?

 people can decide to not contribute to a volunteer project for many
 reasons:  hostile work environment, discouragement when expressing ideas are 
 2.
 A project as huge as Debian has a hard enough time keeping the 'fun' but
 making the atmostphere for people unplesent will not only discourage
 current people but also future contributer.

The single largest factor in making the atmosphere unpleasant is people who
aren't contributing to Debian running their mouths on our development lists.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Julien BLACHE

Jan Hauke Rahm i...@jhr-online.de wrote:

Hi,

 Reading this (and following the idea of not introducing new stuff or
 archives but releasing faster) it sounds as simple as testing needs
 to be more strict and rigorous in accepting packages to be *indeed*
 always in a seriously better shape than unstable so that releases can be
 done with shorter freeze times, right?

When testing was introduced, people moved from using unstable to using
testing to get the latest and greatest.

At that time, unstable was sometimes pretty wild, prone to serious
breakages way more often that today (be it after a release - which was
a horrible time, really - or during heavy development).

Also new users have a tendency to go with testing and don't use
unstable much these days.

The net effect is that there aren't enough people left using unstable
to uncover enough problems. Hence bugs silently make it to testing.

Being stricter wrt testing migration is hardly going to help. What
will help is having more people actually use unstable so bugs are
uncovered before they hit testing.

JB.

-- 
 Julien BLACHE - Debian  GNU/Linux Developer - jbla...@debian.org 
 
 Public key available on http://www.jblache.org - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Neil McGovern

On Tue, Dec 16, 2008 at 06:07:25PM +0100, Lucas Nussbaum wrote:
 clear that most people don't work on RC bugs instead of working on their
 packages: I don't have any data on that, it's mostly based on
 perception. Let's try to gather data on something relevant:
 
 Number of distinct posters per month on debian-bugs...@lists.d.o:
[snip]
 So, the number of people working on RC bugs has significantly decreased
 since the beginning of the freeze.
 

Accountable by ther being less RC bugs (obviously) and perhaps vote_002
and vote_003 taking up peoples time.


 it's judged socially incorrect to work on one's packages in unstable or
 *experimental* during the freeze.
 I'm not sure if a difference is made between unstable and experimental
 by people complaining about people doing something else than fixing RC
 bugs. Is the concern purely technical, ie working on unstable packages
 makes thing harder for the release? Or social, ie you should work on
 the release instead of doing $FOO.

Work on very disruptive changes in unstable is discouraged as this may
mean that packages which mean to go through to lenny aren't able to. The
release team actively encourages the use of experimental to avoid these
problems.

I would also note that working on unstable != working on release. The
RC bugs still need fixing.

Neil
-- 
* toresbe wonders what would happen if Ted Walther and Amaya were put in the
same room
Amaya toresbe: blood, sweat, tears and finally castration


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

On Tue, Dec 16, 2008 at 09:53:58PM +, Neil Williams wrote:
 I get criticised for being rude or direct - well here's the news: I don't care
 if people think I'm rude, deal with it. At least I do what I can to fix stuff,
 I apologise when I do make mistakes and I do not recommend something I have
 not done myself. Would that more contributors were as active.

I think you should care about upsetting people, and so should others. When you
work for an organisation like Debian, the community is the most valuable asset
it has going for it. Rude and abrasive characters who contribute a lot of code,
but who upset the community, waste time by drawing fire or starting flame wars,
or scare away new contributers do not deserve to be excused for such behaviour.

-- 
Noah Slater, http://tumbolia.org/nslater


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Russell Coker

On Tuesday 16 December 2008 10:06, Romain Beauxis to...@rastageeks.org 
wrote:
  Is that important? Unstable is frozen for nearly 1/2 year now, that's a
  problem we should try to solve if we don't want to degrade ourselves to
  a server-only distribution.

 You can't get both recent *and* stabilized software. For a solid release to
 be done, one needs to hold new improvements for a while.

I think it would be good if we could take time to stabilise the server version 
while continuing to work on development versions.

The Fedora vs RHEL model that Red Hat uses has some benefits.

If we were to follow that idea then we could skip most of the X stuff from the 
server variant.  My observation is that it's pretty common to use GNOME and a 
KVM switch (or similar functionality such as HP ILO) to manage RHEL servers 
while for Debian servers most people just use command-line utilities with 
SSH.

Note that I am not strongly advocating the Fedora vs RHEL model, because it 
does involve a moderate amount of extra work.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Russell Coker

On Tuesday 16 December 2008 23:38, Holger Levsen hol...@layer-acht.org 
wrote:
 I find it very strange to see people complaining about the long freeze,
 instead of working on making it shorter.

 If we decouple the freeze from development in unstable, the result will
 that less people will be working on releasing, thus the freeze will take
 even longer.

There are however some benefits to decoupling which can reduce the time taken 
to fix some bugs.

If a package has a bug in testing but a newer version in unstable doesn't have 
the bug, then it makes it easier for the person who reports the bug to 
discover this fact and note it in the bug report.  Then the maintainer can 
diff the packages to try and find the fix.  This could in some situations 
allow the maintainer to fix a bug that they can't reproduce.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Jan Hauke Rahm

On Tue, Dec 16, 2008 at 11:22:29PM +0100, Julien BLACHE wrote:
 Being stricter wrt testing migration is hardly going to help. What
 will help is having more people actually use unstable so bugs are
 uncovered before they hit testing.

Sounds reasonable... so, we have to encourage (competent) users to
stick with sid and extensively report bugs which means to generally
recommend sid for experienced users.
Some might object but it could indeed shorten the freeze time since RC
bugs would have been found much earlier.

Hauke


signature.asc
Description: Digital signature

Re: problems with the concept of unstable - testing

Ana Guerrero wrote:

 On Tue, Dec 16, 2008 at 12:29:21AM +0100, Didier Raboud wrote:
 
 Look for example at the upcoming KDE4.2 : KDE4.0 (public beta) went out
 in january 2008. Since then and 'because' of the unstable-to-testing
 pipe, KDE4.0 has only lived in experimental with the big fat blinking
 red WARNING sign above.
 
 KDE4 was then hard to test for testing users that don't play with
 apt-pinning and KDE4 will not be part of Lenny (even if it could…),
 roughly 15 months after its release.
 
 That's not a problem from Debian stable users, who need a stable before
 all release. But for the FLOSS community and the geeky users, I guess
 that it is in fact a problem.
 
 With a less jungle experimental which you could trust as the unfrozen
 unstable or with a constantly unfrozen unstable, this would not be an
 issue.

 Please, next time pick up an example you know better.
 
 KDE 4.0 totally belonged to experimental, 4.1 has never been uploaded to
 unstable because lenny was planned to be released with KDE 3.5, and even
 there was an update to this series a few months ago.  Furthermore, Lenny
 users can test it from http://kde4.debian.net
 KDE 4.2 has not being release *yet*.

Point understood. I apologize for that.

 I encourage you to (co)maintain packages in Debian. It will give you a
 better idea of how some stuff works and I think it could change some of
 the points of view I have read from you in this thread.
 
 Ana 

Thanks for the encouragement.

Didier
-- 
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Tzafrir Cohen

On Wed, Dec 17, 2008 at 09:31:13AM +1100, Russell Coker wrote:
 On Tuesday 16 December 2008 10:06, Romain Beauxis to...@rastageeks.org 
 wrote:
   Is that important? Unstable is frozen for nearly 1/2 year now, that's a
   problem we should try to solve if we don't want to degrade ourselves to
   a server-only distribution.
 
  You can't get both recent *and* stabilized software. For a solid release to
  be done, one needs to hold new improvements for a while.
 
 I think it would be good if we could take time to stabilise the server 
 version 
 while continuing to work on development versions.
 
 The Fedora vs RHEL model that Red Hat uses has some benefits.

The Fedora and RHEL is:

Fedora: a somewhat equivalent of Debian Testing. The rules for updating 
a package even after a version is released are way more laxed than 
Debian Stable.

RHEL: Much less software. You can't expect to maintain the whole 
archive of Debian Stable for 5 or 7 years without it. There are many 
packages I miss in the CentOS archive.

Also note that none of those distribution has a distinction between 
server and desktop in the release cycle management. Ubuntu has a 
server variant, but it is merely a way to package different packages 
and defaults into the installation CD. RHEL has a distinction between 
server and desktop, but I figure that this is because supporting a 
server instance costs more (or that people are willing to pay more for 
it).

This is somewhat like Ubuntu's LTS: it is a guarantee for 5 years, but 
only for Ubuntu's Main, and not for Ubuntu's Universe.

And I figure that sure, the model of RHEL would work well for us. Only if 
the Stable release includes *my* pet packages. Just as much as: 'Sure we 
can release Lenny tommorow. Just as long as *my* pet bugs get fixed'.


Regards,

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Josselin Mouette

Le mardi 16 décembre 2008 à 23:55 +, Tzafrir Cohen a écrit :
 Fedora: a somewhat equivalent of Debian Testing. The rules for updating 
 a package even after a version is released are way more laxed than 
 Debian Stable.

For what I’ve seen, Fedora rawhide is more similar to Debian
experimental – and I don’t mean experimental as it is right now, as a
replacement for unstable during the freeze.

 And I figure that sure, the model of RHEL would work well for us. Only if 
 the Stable release includes *my* pet packages. Just as much as: 'Sure we 
 can release Lenny tommorow. Just as long as *my* pet bugs get fixed'.

Quite true indeed.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: problems with the concept of unstable - testing

2008-12-16 Thread Josselin Mouette

Le mardi 16 décembre 2008 à 23:22 +0100, Julien BLACHE a écrit :
 Also new users have a tendency to go with testing and don't use
 unstable much these days.
 
 The net effect is that there aren't enough people left using unstable
 to uncover enough problems. Hence bugs silently make it to testing.

Maybe that’s because I maintain packages with a large audience, but I
don’t find that effect very important. 

More annoying are these effects:
  * Bugs that trigger with a specific combination of packages. In
unstable they are fixed very quickly, but even when adding a
Conflict, one of the packages can migrate to testing long before
the others and keep testing in a broken state.
  * Testing users don’t check whether a bug is fixed in unstable.
It’s not that bugs silently make it to testing, but they are
fixed much more quickly in unstable. That could be improved with
reportbug being stricter about bugs against testing packages
with newer versions in unstable.

 Being stricter wrt testing migration is hardly going to help. What
 will help is having more people actually use unstable so bugs are
 uncovered before they hit testing.

Actually I don’t think we should recommend testing at all to desktop
users. Except during freeze times, I find unstable to be much more
usable, and keep testing for (non-production) servers.

However it is important to keep a large testing userbase, since
developers don’t (at least, they aren’t supposed to) use it. Some bugs
triggering with some package combinations only appear in testing and
during the etch freeze, some very nasty bugs were detected this way.
(This didn’t happen with lenny since unstable has remained almost the
same as testing.)

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: problems with the concept of unstable - testing

2008-12-16 Thread Cyril Brulebois

Romain Beauxis to...@rastageeks.org (16/12/2008):
 I think you completely forgot about the fact that this project is run
 by people who aren't payed for that.

They aren't paid for repeatedly ranting about the fact we have not
released yet, either. Which is something Bastian does, and which is what
was answered to.

(And yes, I've been busy ranting lately, too, but I guess it's a bit of
a different story.)

 And, yes I didn't fix any RC bug today, nor yesterday. I even have now
 3 on mediawiki for which I won't be able to take much time.

Why not documenting that in those bugreports so that people looking at
them can see that (without having to notice it through the quotes by
Raphael)? In addition to a quick mail to the bugs, you could tag them
help, too.

 And I won't explain my reasons, it is private for me.

Sure,

 However the packages are open for any contribution. Maybe yours ?

but please communicate on their being open for contribution, especially
because you won't be able to deal with them. Particularly helps
debian-bugs-rc@ readers.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: problems with the concept of unstable - testing

2008-12-16 Thread Tzafrir Cohen

On Wed, Dec 17, 2008 at 01:17:33AM +0100, Josselin Mouette wrote:
 Le mardi 16 décembre 2008 à 23:55 +, Tzafrir Cohen a écrit :
  Fedora: a somewhat equivalent of Debian Testing. The rules for updating 
  a package even after a version is released are way more laxed than 
  Debian Stable.
 
 For what I’ve seen, Fedora rawhide is more similar to Debian
 experimental – and I don’t mean experimental as it is right now, as a
 replacement for unstable during the freeze.

Just to clarify: I was relating to Fedora releases. I'll also point out 
that I'm not much familiar with Fedora.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-16 Thread Daniel Moerner

On Tue, Dec 16, 2008 at 4:34 PM, Josselin Mouette j...@debian.org wrote:
 Le mardi 16 décembre 2008 à 23:22 +0100, Julien BLACHE a écrit :
 Also new users have a tendency to go with testing and don't use
 unstable much these days.

 The net effect is that there aren't enough people left using unstable
 to uncover enough problems. Hence bugs silently make it to testing.

 Maybe that's because I maintain packages with a large audience, but I
 don't find that effect very important.

 More annoying are these effects:
  * Bugs that trigger with a specific combination of packages. In
unstable they are fixed very quickly, but even when adding a
Conflict, one of the packages can migrate to testing long before
the others and keep testing in a broken state.
  * Testing users don't check whether a bug is fixed in unstable.
It's not that bugs silently make it to testing, but they are
fixed much more quickly in unstable. That could be improved with
reportbug being stricter about bugs against testing packages
with newer versions in unstable.


Obviously, having more users test unstable is good.  However, I agree
that it's not necessarily a big issue.  A good deal of RC-bugs are
related to FTBFS, security advisories, package conflicts, and the
like.  These bugs can pop up independently of how much testing a
package receives in unstable, so focusing on just increasing the
number of unstable users would produce diminishing returns.

 Being stricter wrt testing migration is hardly going to help. What
 will help is having more people actually use unstable so bugs are
 uncovered before they hit testing.

 Actually I don't think we should recommend testing at all to desktop
 users. Except during freeze times, I find unstable to be much more
 usable, and keep testing for (non-production) servers.

I think this is true as well, especially in the context of other
non-Ubuntu distributions that track Debian.  Sidux, which tracks Sid,
is able to keep almost complete compatibility with the main Debian
repositories with the exception of kernels.  In contrast,
distributions that track testing often have to have much more complete
supplementary repositories.  In part, this is due to ideological
differences, but I think it's also due to the fact that desktop users
can get more mileage from unstable.

Cheers,
Daniel

-- 
Daniel Moerner dmoer...@gmail.com


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Re: problems with the concept of unstable - testing

2008-12-16 Thread Filipus Klutiero



The other way round works, too: Removing people who don't have that
minimal commitment from the project and their packages from the archive
would also allow us to release (a lot less) in a timely fashion.
  



Right... And it would also help releasing timely to remove all buggy 
packages.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Re: problems with the concept of unstable - testing

2008-12-16 Thread Filipus Klutiero



That works both ways - those who do contribute and help Debian across a
wide range of areas should be valued and supported, even if they show
that frustration from time to time. Everyone makes mistakes but why
must the most active contributors be the first target of criticism when
they criticise others who do little to help Debian? What about those who
simply obstruct other developers? Isn't there any wider consideration
that uploading packages that are unfit for purpose and refusing to fix
problems identified by more active, more respected members is only
going to frustrate those who do care?

What packages do you have in mind?

Where's the criticism of the original post that brings nothing useful
or new to the discussion and comes from someone who has done nothing
positive to further the release of Lenny? It's laughable. Why must we
always blame the responder and not the initiator?
  

Your questions assume several things I disagree with:

the original post comes from someone who has done nothing positive to 
further the release of Lenny


we always blame the responder and not the initiator

Overly long freezes are a pain but the solution is not to complain, the
solution is to fix the RC bugs, help with the debian-installer, help
with the translation team and get the release finished. That's what I'm
trying to do, that's what Thomas was doing.

I didn't realize either mail did that.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Re: problems with the concept of unstable - testing

2008-12-16 Thread Filipus Klutiero



The single largest factor in making the atmosphere unpleasant is people who
aren't contributing to Debian running their mouths on our development lists.
  
I disagree, though I know relatively well how much people contribute. 
I'd rather blame the mailing lists if simple enthusiasts caused too much 
noise.
What bores me more than non-contributors running their mouths is people 
choking during a marathon.

http://lists.debian.org/debian-devel/2008/12/msg00229.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

problems with the concept of unstable - testing

2008-12-15 Thread Russell Coker

Currently any time I want to update a package for Lenny it has to go through 
unstable and testing first.

If the Lenny freeze time was short this MIGHT be considered to be only a minor 
obstacle to development.  But as the freeze is getting longer and we have a 
GR which could make it a lot longer this seems like a significant problem.

If I upload a significantly newer version to unstable (which I would like to 
do for some of my packages as part of ongoing development that will lead to 
Lenny+1) then AKAIK there is no way to put a minor update in Lenny (unless I 
was to use an epoch change which would be horrible and might require changes 
to several other packages).

I think that we need a way to upload to Lenny without involving unstable.

I don't think that my suggestion is anything new, it is the practice on every 
other large software development project that I have seen which has been 
reasonably well run.

While changes to the processes for uploading new packages are probably not 
desirable when a freeze is starting, it seems that Lenny might be delayed for 
a while.  So if the GR on the Lenny release ends up actually changing 
anything then I suggest that we make some changes to prevent stalling all 
development.

Failing that I will create my own repository for unstable versions of my 
packages - which of course won't give as good a result as most users of 
Unstable won't get them.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-15 Thread Michal Čihař

Hi

Dne Tue, 16 Dec 2008 07:02:59 +1100
Russell Coker russ...@coker.com.au napsal(a):

 Currently any time I want to update a package for Lenny it has to go through 
 unstable and testing first.
 
 If the Lenny freeze time was short this MIGHT be considered to be only a 
 minor 
 obstacle to development.  But as the freeze is getting longer and we have a 
 GR which could make it a lot longer this seems like a significant problem.
 
 If I upload a significantly newer version to unstable (which I would like to 
 do for some of my packages as part of ongoing development that will lead to 
 Lenny+1) then AKAIK there is no way to put a minor update in Lenny (unless I 
 was to use an epoch change which would be horrible and might require changes 
 to several other packages).
 
 I think that we need a way to upload to Lenny without involving unstable.

I thought testing-proposed-updates is for that...

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: problems with the concept of unstable - testing

Russell Coker russ...@coker.com.au (16/12/2008):
 I think that we need a way to upload to Lenny without involving
 unstable.

Or you might use experimental, and keep unstable for lenny.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: problems with the concept of unstable - testing

2008-12-15 Thread Julien BLACHE

Russell Coker russ...@coker.com.au wrote:

Hi,

 I think that we need a way to upload to Lenny without involving unstable.

Something like testing-proposed-updates, which already exists today, and
also existed for previous releases?

 Failing that I will create my own repository for unstable versions of my 
 packages - which of course won't give as good a result as most users of 
 Unstable won't get them.

You mean, something like experimental?

You failed Basic research 101. And it was as simple as going to
http://release.debian.org and read the Lenny freeze announcement
http://lists.debian.org/debian-devel-announce/2008/07/msg7.html
that is linked under the Lenny frozen title.

JB.

-- 
 Julien BLACHE - Debian  GNU/Linux Developer - jbla...@debian.org 
 
 Public key available on http://www.jblache.org - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

Michal Čihař ni...@debian.org (15/12/2008):
 I thought testing-proposed-updates is for that...

tpu is considered a last resort measure in case it's not possible to fix
a package through unstable. Less testing (hmm) through tpu than through
unstable is a part of the problem with pushing things this way rather
than letting them flow in through unstable + unblocks.

Oh, and please note the hard freeze we entered, too.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: problems with the concept of unstable - testing

2008-12-15 Thread Steffen Joeris

Hi Russell

 If I upload a significantly newer version to unstable (which I would like
 to do for some of my packages as part of ongoing development that will lead
 to Lenny+1) then AKAIK there is no way to put a minor update in Lenny
 (unless I was to use an epoch change which would be horrible and might
 require changes to several other packages).
You can upload to testing-proposed-updates (testing in the changelog will work 
too). Then the package will be autobuild on the archs and released into 
testing by the release team. Nonetheless, it should be discussed with the 
release team first, if such an upload is desired.

The same goes for security. There is testing-security, which is accepted on 
security.debian.org. Once it is released there as a DTSA, the packages will 
be copied to ftp-master and then go into the testing-proposed-updates queue 
and eventually end up in testing. (Of course it should be coordinated with 
the security team to avoid confusion, broken uploads and duplicated work :))

Is that what you were after?

Cheers
Steffen


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

Re: problems with the concept of unstable - testing

2008-12-15 Thread Noah Slater

On Mon, Dec 15, 2008 at 09:30:33PM +0100, Julien BLACHE wrote:
 You mean, something like experimental?

 You failed Basic research 101. And it was as simple as going to
 http://release.debian.org and read the Lenny freeze announcement
 http://lists.debian.org/debian-devel-announce/2008/07/msg7.html that is
 linked under the Lenny frozen title.

Is there any need for such rude condescension?

-- 
Noah Slater, http://tumbolia.org/nslater


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-15 Thread Bastian Venthur

Russell Coker schrieb:
[...]
 While changes to the processes for uploading new packages are probably not 
 desirable when a freeze is starting, it seems that Lenny might be delayed for 
 a while.  So if the GR on the Lenny release ends up actually changing 
 anything then I suggest that we make some changes to prevent stalling all 
 development.

I support that request. Not only is unstable quite outdated already
(bleeding edge?) it also becomes more and more a problem since the
kernel and Xorg aren't updated anymore in unstable. That means that
newer hardware (especially Laptops) don't fully work anymore (WLAN,
Graphic, Sound).

Since we're making it very hard for our users to get their new hardware
working seamlessly, unstable becomes more and more unattractive compared
to other distributions.

Some suggest to cherry pick packages from experimental, but first some
packages like the kernel aren't even available there and second, since
experimental is not part of the unstable  testing  stable flow, it has
the aura of sandbox/playground/if-your-box-breaks-its-your-own-fault.
And officially we don't even recommend using unstable, aren't we? So for
me that argument is invalid.

What I'd like to see is a solution where unstable is *never* frozen,
maybe by replacing the current frozen unstable with something temporary
and putting it between unstable and testing, where all the fixes go
while all the new stuff can still go into unstable but cannot enter the
next step while we're in the freeze:

Normal:

experimental || unstable  testing  stable

Freeze:

experimental || unstable || $something frozen  testing  stable

Basicly we already have this with:

experimental || unstable  testing  stable

but that's an abuse of experimental (as a substitute for unstable), not
everyone uses it to upload new packages and it still has the
I'll-break-you-box-aura.


Cheers,

Bastian


-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

Bastian Venthur vent...@debian.org (15/12/2008):
 Some suggest to cherry pick packages from experimental, but first some
 packages like the kernel aren't even available there and second,

AFAICT since kernel people are already busy with getting the kernel in
shape for lenny. Not because of some classification. IMHO, IANAKM, etc.

 since experimental is not part of the unstable  testing  stable
 flow, it has the aura of
 sandbox/playground/if-your-box-breaks-its-your-own-fault.

So is unstable. Or even testing, to a lower extent.

 And officially we don't even recommend using unstable, aren't we? So
 for me that argument is invalid.

Which argument?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: problems with the concept of unstable - testing

2008-12-15 Thread Didier Raboud

Bastian Venthur wrote:

 Russell Coker schrieb:
 [...]
 While changes to the processes for uploading new packages are probably
 not desirable when a freeze is starting, it seems that Lenny might be
 delayed for
 a while.  So if the GR on the Lenny release ends up actually changing
 anything then I suggest that we make some changes to prevent stalling all
 development.
 
 I support that request. Not only is unstable quite outdated already
 (bleeding edge?) it also becomes more and more a problem since the
 kernel and Xorg aren't updated anymore in unstable. That means that
 newer hardware (especially Laptops) don't fully work anymore (WLAN,
 Graphic, Sound).
 
 Since we're making it very hard for our users to get their new hardware
 working seamlessly, unstable becomes more and more unattractive compared
 to other distributions.
 
 Some suggest to cherry pick packages from experimental, but first some
 packages like the kernel aren't even available there and second, since
 experimental is not part of the unstable  testing  stable flow, it has
 the aura of sandbox/playground/if-your-box-breaks-its-your-own-fault.
 And officially we don't even recommend using unstable, aren't we? So for
 me that argument is invalid.
 
 What I'd like to see is a solution where unstable is *never* frozen,
 maybe by replacing the current frozen unstable with something temporary
 and putting it between unstable and testing, where all the fixes go
 while all the new stuff can still go into unstable but cannot enter the
 next step while we're in the freeze:
 
 Normal:
 
 experimental || unstable  testing  stable
 
 Freeze:
 
 experimental || unstable || $something frozen  testing  stable
 
 Basicly we already have this with:
 
 experimental || unstable  testing  stable

Something like

experimental || unstable-be || unstable-pt  testing  stable

with: 

experimentalReal sandbox/playground/if-your-box-breaks-its-your-own-fault
unstable-be Bleeding-Edge   Constantly updated to newest upstream
unstable-pt Pre-Testing Last considered long-time and stable upstream
Bug-fixing, actual unstable
testing as actually Future Stable

?

-- 
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing

2008-12-15 Thread Bastian Venthur

Didier Raboud schrieb:
 Bastian Venthur wrote:
 What I'd like to see is a solution where unstable is *never* frozen,
 maybe by replacing the current frozen unstable with something temporary
 and putting it between unstable and testing, where all the fixes go
 while all the new stuff can still go into unstable but cannot enter the
 next step while we're in the freeze:

 Normal:

 experimental || unstable  testing  stable

 Freeze:

 experimental || unstable || $something frozen  testing  stable

 Basicly we already have this with:

 experimental || unstable  testing  stable
 
 Something like
 
 experimental || unstable-be || unstable-pt  testing  stable
 
 with: 
 
 experimentalReal sandbox/playground/if-your-box-breaks-its-your-own-fault
 unstable-be Bleeding-Edge   Constantly updated to newest upstream
 unstable-pt Pre-Testing Last considered long-time and stable 
 upstream
 Bug-fixing, actual unstable
 testing as actually Future Stable
 
 ?

Something like that, I don't really care about the name. The important
thing is, that unstable is never frozen, but temporarily disconnected
from the unstable  testing  stable flow.

Another way to see it is that unstable is constantly flowing and we're
just forking a stable distribution from it from time to time.


Cheers,

Bastian

-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problems with the concept of unstable - testing