Re: Bits from the Release Team - Kicking off Wheezy
On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote: Sprint -- We feel it would be useful for the Release Team as a whole to get together to think about what the plans are for the next release. As such, we're planning a sprint to meet in person. Details will follow once diaries have been able to be synchronised! Hi all, This now has a wiki page, at http://wiki.debian.org/Sprints/2011/Release We're hoping to hold this in two weeks time in Antwerp. Comments welcome! Neil -- +Mulligan Your folk tale is inconsistent and confusing. +Mulligan I shall round up your local population and tell them good CHRISTIAN folk tales. +Mulligan Then build churches on all your pagan temples in order to stamp out your heathen idolatry. @Ulthar How about I give you the finger, and you give me my temples back? +Mulligan Tell me Mr Ulthar. How will you gather faith when you have no followers? * Mulligan makes a gesture and converts everyone to Christianity. +Mulligan Wow. I think we just summarised 800 years of history in about six sentences. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110522082049.gr...@feta.halon.org.uk
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 08, 2011 at 10:46:35AM +0900, Charles Plessy wrote:
the 2008 GR invites to seek consensus, and in my opinion, what prove
to be anti-consensual is to divide developers into formal categories.
I have not seen such a vigourous opposition in the recent years to the
idea of accepting non-packaging developers in Debian.
I'm happy to see that today the problem seems easy to solve to several
commenters and I'm sorry I haven't seen how easy it was to solve one
year ago or so: me, Enrico, DAM, DDs, we all have limits. Were it
possible, I'll be happy to offer a time machine so that we can go back
in time 3 years to solve it way more quickly than we did so that today
we would have had not 5 people in the pipe of non-packaging developers,
but 50 or 500. But given that is not possible, I would be happy if we
could stop discussing what today is just spilled milk, given that one
way or another this matter has been settled.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
Le Sun, May 08, 2011 at 10:07:53AM +0200, Stefano Zacchiroli a écrit : I would be happy if we could stop discussing what today is just spilled milk, given that one way or another this matter has been settled. To clarify, Enrico wrote that “the hands of FD were rather tied” by the 2008 GR, and this is about what I react, and only this. Whether this GR made it more difficult to have non-packaging DDs or not is indeed another question that I agree to not discuss. As the proposer of this GR I feel responsible for its consequences, and I wanted to clarify that it is not formally tying any hands. By no way I am suggesting that your efforts were not difficult. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110508112133.ga14...@merveille.plessy.net
Re: Bits from the Release Team - Kicking off Wheezy
On Fri, May 06, 2011 at 02:04:20PM -0400, Michael Gilbert wrote: It wasn't the GR itself. It was the fact that these changes to the NM process were actually made. I suppose it is arguable that those changes simply would not have happened without the GR, but that indicates more of a lack of direct motivation within the new maintainer team. So, if it required the GR to motivate them, then I suppose it was a necessity and ultimately a good thing, but my point is simply that its better when motivation comes from within; rather than an applied external force. I do not see how talking about the NM process or that GR is at all relevant in this thread, and please do not consider this message of mine an intent to contribute to it in any other way but to clarify a misrepresentation of a team I'm a member of. From the point of view of Front Desk, motivation has always been there: http://lists.debian.org/debian-devel-announce/2008/10/msg5.html but a GR was needed to be able to proceed, because the hands of FD were rather tied by this other GR: http://www.debian.org/vote/2008/vote_002 Please do not try to provide facts about the motivation or intentions of others unless you really know them, otherwise you run into the risk of misrepresenting other people, which is bad. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
Enrico Zini wrote: On Fri, May 06, 2011 at 02:04:20PM -0400, Michael Gilbert wrote: It wasn't the GR itself. It was the fact that these changes to the NM process were actually made. I suppose it is arguable that those changes simply would not have happened without the GR, but that indicates more of a lack of direct motivation within the new maintainer team. So, if it required the GR to motivate them, then I suppose it was a necessity and ultimately a good thing, but my point is simply that its better when motivation comes from within; rather than an applied external force. I do not see how talking about the NM process or that GR is at all relevant in this thread, and please do not consider this message of mine an intent to contribute to it in any other way but to clarify a misrepresentation of a team I'm a member of. From the point of view of Front Desk, motivation has always been there: http://lists.debian.org/debian-devel-announce/2008/10/msg5.html but a GR was needed to be able to proceed, because the hands of FD were rather tied by this other GR: http://www.debian.org/vote/2008/vote_002 Then the core problem is the hand-tying itself, and that is the consequence of the GR process itself. Thus, my point remains: GRs are the wrong way to achieve change; they have long-term and unintended consequences. Ideally, changes should be adopted based on technical merit itself; rather than forced. Please do not try to provide facts about the motivation or intentions of others unless you really know them, otherwise you run into the risk of misrepresenting other people, which is bad. OK, I actually tried to avoid presenting that as a fact, and more as an interpretation of the situation. ...if it required the GR to motivate them... makes that intent pretty clear I think. I didn't intend the word motivation to be interpreted as lack of interest or in any kind of negative connotation, but more in the sense of overcoming some kind of barrier/inertia; i.e. definition 1 in a google search: The reason or reasons one has for acting or behaving in a particular way. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110507132223.d2deb096.michael.s.gilb...@gmail.com
Re: Bits from the Release Team - Kicking off Wheezy
Le Sat, May 07, 2011 at 03:43:11PM +0200, Enrico Zini a écrit : a GR was needed to be able to proceed, because the hands of FD were rather tied by this other GR: http://www.debian.org/vote/2008/vote_002 Hi Enrico, the 2008 GR invites to seek consensus, and in my opinion, what prove to be anti-consensual is to divide developers into formal categories. I have not seen such a vigourous opposition in the recent years to the idea of accepting non-packaging developers in Debian. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110508014635.gc12...@merveille.plessy.net
Re: Bits from the Release Team - Kicking off Wheezy
Stefano Zacchiroli wrote: On Fri, Apr 29, 2011 at 06:50:04PM -0400, Michael Gilbert wrote: Look at the welcoming new contributors GR; what did that actually accomplish? There isn't anything new to show for it, there are no new means to bring contributors in, and the number of new people hasn't really changed. I doubt you'll find this surprising, but I beg to disagree. As little as that number can be, there are nowadays 3 people in the contributors keyring, 1 in the NM queue, and 1 which is about to apply (asked me to advocate him a few days ago). Considering that the infrastructure and procedures took a few months to stabilize after the GR outcome, I consider that to be a pretty good result for about 6 months since everything was up and running (and 5 it's a non negligible share of the amount of new DDs we get per year). OK, I was unaware of these developments (better DPL communication on the status in this area would be very welcome). Also, I was unable to find any info on any changes to the process at e.g. [0], so it seemed like nothing of relevance had happened. So these results are a *very good* thing, but I still see the GR as overkill. The same results could have been achieved by just deciding to go ahead and implement the non-packaging contributor process. As an aside, I feel like these changes didn't far enough to achieve the goal of welcoming new contributors. It's still a long, arduous, and drawn-out process even to be considered for the non-packaging role. I would like to see something more immediate. For example, a contributors.debian.net that would give people an email address relatively quickly with a very low barrier to entry (a few good bug reports and/or patches). This would go a long way in making people feel welcomed in a system that takes years to become a part of. I have no idea whether those people would have diminished their involvement in or not considered contributing to Debian, if the GR weren't there. But as a matter of fact, chances are that those people wouldn't have been able to be Debian Developers today if it weren't for the GR. It wasn't the GR itself. It was the fact that these changes to the NM process were actually made. I suppose it is arguable that those changes simply would not have happened without the GR, but that indicates more of a lack of direct motivation within the new maintainer team. So, if it required the GR to motivate them, then I suppose it was a necessity and ultimately a good thing, but my point is simply that its better when motivation comes from within; rather than an applied external force. Best wishes, Mike [0] http://nm.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110506140420.409cffc9.michael.s.gilb...@gmail.com
Re: Bits from the Release Team - Kicking off Wheezy
On Tue, May 03, 2011 at 04:49:42PM +0200, Jan Hauke Rahm wrote: On Tue, May 03, 2011 at 01:31:24PM +0200, Pierre Habouzit wrote: On Tue, May 03, 2011 at 11:41:35AM +0200, Lucas Nussbaum wrote: It is clear from the discussion that there would be consequences. Some would be negative, some positive. I think that we have now a pretty good understanding of the possibilities and their consequences. The remaining problem is to count DDs heads in the two camps: - Let's focus on stable releases. A rolling release should not be provided officially by Debian. - Let's see what we can do about rolling, provided we find a way to do it without diminishing the quality of our stable releases. FWIW I'm in neither. My camp would be: Please do not impede our way to produce stable releases in any ways, do whatever you want with rolling. I'm sorry but I find that a lame request. If, in whatever circumstances, Debian as a project decides to care about something beyond stable releases, for instance something called rolling, it will as a matter of fact use power of the project for such new thing and thus distract that power from stable releases. Always. Saying that anyone can do anything as long as it never interferes with what we have now is exactly the definition of keeping the status-quo, i.e. preventing improvement. Granted, it also prevents breakage. Huh, no, you can do lots of stuff that don't harm releasing a Stable… I've suggested integrating aptosid (or $derivative) people inside of Debian as a way to provide rolling, I know that Joss did so on planet too e.g. That has two very important advantages: * it brings in new blood *now* (and not an hypothetical later) to actually take care of rolling (which doesn't make all my reservation moot but I reckon does lessen their scope significantly); * it brings people who know how to do that and already have infrastructure to do so. We would just give them the opportunity to benefit from the larger and robust infrastructure we have, while taking their experience. Looks like it's win-win. Have you asked *any* contributor of *any* project about why they didn't put their efforts in Debian but instead into a different project? That's not the same thing as creating ways inside of Debian to scatter resources on too many projects. That would be irrational. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504155811.gg27...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
Marc 'HE' Brockschmidt dijo [Mon, May 02, 2011 at 09:15:38AM +0200]: I understand members of the release team feel particularly responsible to do various release-critical tasks that should have been done by the maintainers but haven't (for various reasons). And I guess that's the reason of your remark. But that's not scalable ultimately. So I think it's a good move to say we support testing and we expect every maintainer to take care of their packages there (as opposed to the current situation where too much of that work is left in the hands of the release team). Saying that will not make people do it. We have also said that we will fix bugs in a frozen testing distribution, but that doesn't mean that everyone does it. Raphael, just announcing that something should be done doesn't get stuff done. FWIW... Splitting developers' focus this way does not only mean some of us are bound to ignore rolling (as we care about stable), but the opposite - Some of us will ignore stable (as we package stuff that caters better to rolling). Of course, some packages could be hinted never to enter stable, or stuff like that... But I do feel that, although I overall like the rolling proposal, it is bound to dillute attention and, therefore, overall QA. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504165042.ga16...@gwolf.org
Re: Bits from the Release Team - Kicking off Wheezy
* Russ Allbery r...@debian.org [2011-05-03 01:20]: Lucas Nussbaum lu...@lucas-nussbaum.net writes: [ Note that my position is based on the assumption that we have a share of DDs interested in rolling similar to the share of DDs interested in stable releases. Unfortunately, it's very difficult to know where we stand regarding this. ] I'm very dubious. To take one example, if Debian stopped making stable releases, it would no longer be usable at work, which would mean that my ability to work in Debian would substantially decrease and quite possibly go away completely. I realize that we're often not on the mailing lists jumping up and down and advocating for our issues, in part because Debian works great for us and not much needs to be changed, but please remember that there are a *lot* of us using Debian on servers in large-scale production environments. And stable is our world. It's EXTREMELY IMPORTANT. It is, in many cases, the reason why we were able to sell Debian in the first place; if it weren't for Debian's exceptionally good stable releases, we would probably all be running Red Hat. I went on about this at some length at the last DebConf as part of the enterprise track. +100 on this one. yours Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110503074025.gg26...@anguilla.debian.or.at
Re: Bits from the Release Team - Kicking off Wheezy
On 02/05/11 at 16:19 -0700, Russ Allbery wrote: Lucas Nussbaum lu...@lucas-nussbaum.net writes: [ Note that my position is based on the assumption that we have a share of DDs interested in rolling similar to the share of DDs interested in stable releases. Unfortunately, it's very difficult to know where we stand regarding this. ] I'm very dubious. To take one example, if Debian stopped making stable releases, it would no longer be usable at work, which would mean that my ability to work in Debian would substantially decrease and quite possibly go away completely. Except for the sake of argumentation, I don't think that anybody considers seriously that Debian would stop making stable releases. The question is whether we want to provide a rolling release in addition to our stable releases. I realize that we're often not on the mailing lists jumping up and down and advocating for our issues, in part because Debian works great for us and not much needs to be changed, but please remember that there are a *lot* of us using Debian on servers in large-scale production environments. And stable is our world. It's EXTREMELY IMPORTANT. It is, in many cases, the reason why we were able to sell Debian in the first place; if it weren't for Debian's exceptionally good stable releases, we would probably all be running Red Hat. I went on about this at some length at the last DebConf as part of the enterprise track. I assume that when you write 'us' or 'we' here, you mean 'Debian users in large-scale production environments'. Again, I'm not diminishing the importance of stable releases. But I've always found it strange that, as a volunteer project, we are creating a product that is mainly used in professional environments. I think that the key information missing in this thread is simply: | Do DDs want to consider the possibility to create a 'rolling release' | product? It is clear from the discussion that there would be consequences. Some would be negative, some positive. I think that we have now a pretty good understanding of the possibilities and their consequences. The remaining problem is to count DDs heads in the two camps: - Let's focus on stable releases. A rolling release should not be provided officially by Debian. - Let's see what we can do about rolling, provided we find a way to do it without diminishing the quality of our stable releases. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110503094135.ga15...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
On Tue, May 03, 2011 at 11:41:35AM +0200, Lucas Nussbaum wrote: It is clear from the discussion that there would be consequences. Some would be negative, some positive. I think that we have now a pretty good understanding of the possibilities and their consequences. The remaining problem is to count DDs heads in the two camps: - Let's focus on stable releases. A rolling release should not be provided officially by Debian. - Let's see what we can do about rolling, provided we find a way to do it without diminishing the quality of our stable releases. FWIW I'm in neither. My camp would be: Please do not impede our way to produce stable releases in any ways, do whatever you want with rolling. I've suggested integrating aptosid (or $derivative) people inside of Debian as a way to provide rolling, I know that Joss did so on planet too e.g. That has two very important advantages: * it brings in new blood *now* (and not an hypothetical later) to actually take care of rolling (which doesn't make all my reservation moot but I reckon does lessen their scope significantly); * it brings people who know how to do that and already have infrastructure to do so. We would just give them the opportunity to benefit from the larger and robust infrastructure we have, while taking their experience. Looks like it's win-win. They probably have good ideas on what could be improved in Debian to make their job easier, while *we* don't since we never tried. Just to say that your bipartisan view is a tad simplistic :) -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110503113123.gn...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On 03/05/2011 11:41, Lucas Nussbaum wrote:
It is clear from the discussion that there would be consequences. Some
would be negative, some positive. I think that we have now a pretty good
understanding of the possibilities and their consequences. The remaining
problem is to count DDs heads in the two camps:
- Let's focus on stable releases. A rolling release should not be
provided officially by Debian.
- Let's see what we can do about rolling, provided we find a way to do it
without diminishing the quality of our stable releases.
I hope my message will be clear here. But, I find your message quite
subjective. Without reading your message or knowing your opinion on the
subject, we can very easily guess that you prefer the second option.
I don't think that putting people in camps would resolve anything here.
The first option is not about making it not officially provided by Debian,
but there are people that are not convinced yet by the idea and some of
them think that sacrificing stable for the sake of a hype is not a good
idea especially with no evidence that it'll work. There are other
arguments against and your two options really can't summarize all opinions
and looks to me an easy way to diminish what has been said during all this
thread.
And, no, I don't agree when you say I think that we have now a pretty
good understanding of the possibilities and their consequences. All this
thread is about this issue particularly. We don't know yet the
consequences that rolling would have on our stable releases. But, we can't
simply adopt it without having any guarantee on its success. Because if it
turns out that users still prefer $other, then we gained nothing but some
burden within Debian and some bad consequences for Wheezy.
So, please do not use such simplistic conclusions.
Regards,
--
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,debian.org}
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbfe7a5.60...@debian.org
Re: Bits from the Release Team - Kicking off Wheezy
Le lundi 02 mai 2011 à 16:19 -0700, Russ Allbery a écrit : I realize that we're often not on the mailing lists jumping up and down and advocating for our issues, in part because Debian works great for us and not much needs to be changed, but please remember that there are a *lot* of us using Debian on servers in large-scale production environments. And stable is our world. It's EXTREMELY IMPORTANT. It is, in many cases, the reason why we were able to sell Debian in the first place; if it weren't for Debian's exceptionally good stable releases, we would probably all be running Red Hat. I fully concur. And let me add that although it concerns less people, the same holds for desktops. -- Joss -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304423155.22032.244.camel@pi0307572
Re: Bits from the Release Team - Kicking off Wheezy
Hi Carsten, A bit late on responding to your mails, but... On Mon, May 02, 2011 at 01:56:14AM +0200, Carsten Hey wrote: So if we tell users to use this repository, we're going to have some users (I upgrade my servers to testing during the freeze and I would enable it if it was generally advised for beta-testers). The libpam-mount example was not a 100% fit because it went through testing-security and not through t-p-a. The segfaulting package migrated to testing on the 28th of November 2008. Just five months earlier the Testing Security team announced[1] on d-d-a that they provide nearly full security support (the kernel was missing at this time). I'd say it's a very good fit for describing the type of problem; even if it was t-s vs t-p-u, it's the same problem in terms of testing coverage. Especially with software that's used in a wide variety of configurations and environments, even what is seen as thorough review/testing on the part of the maintainer could miss stuff like this. I doubt that generally advising to add t-p-a would significantly work out better than the testing-security announcement. I'm thinking more and more that if we did do the branch testing approach, it would need to be in tandem with changes to default installation settings, release upgrade procedures, etc, to get more people on board by default. That said, I also think your discussion/suggestions regarding unstable-p-u are really good. While it may not necessarily solve the rolling needs, it could solve the non-release standstill issue by providing something more useful than experimental. As you might or might not know, I took out DEP-10 over the weekend, to explore different ways that we could parallelize the release management, and plan to explore the details/problems/benefits of both of these ideas (branch testing / unstable-p-u). It would be awesome if I could get some feedback/help from you along these lines. sean -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110503120855.gb28...@cobija.connexer.com
Re: Bits from the Release Team - Kicking off Wheezy
On 03/05/11 at 13:31 +0200, Mehdi Dogguy wrote: On 03/05/2011 11:41, Lucas Nussbaum wrote: It is clear from the discussion that there would be consequences. Some would be negative, some positive. I think that we have now a pretty good understanding of the possibilities and their consequences. The remaining problem is to count DDs heads in the two camps: - Let's focus on stable releases. A rolling release should not be provided officially by Debian. - Let's see what we can do about rolling, provided we find a way to do it without diminishing the quality of our stable releases. I hope my message will be clear here. But, I find your message quite subjective. Without reading your message or knowing your opinion on the subject, we can very easily guess that you prefer the second option. I don't think that putting people in camps would resolve anything here. The first option is not about making it not officially provided by Debian, but there are people that are not convinced yet by the idea and some of them think that sacrificing stable for the sake of a hype is not a good idea especially with no evidence that it'll work. There are other arguments against and your two options really can't summarize all opinions and looks to me an easy way to diminish what has been said during all this thread. And, no, I don't agree when you say I think that we have now a pretty good understanding of the possibilities and their consequences. All this thread is about this issue particularly. We don't know yet the consequences that rolling would have on our stable releases. But, we can't simply adopt it without having any guarantee on its success. Because if it turns out that users still prefer $other, then we gained nothing but some burden within Debian and some bad consequences for Wheezy. What kind of guarantees are you looking for, exactly? Can you suggest ways to acquire them? L. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110503125405.gb19...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
On Tue, May 03, 2011 at 11:41:35AM +0200, Lucas Nussbaum wrote:
[...]
I've always found it strange that, as a volunteer project, we are
creating a product that is mainly used in professional
environments.
[...]
I see that as a side effect. The same qualities of stable which lead
me to rely on it on for a vast number of servers in an ISP/data
center setting also make it an ideal platform for the servers which
host and provide services to the whole of the free software
community... much the same way that the volunteers who maintain
buildds, mirrors and the bulk of Debian's infrastructure are almost
certainly also enterprise, service provider or university technology
professionals by day.
The lessons learned in those environments help demonstrate what
technologies do and don't scale. A volunteer sysadmin managing a ton
of infrastructure for a large free software project is, given the
opportunity, going to choose a platform which requires as little
maintenance as possible. This increased efficiency maximizes the
impact of his or her contribution to the community. In many cases,
this is Debian's stable release.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110503135944.gc1...@yuggoth.org
Re: Bits from the Release Team - Kicking off Wheezy
On Tue, May 03, 2011 at 01:31:24PM +0200, Pierre Habouzit wrote: On Tue, May 03, 2011 at 11:41:35AM +0200, Lucas Nussbaum wrote: It is clear from the discussion that there would be consequences. Some would be negative, some positive. I think that we have now a pretty good understanding of the possibilities and their consequences. The remaining problem is to count DDs heads in the two camps: - Let's focus on stable releases. A rolling release should not be provided officially by Debian. - Let's see what we can do about rolling, provided we find a way to do it without diminishing the quality of our stable releases. FWIW I'm in neither. My camp would be: Please do not impede our way to produce stable releases in any ways, do whatever you want with rolling. I'm sorry but I find that a lame request. If, in whatever circumstances, Debian as a project decides to care about something beyond stable releases, for instance something called rolling, it will as a matter of fact use power of the project for such new thing and thus distract that power from stable releases. Always. Saying that anyone can do anything as long as it never interferes with what we have now is exactly the definition of keeping the status-quo, i.e. preventing improvement. Granted, it also prevents breakage. I've suggested integrating aptosid (or $derivative) people inside of Debian as a way to provide rolling, I know that Joss did so on planet too e.g. That has two very important advantages: * it brings in new blood *now* (and not an hypothetical later) to actually take care of rolling (which doesn't make all my reservation moot but I reckon does lessen their scope significantly); * it brings people who know how to do that and already have infrastructure to do so. We would just give them the opportunity to benefit from the larger and robust infrastructure we have, while taking their experience. Looks like it's win-win. Have you asked *any* contributor of *any* project about why they didn't put their efforts in Debian but instead into a different project? aptosid for example claims that unstable is in fact usable by people not too technically equiped. Debian (usually) claims, it isn't. They think, it just needs a bit of fixing every now and then and there you go with a fine rolling release. If we, however we could achieve it, integrated aptosid in Debian, how would that be different to adding a rolling release suite? My actual point being, whether we contact developers of derivatives first and then add rolling (or whatever it's going to be called), or add such thing and then promote it to developers outside Debian hoping for their interest and involvement isn't at all important while we're still discussing if Debian wants to take care of something beyond stable releases. Hauke -- .''`. Jan Hauke Rahm j...@debian.org www.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On 03/05/2011 14:54, Lucas Nussbaum wrote:
What kind of guarantees are you looking for, exactly? Can you suggest
ways to acquire them?
- That it won't affect stable in bad ways.
- preventing removals from testing is a no-go.
Quite honestly, I see no reason to continue feeding this thread because
I realized (maybe quite late) that there were good arguments against
frozen and not much for it apart of hand-waving. It seems that those
who want to have rolling in Debian didn't even try to summarize what
made the success of other rolling distros, and what their users liked
there. We do need this kind of survey before even thinking about how to
do rolling in Debian… and we don't have this kind of data yet.
I don't know (yet) what other rolling distros Debian based offer to its
users that we don't. I don't know what made aptosid so popular. I don't
know what made Mint Debian popular? (and there are others). Did you even
try to gather those informations before even mentioning rolling for
Debian? How can we discuss about rolling in Debian if we don't have
that kind of data? You are always mentioning potential users, but those
potential users might be today-users of aptosid or Mint Debian. So, we
should start from there, instead of just saying No, but you'll see,
rolling will be cool, it will make maintainers care about their
pacakges, it won't affect stable because bla bla bla…
So, I'll start document myself on this and I'll be back when I know enough
about this story. Sadly, I don't have much time to do this these days and
it might take some time. I'd be glad if others start to gather such
informations and put them somewhere so that we don't understand why is it
so important, and why users don't just use testing today.
I can't find the answers here and it seems that you're not able to give
them, because otherwise you would have used them already to say why
rolling will bring users, or what do rolling users like?
(The survey we need should rolling-topic specific, not about Debian in
general).
Regards,
--
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,debian.org}
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dc01f93.2010...@debian.org
Re: Bits from the Release Team - Kicking off Wheezy
Lucas Nussbaum lu...@lucas-nussbaum.net writes: On 02/05/11 at 16:19 -0700, Russ Allbery wrote: I'm very dubious. To take one example, if Debian stopped making stable releases, it would no longer be usable at work, which would mean that my ability to work in Debian would substantially decrease and quite possibly go away completely. Except for the sake of argumentation, I don't think that anybody considers seriously that Debian would stop making stable releases. The question is whether we want to provide a rolling release in addition to our stable releases. Yeah, sorry, I knew that's what you meant and should have said so explicitly. I'm totally fine with a rolling release if we can figure out how to add it to the project without hurting stable. I'm only speaking up to make clear that yes, there really are people who are passionate about (and passionately happy about) stable. It sometimes feels in some of the rolling testing discussions like DDs can start feeling like stable isn't a useful product, since a lot of the input is from people for whom stable isn't ideal (since people with problems talk more than people without problems). But it definitely is. I realize that we're often not on the mailing lists jumping up and down and advocating for our issues, in part because Debian works great for us and not much needs to be changed, but please remember that there are a *lot* of us using Debian on servers in large-scale production environments. And stable is our world. It's EXTREMELY IMPORTANT. It is, in many cases, the reason why we were able to sell Debian in the first place; if it weren't for Debian's exceptionally good stable releases, we would probably all be running Red Hat. I assume that when you write 'us' or 'we' here, you mean 'Debian users in large-scale production environments'. Yes, indeed. Again, I'm not diminishing the importance of stable releases. But I've always found it strange that, as a volunteer project, we are creating a product that is mainly used in professional environments. I guess I don't find that to be any sort of conflict. Many of us aren't only volunteering as individual contributors to create things that we want to run on our desktops. We're also volunteering as system administrators, developers, or similar sorts of IT roles to create things that we want to run at work. And I think in many cases (such as mine), our employers are actually volunteering substantial amounts of our paid time to work on Debian as well. It's still a volunteer project. One of the volunteers happens to be Stanford University, donating staff time. :) It is clear from the discussion that there would be consequences. Some would be negative, some positive. I think that we have now a pretty good understanding of the possibilities and their consequences. The remaining problem is to count DDs heads in the two camps: - Let's focus on stable releases. A rolling release should not be provided officially by Debian. - Let's see what we can do about rolling, provided we find a way to do it without diminishing the quality of our stable releases. Well, I don't think anyone really objects to the second category and we'd all consider ourselves to be in that category if it works. Most of the discussion, from where I sit, is over whether or not it's possible to do that. If we can have both, that's clearly the best possible outcome. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hb9bkb2r@windlord.stanford.edu
Re: Bits from the Release Team - Kicking off Wheezy
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110503 11:47]: On 02/05/11 at 16:19 -0700, Russ Allbery wrote: Lucas Nussbaum lu...@lucas-nussbaum.net writes: [ Note that my position is based on the assumption that we have a share of DDs interested in rolling similar to the share of DDs interested in stable releases. Unfortunately, it's very difficult to know where we stand regarding this. ] I'm very dubious. To take one example, if Debian stopped making stable releases, it would no longer be usable at work, which would mean that my ability to work in Debian would substantially decrease and quite possibly go away completely. Except for the sake of argumentation, I don't think that anybody considers seriously that Debian would stop making stable releases. The question is whether we want to provide a rolling release in addition to our stable releases. 20110501133957.ga13...@rivendell.home.ouaza.com sounds to me like we will loose quite some man-power for making stable releases. This could equally well mean we can't do some. If it is guranteed that stable release don't become harder / uglier, I don't think anybody has any reservations to adding new suites. However, as long as the general impression is making stable releases will get way harder, that's different. Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110503192328.gq15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
On Mon, May 02, 2011 at 01:56:14AM +0200, Carsten Hey wrote: * Pierre Habouzit [2011-05-01 23:17 +0200]: The problem is, you need to entry points, one for testing as we know it, one for rolling. Actually, we need two entry points each, a default one and an exceptional one. The latter ideally requires a special permission from a release team before an upload. For testing these are unstable and testing-proposed-updates. Urgh. Sounds a lot. If you use t-p-u for testing and unstable for rolling, or unstable for testing and rolling-updates for rolling is just bikeshedding. The result is some of the users will use unstable and help testing, the other sort will run rolling-updates or rolling. So basically you split our users in two non overlapping sets, meaning that you divide coverage and tests. The result of this bikeshedding has an influence on how big these sets are. I agree, the original sizes, I expect them to converge more or less to the same end result, which is what is important on the long term. And clearly, we have to make rolling create its feeding routes, not steal testing ones, that's kind of obvious to me :) I'm interested about *why* they want it, not the mere fact that they do. Because when you know why they want it, maybe there will be better answers that don't make releasing even more brittle and burn even more people out. I guess it's mainly about new upstream versions (firefox, chromium, gnome and so on) they read in the news about, saw on other computers or really contain features useful for the users. Moving backports.org to backports.debian.org and enabling automatic upgrades by default are steps in the right direction to address this (except for desktop environments). Supporting or even recommending to use all packages from b.d.o to make it feel like a rolling release would be nearly the opposite of how it is intended to be used now and I don't think it would make those users really more happy. So all in all, the scheme used to manage b.d.o seems to lack improvement potential from a users point of view :) An other way to use newer upstream versions is via chroots. With faster internet connections, larger hard disks, faster CPUs and a smaller size of a minimal Debian chroot, using a chroot to run a single application could become more worthwhile. With a frontend to configure such things, it could be used be end users in future. Yes, I'd very much like to see this kind of routes explored before we rework all the suites in Debian… -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502060855.ga22...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Mon, May 02, 2011 at 12:10:42AM +0200, Lucas Nussbaum wrote: On 01/05/11 at 23:46 +0200, Pierre Habouzit wrote: Benefits for Debian: - attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (developers, free software contributors), thus interesting to work with. Some of them could become Debian contributors. And even if they don't, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian's -- some areas of Debian could use more testers]. I think those can use unstable, But unstable is a development branch not targeted at being used by 'standard' users. Well, assuming it's the case, what is missing in order to be usable by mere users? Also note that testing as is has not enough security support, and read Carsten very good example of the PAM issues. How would CUT or rolling address those? I've used testing in the past, in the sarge era. I had to constantly install packages from unstable for it to work, and the result was a nightmare of apt-get installability. I've not used testing since, so /maybe/ it's better nowadays, I'd very much like to have some feedback from real and recent testing users if there are any, but if I trust my past experience, the gap to make testing usable is significant. So maybe making unstable usable isn't *that* much more significant, and is definitely more compatible with our current workflow. and if they use rolling, I think I already proved or at least explained why those don't contribute to the stable in being, but rather the N+1 one. I think that you are mixing two things here: 1) whether we want to turn testing into a rolling release 2) what do do with the 'rolling' suite during freeze (fork a 'frozen' branch at the beginning of the freeze ? freeze rolling ? start by freezing rolling, then after a few months, fork 'frozen' and unfreeze 'rolling'?) I don't mix things. (1) is: no we don't want to turn testing into rolling because you need to freeze to release. If rolling appears it must be a second suite. So yes (2) is a question. But frankly, if the answer of (2) is we don't do rolling during freezes I don't understand the point of the whole discussion, so I assumed that the answer was yes we do rolling all the time. Actually, the more I read, I think that: - nobody knows why we want rolling or CUT (though I've read cut.d.net since, and to me it looks like a glorified snapshot of testing + d-i + cd images + all that makes a stable, which basically is just fine by me); - nobody knows what rolling *exactly* is, what the plan is. We know the hype and that Debian would very much like to support it, but what's the formal definition, what does it encompass, what does it mean, what's the recommended implementation? - give back to the free software world by providing a platform where new upstream releases would quickly be available to users. Since users would be able to test new upstream releases earlier, they would be able to provide feedback to upstream devs earlier, contributing to a shorter feedback loop. Why doesn't unstable fit that? Because unstable is a development branch not targeted at being used by 'standard' users. Testing is a release tool not targeted at being used at all. So to me testing and unstable are both more or less at the same point, with unstable having the clear advantaged to be targeted at _some_ users. Why is that so much easier to make testing usable with respect to making unstable audience broader? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502061917.gb22...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On 05/02/2011 12:10 AM, Lucas Nussbaum wrote: On 01/05/11 at 23:46 +0200, Pierre Habouzit wrote: Benefits for Debian: - attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (developers, free software contributors), thus interesting to work with. Some of them could become Debian contributors. And even if they don't, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian's -- some areas of Debian could use more testers]. I think those can use unstable, But unstable is a development branch not targeted at being used by 'standard' users. I can also say exactly the same about testing ;) I don't think we can go too far with this argument. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dbe55f1.9070...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
Hai! Pierre Habouzit madco...@madism.org writes: On Sat, Apr 30, 2011 at 12:28:06PM +0200, Stefano Zacchiroli wrote: Size is just one ingredient. There are plenty of other ways to diminish barrier to deploy big changes in Debian: wider commit access rights, larger VCS repositories, more liberal NMUs, etc. (Unsurprisingly, several Debian derivatives have decide to pursue those other ways and one might argue that they have done so learning from Debian experience.) [...] Oh yes, you really want to attract new contributors ? build debhub.com (as in github) and force everyone to package stuff in there. Ehm, forcing people to use a certain VCS is usually a good way to _lose_ contributors... - PPA should focus on: * co-installability when endurable; * documented and working rollback to unstable (IOW downgrading a package to unstable when co-installability is not possible should work well enough, idealy using pinning and apt, but a documented procedure is good enough too). Wait, that's a completely orthogonal problem. Rollbacks of package upgrades is unsupported generally, trying to solve this at the same time as the PPA issue is a bad idea. There's no reason to connect these things. Marc pgpbX0AFHhhF9.pgp Description: PGP signature
Re: Bits from the Release Team - Kicking off Wheezy
Heya, Raphael Hertzog hert...@debian.org writes: I understand members of the release team feel particularly responsible to do various release-critical tasks that should have been done by the maintainers but haven't (for various reasons). And I guess that's the reason of your remark. But that's not scalable ultimately. So I think it's a good move to say we support testing and we expect every maintainer to take care of their packages there (as opposed to the current situation where too much of that work is left in the hands of the release team). Saying that will not make people do it. We have also said that we will fix bugs in a frozen testing distribution, but that doesn't mean that everyone does it. Raphael, just announcing that something should be done doesn't get stuff done. Marc pgpz8I8A4urVI.pgp Description: PGP signature
Re: Bits from the Release Team - Kicking off Wheezy
On Mon, May 02, 2011 at 09:13:31AM +0200, Marc 'HE' Brockschmidt wrote: Hai! Pierre Habouzit madco...@madism.org writes: On Sat, Apr 30, 2011 at 12:28:06PM +0200, Stefano Zacchiroli wrote: Size is just one ingredient. There are plenty of other ways to diminish barrier to deploy big changes in Debian: wider commit access rights, larger VCS repositories, more liberal NMUs, etc. (Unsurprisingly, several Debian derivatives have decide to pursue those other ways and one might argue that they have done so learning from Debian experience.) [...] Oh yes, you really want to attract new contributors ? build debhub.com (as in github) and force everyone to package stuff in there. Ehm, forcing people to use a certain VCS is usually a good way to _lose_ contributors... I'm not forcing the use of the VCS, more like some infrastructure to host packages if you want, during the development, so that it's easier to track, and not in its source-only form as what matters to users is actually the binary form. Which is missing nowadays. And I disagree, we may lose a few, but it can improve efficiency making it a stable operation, and I think having more standardized ways to look at packages and contribute to the packaging will lower the entry to help. But to be fair, this was an idea I developped in a bout 2 hours of time, it's bound to have deficiencies :) -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502071650.ga23...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On 02/05/11 at 08:19 +0200, Pierre Habouzit wrote: On Mon, May 02, 2011 at 12:10:42AM +0200, Lucas Nussbaum wrote: On 01/05/11 at 23:46 +0200, Pierre Habouzit wrote: Benefits for Debian: - attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (developers, free software contributors), thus interesting to work with. Some of them could become Debian contributors. And even if they don't, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian's -- some areas of Debian could use more testers]. I think those can use unstable, But unstable is a development branch not targeted at being used by 'standard' users. Well, assuming it's the case, what is missing in order to be usable by mere users? IMHO, what is missing for unstable to be usable for mere users is what the unstable-testing migrations provides: a maturation period that allows severe bugs to be catched before they hit most users. Also note that testing as is has not enough security support, and read Carsten very good example of the PAM issues. How would CUT or rolling address those? The PAM issue outlines how splitting the users and developers between two branches (unstable and testing post-freeze in the PAM case) causes problems. However, we can make rolling without splitting the users and developers between two branches during the whole freeze. 'rolling' is a statement by the project that we consider 'testing' (renamed to 'rolling') to be usable by 'mere' users who want more up-to-date software than what they find in our stable releases, or in our derivatives. 'rolling' would be very similar to what we have in 'testing'. Yes, users can already use testing or unstable, but then they have the reasonable feeling that they are using a development branch and not something that the project considers a 'product'. Yes, it's mostly PR bullshit, and I don't expect it to significantly change Debian development processes. However, communication is necessary if we want to attract new users. What might change is more attention from developers to what happens in testing/rolling, which is probably a good thing since a better testing/rolling makes it easier to create stable releases from it. Then, there's the discussion of what to do during freezes. There are several options: [A] we could decide not to do anything special: just freeze rolling for ~6 months, as we used to freeze testing. That might bore people who like the constant flux of new upstream releases, but if we decide that it's the only way to ensure high-quality stable releases, so be it. [B] we could decide to fork a 'frozen' branch when we freeze, and continue to manage rolling using migrations from unstable. This clearly makes it harder to create stable releases, since it splits the users and developers base between two branches (less users = less bug reports ; less developers = less bug fixing). It doesn't sound reasonable to fork a 'frozen' branch, and then try to release it for 6 months. [C] we could compromise. We could freeze rolling for 3 months, so that most of the stabilization work occurs with a single active branch, and then, for the final release preparation, fork 'frozen' off 'rolling', and unfreeze 'rolling'. I've used testing in the past, in the sarge era. I had to constantly install packages from unstable for it to work, and the result was a nightmare of apt-get installability. I've not used testing since, so /maybe/ it's better nowadays, I'd very much like to have some feedback from real and recent testing users if there are any, but if I trust my past experience, the gap to make testing usable is significant. So maybe making unstable usable isn't *that* much more significant, and is definitely more compatible with our current workflow. I'm using testing, and don't share your views. But YMMV. It's also possible that the introduction of 'rolling' will result in slight changes to the way we manage testing. For example, the 2/5/10 delays for testing migrations are mostly arbitrary. It could make sense to refine them on a case-by-case basis. The goal of those changes would be to increase the usability of testing. I don't see any wrong with that. and if they use rolling, I think I already proved or at least explained why those don't contribute to the stable in being, but rather the N+1 one. I think that you are mixing two things here: 1) whether we want to turn testing into a rolling release 2) what do do with the 'rolling' suite during freeze (fork a 'frozen' branch at the beginning of the freeze ? freeze rolling ? start by freezing rolling, then after a few months, fork 'frozen' and unfreeze 'rolling'?) I
Re: Bits from the Release Team - Kicking off Wheezy
* Pierre Habouzit madco...@madism.org [110501 22:09]: Who are they? Unlike this constant handwaving, I've shared my experience (on #-devel), I'll repeat it here: at work we've like 10 Debian users, some with stable, the other with unstable. Why? Because we're developpers and if our software targets old stuff (RH5, it's as old as lenny), the latest gcc, valgrind, … are priceless tools, and we want them. Also think about people that actually want to computer to work and people administrating their computers. You do not hear much from those users as Debian in its current shape in near to perfect for them. It releases often enough that one has new software, not so often that one can manage upgrades in the time (and users can adapt to changes, anything changed is usually a big hassle for users). There is one repository with all the packages, no hunting for sources, no evaluation which of those sources have use usefull packages and which are crap, and everything fits well together. And in the rare event something newer is needed and one cannot wait one can get something from backports and it still reasonably well fits together. I run unstable on my laptop and workstation for years, with almost daily dist-upgrades. Except for grub2 (and I've been stupid, I removed grub, I should have known better) I've had no serious issues for 5 years, Agreed. Unstable is usually quite stable. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502072557.ga18...@pcpool00.mathematik.uni-freiburg.de
Re: Bits from the Release Team - Kicking off Wheezy
On Mon, May 02, 2011 at 09:20:29AM +0200, Lucas Nussbaum wrote: Yes, it's mostly PR bullshit, and I don't expect it to significantly change Debian development processes. However, communication is necessary if we want to attract new users. What might change is more attention from developers to what happens in testing/rolling, which is probably a good thing since a better testing/rolling makes it easier to create stable releases from it. Is that it, really? What's the point of the rename, forcing all the testing users to sed their sources.list? Wow. Useful. [C] we could compromise. We could freeze rolling for 3 months, so that most of the stabilization work occurs with a single active branch, and then, for the final release preparation, fork 'frozen' off 'rolling', and unfreeze 'rolling'. That's horrible to do because the end of the freeze is *exactly* when people get demotivated, and that the last rush is mostly done by very few people. Doing that will make them feel even more alone, which is a great way to burn them out even faster. I really don't like it. I'd rather see ways on how to make the freeze shorter been explored instead. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502073027.gb23...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On 02/05/11 at 09:30 +0200, Pierre Habouzit wrote: On Mon, May 02, 2011 at 09:20:29AM +0200, Lucas Nussbaum wrote: Yes, it's mostly PR bullshit, and I don't expect it to significantly change Debian development processes. However, communication is necessary if we want to attract new users. What might change is more attention from developers to what happens in testing/rolling, which is probably a good thing since a better testing/rolling makes it easier to create stable releases from it. Is that it, really? What's the point of the rename, forcing all the testing users to sed their sources.list? Wow. Useful. I'm sorry if you don't understand the interest of communication. And of course, we would keep a testing-rolling symlink to avoid breaking the world... [C] we could compromise. We could freeze rolling for 3 months, so that most of the stabilization work occurs with a single active branch, and then, for the final release preparation, fork 'frozen' off 'rolling', and unfreeze 'rolling'. That's horrible to do because the end of the freeze is *exactly* when people get demotivated, and that the last rush is mostly done by very few people. Isn't it partially done by very few people because the work doesn't scale to many developers? Anyway, the message that should be sent during the end of the freeze is: The good thing to do is to help with the release. If you tried that, and really cannot help anymore, then of course you are free to work on other things, including rolling. Doing that will make them feel even more alone, which is a great way to burn them out even faster. I really don't like it. I'd rather see ways on how to make the freeze shorter been explored instead. Why would it be mutually exclusive? We could explore ways to make the freeze shorter, and at the same time do rolling. L. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502074811.ga14...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
Hi, On Sun May 01, 2011 at 21:53:58 +0200, Lucas Nussbaum wrote: On 01/05/11 at 20:51 +0200, Martin Zobel-Helas wrote: Hi, On Sun May 01, 2011 at 20:02:51 +0200, Lucas Nussbaum wrote: 2. determine who is in support of each action plan, through a GR or a poll. I don't think we need a GR for that. Those who are interested in rolling releases could show that they are interested and just doing so (like Norbert/formorer/Rhona/... did with backports, like Joey Hess did with testing-security, like Andi and me did with volatile, ...). I am aware this might need changes in some of Debian's infrastructure, but i am quite sure if you provide help/patches/... those will be implemented. I don't see how that could work. Iet's assume that the goal is to demonstrate the interest in the rename testing to rolling scenario, without even talking about what to do during freezes. The first steps of the implementation will include: - rename testing to rolling. I don't see how ftpmasters would do it without a consensus that this is something wanted by the project. - communicate officially, to the general public, that rolling is not only a development branch, but also suited for use by the general public (given known limitations). I don't see how the press team would publish something like that without a consensus that it's what the project thinks. What was applicable for backports, testing-security or volatile is not applicable here, because the implications for the project are deeper. It's not about adding a suite with some different packages in the margin. It's about shifting developers' focus and user attention a bit. No, it just needs that rolling is running on a different dak instance as testing. The same we had for volatile, the same we had for backports. The team (whoever that is) wo is interested in the rolling releases can show it is worth the effort, then we can start thinking integrating it back into the main archive. Cheers, Martin -- Martin Zobel-Helas zo...@debian.org | Debian System Administrator Debian GNU/Linux Developer | Debian Listmaster GPG key http://go.debian.net/B11B627B | GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502083130.gd13...@ftbfs.de
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, 1 May 2011, Stefano Zacchiroli wrote: weren't there. But as a matter of fact, chances are that those people wouldn't have been able to be Debian Developers today if it weren't for the GR. As I was the very first to apply under the GR (not in the first batch of accepts though) I just wanted to underline the truth in this. I wouldn't have been on the line for applying for DD for years to come. I most probably would have stayed with the project anyhow but the membership couples me tighter to Debian now. I am more interested in doing things for Debian now than before, and given that I have been running mirrors for both FTP and debconf video streams since 2004 and been a active contributor for the translations since 2007 (let's not even count the time spent on advocacy for the project), the GR was a warm fuzzy feeling of out reach and I like it. -- brother http://sis.bthstudent.se -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dbe70d6.3070...@bsnet.se
Re: Bits from the Release Team - Kicking off Wheezy
On 02/05/11 at 10:31 +0200, Martin Zobel-Helas wrote: Hi, On Sun May 01, 2011 at 21:53:58 +0200, Lucas Nussbaum wrote: On 01/05/11 at 20:51 +0200, Martin Zobel-Helas wrote: Hi, On Sun May 01, 2011 at 20:02:51 +0200, Lucas Nussbaum wrote: 2. determine who is in support of each action plan, through a GR or a poll. I don't think we need a GR for that. Those who are interested in rolling releases could show that they are interested and just doing so (like Norbert/formorer/Rhona/... did with backports, like Joey Hess did with testing-security, like Andi and me did with volatile, ...). I am aware this might need changes in some of Debian's infrastructure, but i am quite sure if you provide help/patches/... those will be implemented. I don't see how that could work. Iet's assume that the goal is to demonstrate the interest in the rename testing to rolling scenario, without even talking about what to do during freezes. The first steps of the implementation will include: - rename testing to rolling. I don't see how ftpmasters would do it without a consensus that this is something wanted by the project. - communicate officially, to the general public, that rolling is not only a development branch, but also suited for use by the general public (given known limitations). I don't see how the press team would publish something like that without a consensus that it's what the project thinks. What was applicable for backports, testing-security or volatile is not applicable here, because the implications for the project are deeper. It's not about adding a suite with some different packages in the margin. It's about shifting developers' focus and user attention a bit. No, it just needs that rolling is running on a different dak instance as testing. The same we had for volatile, the same we had for backports. The team (whoever that is) wo is interested in the rolling releases can show it is worth the effort, then we can start thinking integrating it back into the main archive. What's the point? Outside of freezes, rolling == testing. What's the point of running a separate dak instance? It would be about as efficient to collect statements of users saying if rolling existed, I would use it. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502100932.ga17...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
* Pierre Habouzit [2011-05-02 08:08 +0200]: On Mon, May 02, 2011 at 01:56:14AM +0200, Carsten Hey wrote: * Pierre Habouzit [2011-05-01 23:17 +0200]: The problem is, you need to entry points, one for testing as we know it, one for rolling. Actually, we need two entry points each, a default one and an exceptional one. The latter ideally requires a special permission from a release team before an upload. For testing these are unstable and testing-proposed-updates. Urgh. Sounds a lot. 1st phase: - add unstable-proposed-updates 2nd phase: - create symlink rolling, pointing to testing - create symlink rolling-proposed-updates, pointing to testing-proposed updates 3rd phase: - freeze testing - make rolling and rolling-proposed-updates real suites If rolling is supposed to be a subset of testing, making rolling and rolling-proposed-updates real suites would need to happen earlier. This completely ignores what seems to be the original motivation for CUT. Maybe there is a different solution to provide what d-i alpha and beta releases need or reduce what they need. If you use t-p-u for testing and unstable for rolling, or unstable for testing and rolling-updates for rolling is just bikeshedding. The result is some of the users will use unstable and help testing, the other sort will run rolling-updates or rolling. So basically you split our users in two non overlapping sets, meaning that you divide coverage and tests. The result of this bikeshedding has an influence on how big these sets are. I agree, the original sizes, I expect them to converge more or less to the same end result, which is what is important on the long term. Many people just choose what's default. d-i installing testing instead of rolling by default would raise the number of the testing set. Requiring users of unstable + -updates to add -updates manually to the sources.list would in my opinion decrease this set of people. I'm interested about *why* they want it, not the mere fact that they do. Because when you know why they want it, maybe there will be better answers that don't make releasing even more brittle and burn even more people out. I guess it's mainly about new upstream versions (firefox, chromium, gnome and so on) they read in the news about, saw on other computers or really contain features useful for the users. Moving backports.org to backports.debian.org and enabling automatic upgrades by default are steps in the right direction to address this (except for desktop environments). backports.debian.org does not fit here, it makes stable more attractive for users that would otherwise run testing. Making testing more attractive for users that would otherwise run rolling could be done with semi-official PPAs. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502130302.gr5...@furrball.stateful.de
Re: Bits from the Release Team - Kicking off Wheezy
* Lucas Nussbaum [2011-05-02 09:20 +0200]: On 02/05/11 at 08:19 +0200, Pierre Habouzit wrote: Also note that testing as is has not enough security support, and read Carsten very good example of the PAM issues. How would CUT or rolling address those? The PAM issue outlines how splitting the users and developers between two branches (unstable and testing post-freeze in the PAM case) causes problems. In my opinion it outlines how migration through barely used suites (e.g., *-updates) significantly raises the number of buggy packages entering a frozen testing. The need to use those suites is mostly caused by uploading new upstream versions to unstable even though they will never reach the suite that currently is testing. [C] we could compromise. We could freeze rolling for 3 months, so that most of the stabilization work occurs with a single active branch, and then, for the final release preparation, fork 'frozen' off 'rolling', and unfreeze 'rolling'. The mentioned PAM issue happened four months after freeze. Decreasing the chances to catch critical bugs before they enter a frozen testing does not seem to be the best idea, especially if it is done shortly before we plan to release. It would be great if we would find a clever way to be able to release three months after freeze. If we don't find a way to do so, we could: * Add a non-selfcontained suite to upload non-experimental packages not targeted at testing to. This would lower the number of packages needing to go through testing-proposed-updates during freeze and could also serve as entry point for rolling. * Set up a dak instance for rolling and rolling-proposed-updates on rolling.debian.net, announce it and see if it works. * If it works, make rolling official. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502135115.ga22...@furrball.stateful.de
Re: Bits from the Release Team - Kicking off Wheezy
George Danchev wrote: On Friday 29 April 2011 11:46:30 Lucas Nussbaum wrote: - rename 'testing' to 'rolling' to make it clear that it's usable as a rolling release It is also possible that a 'rename' brings no more value, but a confusion to the users for unpredictable amount of time. 100% agreed. -- .''`. Hate's no fun if you keep it to yourself : :' : -- The life of David Gale `. `' `-Proudly running Debian GNU/Linux -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502151341.GF3099@aenima
Re: Bits from the Release Team - Kicking off Wheezy
Holger Levsen wrote: Do you think a piuparts / policy workshop (or something) is useful at DebConf11? Please! There's never too much chocolate, cheese or QA in Debconf :) -- .''`. Hate's no fun if you keep it to yourself : :' : -- The life of David Gale `. `' `-Proudly running Debian GNU/Linux -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502152458.GG3099@aenima
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 11:00:58PM +0200, Pierre Habouzit wrote:
First of all I think you should concede that the exercise you're asking
us to do cannot be done as easily as you did yours.
I don't concede that. I've read your mail, and to sum up you say:
(Note that the concede was on a side aspect, not on the fact that I
was able---which clearly I was not---to convince you of my arguments.)
So the next question is why your mail doesn't answer that. I still
think that rolling is a bad idea, until you've proven me that it's the
sole way to address a real life issue/need/itch.
Yes, you're right and I've no answer for that, because the way I've
interacted with people was in some aggregate form, which didn't permit
me to investigate more than that. So, sorry, I give up on answering
this. But that doesn't stop me from seeing as perfectly reasonable the
use cases already mentioned several times in this thread
(e.g. 20110501200120.ga18...@gnu.kitenet.net for a short version).
It's very clear to me that they are not enough to convince you and
others, but they are convincing for me.
We should probably stop here and agree to disagree. Ultimately, we'll
be able to know who is right only if someone builds the thing and see
how many users actually use it.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 10:43:18PM +0200, Carsten Hey wrote:
Testing also has just little protection against severe breakage if it is
frozen and updates need to go through rarely used suites. An example
illustrates this quite well:
Thanks for this example Carsten. However, one example is not enough
evidence to say that testing provide little protection. We can always
find bad examples of this kind, for any suite. I'm pretty sure we can
find horror stories even for stable, but from that we cannot conclude
that the protection you get against horror stories in stable is lower
than the one you would get in testing or unstable.
A 'frozen' requiring most updates to go through *-proposed-updates would
make this quarantine period a lot less useful, and it would make
circumstances like the one described above a lot more probable.
I do agree with this: any parallel path comes with its own risks of
reducing package testing. Once more, for me this discussion is really
about two orthogonal aspects: the goal of having a user-targeted testing
(on which we might agree or disagree) and the specific way we choose to
achieve it (which might have issues as the one embodied by your
example).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Mon, May 02, 2011 at 05:36:34PM +0200, Stefano Zacchiroli wrote: On Sun, May 01, 2011 at 11:00:58PM +0200, Pierre Habouzit wrote: First of all I think you should concede that the exercise you're asking us to do cannot be done as easily as you did yours. I don't concede that. I've read your mail, and to sum up you say: (Note that the concede was on a side aspect, not on the fact that I was able---which clearly I was not---to convince you of my arguments.) So the next question is why your mail doesn't answer that. I still think that rolling is a bad idea, until you've proven me that it's the sole way to address a real life issue/need/itch. Yes, you're right and I've no answer for that, because the way I've interacted with people was in some aggregate form, which didn't permit me to investigate more than that. So, sorry, I give up on answering this. But that doesn't stop me from seeing as perfectly reasonable the use cases already mentioned several times in this thread (e.g. 20110501200120.ga18...@gnu.kitenet.net for a short version). It's very clear to me that they are not enough to convince you and others, but they are convincing for me. Well I don't want to be convinced or not convinced, you misunderstood why I'm asking that. I'm asking because I want to evaluate if rolling is the sole answer we can bring to these people. They say they want testing to be usable, but maybe what they want is something that we can achieve without touching testing at all. So I'd like to understand. There is absolutely no will on my end to be convinced or not convinced, this was a genuine question for pure technical considerations. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502164258.gg23...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Mon, May 02, 2011 at 06:42:58PM +0200, Pierre Habouzit wrote:
Well I don't want to be convinced or not convinced, you misunderstood
why I'm asking that. I'm asking because I want to evaluate if rolling is
the sole answer we can bring to these people.
Oh no, not at all, I apologize if that wasn't clear. I did understand
very well why you were asking that, and I would love to have an
answer---coming from those (potential) users---to give you, but
unfortunately I don't have it.
I'll take care in the future of asking individuals which will bring up
with me the topic of CUT/rolling (no matter how non-representative that
could be) and will let you know. In the meantime I've highlighted an
approximate way to ask them (the survey, which is unfortunately limited
by the non-scalability of surveys with open-ended answers), that's the
best I could do for now.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
* Joey Hess (jo...@debian.org) [110501 22:36]: The problem with the moving target is that it means that d-i betas begin to be broken as time goes on after their release, starting with the smallest boot images and moving up to the netinst images. We could e.g. create an copy of testing at the time, so that the betas will work for 3 weeks or so. Perhaps we should take an hour or so during debconf and see where we arrive? Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502172421.gn15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
* Marc 'HE' Brockschmidt (h...@ftwca.de) [110502 09:12]: Pierre Habouzit madco...@madism.org writes: - PPA should focus on: * co-installability when endurable; * documented and working rollback to unstable (IOW downgrading a package to unstable when co-installability is not possible should work well enough, idealy using pinning and apt, but a documented procedure is good enough too). Wait, that's a completely orthogonal problem. Rollbacks of package upgrades is unsupported generally, trying to solve this at the same time as the PPA issue is a bad idea. There's no reason to connect these things. One could say from packages in ppa it is expected that they have appropriate prerm-scripts to make that work. Doesn't mean it will always do, but sounds good to me. Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502172729.go15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
Andreas Barth wrote: We could e.g. create an copy of testing at the time, so that the betas will work for 3 weeks or so. Perhaps we should take an hour or so during debconf and see where we arrive? There is a spec for doing so, which aj mostly developed, at http://cut.debian.net/snapshots/implementation_plan/ -- see shy jo signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
Lucas Nussbaum lu...@lucas-nussbaum.net writes: [ Note that my position is based on the assumption that we have a share of DDs interested in rolling similar to the share of DDs interested in stable releases. Unfortunately, it's very difficult to know where we stand regarding this. ] I'm very dubious. To take one example, if Debian stopped making stable releases, it would no longer be usable at work, which would mean that my ability to work in Debian would substantially decrease and quite possibly go away completely. I realize that we're often not on the mailing lists jumping up and down and advocating for our issues, in part because Debian works great for us and not much needs to be changed, but please remember that there are a *lot* of us using Debian on servers in large-scale production environments. And stable is our world. It's EXTREMELY IMPORTANT. It is, in many cases, the reason why we were able to sell Debian in the first place; if it weren't for Debian's exceptionally good stable releases, we would probably all be running Red Hat. I went on about this at some length at the last DebConf as part of the enterprise track. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tydczo4v@windlord.stanford.edu
Re: Bits from the Release Team - Kicking off Wheezy
On 04/30/2011 04:32 PM, Pierre Habouzit wrote: FWIW I think that rolling or CUT miss the point entirely. As a Debian user I use stable on my servers (with a few backports for the 3-4 things I need bleeding edge for). For my desktop I use unstable, and when that breaks (which is *very* rare, really) I go to snapshots and go back a few versions. I couldn't care about testing any less. And at work, every person I know either uses just stable or does the same as me. I know no testing user around me. Of course I'm not pretending I know the absolute Truth, but well, I find this whole users want testing badly thing dubious. I do know people who run testing. Actually I can see two kinds of users who run testing. -people who want to keep getting software updates, but do not want to run unstable [1]. They would point to testing in their apt sources.list. These are the users who want rolling -people who would decided to run the next stable release, before it is actually released, they would point their sources.list to wheezy (as of now). there are the users who will go though rolling, then frozen, then stable [1] I run unstable in my laptop, and it is stable enough for me, but for a regular user I can see how these 10 days between unstable and testing can help her to avoid getting in contact with major bugs/issues. Even though I do not have numbers, I can see both use cases for rolling and frozen. Ok, frozen might get less users than testing during freeze, but handling both these 2 use cases could actually attract more users. Form what I could understand, the main purpose of rolling is to avoid the discontinuity in updates flow that happens in unstable (and of course in testing), when testing is under freeze. Which is annoying for users who do not care about stable. Such users (first type above) will have to go and pick updates from experimental during freeze (with all the problems Pierre mentioned about experimental). Similar reasoning applies to developers: those who care about having the latest version in unstable, will switch to uploading to experimental rather than unstable. So I am not sure that arguments like having testing frozen and avoiding major updates in unstable help DD and users focus on preparing the next stable actually apply... - get rid of experimental that would mostly become useless as PPA would clearly be a superset of the features. I completely agree on this, sounds like a really good idea. My 2 cents, Cheers, Ludovico -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dbcfca9.8050...@debian.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 01:32:19AM +0200, Pierre Habouzit wrote: FWIW I think that rolling or CUT miss the point entirely. As a Debian user I use stable on my servers (with a few backports for the 3-4 things I need bleeding edge for). For my desktop I use unstable, and when that breaks (which is *very* rare, really) I go to snapshots and go back a few versions. I couldn't care about testing any less. And at work, every person I know either uses just stable or does the same as me. I know no testing user around me. Of course I'm not pretending I know the absolute Truth, but well, I find this whole users want testing badly thing dubious. The real problem is not users want testing badly, but Debian wants people to use testing badly. Because what Debian releases is testing. If nobody uses it, we don't know until it becomes stable that it's broken in some subtle ways because it's not exactly what everyone else using unstable is using. So while I do agree with the rest of your message, I do see a need to make testing more attractive so that we have a solid user base actually testing what we are going to release, and stop saying to people that they shouldn't be using testing (and I've seen that said *a lot*). Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501063855.gb18...@glandium.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sat, 30 Apr 2011, Russ Allbery wrote: Pierre Habouzit madco...@madism.org writes: No what we want is probably to be attractive to developers, while keeping our standards about the stable release, which is what really matters. And to do that, well, what we need is to make working for Debian easier. Not harder. rolling is making working for Debian harder, hence is a bad proposal. Harder because it means people will have more work for a package. Maintainers are (me included) often too lazy to prepare Stable updates because it's a PITA to have to work on a 1-yo version of the package. Why would they be more motivated to work on testing packages? No we should focus instead on making packaging easier, not adding new constraints, new goals. Here are a few thoughts on how to do that. [...] I don't think I'm convinced that rolling would make anything harder, and I don't want to support that part of Pierre's message, but I did want to say that the description laid out in this message about how PPAs could work and on using a unified VCS for that purpose sounds *awesome*, and I would love to use something like that. +1 I'm in favor of what Pierre has described[1] and it's certainly something that I would like to see happen. But it's absolutely not in opposition to CUT/rolling. The philosophy behind testing is that it should always stay as close as possible to a releasable state and anything we do to make testing more usable certainly contributes to this. Fixing RC bugs in testing and getting new upstream versions that are ready in testing is not a burden for developers, it's what we're supposed to do to ensure we can release as quickly as possible. Cheers, [1] It's very similar to the overlay repositories that I suggested last year in http://lists.debian.org/debian-release/2010/03/msg00385.html -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501064031.gb25...@rivendell.home.ouaza.com
Re: Bits from the Release Team - Kicking off Wheezy
On Du, 01 mai 11, 08:38:55, Mike Hommey wrote: So while I do agree with the rest of your message, I do see a need to make testing more attractive so that we have a solid user base actually testing what we are going to release, and stop saying to people that they shouldn't be using testing (and I've seen that said *a lot*). Just make 'rolling' a symlink to 'testing' and get on with your... hacking :) Add to this a press announcement (I can draft one if you want) along the lines: - 'testing' doesn't deserve it's name and will be called 'rolling' instead - users familiar with Debian are encouraged to use it, but should subscribe to debian-news (and/or d-d-a?) to watch for major transitions that might affect stability This would give you have more than 1 year time to see if this attracts more users. When the freeze approaches you can restart the flame war^W^Wdiscussion about 'frozen', but in the meantime there is enough time to create the PPA infrastructure, which will most probably solve the perceived problem[1] that rolling/testing would be frozen too long, because, instead of creating a completely new suite you can tell users just enable the foo-rolling PPA to have the latest foo on rolling. I'm sure -publicity will be happy to include such snippets in -news if you let them know ;) [1] In my almost 6 years of lurking on debian-user I haven't seen too many complaints about the freeze[2], but rather users enabling the frozen testing to prepare for the next release. [2] maybe it helps that I missed the sarge freeze ;) If you're curious, the usual advise on d-u to what should I run is: - beginning of the release cycle: stable, unless you know what you're doing (but then you wouldn't be asking) - after the major transitions (like KDE4 for squeeze): stable if you're new to Debian/Linux + backports, testing for newer stuff - freeze: testing, unless it's a production machine, but have in mind that security support will end in less than 1.5 years Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Sat, Apr 30, 2011 at 11:24:41PM -0700, Ludovico Cavedon wrote: On 04/30/2011 04:32 PM, Pierre Habouzit wrote: FWIW I think that rolling or CUT miss the point entirely. As a Debian user I use stable on my servers (with a few backports for the 3-4 things I need bleeding edge for). For my desktop I use unstable, and when that breaks (which is *very* rare, really) I go to snapshots and go back a few versions. I couldn't care about testing any less. And at work, every person I know either uses just stable or does the same as me. I know no testing user around me. Of course I'm not pretending I know the absolute Truth, but well, I find this whole users want testing badly thing dubious. I do know people who run testing. Actually I can see two kinds of users who run testing. -people who want to keep getting software updates, but do not want to run unstable [1]. They would point to testing in their apt sources.list. These are the users who want rolling -people who would decided to run the next stable release, before it is actually released, they would point their sources.list to wheezy (as of now). there are the users who will go though rolling, then frozen, then stable [1] I run unstable in my laptop, and it is stable enough for me, but for a regular user I can see how these 10 days between unstable and testing can help her to avoid getting in contact with major bugs/issues. I used to run testing in the sarge days. It was utterly broken with lots of uninstallable (or hard to insall) stuff when you had KDE migrations for example. I knew lots of people using testing at the time, we all moved to unstable because it was just too hard trying to get to install stuff at some point. Plus, you also have the very real effect of This RC bug that affects testing isn't fixed for 50 days because the fix that sits in unstable for now 45 cannot migrate because it's tangled in this or this transition. Okay I understand that rolling probably intends to fix the latter, but I'm not sure it's that easily fixable without some kind of testing-proposed-updates thing (which is a no-go because it means testing receives non-unstable-tested packages), *or* is pretty much impossible to achieve because you just can't make transition go faster, but for NMUing the blockers. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501074904.ga15...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 08:38:55AM +0200, Mike Hommey wrote: On Sun, May 01, 2011 at 01:32:19AM +0200, Pierre Habouzit wrote: FWIW I think that rolling or CUT miss the point entirely. As a Debian user I use stable on my servers (with a few backports for the 3-4 things I need bleeding edge for). For my desktop I use unstable, and when that breaks (which is *very* rare, really) I go to snapshots and go back a few versions. I couldn't care about testing any less. And at work, every person I know either uses just stable or does the same as me. I know no testing user around me. Of course I'm not pretending I know the absolute Truth, but well, I find this whole users want testing badly thing dubious. The real problem is not users want testing badly, but Debian wants people to use testing badly. Because what Debian releases is testing. If nobody uses it, we don't know until it becomes stable that it's broken in some subtle ways because it's not exactly what everyone else using unstable is using. So while I do agree with the rest of your message, I do see a need to make testing more attractive so that we have a solid user base actually testing what we are going to release, and stop saying to people that they shouldn't be using testing (and I've seen that said *a lot*). I know it's not a good excuse, but testing is something that many distributions have not. They have alphas, betas, pre-releases of many sorts, but testing is very specific to Debian, and it does receive attention. We would like more, sure, but I don't think we want to support testing either. I think we'd like people running unstable stick with testing when we freeze, that makes sense, yes. And FWIW, I use to migrate my servers to testing during the freeze (I did that for lenny and for squeeze), because the update flow is way slower than for the 18 other months. And I'm pretty sure others do it. Do we care about people testing being throughly tested all the time? I'm not really that sure, it's a volatile target and it makes no sense to fix software version incompatibility bugs that ends up never really exist in the release nor in unstable for more than a few days e.g. It's more work for a very doubtful quality gain. So instead of rolling, I'd find a way to expose testing a lot more while it counts for us, yes, and while we do care about testing being usable, meaning, the damn freeze! -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501075750.gb15...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Du, 01 mai 11, 09:57:50, Pierre Habouzit wrote: I think we'd like people running unstable stick with testing when we freeze, that makes sense, yes. This doesn't make sense to me, why would I want to downgrade to testing during the freeze? Besides, during the freeze testing and unstable are not very different, at least that's what happened during the last 2 cycles, when most updates were done via unstable. As far as I can tell, the typical unstable user will rather use experimental during the freeze, because that's where the new stuff is. Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 11:22:51AM +0300, Andrei Popescu wrote: On Du, 01 mai 11, 09:57:50, Pierre Habouzit wrote: I think we'd like people running unstable stick with testing when we freeze, that makes sense, yes. This doesn't make sense to me, why would I want to downgrade to testing during the freeze? Besides, during the freeze testing and unstable are not very different, at least that's what happened during the last 2 cycles, when most updates were done via unstable. As far as I can tell, the typical unstable user will rather use experimental during the freeze, because that's where the new stuff is. That's because it's not downgrading, I meant it rather as a freeze-with-testing kind of thing, IOW ageing with testing instead of living the bleeding edge. And no, not everybody lives in unstable for the bleeding edge, many people live with unstable because stable is too damn old for their purpose. E.g. as a developper, I need fresh enough tools: recent toolchain for its better diagnostics, better dev tools with more debugging features, though my software targets stuff way older (RH5 usually, which is globally older than *lenny*). So when the freeze arrives I'm mostly following testing, then stable for a few months to avoid the shitstorm that inevitably follows in the following 1-3 months after a release. I may not be a typical Debian User (but what is a typical Debian User anyways ?!), but I think there are more ways to use Debian than the clichés you're trying to enforce as the general rule. And FWIW, no I disagree, unstable users that want bleeding edge just suffer because experimental has no way to select overlays of wanted packages (Pinning is just a bad joke since you can't pin source packages nor regexes), and getting all experimental is just too damn broken. I think this class of users just cringe for 6 months until unstable becomes bleeding edge again. Also, and that's personal, I couldn't care about such users less, I don't think it adds value to Debian to make them happy. Putting random bleeding edge crap in a Bag isn't what I believe to be sane, and has never been a Debian goal afaict. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501094108.gc15...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
* Raphael Hertzog (hert...@debian.org) [110501 08:41]: Fixing RC bugs in testing and getting new upstream versions that are ready in testing is not a burden for developers, it's what we're supposed to do to ensure we can release as quickly as possible. Who is the we you are speaking about here? Does that we have enough man power to do that? Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501104042.gb15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sat, 30 Apr 2011 16:48:24 +0200, Andreas Barth a...@not.so.argh.org wrote: Actually, it worked quite well for both volatile and backports to start as a non-official service. Agreed for backports, violently disagreed for volatile. Volatile has been a source of demotivation and frustration, at least for me, since it was taken over by the officials. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qgvz6-00076k...@swivel.zugschlus.de
Re: Bits from the Release Team - Kicking off Wheezy
* Marc Haber (mh+debian-de...@zugschlus.de) [110501 14:16]: On Sat, 30 Apr 2011 16:48:24 +0200, Andreas Barth a...@not.so.argh.org wrote: Actually, it worked quite well for both volatile and backports to start as a non-official service. Agreed for backports, violently disagreed for volatile. Volatile has been a source of demotivation and frustration, at least for me, since it was taken over by the officials. Yes. The only thing that didn't work was clamav-data, which I considered a good use case. However, looking at the bigger picture, when I started volatile, it was basically impossible to bring any new features into stable like fixing broken communications when backends changed. All of that is now fixed. I'm really sorry for clamav-data - but at the bigger picture volatile was still a great success. Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501124106.gd15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, 01 May 2011, Andreas Barth wrote: * Raphael Hertzog (hert...@debian.org) [110501 08:41]: Fixing RC bugs in testing and getting new upstream versions that are ready in testing is not a burden for developers, it's what we're supposed to do to ensure we can release as quickly as possible. Who is the we you are speaking about here? Does that we have enough man power to do that? We = developers/maintainers/Debian as a whole It seemed obvious to me. I understand members of the release team feel particularly responsible to do various release-critical tasks that should have been done by the maintainers but haven't (for various reasons). And I guess that's the reason of your remark. But that's not scalable ultimately. So I think it's a good move to say we support testing and we expect every maintainer to take care of their packages there (as opposed to the current situation where too much of that work is left in the hands of the release team). Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501133957.ga13...@rivendell.home.ouaza.com
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 02:06:19AM +0200, Pierre Habouzit wrote:
I think that we should not do any trade off on the quality of
rolling/testing/the-antechamber-of-stable, but instead raise the quality
of unstable so that (which isn't *that* bad, unstable is rarely badly
broken, and I know lots of stable releases of linux distributions that
are in worse state than the average of unstable on the same set of
packages…):
YMMV, but I don't think the problem in using unstable directly is of
average quality, but rather the fact that you've little shields against
temporary yet severe breakages. apt-listbugs helps a bit, but it depends
too much on the interleaving of upgrades and you might very well be the
first one encountering a big trouble even if you're using apt-listbugs
(I speak out of my own experience here as I use an unstable laptop as my
main productivity environment).
Testing, OTOH, is really unique in that respect, with its mixture of
fresh software and quarantine period. That is the case even if it has
been designed with a different goal in mind. Out of all this
discussion, the challenge that interests me is whether testing (or
something new, similar to it) can be targeted at final users without
having significant differences in its lifetime depending on the release
cycle of Debian stable. As many posts have shown, the difficulty lies in
how (and if) we can do that without harming the stable release process
itself. It might very well be that the 'frozen' proposal does not cut
the deal, but that's not a reason by itself to give up this challenge.
I've already written one too long mail about that, but allowing DDs to
spin off some repositories in a PPA-way can be the way. Managing a
Debian mirror plus all the {uploading,building,bts}-infrastructure is a
PITA, but if we make it easy, it'll get used.
Amen (see my post with 'PPA' in its subject).
For now we're not even in the packing CVS era since branching is a
PITA. Let's make it easy, and then the whole rolling thing will be
moot because unstable will be good enough for our users 98% of the
time.
As we have discussed on #d-devel, there might be plenty of lower hanging
fruits than a user-targeted testing out there, but for me there is no
reason not to discuss other topics as well.
[ And also relaxing our NMU policies would help too but that's yet
another story: in a few words, we should allow NMUs as soon as there
is enough acked-by for them… to enforce a minimal level of
peer-review, so that quality is checked, and relax all the
conditions to perform NMUs at once ]
I'll repeat this to death: NMU policies are already quite relaxed.
Basically, if you do things properly, there is no bug you cannot fix
with a long DELAYED NMUs. We don't need any change in policy to use NMU
more liberally, we need a culture shift, which IMHO is even happening,
although quite slowly.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 01:32:19AM +0200, Pierre Habouzit wrote:
Oh yes, you really want to attract new contributors ? build debhub.com
(as in github) and force everyone to package stuff in there. Let people
propose patches, packaging new upstreams and so forth using merge
requests (as in github), and there you'll be attractive. We would have
invented social packaging (so 2.0-ish), and also lower the difficulty
to contribute patches in a more efficient way than the BTS (sorry but
the BTS *isn't* a tractable way to do heavy lifting, it's only good to
send small unrelated patches).
That is called Launchpad, I believe. Having all packages in there our
Ubuntu cousins can add menu items to applications that instantly branch
off a local directory where users can hack on the packaging (or source
code) and shortly after push a branch back to Launchpad with a merge
request. Once you have all packages in the same $VCS, imagining
applications like the above is not rocket science.
I've been dreaming of a similar integration in Debian since the days
where I was pushing for the Vcs-* headers, but as you explained later on
in your mail the problem is: how can we converge on a specific Vcs in
Debian? Or, even easier, how can we converge on the guarantee that all
packages are maintained within some VCS in the first place? Are we
ready to take votes on this and lose the people which won't like the
choice and will go away slamming the door? I appeal to all the
creativity people might have to solve the integration vs liberty
dilemma.
I essentially agree with everything you've written later about PPA.
Maybe that mail of yours will actually help finding someone drafting a
first implementation
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Fri, Apr 29, 2011 at 06:50:04PM -0400, Michael Gilbert wrote:
Look at the welcoming new contributors GR; what did that actually
accomplish? There isn't anything new to show for it, there are no new
means to bring contributors in, and the number of new people hasn't
really changed.
I doubt you'll find this surprising, but I beg to disagree. As little as
that number can be, there are nowadays 3 people in the contributors
keyring, 1 in the NM queue, and 1 which is about to apply (asked me to
advocate him a few days ago). Considering that the infrastructure and
procedures took a few months to stabilize after the GR outcome, I
consider that to be a pretty good result for about 6 months since
everything was up and running (and 5 it's a non negligible share of the
amount of new DDs we get per year).
I have no idea whether those people would have diminished their
involvement in or not considered contributing to Debian, if the GR
weren't there. But as a matter of fact, chances are that those people
wouldn't have been able to be Debian Developers today if it weren't for
the GR.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Fri, Apr 29, 2011 at 06:05:35PM -0400, Joey Hess wrote:
In the Squeeze release we have done better than before by calling for
explicit upgrade testing (kudos to the Release Team!), but a specific
plan of alpha/beta/... might bring even more testing, especially if the
media help us out with some hype.
FWIW, d-i already has a history of numerous beta releases, including CD
images, although it was somewhat crippled by our inability to call them
betas of Debian as a whole, not just d-i (although I think we managed to
fool some people about that), as well as our inability to target them to
a non-moving suite.
Out of curiosity, have the d-i discussed with the release team the
possibility of presenting them as alpha/beta/... of Debian as a whole?
I ask to try to figure out whether there were some agreed upon technical
issues (like the moving target issue you mention) or whether it is
simply yet to be discussed/analyzed.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Sat, Apr 30, 2011 at 10:11:49PM +0200, sean finney wrote:
A complete aside: I have yet to see DEPs being anything but a structured
way to bikeshed. However, if you wish to go down this route, feel free.
This does bring me full circle back to the start of my mail - if you
want to push this, that's fine. But please don't try and make extra work
for others.
While just about any technical discussion on -devel will have its tangents
and its non sequitors, I think we *have* had some good stuff come out of the
DEP's, so I disagree there. For example, DEP-3 and DEP-5 have (indeed,
after quite a bit of bikeshedding) resulted in some nice pseudo-standards
that are gaining increasing traction/usage.
Agreed. DEPs neither add nor remove anything from a specific discussion,
they are just a way to keep track of the outcome, or status, of it. In
that sense, if there is too much bikeshed, it's most likely inherited
from the way we discuss. Additionally, in the specific case of using
DEPs to write standards, bikeshed is part of the game, as many
participants in standards body can confirm.
JFYI, Sean and Raphael have taken DEP number 10 and I believe they're
going to use it to summarize the proposal and the other pro/against
arguments raised in this thread. So we might all want to hold on a bit
and start fresh from their summary.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
* Stefano Zacchiroli (z...@debian.org) [110501 16:12]: On Fri, Apr 29, 2011 at 06:05:35PM -0400, Joey Hess wrote: In the Squeeze release we have done better than before by calling for explicit upgrade testing (kudos to the Release Team!), but a specific plan of alpha/beta/... might bring even more testing, especially if the media help us out with some hype. FWIW, d-i already has a history of numerous beta releases, including CD images, although it was somewhat crippled by our inability to call them betas of Debian as a whole, not just d-i (although I think we managed to fool some people about that), as well as our inability to target them to a non-moving suite. Out of curiosity, have the d-i discussed with the release team the possibility of presenting them as alpha/beta/... of Debian as a whole? That's how the press reads it anyways. Perhaps we should label them so. Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501142316.gg15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
Ludovico Cavedon cave...@debian.org wrote: On 04/30/2011 04:32 PM, Pierre Habouzit wrote: FWIW I think that rolling or CUT miss the point entirely. As a Debian user I use stable on my servers (with a few backports for the 3-4 things I need bleeding edge for). For my desktop I use unstable, and when that breaks (which is *very* rare, really) I go to snapshots and go back a few versions. I couldn't care about testing any less. And at work, every person I know either uses just stable or does the same as me. I know no testing user around me. Of course I'm not pretending I know the absolute Truth, but well, I find this whole users want testing badly thing dubious. I do know people who run testing. Actually I can see two kinds of users who run testing. -people who want to keep getting software updates, but do not want to run unstable [1]. They would point to testing in their apt sources.list. These are the users who want rolling -people who would decided to run the next stable release, before it is actually released, they would point their sources.list to wheezy (as of now). there are the users who will go though rolling, then frozen, then stable [1] I run unstable in my laptop, and it is stable enough for me, but for a regular user I can see how these 10 days between unstable and testing can help her to avoid getting in contact with major bugs/issues. Even though I do not have numbers, I can see both use cases for rolling and frozen. Ok, frozen might get less users than testing during freeze, but handling both these 2 use cases could actually attract more users. Form what I could understand, the main purpose of rolling is to avoid the discontinuity in updates flow that happens in unstable (and of course in testing), when testing is under freeze. Which is annoying for users who do not care about stable. Such users (first type above) will have to go and pick updates from experimental during freeze (with all the problems Pierre mentioned about experimental). Similar reasoning applies to developers: those who care about having the latest version in unstable, will switch to uploading to experimental rather than unstable. So I am not sure that arguments like having testing frozen and avoiding major updates in unstable help DD and users focus on preparing the next stable actually apply... I think that such a solution would, at best, be a half solution to the problem you describe. Even when Testing is not frozen, interlocking transitions often delay availability of new releases. Sometimes this is due to an entanglement delaying a transition and sometimes it's due to needing to wait for a transition slot. Unless this problem is solved too, I doubt rolling will roll nearly as much as people will want or accept. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e7e4fe9d-8b6e-4566-8545-38e11c384...@email.android.com
Re: Bits from the Release Team - Kicking off Wheezy
* Raphael Hertzog hert...@debian.org [2011-05-01 15:40]: On Sun, 01 May 2011, Andreas Barth wrote: * Raphael Hertzog (hert...@debian.org) [110501 08:41]: Fixing RC bugs in testing and getting new upstream versions that are ready in testing is not a burden for developers, it's what we're supposed to do to ensure we can release as quickly as possible. Who is the we you are speaking about here? Does that we have enough man power to do that? We = developers/maintainers/Debian as a whole It seemed obvious to me. Why don't you (where you = Raphael Hertzog) demonstrate that CUT/rolling brings the benefit you predict, just like AJ did with testing and Andreas did with volatile, before asking developers/maintainers/Debian as a whole to implement the change? Yours, Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501150313.ga26...@anguilla.debian.or.at
How to change the world, was: Re: Bits from the Release Team - Kicking off Wheezy
Hello, Marc laid that wonderful bait in this thread to which then Stefano bite, and then the thread ended after some clarification by Marc where IMHO there was no clarification needed [not shown]. On 04/30/2011 12:28 PM, Stefano Zacchiroli wrote: On Sat, Apr 30, 2011 at 11:28:17AM +0200, Marc 'HE' Brockschmidt wrote: In the last years, Debian hasn't been able to contribute any important feature to the F/OSS distribution world - change (leading to both good or bad results) happens at other places (namely Ubuntu) at the moment. I believe this has a simple, technical reason - Debian has become too big. Every change requires a massive amount of work on thousands of packages, interaction with hundreds of (sometimes absent) volunteers and is thus increasingly costly. This high cost makes experiments impossible, because backing out of a change is a waste of the scare resources of the Debian project. No, no, and ... uhm ... no :-) (although we're getting a bit off-topic here, I'll bite) I agree with your analysis above, but exactly because I agree with it, I argue that you cannot single out big as the main cause. To disprove that as the main cause, it would be enough to notice that some of our derivatives are, by definition, as big as Debian is, but still can make significant changes on top of what we offer them. So the overall issue is rather the interaction among the size and the processes that govern that huge package repository monster that we are. As an example, consider a maintainer willing to devote her time in making a change that touches 300 packages. Let's assume that the change is consensual. To deploy the change in Debian either you are lucky and: 1) all the packages are in the same VCS and 2) you've commit write access to it (in which case you've very little procedural obstacles in your way). Or rather you need to ping maintainers, chase the sometimes absent people, do NMUs, etc. And that is the easy case where the change is consensual! Size is just one ingredient. There are plenty of other ways to diminish barrier to deploy big changes in Debian: wider commit access rights, larger VCS repositories, more liberal NMUs, etc. (Unsurprisingly, several Debian derivatives have decide to pursue those other ways and one might argue that they have done so learning from Debian experience.) Of course each such change will have consequences elsewhere, but please don't assume that size is the only problem. I've the impression that will simply stop our creativity in improving our processes. Debian is perfectly good at holding the status quo - it's a well-integrated, stable, mostly state of the art distribution suited for almost anything you can come up with. Trying to repaint one of the existing bikesheds with your new rolling color will not attract the developers (nor users) interested in making it a hip place again. And how do you know that? In fact, I'm even happy to see becoming manifest the various disagreement and different expectations we have around testing: on such vague aspects it's hard to have upfront agreements. But both you and Raphael are taking guesses on the number of users / developers / effects of a thing which does not exist yet. At this point, it can only be speculation. You might disagree how much as you please, but there is only one way to know who is right: build the thing. As long as that does not step on others toes and as long as there are volunteers willing to put their energy into a new experiment, that's just fine. Big changes after all also need people willing to go ahead against some odds and show they were right --- or alternatively fail miserably. I very much agree to what was said above - from both sides. What I would like to add is that Debian's most amazing resource is our community. We have an enormous outreach into many many disciplines in Engineering and Science and academia and industry. That Open Source has achieved that, and is getting steadily better in getting that outreach, is truly amazing. Yes, it is increasingly difficult to manage out packages. And I have good confidence that we will find the energy to get those changes established that are required to get this done. We are doing so already: * the Debian PPAs are such a means, basically separating core and periphery of Debian * rolling.d.n is up for such * snapshots.d.o is of tremendous value, very much underrated by many * backports.d.o * community maintainerships in our blends * ...? The community will become increasingly important to get their production tools into our distribution (or into some PPA). This will especially change our Java world more, from what I observe. When they do, this seems likely to have a very positive impact especially on developing countries. If it does, then we have changed the world more than with the invention of some special technology for ourselves. From a more technical point of view I am thrilled about the surprises and conflicts that we will run into
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 03:39:57PM +0200, Raphael Hertzog wrote: On Sun, 01 May 2011, Andreas Barth wrote: * Raphael Hertzog (hert...@debian.org) [110501 08:41]: Fixing RC bugs in testing and getting new upstream versions that are ready in testing is not a burden for developers, it's what we're supposed to do to ensure we can release as quickly as possible. Who is the we you are speaking about here? Does that we have enough man power to do that? We = developers/maintainers/Debian as a whole It seemed obvious to me. I understand members of the release team feel particularly responsible to do various release-critical tasks that should have been done by the maintainers but haven't (for various reasons). And I guess that's the reason of your remark. But that's not scalable ultimately. So I think it's a good move to say we support testing and we expect every maintainer to take care of their packages there (as opposed to the current situation where too much of that work is left in the hands of the release team). I've stared at that for a long time, read it three time to be sure I read it properly. And it seems I did… I'm still staring at it in disbelief while I'm answering. You're saying: Problem: I acknowledge that people are not interested in stable releases enough and that the RT has to compensate all the time. Solution: Let's pretend we care about testing being usable, that will make people who don't care, to actually care and fix their bugs! Of course the release team doesn't scale this way, I'm happy you noticed. But what you propose isn't even wishful thinking. I'm still not believing you've written something that naive, are you really deluding yourself to that point? PS: when you say your trick like that, you know, people know you're trying to trick them and it doesn't work anymore. I've two children, I can tell. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501163813.ga19...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
]] Stefano Zacchiroli | I've been dreaming of a similar integration in Debian since the days | where I was pushing for the Vcs-* headers, but as you explained later on | in your mail the problem is: how can we converge on a specific Vcs in | Debian? Or, even easier, how can we converge on the guarantee that all | packages are maintained within some VCS in the first place? Are we | ready to take votes on this and lose the people which won't like the | choice and will go away slamming the door? I appeal to all the | creativity people might have to solve the integration vs liberty | dilemma. I'd suggest something like: - Choose a preferred VCS system. - Import packages native to that system directly, for others, use the fast-export where available. If there's no fast-export or no public VCS, just import each upload. - Provide fast-export dumps (or just let people do fast-export themselves) from the preferred system (in addition to whatever native format the system has, of course). While this won't guarantee that packages are actually maintained in said VCS, it pushes people in that direction and enables others to build on the work that's already done and makes it fairly simple to move to a VCS-ed system if somebody wants to do so down the line. Regards, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vuqb8z9@qurzaw.varnish-software.com
Re: Bits from the Release Team - Kicking off Wheezy
On 01/05/11 at 18:38 +0200, Pierre Habouzit wrote: You're saying: Problem: I acknowledge that people are not interested in stable releases enough and that the RT has to compensate all the time. Those two statements are true: - A subset of DDs care about doing stable releases. The rest of DDs don't care. - A subset of DDs care about doing 'rolling'. The rest of DDs don't care. The release team obviously cares about stable releases, and I mostly read the individual positions of RT members in this thread as if we do 'rolling', it will be harder to do stable releases. Their position is completely understandable. It's likely that doing 'rolling' will impact stable releases in some ways. Some of the impact might be negative, some might be positive. But what we (the project) need to decide on is where we want to go. After all, we could decide not to do stable releases, or to do them every six months instead of every two years. The current choice of doing stable releases every two years is there only because a large subset of DDs care about doing that. It seems that the 'rolling' idea has some supporters. So what we need to do is: 1. determine one or more action plans around the 'rolling' idea, and their impacts on all the parts of the projects (including the process of doing stable releases). This thread provides great input about that, and badly needs someone to do a summary (hint hint). 2. determine who is in support of each action plan, through a GR or a poll. There are some 'cheap' ways (for the project) to do 'rolling'. For example, we could decide to: [Plan A -- s/testing/rolling/:] - rename testing to rolling - advertise it as something end-user friendly - manage it exactly like testing (freeze it even for 6 months, etc) That would have a very limited impact on the release team AFAICS. Or we could decide to implement the 'frozen' plan: [Plan B -- rolling+frozen:] - do Plan A. - But instead of freezing rolling, fork it to a 'frozen' branch, and continue the normal 'rolling' process. This plan clearly has a severe impact on the preparation of stable releases. There are compromise solutions, too: [Plan C -- freeze rolling before forking frozen:] - do plan A. - But When the release team decides to do a general freeze, rolling is frozen for a few months to maximize user testing and developer attention. After two to four months, 'frozen' is forked from 'rolling', and the normal 'rolling' process resumes. (And of course, there's:) [Plan B -- do not change anything] Can anyone think of other plans? Dear Release Team members, what would you think of Plan A? Are there conditions under which Plan C would be acceptable from your POV? - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501180251.ga25...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
Hi, On Sun May 01, 2011 at 20:02:51 +0200, Lucas Nussbaum wrote: 2. determine who is in support of each action plan, through a GR or a poll. I don't think we need a GR for that. Those who are interested in rolling releases could show that they are interested and just doing so (like Norbert/formorer/Rhona/... did with backports, like Joey Hess did with testing-security, like Andi and me did with volatile, ...). I am aware this might need changes in some of Debian's infrastructure, but i am quite sure if you provide help/patches/... those will be implemented. Cheers, Martin -- Martin Zobel-Helas zo...@debian.org | Debian System Administrator Debian GNU/Linux Developer | Debian Listmaster GPG key http://go.debian.net/B11B627B | GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501185114.gb13...@ftbfs.de
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 08:02:51PM +0200, Lucas Nussbaum wrote: On 01/05/11 at 18:38 +0200, Pierre Habouzit wrote: You're saying: Problem: I acknowledge that people are not interested in stable releases enough and that the RT has to compensate all the time. Those two statements are true: - A subset of DDs care about doing stable releases. The rest of DDs don't care. - A subset of DDs care about doing 'rolling'. The rest of DDs don't care. The release team obviously cares about stable releases, and I mostly read the individual positions of RT members in this thread as if we do 'rolling', it will be harder to do stable releases. Their position is completely understandable. It's likely that doing 'rolling' will impact stable releases in some ways. Some of the impact might be negative, some might be positive. But what we (the project) need to decide on is where we want to go. After all, we could decide not to do stable releases, or to do them every six months instead of every two years. The current choice of doing stable releases every two years is there only because a large subset of DDs care about doing that. The thing is, I think that rolling and testing are not compatible. So it seems unlikely to me that we can support both in Debian, especially not in the same namespace testing or rolling. I don't want to lose stable releases, it's a disservice to our users. And if you try something like your plan B, you'll have two issues: (1) you'll split the userbase, some of the users will use rolling instead of testing, and during the freeze we're very interested about our users to test testing. It's actually the period where it matters the most. In the end you get less testing coverage, hence mathematically lessen the quality. (2) developers who already care little about stable releases will even care less because they will be able to do the work that they like (brining their software up to date, not really caring about stable), IOW it'll divert attention of the maintainers even more. Both will lead to a poorer quality of the stable release, and probably even longer freezes. Both are a disservice to the stable release, and to our users. And in the end both will put more pressure on the shoulders of the RT members that already don't scale. Of course rolling has some appeal, but it's just hype, and well, sometimes our users want silly things and we should know better than to indulge them. I agree that a 6 months freeze sucks because we miss a release for many upstreams (gnome, KDE, …), which makes packaging harder. But maybe we should focus on how to reduce the freeze period (which would in turn mean that we should have some study about why it's 6-months long instead of 3 like I'm sure it could be). I strongly believe that lessening the quality of the Debian stable release is harming Debian as a whole. And I know I'm rehashing things, but this will inevitably lead to more work for maintainers: supporting stable + testing means more work there is no way it will reduce the work. It's our scarce resource (developpers), so why don't we *first* focus on making packaging easier, leaner, simpler, and *then* see what we can do with all that new free time we just bought? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501185525.ga20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 04:17:10PM +0200, Stefano Zacchiroli wrote: JFYI, Sean and Raphael have taken DEP number 10 They have? I haven't seen mail to debian-project about this, which is what http://dep.debian.net/deps/dep0/ requires? (The chance of a collision here is quite small of course, but I'm still confused how they have taken this number without following the procedure.) -- 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 Archive: http://lists.debian.org/20110501190247.gc21...@virgil.dodds.net
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 09:43:51PM +0200, Stefano Zacchiroli wrote: On Sun, May 01, 2011 at 08:55:25PM +0200, Pierre Habouzit wrote: (1) you'll split the userbase, some of the users will use rolling instead of testing, and during the freeze we're very interested about our users to test testing. It's actually the period where it matters the most. Just for the sake of the argument, that is not granted. The above is true only if the user base remains constant. Arguably, rolling is appealing to users of other existing rolling distributions which are based on Debian anyhow (name one) and, who knows, also to current users of release-every-6-months derivatives who want more support on all the archive. Yes, mine is speculation, but it seems to be in the same ballpark of a hidden assumption in the above. Well, we've heard about that argument before, namely when Ubuntu was created. I think we've had enough history to know that Ubuntu users don't directly make Debian better, and certainly not at a fast pace. I don't see why rolling users would benefit to testing for the same reasons[1]. The key point is, when we do need rolling users to help testing (namely during the freeze), it's when rolling is the most different from testing. So when the users from rolling actually don't help. The sole benefit from rolling is that unstable would probably end up less broken the two months just after a release. Also I skipped an important point out, name it (3), the entry points. unstable can't be the antechamber of testing and rolling at the same time. If unstable is diverted to rolling, it means a t-p-u like setup to feed testing. But that sucks, quality from t-p-u isn't as good as unstable, this is a really frowned upon way to feed testing, that the RT doesn't like to be forced to use. And if you say unstable feeds testing, then you'll need a dedicated feed channel for rolling, and you'll end-up with either less test for rolling (since this distribution say unstable/rolling has less users), hence rolling will suck, _OR_ it'll divert users from unstable and we're back to unstable being t-p-u without the name, which isn't acceptable. [1] Of course since both are under the Debian umbrella it'll /probably/ be a lot less politicized than the Debian-Ubuntu relations. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501195213.gb20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On 01/05/11 at 20:51 +0200, Martin Zobel-Helas wrote: Hi, On Sun May 01, 2011 at 20:02:51 +0200, Lucas Nussbaum wrote: 2. determine who is in support of each action plan, through a GR or a poll. I don't think we need a GR for that. Those who are interested in rolling releases could show that they are interested and just doing so (like Norbert/formorer/Rhona/... did with backports, like Joey Hess did with testing-security, like Andi and me did with volatile, ...). I am aware this might need changes in some of Debian's infrastructure, but i am quite sure if you provide help/patches/... those will be implemented. I don't see how that could work. Iet's assume that the goal is to demonstrate the interest in the rename testing to rolling scenario, without even talking about what to do during freezes. The first steps of the implementation will include: - rename testing to rolling. I don't see how ftpmasters would do it without a consensus that this is something wanted by the project. - communicate officially, to the general public, that rolling is not only a development branch, but also suited for use by the general public (given known limitations). I don't see how the press team would publish something like that without a consensus that it's what the project thinks. What was applicable for backports, testing-security or volatile is not applicable here, because the implications for the project are deeper. It's not about adding a suite with some different packages in the margin. It's about shifting developers' focus and user attention a bit. Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501195358.gb31...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
On 01/05/11 at 20:55 +0200, Pierre Habouzit wrote: On Sun, May 01, 2011 at 08:02:51PM +0200, Lucas Nussbaum wrote: On 01/05/11 at 18:38 +0200, Pierre Habouzit wrote: You're saying: Problem: I acknowledge that people are not interested in stable releases enough and that the RT has to compensate all the time. Those two statements are true: - A subset of DDs care about doing stable releases. The rest of DDs don't care. - A subset of DDs care about doing 'rolling'. The rest of DDs don't care. The release team obviously cares about stable releases, and I mostly read the individual positions of RT members in this thread as if we do 'rolling', it will be harder to do stable releases. Their position is completely understandable. It's likely that doing 'rolling' will impact stable releases in some ways. Some of the impact might be negative, some might be positive. But what we (the project) need to decide on is where we want to go. After all, we could decide not to do stable releases, or to do them every six months instead of every two years. The current choice of doing stable releases every two years is there only because a large subset of DDs care about doing that. The thing is, I think that rolling and testing are not compatible. So it seems unlikely to me that we can support both in Debian, especially not in the same namespace testing or rolling. I don't want to lose stable releases, it's a disservice to our users. And if you try something like your plan B, you'll have two issues: (1) you'll split the userbase, some of the users will use rolling instead of testing, and during the freeze we're very interested about our users to test testing. It's actually the period where it matters the most. In the end you get less testing coverage, hence mathematically lessen the quality. (2) developers who already care little about stable releases will even care less because they will be able to do the work that they like (brining their software up to date, not really caring about stable), IOW it'll divert attention of the maintainers even more. Both will lead to a poorer quality of the stable release, and probably even longer freezes. Both are a disservice to the stable release, and to our users. And in the end both will put more pressure on the shoulders of the RT members that already don't scale. The problems of Plan B have already been well explained in this thread. And both (1) and (2) are (at least partially) addressed by Plans A and C. Of course rolling has some appeal, but it's just hype, and well, sometimes our users want silly things and we should know better than to indulge them. I agree that a 6 months freeze sucks because we miss a release for many upstreams (gnome, KDE, …), which makes packaging harder. But maybe we should focus on how to reduce the freeze period (which would in turn mean that we should have some study about why it's 6-months long instead of 3 like I'm sure it could be). I strongly believe that lessening the quality of the Debian stable release is harming Debian as a whole. And I know I'm rehashing things, but this will inevitably lead to more work for maintainers: supporting stable + testing means more work there is no way it will reduce the work. It's our scarce resource (developpers), so why don't we *first* focus on making packaging easier, leaner, simpler, and *then* see what we can do with all that new free time we just bought? We have been trying to do stable releases while making packaging easier for years now. If I follow your argument, why don't we stop making stable releases for a while, and focus on making packaging easier? [ Note that my position is based on the assumption that we have a share of DDs interested in rolling similar to the share of DDs interested in stable releases. Unfortunately, it's very difficult to know where we stand regarding this. ] - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501193507.ga31...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
Pierre Habouzit wrote: FWIW I think that rolling or CUT miss the point entirely. As a Debian user I use stable on my servers (with a few backports for the 3-4 things I need bleeding edge for). For my desktop I use unstable, and when that breaks (which is *very* rare, really) I go to snapshots and go back a few versions. I couldn't care about testing any less. And at work, every person I know either uses just stable or does the same as me. I know no testing user around me. Of course I'm not pretending I know the absolute Truth, but well, I find this whole users want testing badly thing dubious. Consider all the users who are running stable, plus a backport of some servers, or a chromium or firefox installed from upstream because stable's is too old. Consider the users who have so many backports installed that they start to encounter integration problems between them. Consider users who install Ubuntu because there is no usable Debian release with a kernel new enough for their hardware, but then have to fight with it to disable some Unity thing. These are all use cases for CUT. -- see shy jo signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On 05/01/2011 08:02 PM, Lucas Nussbaum wrote: There are compromise solutions, too: [Plan C -- freeze rolling before forking frozen:] - do plan A. - But When the release team decides to do a general freeze, rolling is frozen for a few months to maximize user testing and developer attention. After two to four months, 'frozen' is forked from 'rolling', and the normal 'rolling' process resumes. That still means starting the dev cycle with something that's not the just released stable. It looks like a problem, to me. I also think that trying to reduce freeze's duration is the way to go. (and I think I already said so). Some blockers during the freeze have been mentioned on IRC (by Julien, iirc) that ought to be mentioned here (IMHO) just to keep them in mind: 1) someone manpower needed to work on release notes 2) not enough contributors fixing RC-bugs 3) people working on upgrade tests and fixing upgrade issues 4) d-i releases are not frequent and take too long, that really slows down things a bit. It has direct impact on 3). If we can enhance some of them (hopefully, all of them), we will be able to reduce freeze's duration, IMHO. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dbdbcba.6020...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 04:01:20PM -0400, Joey Hess wrote: Pierre Habouzit wrote: FWIW I think that rolling or CUT miss the point entirely. As a Debian user I use stable on my servers (with a few backports for the 3-4 things I need bleeding edge for). For my desktop I use unstable, and when that breaks (which is *very* rare, really) I go to snapshots and go back a few versions. I couldn't care about testing any less. And at work, every person I know either uses just stable or does the same as me. I know no testing user around me. Of course I'm not pretending I know the absolute Truth, but well, I find this whole users want testing badly thing dubious. Consider all the users who are running stable, plus a backport of some servers, or a chromium or firefox installed from upstream because stable's is too old. Consider the users who have so many backports installed that they start to encounter integration problems between them. Consider users who install Ubuntu because there is no usable Debian release with a kernel new enough for their hardware, but then have to fight with it to disable some Unity thing. These are all use cases for CUT. Who are they? Unlike this constant handwaving, I've shared my experience (on #-devel), I'll repeat it here: at work we've like 10 Debian users, some with stable, the other with unstable. Why? Because we're developpers and if our software targets old stuff (RH5, it's as old as lenny), the latest gcc, valgrind, … are priceless tools, and we want them. I run unstable on my laptop and workstation for years, with almost daily dist-upgrades. Except for grub2 (and I've been stupid, I removed grub, I should have known better) I've had no serious issues for 5 years, nothing that prevented a boot, almost nothing that prevented X to start, and absolutely nothing that a revert to testing or using snapshots.debian.org couldn't fix (plus a dpkg-hold for good measure). At work something like 6 different people use that setup, and we have complex boots with dm-raid, lvm, cryptsetup, it never broke. Those are real users from real life. I'm not saying we-re representative of a majority of Debian Users, but unlike all the handwaived users we've read about in this thread, those are real. Could someone here explain with a real life example who the users who badly need CUT/rolling are, and explain to me why unstable isn't a good choice for them (and no, unstable brokeness doesn't CUT it — sorry I had to do it — my experience proves it's rare). -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501200845.gc20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 09:35:07PM +0200, Lucas Nussbaum wrote: [ Note that my position is based on the assumption that we have a share of DDs interested in rolling similar to the share of DDs interested in stable releases. Unfortunately, it's very difficult to know where we stand regarding this. ] I'm assuming that releasing is what Debian is about (and fwiw if you read Raphael's proposal, it's for him too), meaning that rolling is a second class citizen here. And frankly, I think that anything that makes rolling as important as releasing stables is against Debian (and its users) interest. Why? well just answer that question: would you run a rolling-based distro on servers? Answer: if you're a sysadmin it will be NO because the security model of rolling is update to the latest software, you know, the firefox-kind-of-security. Remember that we hate it, because with security fix come: - upgrade path hells - new bugs - removed features - … There are other distros out-there that do rolling release only (gentoo, arch), note how none of them also do stable releases (I think gentoo used to tag their repository every now and then, but that doesn't make them releases, please, at least not in the Debian sense). -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501201701.gd20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
Pierre Habouzit wrote: Who are they? Unlike this constant handwaving, I've shared my experience ^^^ If you feel that my contributions and experience in Debian consist of constant handwaving, feel free to ignore and dismiss me. -- see shy jo signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 04:26:57PM -0400, Joey Hess wrote: Pierre Habouzit wrote: Who are they? Unlike this constant handwaving, I've shared my experience ^^^ If you feel that my contributions and experience in Debian consist of constant handwaving, feel free to ignore and dismiss me. Your mail describes hypothetic users needing lots of backports. Where on earth did I speak of your contributions !? Please don't mix-up everything, this thread is painful enough as it is. Frankly I'm disappointed I used to think you didn't bait people like this. I'll re-phrase my question more directly: please explain me why CUT or rolling would change your life, and why wouldn't unstable cut it for you. Or if what was presented like an hypothetical user is you, why do you need so many backports that it doesnt work? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501203301.ge20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
Stefano Zacchiroli wrote: Out of curiosity, have the d-i discussed with the release team the possibility of presenting them as alpha/beta/... of Debian as a whole? It seemed better when I was leading d-i to just do it, rather than talk about doing it. (Which AFAICS also holds true of this thread and/or CUT.) I ask to try to figure out whether there were some agreed upon technical issues (like the moving target issue you mention) or whether it is simply yet to be discussed/analyzed. The problem with the moving target is that it means that d-i betas begin to be broken as time goes on after their release, starting with the smallest boot images and moving up to the netinst images. (Full CDs tended to be ok then, but probably only DVDs are self-contained enough to not be affected now.) That is mostly a problem outside the freeze, so most d-i betas (and much final d-i integration work) is now done inside the freeze. As has been noted, that tends to extend the length of the freeze. -- see shy jo signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On 01/05/11 at 22:17 +0200, Pierre Habouzit wrote: On Sun, May 01, 2011 at 09:35:07PM +0200, Lucas Nussbaum wrote: [ Note that my position is based on the assumption that we have a share of DDs interested in rolling similar to the share of DDs interested in stable releases. Unfortunately, it's very difficult to know where we stand regarding this. ] I'm assuming that releasing is what Debian is about (and fwiw if you read Raphael's proposal, it's for him too), meaning that rolling is a second class citizen here. Well, I disagree. I believe that Debian is about building an operating system. Whether we deliver it through stable releases, or through a rolling release, or both, is an implementation detail. And frankly, I think that anything that makes rolling as important as releasing stables is against Debian (and its users) interest. Why? well just answer that question: would you run a rolling-based distro on servers? (JFTR, my answer would be no) Answer: if you're a sysadmin it will be NO because the security model of rolling is update to the latest software, you know, the firefox-kind-of-security. Remember that we hate it, because with security fix come: - upgrade path hells - new bugs - removed features - … There are other distros out-there that do rolling release only (gentoo, arch), note how none of them also do stable releases (I think gentoo used to tag their repository every now and then, but that doesn't make them releases, please, at least not in the Debian sense). I don't follow your reasoning. - I don't think that we should restrict Debian to servers managed by serious sysadmins. - Gentoo Arch don't do stable releases, OK. Why would it mean that we couldn't do it? It's clear that we are not going to stop doing stable releases anytime soon. However, there seem to be some interest in the rolling release concept. The question is: can we (Debian) provide a rolling release with an acceptable increase in workload, and without compromizing the quality of our stable releases ? If yes, why shouldn't we do it? - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501203607.ga2...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 10:08:46PM +0200, Pierre Habouzit wrote:
Those are real users from real life. I'm not saying we-re
representative of a majority of Debian Users, but unlike all the
handwaived users we've read about in this thread, those are real.
First of all I think you should concede that the exercise you're asking
us to do cannot be done as easily as you did yours. You've been able to
mention real users of an existing distro, you are asking others to
provide evidence of users of a thing that does not exist yet; quite
challenging... So you do have an inherent advantage, but let me try
nonetheless.
During last year:
- I've talked at several trade shows and conferences with developers of
rolling distros based on Debian (in particular: Aptosid/Sidux and
Linux Mint Debian Edition). They usually claim they have built those
distros because Debian wasn't offering such feature (yes, they should
have probably tried do that in Debian, NIH syndrome exists, yada yada,
not to mention the fact they might have said that to me because they
wanted to be kind towards Debian). It must have been half a dozen
people.
- I've been interviewed in various venues since DebConf10 (probably
around 10, you can check my bits mails to d-d-a) and in about half of
them (IIRC!) I've been asked about CUT. At that level, the
understanding of CUT it was probably only like a testing which is
meant to be used by final users, nothing more precise than that.
Still, I take that as a sign of interest from the target public of
those who has interviewed me.
- At LCA, I had to answer several questions about the fact that one of
the most important Debian mistake in recent years has been to
undersell testing. People asking those questions believe that
testing, up to the tweaking CUT was meant to add, is a good distro for
final users. I've mentioned all this in my LCA report [1] way before
this monster thread. The audience asking those questions was full of
Debian enthusiasts from various places in the world.
Is the above hand waving? Maybe yes, you name it.
For me it's convincing evidence that there is interest in what we might
have to offer on the front of making targeted to (some kind of) final
users.
Various notes are in order:
- the above do not address stances like we know better than users
(which I don't buy, not because I think users *always* know better,
but rather because I'm making a Free OS *for* users and I think with
that comes the moral duty to at least listen to them)
- I've been very vague above wrt CUT/rolling/etc, because for the mere
point of knowing whether there is a public for a user-targeted
testing I think it doesn't make much of a difference
As I observed on #d-devel earlier on today, I think we will go nowhere
neither with hand waving, nor with head counts coming from narrow
examples of our own lives. What I've proposed is then to take the
chance of a user survey, on which I'm working, to have a few questions
that might help us knowing more asking directly our community.
If any of you have suggestions on what we can ask to users to help out
in this dilemma, please mail me. (Requirements are: no open-ended
questions and a maximum of 2-3 questions on this specific topic.)
Cheers.
[1]
http://upsilon.cc/~zack/blog/posts/2011/01/who_the_bloody_hell_cares_about_Debian/
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
* Stefano Zacchiroli [2011-05-01 15:43 +0200]: On Sun, May 01, 2011 at 02:06:19AM +0200, Pierre Habouzit wrote: I think that we should not do any trade off on the quality of rolling/testing/the-antechamber-of-stable, but instead raise the quality of unstable so that (which isn't *that* bad, unstable is rarely badly broken, and I know lots of stable releases of linux distributions that are in worse state than the average of unstable on the same set of packages…): YMMV, but I don't think the problem in using unstable directly is of average quality, but rather the fact that you've little shields against temporary yet severe breakages. Testing also has just little protection against severe breakage if it is frozen and updates need to go through rarely used suites. An example illustrates this quite well: When Lenny was frozen, a new upstream version of libpam-mount uploaded to sid. A fix for a release critical bug in libpam-mount/testing could thus not migrate through unstable and the maintainer uploaded it together with a security related fix to testing-security. The new package introduced a new bug, it segfaulted when logging in. This bug was not reported in the four days the package was in testing-security. After migration to testing, four according bugs were filed, two of them even within ten hours. I've put related dates, message-id's and bug numbers at the end of this mail[1]. Testing, OTOH, is really unique in that respect, with its mixture of fresh software and quarantine period. A 'frozen' requiring most updates to go through *-proposed-updates would make this quarantine period a lot less useful, and it would make circumstances like the one described above a lot more probable. One cause that testing-proposed-updates is not more widely used is that there is no good non-altruistic reason for a user to do so. More up-to-date packages are available in unstable and more tested packages are available in testing. Partly giving up the protection of the quarantine period just to get some packages a few days earlier seems to be a bad deal. Out of all this discussion, the challenge that interests me is whether testing (or something new, similar to it) can be targeted at final users without having significant differences in its lifetime depending on the release cycle of Debian stable. As many posts have shown, the difficulty lies in how (and if) we can do that without harming the stable release process itself. To avoid harming the stable release process, packages should to be tested by many users before they enter testing. The most used suite containing packages newer than testing is unstable. I think the migration of unstable to testing should stay as it is now, whether or not testing is frozen. If we want to add a new never-freezing suite 'rolling' targeted at final users, we should find a way to test packages in a sufficing way before they enter rolling. These packages would be newer than those in rolling or unstable, but adding a full suite above both does not seem to be reasonable. An non-selfcontained suite (like *-updates and experimental) between unstable and experimental could solve this. Unlike t-p-u, there would be a reason for users to opt-in to use this suite, since it would contains the latest non-experimental packages. The need to explicitly opt-in would help to ensure that pure unstable is sufficiently tested. Such a suite should be pinned to 500 by default to encourage using all packages from it rather than just picking specific packages, it should also only contain packages that would be uploaded to unstable if testing would not be frozen (both in contrast to experimental). After release, packages in it could migrate to unstable, either all at once or using a clever algorithm. In the following table, I only choose 'sid-updates' as name because it is short: - | not frozen |frozen - | sid| sid suites:| rolling| rolling | testing (equal to rolling) | testing (frozen) | stable | stable - | sid = testing/rolling | sid = testing migration: | no migration from sid-updates | sid-updates = rolling | t-p-u/r-p-u = testing/rolling | t-p-u = testing || r-p-u = rolling - In comparision to Raphael's proposal, the above would weaken the stability of rolling during the freeze a bit, but it would strengthen testing's stability. Maintainers would only need to support an additional release if they upload packages not targeted at the next
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 10:36:07PM +0200, Lucas Nussbaum wrote: On 01/05/11 at 22:17 +0200, Pierre Habouzit wrote: On Sun, May 01, 2011 at 09:35:07PM +0200, Lucas Nussbaum wrote: [ Note that my position is based on the assumption that we have a share of DDs interested in rolling similar to the share of DDs interested in stable releases. Unfortunately, it's very difficult to know where we stand regarding this. ] I'm assuming that releasing is what Debian is about (and fwiw if you read Raphael's proposal, it's for him too), meaning that rolling is a second class citizen here. Well, I disagree. I believe that Debian is about building an operating system. Whether we deliver it through stable releases, or through a rolling release, or both, is an implementation detail. Yes, I pushed the thinking up to the point that I /also/ (I never said /only/) want to run Debian on servers and that a Stable release is the sole thing I'd like to run on them. [...] There are other distros out-there that do rolling release only (gentoo, arch), note how none of them also do stable releases (I think gentoo used to tag their repository every now and then, but that doesn't make them releases, please, at least not in the Debian sense). I don't follow your reasoning. - I don't think that we should restrict Debian to servers managed by serious sysadmins. - Gentoo Arch don't do stable releases, OK. Why would it mean that we couldn't do it? It's not a reasoning, I'm saying, I'm fine if Debian doesn't do rolling releases and to point people towards them. I just note that non of the rolling-released distro do no stable releases, something that tends to comfort my opinion that rolling and stable releases are somehow incompatible. It's clear that we are not going to stop doing stable releases anytime soon. However, there seem to be some interest in the rolling release concept. The question is: can we (Debian) provide a rolling release with an acceptable increase in workload, and without compromizing the quality of our stable releases ? If yes, why shouldn't we do it? Well, if you hadn't guess, I think it will increase workload and worse divert attention from what I think is a more important goal. But really what I'd like to see is numbers and compelling reasons to start all that CUT/rolling thing, because that's missing completely from the thread, I'm still not understanding why we need anything like that. You don't do something like that because it's hype, you do it because it's badly needed, and well, why? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501204833.gf20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 10:41:07PM +0200, Stefano Zacchiroli wrote: On Sun, May 01, 2011 at 10:08:46PM +0200, Pierre Habouzit wrote: Those are real users from real life. I'm not saying we-re representative of a majority of Debian Users, but unlike all the handwaived users we've read about in this thread, those are real. First of all I think you should concede that the exercise you're asking us to do cannot be done as easily as you did yours. You've been able to mention real users of an existing distro, you are asking others to provide evidence of users of a thing that does not exist yet; quite challenging... So you do have an inherent advantage, but let me try nonetheless. I don't concede that. I've read your mail, and to sum up you say: I've been in contact with lots of people interested into testing, Okay fine, I buy that, I won't call you a liar. So the next question is why your mail doesn't answer that. I still think that rolling is a bad idea, until you've proven me that it's the sole way to address a real life issue/need/itch. So why do Aptosid/Sidux/... exist, why do people think we should sell testing more? You don't answer that and it's critical to know it. IOW what does having CUT/rolling fixes please. FWIW I see one problem with the current testing, tied to the freeze, which is that a 6-months freeze means that we skip a release for all those projects that release twice a year, and those are many. Which is annoying for some of our users (gnome releases when it's not gnome3 are pretty sound e.g. it's not really bleeding edge that harms), and even more for packagers because it's harder not to package all upstream versions, it means that the upgrade is harder to deal with. But *that* I think can be adressed with a better experimental (using PPA, but we discussed that already and I think it's a consensus). And for that I think that rolling isn't the solution because of the entry-point issue I talked elsewhere: You still need to update testing during the freeze. And the larger the project, the higher the probability is that: - users will want the last version available; - you will have updates to send during the freeze. I surely miss other uses cases, so please enlighten me. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501210057.gg20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, 01 May 2011, Carsten Hey wrote: Testing, OTOH, is really unique in that respect, with its mixture of fresh software and quarantine period. A 'frozen' requiring most updates to go through *-proposed-updates would make this quarantine period a lot less useful, and it would make circumstances like the one described above a lot more probable. One cause that testing-proposed-updates is not more widely used is that there is no good non-altruistic reason for a user to do so. More up-to-date packages are available in unstable and more tested packages are available in testing. There's a good reason to use testing-proposed-updates during freeze, it fixes security and release critical bugs that are present in testing! So if we tell users to use this repository, we're going to have some users (I upgrade my servers to testing during the freeze and I would enable it if it was generally advised for beta-testers). But yes there might be some unrelated regressions from time to time. There's a reason why it's not labeled stable yet. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501210748.gd18...@rivendell.home.ouaza.com
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 11:07:48PM +0200, Raphael Hertzog wrote: On Sun, 01 May 2011, Carsten Hey wrote: Testing, OTOH, is really unique in that respect, with its mixture of fresh software and quarantine period. A 'frozen' requiring most updates to go through *-proposed-updates would make this quarantine period a lot less useful, and it would make circumstances like the one described above a lot more probable. One cause that testing-proposed-updates is not more widely used is that there is no good non-altruistic reason for a user to do so. More up-to-date packages are available in unstable and more tested packages are available in testing. There's a good reason to use testing-proposed-updates during freeze, it fixes security and release critical bugs that are present in testing! So if we tell users to use this repository, we're going to have some users (I upgrade my servers to testing during the freeze and I would enable it if it was generally advised for beta-testers). But yes there might be some unrelated regressions from time to time. There's a reason why it's not labeled stable yet. That's just semantics, Carsten mail is very good, and sums up what I've said elsewhere in a very clean way. The problem is, you need to entry points, one for testing as we know it, one for rolling. If you use t-p-u for testing and unstable for rolling, or unstable for testing and rolling-updates for rolling is just bikeshedding. The result is some of the users will use unstable and help testing, the other sort will run rolling-updates or rolling. So basically you split our users in two non overlapping sets, meaning that you divide coverage and tests. How come is that in the distribution interest?! I think it's not, I think it's resource squandering. So please, what is so useful and important that we wast our precious resources here, have two inconciliable Debians at once? Because users want it doesn't fly. I couldn't care less, I'm interested about *why* they want it, not the mere fact that they do. Because when you know why they want it, maybe there will be better answers that don't make releasing even more brittle and burn even more people out. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501211721.gh20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On 2011-05-01, Stefano Zacchiroli z...@debian.org wrote: - I've talked at several trade shows and conferences with developers of rolling distros based on Debian (in particular: Aptosid/Sidux and Linux Mint Debian Edition). They usually claim they have built those distros because Debian wasn't offering such feature (yes, they should have probably tried do that in Debian, NIH syndrome exists, yada yada, not to mention the fact they might have said that to me because they wanted to be kind towards Debian). It must have been half a dozen people. Maybe you could outline what they add to Debian to make it more useful. I know that Sidux used to provide a kernel and stopgap solutions to bad bugs in unstable where the maintainers needed more time or looked for more sane solutions. But that's more from casual searching, so maybe we could clear that up first? My guess is that those users could also easily use testing and that the effort would better be spent to fix bugs in testing more quickly. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnirrjj9.cpe.tr...@kelgar.0x539.de
Re: Bits from the Release Team - Kicking off Wheezy
Hi Ste(ve|fano), On Sun, May 01, 2011 at 12:02:47PM -0700, Steve Langasek wrote: On Sun, May 01, 2011 at 04:17:10PM +0200, Stefano Zacchiroli wrote: JFYI, Sean and Raphael have taken DEP number 10 They have? I haven't seen mail to debian-project about this, which is what http://dep.debian.net/deps/dep0/ requires? (The chance of a collision here is quite small of course, but I'm still confused how they have taken this number without following the procedure.) Mea culpa. I did not realize there was an official procedure for this, as I found and followed the howto[1] link from the main page on dep.d.n. I figured that it would be better to have some content in there before making any kind of announcement. I'll drop a line to -project as well as put something in the howto referencing the DEP-0 procedure. sean [1] http://dep.debian.net/depdn-howto/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501212118.ga23...@cobija.connexer.com
Re: Bits from the Release Team - Kicking off Wheezy
Hi Stefano, On Mon, 2 May 2011 06:41:07 AM Stefano Zacchiroli wrote: On Sun, May 01, 2011 at 10:08:46PM +0200, Pierre Habouzit wrote: Those are real users from real life. I'm not saying we-re representative of a majority of Debian Users, but unlike all the handwaived users we've read about in this thread, those are real. First of all I think you should concede that the exercise you're asking us to do cannot be done as easily as you did yours. You've been able to mention real users of an existing distro, you are asking others to provide evidence of users of a thing that does not exist yet; quite challenging... So you do have an inherent advantage, but let me try nonetheless. During last year: - I've talked at several trade shows and conferences with developers of rolling distros based on Debian (in particular: Aptosid/Sidux and Linux Mint Debian Edition). They usually claim they have built those distros because Debian wasn't offering such feature (yes, they should have probably tried do that in Debian, NIH syndrome exists, yada yada, not to mention the fact they might have said that to me because they wanted to be kind towards Debian). It must have been half a dozen people. On the contrary, sidux/aptosid/$whatever exists, in my opinion, because Debian sid is a very useful and usable software collection with a small army of real communicative people who are motivated to care for it and keep it working well. Personally, I never involved myself in those groups to try and solve any kind of deficiency in Debian, but rather to get with people to learn about Debian, help it function better and to solve or advise about occaisional problems associated with using constantly changing software. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105020713.54829@otaku42.de
Re: Bits from the Release Team - Kicking off Wheezy
On 01/05/11 at 22:48 +0200, Pierre Habouzit wrote: On Sun, May 01, 2011 at 10:36:07PM +0200, Lucas Nussbaum wrote: It's clear that we are not going to stop doing stable releases anytime soon. However, there seem to be some interest in the rolling release concept. The question is: can we (Debian) provide a rolling release with an acceptable increase in workload, and without compromizing the quality of our stable releases ? If yes, why shouldn't we do it? Well, if you hadn't guess, I think it will increase workload I agree. The question is: will the increase of workload be worth it? and worse divert attention from what I think is a more important goal. Your point is basically we should discourage developers to do something else than working on getting the next stable release out. I don't buy it. I'm sure that we are all very good at procrastinating the things that we don't want to do, whether the excuses are provided by Debian or by other projects/hobbies. Developers who are not interested in helping with the release will just do something else. We can send a clear message to developers that getting the stable release out should be considered more important than working on rolling or on one's other pet projects, but besides that, I don't think that there's much more to do. But really what I'd like to see is numbers and compelling reasons to start all that CUT/rolling thing, because that's missing completely from the thread, I'm still not understanding why we need anything like that. You don't do something like that because it's hype, you do it because it's badly needed, and well, why? There's a clear user demand for rolling releases. For evidence, one can look at the usage of Debian testing or unstable which clearly goes further than the DD community. Or at the quickly growing market share of ArchLinux. Or at the interest in LinuxMint and Aptosid. Personally, I'm surrounded by [advanced] Ubuntu users who would be interested in something *slightly* harder to use, with more recent software. I think that Debian is in a perfect position to provide a rolling release with marginal additional work, since we already have testing to build on. Benefits for Debian: - attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (developers, free software contributors), thus interesting to work with. Some of them could become Debian contributors. And even if they don't, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian's -- some areas of Debian could use more testers]. - give back to the free software world by providing a platform where new upstream releases would quickly be available to users. Since users would be able to test new upstream releases earlier, they would be able to provide feedback to upstream devs earlier, contributing to a shorter feedback loop. - get back some attention that is currently taken away from Debian by derivatives. This is important to carry our /political/ messages, which are not necessarily carried out by our derivatives. Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501213947.ga4...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 11:39:47PM +0200, Lucas Nussbaum wrote: On 01/05/11 at 22:48 +0200, Pierre Habouzit wrote: On Sun, May 01, 2011 at 10:36:07PM +0200, Lucas Nussbaum wrote: It's clear that we are not going to stop doing stable releases anytime soon. However, there seem to be some interest in the rolling release concept. The question is: can we (Debian) provide a rolling release with an acceptable increase in workload, and without compromizing the quality of our stable releases ? If yes, why shouldn't we do it? Well, if you hadn't guess, I think it will increase workload I agree. The question is: will the increase of workload be worth it? and worse divert attention from what I think is a more important goal. Your point is basically we should discourage developers to do something else than working on getting the next stable release out. I don't buy it. I'm sure that we are all very good at procrastinating the things that we don't want to do, whether the excuses are provided by Debian or by other projects/hobbies. Developers who are not interested in helping with the release will just do something else. We can send a clear message to developers that getting the stable release out should be considered more important than working on rolling or on one's other pet projects, but besides that, I don't think that there's much more to do. No I say we're already not that good for Stable releases, why would we chose to be even worse. Would releasing be just a breeze my discourse would be very different. I think we're not that good at releasing that we can sustain rolling. 6 months of freeze is just too long. But really what I'd like to see is numbers and compelling reasons to start all that CUT/rolling thing, because that's missing completely from the thread, I'm still not understanding why we need anything like that. You don't do something like that because it's hype, you do it because it's badly needed, and well, why? There's a clear user demand for rolling releases. For evidence, one can look at the usage of Debian testing or unstable which clearly goes further than the DD community. Or at the quickly growing market share of ArchLinux. Or at the interest in LinuxMint and Aptosid. Personally, I'm surrounded by [advanced] Ubuntu users who would be interested in something *slightly* harder to use, with more recent software. I think that Debian is in a perfect position to provide a rolling release with marginal additional work, since we already have testing to build on. Benefits for Debian: - attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (developers, free software contributors), thus interesting to work with. Some of them could become Debian contributors. And even if they don't, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian's -- some areas of Debian could use more testers]. I think those can use unstable, and if they use rolling, I think I already proved or at least explained why those don't contribute to the stable in being, but rather the N+1 one. Which is probably not bad, but not the most urgent thing. - give back to the free software world by providing a platform where new upstream releases would quickly be available to users. Since users would be able to test new upstream releases earlier, they would be able to provide feedback to upstream devs earlier, contributing to a shorter feedback loop. Why doesn't unstable fit that? - get back some attention that is currently taken away from Debian by derivatives. This is important to carry our /political/ messages, which are not necessarily carried out by our derivatives. *I* (but that's personal) don't care about that. I don't find that a compelling argument. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501214614.gi20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
Hi On Sunday 01 May 2011, Philipp Kern wrote: On 2011-05-01, Stefano Zacchiroli z...@debian.org wrote: - I've talked at several trade shows and conferences with developers of rolling distros based on Debian (in particular: Aptosid/Sidux and Linux Mint Debian Edition). They usually claim they have built those distros because Debian wasn't offering such feature (yes, they should have probably tried do that in Debian, NIH syndrome exists, yada yada, not to mention the fact they might have said that to me because they wanted to be kind towards Debian). It must have been half a dozen people. Maybe you could outline what they add to Debian to make it more useful. I know that Sidux used to provide a kernel and stopgap solutions to bad bugs in unstable where the maintainers needed more time or looked for more sane solutions. But that's more from casual searching, so maybe we could clear that up first? [...] This perception is correct, we directly use Debian unstable/main[1] and only augment it with custom packages[2] (live framework, kernel, some configuration helpers, artwork) and (try to) provide hotfixes for serious (long(er) term issues). We don't provide updated packages for newer upstream versions just because they are available or would be nice to have; retaining an untainted upgrade path is a core priority. Of course, times of (long) freeze aren't particularly nice, both from a user's (boring package versions) and developer's (getting detached from upstream development (experimental is not really useful, as it lacks any form of integration efforts - which directly results in difficult unfreezing situations, due to lots of accumulated changes happening at once and often with little coordination)) points of view. Regards Stefan Lippers-Hollmann (aptosid developer) [1] releases are snapshots of the repository state (Debian and our own) of the release date, installed systems track unstable directly[2]. [2] http://aptosid.com/files/misc/sources.list.d/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105012349.35012.s@gmx.de
Re: Bits from the Release Team - Kicking off Wheezy
On 01/05/11 at 23:46 +0200, Pierre Habouzit wrote: Benefits for Debian: - attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (developers, free software contributors), thus interesting to work with. Some of them could become Debian contributors. And even if they don't, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian's -- some areas of Debian could use more testers]. I think those can use unstable, But unstable is a development branch not targeted at being used by 'standard' users. and if they use rolling, I think I already proved or at least explained why those don't contribute to the stable in being, but rather the N+1 one. I think that you are mixing two things here: 1) whether we want to turn testing into a rolling release 2) what do do with the 'rolling' suite during freeze (fork a 'frozen' branch at the beginning of the freeze ? freeze rolling ? start by freezing rolling, then after a few months, fork 'frozen' and unfreeze 'rolling'?) Which is probably not bad, but not the most urgent thing. - give back to the free software world by providing a platform where new upstream releases would quickly be available to users. Since users would be able to test new upstream releases earlier, they would be able to provide feedback to upstream devs earlier, contributing to a shorter feedback loop. Why doesn't unstable fit that? Because unstable is a development branch not targeted at being used by 'standard' users. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501221042.ga5...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 11:17:21PM +0200, Pierre Habouzit wrote: The problem is, you need to entry points, one for testing as we know it, one for rolling. snip So basically you split our users in two non overlapping sets, meaning that you divide coverage and tests. How come is that in the distribution interest?! I think it's not, I think it's resource squandering. Yes, and it *will* split up users into two camps, just like any parallel system of development would. I don't think that's necessarily bad, since some users/developers would want to be split because of diverging interests anyway. The question is, can it be done in such a way as to keep the level of attention and QA that we want to have on the candidate releases while we're preparing them. I completely agree that it's a non-starter if we can't address that. So please, what is so useful and important that we wast our precious resources here, have two inconciliable Debians at once? Because users want it doesn't fly. I couldn't care less, I'm interested about *why* they want it, not the mere fact that they do. Because when you know why they want it, maybe there will be better answers that don't make releasing even more brittle and burn even more people out. As the release process drags on, non-release related activity decreases, which I'm suggesting has a detrimental effect on the project (including the *next* stable release to a certain extent) for a number of reasons previously outlined. If the union of people who are interested in using and/or contributing to the respective parts (stable prep vs unstable) is considerably larger than the intersection, then to me it makes a lot of sense to explore whether there's a better way we can serve both groups at the same time. sean -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501224521.gc23...@cobija.connexer.com
Re: Bits from the Release Team - Kicking off Wheezy
* Pierre Habouzit [2011-05-01 23:17 +0200]: On Sun, May 01, 2011 at 11:07:48PM +0200, Raphael Hertzog wrote: On Sun, 01 May 2011, Carsten Hey wrote: Testing, OTOH, is really unique in that respect, with its mixture of fresh software and quarantine period. A 'frozen' requiring most updates to go through *-proposed-updates would make this quarantine period a lot less useful, and it would make circumstances like the one described above a lot more probable. One cause that testing-proposed-updates is not more widely used is that there is no good non-altruistic reason for a user to do so. More up-to-date packages are available in unstable and more tested packages are available in testing. There's a good reason to use testing-proposed-updates during freeze, it fixes security and release critical bugs that are present in testing! I should have highlighted the word most. With the present scheme, updates to testing that need to go through t-p-u are exceptions. So if we tell users to use this repository, we're going to have some users (I upgrade my servers to testing during the freeze and I would enable it if it was generally advised for beta-testers). The libpam-mount example was not a 100% fit because it went through testing-security and not through t-p-a. The segfaulting package migrated to testing on the 28th of November 2008. Just five months earlier the Testing Security team announced[1] on d-d-a that they provide nearly full security support (the kernel was missing at this time). I doubt that generally advising to add t-p-a would significantly work out better than the testing-security announcement. [1] http://lists.debian.org/debian-devel-announce/2008/06/msg6.html But yes there might be some unrelated regressions from time to time. There's a reason why it's not labeled stable yet. Not being able to login is more than just a unrelated regression. Quote from #507199: | for users with encrypted volumes there is NO LOGIN POSSIBLE! it | renders my system unusable. without the crypted volumes, there is no | need to login at all... ( now i am glad that root does not have any | encrypted volumes! ) | | login is only possible, if all crypted volumes for the user are | commented out. With sudo instead of a real root account he would have needed to start a rescue system to be able to login again. The problem is, you need to entry points, one for testing as we know it, one for rolling. Actually, we need two entry points each, a default one and an exceptional one. The latter ideally requires a special permission from a release team before an upload. For testing these are unstable and testing-proposed-updates. If you use t-p-u for testing and unstable for rolling, or unstable for testing and rolling-updates for rolling is just bikeshedding. The result is some of the users will use unstable and help testing, the other sort will run rolling-updates or rolling. So basically you split our users in two non overlapping sets, meaning that you divide coverage and tests. The result of this bikeshedding has an influence on how big these sets are. How come is that in the distribution interest?! I think it's not, I think it's resource squandering. I'm undecided if rolling in general is a good idea, but I think unstable-proposed-updates (the name does not matter, but the concept) would be a good thing, with or without rolling. This possible non-selfcontaining suite just happens to fit rather good into the rolling concept. I also think using t-p-u per default to feed testing would significantly lower the quality of a frozen testing (with an other color and thus different sized sets, it should in my opinion work though). I'm interested about *why* they want it, not the mere fact that they do. Because when you know why they want it, maybe there will be better answers that don't make releasing even more brittle and burn even more people out. I guess it's mainly about new upstream versions (firefox, chromium, gnome and so on) they read in the news about, saw on other computers or really contain features useful for the users. Moving backports.org to backports.debian.org and enabling automatic upgrades by default are steps in the right direction to address this (except for desktop environments). Supporting or even recommending to use all packages from b.d.o to make it feel like a rolling release would be nearly the opposite of how it is intended to be used now and I don't think it would make those users really more happy. So all in all, the scheme used to manage b.d.o seems to lack improvement potential from a users point of view :) An other way to use newer upstream versions is via chroots. With faster internet connections, larger hard disks, faster CPUs and a smaller size of a minimal Debian chroot, using a chroot to run a single application could become more worthwhile. With a frontend to configure such things, it could be used
Re: Bits from the Release Team - Kicking off Wheezy
Heya, Raphael, it would be so great to reply to messages in single mails instead of squeezing (are you release-themed, or what?) all of your answers into one mail. I'm really tired of chasing a specific answer From you through the whole thread. Raphael Hertzog hert...@debian.org writes: But I don't plan to work on any of those if the project does not agree to promote testing to something that can be advertised as usable by end-users and as something that we strive to support on a best-effort basis. What does a best-effort basis mean? Who is going to install a rolling release instead of testing? I cannot imagine a use case where this might make sense, and I haven't found any presentation of one by you. Marc pgpYD4XASJLPW.pgp Description: PGP signature
