[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Drop testing



#include <hallo.h>
* Gergely Nagy [Sat, Oct 23 2004, 10:44:58PM]:

> >  - 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
 - 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".

> 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?

> 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).

> willing to do the work neccessary for the release are already trying to.

Yeah... with Testing overhead throwing stones in their way.

> 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.

> >    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.

> 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.

Regards,
Eduard.
-- 
Der klügere gibt nach, der andere bleibt bei Outlook.



Reply to: