Re: problems with the concept of unstable - testing
On Monday 22 December 2008 17:55, Paul Wise p...@debian.org wrote: On Mon, Dec 22, 2008 at 6:08 AM, Kjeldgaard Morten mortenkjeldga...@gmail.com wrote: Another model that I think has not been discussed is never freezing stable. Freezing is the whole point of stable, if we didn't freeze it, it has no reason to exist. In the current design stable means frozen. The suggestion was that you have a branch named stable (which actually could be given some other name) that consists of packages that have been through testing and found to pass some criteria suggesting quality (in the same way that testing has packages that have passed through unstable after some days of delay without new versions). Then the frozen branches would have some name other than stable. Basically it's a suggestion for two levels of testing. -- 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
On Mon, Dec 22, 2008 at 5:55 AM, Russell Coker russ...@coker.com.au wrote: On Monday 22 December 2008 17:55, Paul Wise p...@debian.org wrote: On Mon, Dec 22, 2008 at 6:08 AM, Kjeldgaard Morten mortenkjeldga...@gmail.com wrote: Another model that I think has not been discussed is never freezing stable. Freezing is the whole point of stable, if we didn't freeze it, it has no reason to exist. In the current design stable means frozen. The suggestion was that you have a branch named stable (which actually could be given some other name) that consists of packages that have been through testing and found to pass some criteria suggesting quality (in the same way that testing has packages that have passed through unstable after some days of delay without new versions). Then the frozen branches would have some name other than stable. Basically it's a suggestion for two levels of testing. The thought of a rolling release system has a lot of appeal to me for desktop usage, but not for server usage, since each update contains the potential to break things. It might be worth investigating into, I know such infrequent releases makes using RELEASE-backports, or running testing becomes almost essential if you want updated tools. -- 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 -- 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
* Michael Casadevall sonicmcta...@gmail.com [081222 12:14]: The thought of a rolling release system has a lot of appeal to me for desktop usage, but not for server usage, since each update contains the potential to break things. I don't see how that is different for server or desktop. Large amount of desktop machines are also much easier to administrate when not changing the software all the time. There might be a difference for personal, one-user-who-is-administrator machines, but I guess such servers might exist, too. Hochachtungsvoll, Bernhard R. Link -- 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 Mon, Dec 22, 2008 at 05:03:03PM +0100, Bernhard R. Link wrote: * Michael Casadevall sonicmcta...@gmail.com [081222 12:14]: The thought of a rolling release system has a lot of appeal to me for desktop usage, but not for server usage, since each update contains the potential to break things. I don't see how that is different for server or desktop. Large amount of desktop machines are also much easier to administrate when not changing the software all the time. Thats partly true. But while it possible makes administration easier is probably does NOT make support easier. That is for several reasons: There is _more_ software to support (e.g. answering questions to users, help them customizing it to their requirements), the target audience is more sensible for isssues that we'd consider minor or not worth to fix in a stable release, etc. Often there are usability improvements in software that helps the people who use the desktop to be more efficient in what they do. Desktops are probably the most-compelling reason why a need for backports exist, IMHO. Regards, Patrick -- 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 15/12/2008, at 21.25, Cyril Brulebois wrote: Or you might use experimental, and keep unstable for lenny. Another model that I think has not been discussed is never freezing stable. Say stable is redefined as bug-free in the sense that there are no RC bugs in that repo. If a serious bug is found in a package, it is removed from stable, until the bug has been fixed in testing. When it's time for a release, that is simply forked off stable, and the release branch is frozen (with the usual development work going on towards the final release.) After the branching, stable will continue to receive updated/fixed packages from testing, which again will continue to receive packages from unstable. This would create a situation where there are three development branches, graduated according to degree of bug-freeness and one release branch. The advantage is that work does not need to halt in any of the development branches, while keeping a stable release that at any point is ready for branching into a release. Cheers, Morten -- 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
In article 1e8bc2f9-7665-4186-acff-79ad91461...@bioxray.au.dk you wrote: Say stable is redefined as bug-free in the sense that there are no RC bugs in that repo. If a serious bug is found in a package, it is removed from stable, until the bug has been fixed in testing. this does only work for packages with no dependencies. But if you ignore that limitation, its a good idea:) Greetings Bernd -- 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 Mon, Dec 22, 2008 at 6:08 AM, Kjeldgaard Morten mortenkjeldga...@gmail.com wrote: Another model that I think has not been discussed is never freezing stable. Freezing is the whole point of stable, if we didn't freeze it, it has no reason to exist. -- bye, pabs http://wiki.debian.org/PaulWise -- 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
Hi, sorry for posting to this thread once more, permit me to get this off my chest. I apologize for the disgraceful lack of civility my posts to this thread and I regret that it reduced your fun in Debian. If you are inclined to do me a favor after all of this, please don't reply to this message. 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
Hi, 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. how about splitting the frozen phase into soft and hard with soft preceding hard? during soft freeze any changes can be made as long as no new RC bugs get introduced, and during hard freeze is what happens today. Kind regards -- -- Dionysios Kalofonos -- 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 Fri, Dec 19, 2008 at 02:09:03PM +0100, Dionysios Kalofonos wrote: during soft freeze any changes can be made as long as no new RC bugs get introduced, and during hard freeze is what happens today. Erm, doesn't this happen already? Neil -- @nurn Paedophile Glitter arrives in UK @nurn is it me or does that sound like a very inappropriate brand name? @sooB the sort that would only be advertised in the run-up to christmas @nurn it's like a twisted my little pony name signature.asc Description: Digital signature
Re: problems with the concept of unstable - testing
Neil McGovern wrote: On Fri, Dec 19, 2008 at 02:09:03PM +0100, Dionysios Kalofonos wrote: during soft freeze any changes can be made as long as no new RC bugs get introduced, and during hard freeze is what happens today. Erm, doesn't this happen already? sorry, something i did not clarify, announce a hard freeze after the RC bugs have been resolved. Only for the last touches. -- -- Dionysios Kalofonos -- 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 11:22:29PM +0100, Julien BLACHE wrote: 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. for the record: i have a script running that monitors that, and bugs are found 50/50 in unstable and testing. no real trend over the last 1.5 years. considering how many people use testing, and how few use unstable, i think unstable is quite effective! cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: problems with the concept of unstable - testing
On Dec 16, 2008, at 9:52 PM, Noah Slater wrote: 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. Well said. This is an attitude that can serve debian well. Regards, Jeremiah -- 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
Christian Perrier dijo [Tue, Dec 16, 2008 at 07:40:12AM +0100]: 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: (...) 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. I like and subscribe to your idea. I feel that many of us are actually bitten by that same problem - even if we have upstreams that understand the process of releasing Debian, it is hard to expect them to work with the madness associated with long freezes. And I do not think we will be able to avoid long freezes in the future, just because of the scale we work with - We might be able to somehow reduce the length, but not as much as to meet a lively upstream's fantasy :) -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- 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
Josselin Mouette j...@debian.org wrote: Hi, Maybe that’s because I maintain packages with a large audience, but I don’t find that effect very important. You're right about the large audience, it does make quite a difference. 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. Agreed. 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 Ditto. 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
Daniel Moerner dmoer...@gmail.com wrote: Hi, 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. Your point is moot, mostly: FTBFS and package relationships issues are probably the easiest RC bugs to fix, they're not the kind of RC bugs we're seeing right now before a release (at that point any RC bugs of these kinds that aren't fixed are either tricky or not being taken care of properly). Also most FTBFS are not reported by users. 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josselin Mouette wrote: Actually I don’t think we should recommend testing at all to desktop users. Why? Except during freeze times, I find unstable to be much more usable, and keep testing for (non-production) servers. IMHO, there is one important difference between testing and unstable, as far as desktop users are concerned: 'testing' at some time will become 'stable'. As a scientist, I basically need stable, reliable software to carry out my work. Sometimes new hardware or new features in some core programs I use warrant an upgrade to testing. However, I would not like to 'indefinitely' cut off a route to 'stable' for my desktop(s). Of course, your mileage may vary... ;-) Cheers, Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklIy4cACgkQC1NzPRl9qEUKLACePM1oWPE+qYtVDPdBa4sNnQTa ITAAnidMpNHFgTBUB84OhL+zD7u/98TE =l2KZ -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
On Wednesday 17 December 2008 10:55, Tzafrir Cohen tzaf...@cohens.org.il wrote: 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. In terms of the requirements for version updates, Debian/Testing and Fedora are quite similar. Debian/Testing is often suggested for home (not corporate) desktop use and Fedora is the home desktop system from Red Hat. 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. True. There are a number of possibilities for alleviating this. One suggestion that has been made is to split Debian into different sections with different release requirements. One possible way of doing this is to have one section for core and server software which would also be the base for a Fedora-like distribution and the entire package list for a CentOS/RHEL like distribution. One possibility if we were to have a Debian equivalent to CentOS/RHEL would be to have apt sources repositories from newer distributions. Having a system with most packages coming from a stable binary package set and a couple of missing packages compiled from a source base such as Debian/Testing should give a good result. If I could find a good set of package sources that would build on CentOS then my CentOS sys-admin work would be a lot easier. 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). The various versions of RHEL have different price-points and different package sets. Pay more money and more server packages are supported. The recommended use of Fedora is desktops not servers. While desktop environments are supported in RHEL, this tends to be mostly centrally managed corporate desktops not individual one-off systems - so it's a similar situation to servers in terms of a resource being centrally managed by the IT group. You can consider the release cycle difference between Fedora and RHEL to be the difference between desktop and server systems. -- 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
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
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
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
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
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
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
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
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
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
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
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
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
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 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 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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Bastian Venthur vent...@debian.org (15/12/2008): 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. It's called Ubuntu. Mraw, SCNR, KiBi. signature.asc Description: Digital signature
Re: problems with the concept of unstable - testing
Bastian Venthur wrote: 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. Isn't there a need for a freeze+stabilisation time (~ a year for Lenny…) in which updates occur in 2 stages to finalize and stableize one particular snapshot ? Note that forking+stable'izing Sid is what Ubuntu does every six months. /me scratches head. -- 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
Didier Raboud schrieb: 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. 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. Isn't there a need for a freeze+stabilisation time (~ a year for Lenny…) in which updates occur in 2 stages to finalize and stableize one particular snapshot ? I'm not sure what you're asking but by temporarily insterting a $frozen-something between unstable and testing, we basically have the same flow as currently just with the benefit of a living unstable. I don't see the problem: currently during the freeze: unstable (frozen) testing stable new: unstable || unstable (frozen) testing stable Note that forking+stable'izing Sid is what Ubuntu does every six months. 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. 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
Hmmm. Thinking about it again: * For now, until the Lenny Release, there is testing-proposed-updates, which should maybe pushed more for users and DD's to use. * http://wiki.debian.org/ReleaseProposals has enough thoughts about possible changes. Maybe develop ideas further more directly in the wiki. After, AFTER, after releasing Lenny, propose a GR for changing the Release Process. -- 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 Mon, Dec 15, 2008 at 08:41:06PM +, Noah Slater wrote: 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? No. The pointers conveyed by the follow-up were great, the tone terrible. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature