On 28/04/2011 15:52, Raphael Hertzog wrote: > On Thu, 28 Apr 2011, Mehdi Dogguy wrote: >> | before | during | release | freeze | freeze >> | day+1 | dev period | | >> ——————————————————————————————————————————————————————————— | sid >> | sid | sid before | testing | testing (frozen) >> | testing==stable | stable | stable | stable >> ——————————————————————————————————————————————————————————— | sid >> | sid | sid after | testing | testing | >> testing | stable | frozen | frozen (new stable now) | >> | stable | oldstable >> ——————————————————————————————————————————————————————————— >> >> Is this what you have in mind? > > Yes (except you missed oldstable in the cell "before / release > day+1"). >
Right. It's not important for our discussion though. But, you're are right. >> How's rolling different from testing? (except that testing freezes >> from time to time… yes, I know, that's the main point of the >> proposal, but still, I want to know if there are other changes). > > It's not different. > Then I have a few remarks. I wrote them earlier today, but then wondered if my table was correct… So, I kept them in a private draft: Philip mentioned some problems with this approach, which are listed below. There are other issues I want to mention here (you may judge them as minor, but let's see): 1) At the beginning of the developement cycle, (with the new plan) you start from testing, and not the new stable. So, you don't start with a base that's rc-bug free, or at least, as polished as the new stable is. 2) During the freeze, you're killing an important step in the Release process which is "the testing". Packages that move from sid to testing are tested by a huge user base (sid users), and then double-tested by testing users. Problems are seen in sid first and stopped from migrating if there are issues. During the freeze, we try to avoid using testing-proposed-updates as much as possible, because fixes that are pushed through t-p-u are not tested enough. We really try to use it when it's really not possible to go through sid. And, it's too late when the t-p-u fix lands in testing because it might require some work to get things fixed again (if it has some regressions ; if it breaks other packages ; etc…). 3) All updates to frozen have to be made through $codename-proposed-updates. That isn't great because we don't test fixes uploaded there hard enough. Now, IMHO, #1 is a sad thing and a pity. #2 is crucial during the freeze period. and #2 and #3 might imply longer freeze period. The fact that we "start the dev cycle with the new stable" and that "sid and testing are used to test the future stable" is what makes the quality of our stable releases outstanding! (IMHO). So, your proposal isn't really about "rolling", that's just changing the name of something that exists already. It's not new. What's new is "frozen"! The fact that testing will never freeze is just a by-product of frozen being used to create the future stable. And as Phil said, it requires adding a *lot* of people on "frozen" to make this viable. I *think* that advertising your proposal as "frozen" will make things clearer for everyone, and reflects better where change is done. Having that said, I do agree with Zack when he says that advertising it as "rolling" might have a positive effect on our users. But, okay, that's a matter of asking FTP-folks to add a symlink "rolling → testing". But, let's go back to the original problem. We want something to use for everyday, that works, that's mostly stable (not in the sense of "stable release" but rather "doesn't have much issues"), etc… Testing works¹, and works great (IMHO). A lot of people want a testing suite that never freezes. And your proposal is one way to get that done. There are other ideas though. The real problem (and the obvious one) isn't the freeze… but rather its duration! We have to try to make freeze periods shorter. If the freeze lasts² two or threee months, it's not a big deal… the freeze becomes quite a burden when it lasts six months. We don't care (almost) about the number of RC-bugs during the dev cycle… and that's one of the issues that cause longer freeze periods. Why not working on this side? ¹: Well, you can't say no since "rolling" *is* "testing" :) ²: No, 3 months isn't 25% of $dev-cylce > 1y. > There are other possible changes but I want to discuss them separately > because even without those changes, the testing without freeze is a > worthwhile goal in itself. > > Still, since you seem to insist, here are ideas I'd like to > investigate: > Well, you asked us to comment on your proposal… > - reduce the set of architectures required for migration to testing to > i386/amd64/armel and have buildd of other architectures prioritize > missing builds in testing over missing builds in unstable (freeze > should be enough time even for slow arches to catch up and FTBFS on > already release architectures is still RC) > It depends on the architecture (the ability to catch up)… but I'll let this question to wb-adm folks. > - be less strict and keep old binaries (and thus 2 versions of the > same source package) in testing. This applies in particular for > libraries going through SONAME changes and which can happily coexist > during a transition. We do that already for big transitions (examples are ffmpeg and openssl). The next Gnome transition will need something like that for some libraries too. > Re-enable the strict requirement a few months before freeze, and get > rid of the old binaries/versions during freeze (eventually dropping > any package which has not been updated if required). > We don't forget about old binaries when the transitions is done. We keep working on reducing the number of reverse dependencies to zero to be able to remove the old binary. It worked quite well up to now. > - allow/encourage usage of t-p-u to rebuild unstable packages that are > ready to transition except for the fact that they are entangled in a > transition > In most cases, we can workaround this doing some britney hinting when some pacakge is needed but has an RC-bug (it's rare though). When it's entangled in a transition, we try to get the transition done quickly. But, I agree that we can make use of t-p-u more often, when needed. Except that it's not needed everytime… and it's mostly relevant when the pacakge fixes an RC bug or security bug. ymmv though. > - have different level of RC bugs: there are RC bugs that are > acceptable in rolling that are not acceptable in stable, I'm thinking > in particular of FTBFS (and even more for FTBFS which affect non-common > architectures) > But that's saying that some architectures are more important than others. And Debian doesn't (yet) prioritize an architecture over another one. If an architecture is largely lagging behind, it becomes obsolete and we try to find for it a new place. Ensuring the same level of quality among all the architectures is the Debian way… I'm not sure that we can get concensus on this change. icbw though… > > Do not confuse those ideas with the current discussion to introduce > rolling as a non-freezing testing. > As said above, the idea is to introduce a "frozen" suite, and this has as side-effect a non-freezing "testing" :) 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/4db97f2d.8030...@debian.org