Re: Drop testing
> > > - unstable lockdown in the freeze
> > > - drop Testing and concentrate on work instead of wasting time on
> > > synching stuff. This eliminates the need for testing-security. See
> > > the last part of the paper for details.
> >
> > Doing this would result in many users who currently run testing fall
> > back to stable + backports or switch to another distro (ubuntu being a
> > likely candidate), which in turn, would result in less bugreports and a
> > less stable distribution. I, for one, wouldn't run unstable on my
> > parents' box, whereas testing proved to be quite reliable there.
>
> Ehm... what is wrong with running stable with backports? Why do you not
> install a such combination for your parents, what is wrong with that?
>
> - Missing few important pieces of software? Backport them
That takes some effort, especially when the new version in unstable
build-depends something bigger (I remember how hard it was to backport
some debhelper-using stuff without backporting all of perl - I do not
want to backport large pieces of unstable).
I do not have the time and energy to do those backports. Nor do I want
to upgrade half the system, nor is any security support for backports as
far as I know. Not officially, that's certain. (Yes, there isn't one for
testing either, but most of the case I can just grab the new package
from unstable and be done with it, while it's not that easy using
backports).
And even if I could do it theoretically, J Random User who is running
testing (because stable is too old) would not be able to do the
backports himself, whenever he needs something that is not backported
already.
> - all the packages are out of date? Well, though luck, this is what the
> whole issue is about. We need to release faster. Faster releases are
> only feasible if enough developers are motivated. They are motivated
> if Unstable is blocked and they must care about the release instead
> of working on stuff that makes "more fun".
No, they are NOT motivated if unstable is frozen. Did we get potato out
sooner than sarge? I don't think so (I may be wrong, though, it was
quite some time ago, and I was only lurking on the lists back then).
I do remember though, that I, as a mere mortal user was very upset about
unstable being frozen. I was running it to get the latest and greatest
software to play with, and when that excitement was taken away I felt a
bit cheated. You take away the toy, and whoever played with it, will
find another one, and since he's angry at you, probably not the
replacement toy you offer. (Ie, freeze unstable and I'm sure to go and
ignore Debian until there's a release - not that I do anything for the
release anyway, so it probably wouldn't matter, but still)
Getting people motivated should not be done in a way that makes - I hope
- many of them unhappy. To get back to your point - blocking uploads to
unstable will not make more people concentrate on the release. They'll
surely find something else that "more fun": it's not "release or
uploads", it's "release or uploads or something else". Those who do not
give a damn about the release, will not change their mind when unstable
is frozen.
Motivating people means getting them interested in the release, making
the process "more fun" for them. Or at least less of a nuiseance.
Freezing unstable will add to the annoyance level, instead of taking
away from it.
> > Freezing unstable will get you nothing compared to what we have now.
>
> What do we have? Release times reaching eternity? Testing, full of
> hidden / obscure bugs that have not been visible in Sid, or that are
> fixed in Sid but the update got stuck somewhere?
So you propose that those hidden / obscure bugs will only surface when
stable comes out, because there was no testing where they could be
observed earlier? How, pray tell, is that better? How was potato's
release any better than today? Except that the arches had to be kept in
sync "manually", without the help of testing.
For updates, that are important enough but got stuck, there is
testing-proposed-updates. Once there are (security or other)
autobuilders for testing, one uploads a package there, it gets approved,
everyone's happy. Little more work on the maintainer's part, but you'd
have to do roughly the same, would unstable get frozen. With the
additional burden on the release managers that they would need to check
EVERY proposed upload. Now they only need to check a smaller amount of
uploads, since unstable - and even some parts of testing - are open
still.
What you propose places even more burden on the release managers, even
more stuff to deal with. They will not get motivated by this, not at
all. Ways to make the current system better - THAT would be very
welcome. Like enhancing the logic of the testing scripts, which decide
when and how a package migrates from unstable to testing, so migrations
could get faster and large blocking stuff could be eliminated, that
would help the release. Placing burden on people who already have more
than enough to care and worry about won't help at all, methinks.
> > Those who don't care about a release, will not care that way either,
> > just their complaints will get louder and more frequent. Those who are
>
> How should they complain? "We cannot update foo in Sid because it has
> been frozen for three weeks now, nya, nya". The answer would be some
> analogue to RTFM (HTFR, help the f... release).
Yes, that would be an answer. And how would that help the release? Would
that answer make them more interested in a release? (No, they'd probably
go back to their regular work, giving thanks to $DEITY that they don't
have to care about their packages, since they won't get into sid anyway,
therefore they can use the time they'd work on packages to do their paid
work.)
> > willing to do the work neccessary for the release are already trying to.
>
> Yeah... with Testing overhead throwing stones in their way.
What kind of stones, if I may ask? And why not teach testing that
throwing stones is a Bad Thing, instead of hiding in a cave, hoping that
some day the blizzard that a frozen unstable generates goes away?
> > Remember, Debian is a volunteer project, you cannot force people to do
> > something they do not want to.
>
> Motivation is the only factor to make them do things. Having to care
> about the release in order to continue the "fun work" leads to
> motivation.
Nope. Making unstable does not force them to care about the release.
They'll find something else that statisfies them. If they don't want to
care about the release, you will not be able to force them.
> > > Testing synchronisation are not of pure technical nature, they are
> > > social problem, and so they should be solved by people and not
> > > scripts.
> >
> > Yes, testing synchronisation is not a purely technical matter. Nor is it
> > purely social, so the testing scripts, which automatically keep stuff in
> > sync, are a real help. On top of that, package maintainers coordinating
>
> They are overhead.
How so? A release needs all architectures in sync, testing does that for
us without much manual hackery. I don't see why it is so much an
overhead. Agreed, it does have _some_ overhead, since a package needs
time to migrate. But that's not neccessarily a bad thing. It's a
compromise, and as far as I see, a good and useful one. So far I didn't
hear _any_ convincing argument against it.
> > with each other (the social part) is welcomed too, and should be
> > encouraged. (And those who break a transition should be kicked in the
> > ass, so they won't try it again :P)
>
> What's the problem? If you feel bored, go to #debian-bugs and help
> fixing RC bugs. We could have a BSP every three days or so. There you
> will have semi-social contact and can motivate each other to do the
> actual work.
...and that can be done with testing in place, with all the benefits it
provides.
So far, the main complaint against testing is that sometimes packages
get stuck. *Duh*, so fix the problem that made them stuck. That might
need some social engineereing, as most of the time, stuckage is not
caused by technical problems. Would you want to push the same larger
update into a frozen unstable, you'd run into the very same problems
anyway.
--
Gergely Nagy
Reply to: