> Hi,
>
> I think the company/ group of people who are supposed to
> create this distribution are called the quality control/testing
> group. This is theoretically composed of people who are not
> necessarily maintainers, so they do not have to worry about new
> software.
>
> Maybe this should be taken up with the people in charge of the
> testing/ quality assurance groups? Are the groups still active? Am I
> mis remembering things?
I think the job of maintaining and updating a separate parallel
distribution (integrating stuff from unstable into stable and making
approximately monthly releases) is a much bigger undertaking than what
the debian-qa group (as it currently exists) can pull off.
The debian-qa group currently seems to focus on fixing orphaned packages
and doing installation tests of "frozen" for major releases. I think
that is what it should be doing.
I think that a separate distribution based on stable would be best
handled as a separate project (perhaps a sub-project of Debian). This
would be the sort of thing that could work very well if it was organized
as a consortium of companies that wish to market an up-to-date version
of Debian to compete with Red Hat. It would involve a lot of time
consuming grunt work, which is best done by paid employees, so it would
fit well with Bruce's concept of using Debian as a base for commercial
distributions.
As far as the current set of volunteer maintainers go -- I'll repeat, I
don't think any of us have enough time to do a really, really good job of
maintaining a separate set of stable releases. That's were commercial
distributions such as Red Hat are going to kick our butt. We'll leap
ahead every six months or so when we do a major release based on the
stuff in unstable. But then our user base will be sort of left behind
for 6 months until the next major release. It's no surprise many users
will choose a distribution such as Red Hat which has enough (paid) resources
to put together up-to-date releases and updates on a tighter schedule.
Where we excel is in development - because we have so many maintainers.
Doing development is inherently parallellizable. Unfortunately, final
release testing and integration testing isn't -- that's best done by a
small close-knit teams. We don't really have any small close-knit teams.
That's a key reason we have so many debacles around the time we come
out with a major release. It's only the flexibility of our packaging
system that enables us to save our butts come release time.
I think it's time to 'fess up to the fact that we aren't really all that
good at building polished, refined, fully tested 'releases' that cut it
as 'product'. (no flames please)
But the raw output of what we do is awesome. If somebody wanted to
invest in doing the final polishing, testing, bug fixing, and releasing
-- they would be rewarded with a highly marketable product.
Cheers,
- Jim