Im adding the cut-team to the loop. Original message: http://lists.debian.org/debian-devel/2013/01/msg00082.html
On Thu, Jan 3, 2013 at 8:15 PM, Carlos Alberto Lopez Perez <clo...@igalia.com> wrote: > AFAIK there is already an ongoing effort to provide an usable updated > rolling release of Debian. > > http://joeyh.name/code/debian/cut/ > > http://cut.debian.net/ > > > Isn't this (more or less) what you are asking for? I watched the bof 2 years ago, and had it on my initial pre-draft, but since i didnt heard much about it and looking at the page/mailing list it looked dead so i removed it. Even the repository links [0] gave 404 [1]. After closer looking, there must have been some change in s.d.o that needs the url ended in / for the link to work [2]. So I guess is not that dead afterall, it has just not having enough attention after the freeze for obvious reasons. I have not tried myself, so i cant really talk. CUT is kind of more ambitious than what i was asking for, since it tries to provide a working installer as well as working snapshot of debian. Not sure of the criteria for the snapshot tho. Does it just look for a complete working dependence graph or does it look for RC bugs as well? The few people on the list seems happy with it. If this is working well, it needs a little more love on debian.org and a 'testing-cut' link in the repos pointing to latest cut, so it can be set on sources.list and forgotten. On Thu, Jan 3, 2013 at 11:45 PM, gregor herrmann <gre...@debian.org> wrote: > On Thu, 03 Jan 2013 19:18:27 +0100, alberto fuentes wrote: > >> The only ways to prevent this if you are running the more or less >> up-to-date testing are: >> * Pin packages with RC bugs on upgrade. This is: >> - Non trivial: it makes you understand how bad the bug is and know how >> the pinning system works > > No and yes. > > No, because apt-listbugs exists and provides a nice interface so users > don't have to care about pinning details for themselves. > > Yes, because from my very practical experience users are often > confused when apt-listbugs presents them a bug subject. > My point with this proposal is to make testing 'usable' for a larger audience. So yes, you agree with me, its non trivial to use. >> - Ineffective: its a matter of luck that the bug is found before you >> upgrade the package. In the worst case scenario, the package entered >> testing one second before you tried to upgrade and has not being broadly >> tested yet to find those pesky RC bugs. > > Pesky RC bugs are usually reported within few hours after they enter > unstable, no danger for testing here. I usually put off the whole upgrade when apt-listbugs reports some RC that I think it can hit me instead of pinning. I did not know the pinning was automatically removed when fixed, but I didnt want the latest of the latest that bad, so putting off the whole thing was okay for me... Even doing this I was hitted with about 3 bugs this year that affected my desktop experience badly. I would dig my own examples, but i think we can agree that testing is usable most of the time. Cases are rare, but it does happen from time to time. 'usable' intends to remove those rare cases. >> - Useless if you are trying to install a new package and the bug >> already hit testing > > Use apt-listbugs. apt-listbugs just will prevent me to install the software. Witch is so so. With 'usable' you still will be able to install a previous version of the software. So what i meant is, it's useless if you really want to install the software. On Fri, Jan 4, 2013 at 7:30 AM, Reinhard Tartler <siret...@gmail.com> wrote: > On Thu, Jan 3, 2013 at 7:18 PM, alberto fuentes <paj...@gmail.com> wrote: >> _Rationale_: >> In current state, stable has packages that are too old. >> Testing, as usable as usually is, occasionally breaks. It broke 3 times more >> or less this year to me. These breakages render a poor desktop user >> experience. > > Why did testing break for you? Why do you think that adding another > stage, in which packages migrate automatically after some time period, > will magically prevent that? > > I'm convinced it will not. You can help here much more by improving > testing instead of making our release process much more complicated > than needed. I think that these bugs will be caught up before it hits 'usable'. It will try to do so by being 2-4 weeks behind testing. Adding it between stable and testing will make it more complicated, i guess... but if this seems like nightmare for the release process, it could be added as a branch hanging from testing without anything else added. Thats it, just leaving it out of the chain stable <- testing <-sid I think it overall involves less work than other solutions and I fail to see how me helping in testing as you suggest would prevent testing being not suitable for all audiences greets! [0]http://lists.alioth.debian.org/pipermail/cut-team/2012-August/000344.html [1]http://snapshot.debian.org/archive/debian/20120713T212116Z [2]http://snapshot.debian.org/archive/debian/20120713T212116Z/ -- 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/calkubt5cnl-ywepwedhwv0dgxqcqeehoak0os4u3u0bfbyo...@mail.gmail.com
