Re: Time to merge back ubuntu improvements!
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
<clopez@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 <gregoa@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 <siretart@gmail.com> wrote:
> On Thu, Jan 3, 2013 at 7:18 PM, alberto fuentes <pajaro@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/
Reply to: