Re: RFC: Debian Service Team

[Christian Schwarz <schwarz@monet.m.isar.de>]

On Wed, 28 May 1997, Dale Scheetz wrote:

> On Wed, 28 May 1997, Christian Schwarz wrote:
> 
> > (I hope this all doesn't sound to negative. I'll really impressed about
> > the stability of "bo" now. I'm just searching for a way how we can
> > improve the system in the 1.3.x releases.)
> > 
> I am not at all opposed to the "Debian Service Team" as you have described
> it, but you seem to have missed two points.
> First, the whole purpose of the QA and Testing teams is already focused on
> these problems and I don't see any indication that these teams are just
> going to disband when 1.3 is released.

Actually, I was thinking that the Test Team and QA Team could form the
Service Team as they are doing are great job right now. (Why didn't I
include this in the first mail? :-)

However, the current procedure of "stable uploads" is missing the "frozen"
feature, which would be necessary for the Test Team to continue. That's
why I suggest that we have a "frozen" distribution for each 1.3.x release. 

> The second point is that you seem to think that 1.3.x releases are a "good
> thing"(tm) and should be encouraged. From my point of view it is the task
> of QA and Testing to avoid as many minor post release versions as possible
> by uncovering problems before the release.

Just have a look at all the uploads in the last two weeks. There were lots
of (minor) bug fixes, which will be not included in 1.3 for good reasons
(it's simply to dangerous that new major bugs are introduced by minor bug
fixes). I totally agree to this policy. However, I think that these bug
fixes should go into 1.3.1, but they'll have to be tested too.

Let me try to make it clearer:

   - currently frozen is really frozen (now uploads are allowed, not even
bug fixes) and it will become "stable" in the next few days (unless a
critical release bug is discovered)

   - after that, we'll set up a new "frozen" distribution (will be the
same as "stable" at that point) were the Debian Service Team is allowed
upload bug fixes. Say we'll give them 2 weeks for that.

   - after that, "frozen" will become "Debian 1.3.1 release candidate" for
two weeks. In that time, the Testing Team should test upgrades (say
1.2->1.3.1 and 1.3->1.3.1) and new installs of 1.3.1, just as they are now
testing 1.3 (and IMHO they are really doing a great job now)

   - if "1.3.1 frozen" has passed this time without "release critical
bugs", it will become "stable" and labeled "Debian 1.3.1". This can happen
minimum 4 weeks after 1.3 is released. That's IMHO a good time, where even
CD-ROM vendors could think of pressing a new CD-ROM

There may be one single exception to this procedure, namely "major
security bug fixes". These should be allowed to be introduced within a
short time, but there should be surely done a minimum testing, if only for
dependency consistency.

> In general, moving packages from hamm to bo is a very bad idea. Asside
> from the fact that hamm is intended to use libc6 while bo is still libc5
> means that your additional team of volunteers are going to need to be
> ready to build, from source, packages on a bo system which include patches
> from the hamm package. This effort is additionally complicated when the
> package in question depends on package in hamm not found in bo. This can
> quickly turn into "porting hamm to bo".

That's exactly what I did _not_ propose. Perhaps I didn't make this point
very clear in the last mail, so I'll try it one more time:

    There will not be any "unstable frozen" or "unstable stable"
    uploads any more!

These are likely to introduce new bugs as most of the maintainers don't
run "stable" releases and it's really a hard job to seperate "bug-fix-only
releases" from "new-code releases". 

The maintainers make their usual "unstable" releases. We'll probably
change our bug tracking system so that bugs can be closed for each
distribution, as what has been proposed on this thread already.

When someone from the Service Team notices such a new release which fixes
some bugs (and perhaps introduces new code) he downloads the _source
package_ him/herself and _merges_ the bug fix changes only into the
version, that was included in the stable release before. Thus, it's not
just copying a package from "unstable" to "stable". Instead, the package
is assembled and generated two times, once for "unstable" by the
maintainer and once for "stable" by someone from the Service Team.

This has another very important advantage: As Debian 2.0 will ship with
libc6, it will be very hard for a maintainer to create a package both for
"stable" and "unstable". Since the developer from the Service Team will
have to compile the package on a "stable" system, this will not be a
problem.

> As most problems for a distribution deal with integration of the package
> into the current system, I feel that our efforts would be better focused
> on integrating hamm with hamm. The testing efforts have already born fruit
> and continued refinement of the QA/Testing cycle should continue to
> provide better benefit as time progresses.

But this will not solve our "unstable is more stable than stable" problem.
AFAIK, all our users would prefer it if more bug fixes would find their
way into stable.

And this will likely encourage even more users to send bug reports: Just
consider someone running a Debian 1.3 system in a few days. When he/she
discovers a bug and spends some time reading the docs how to report the
bug the report finally arrives at our bug tracking system and is usually
acknowledge or even fixed by the maintainers in a few days. However, this
bug fix will not go into stable (unless it's a security bug). Thus, the
user will see the effect from his bug report when Debian 2.0 is out,
that's way to long. Perhaps he/she'll never report a bug again. (I know
that the user could also get the fixed package from "unstable", but this
will be hard in "hamm" since the new libc6.)

> My complaint is not with the team idea but with its goals and principly
> the idea of moving bug fixes from hamm to bo.

I hope that I could clarify some statements which were not accurate in the
first mail. Anyways, this is just the feedback I wanted to have and I
think it's a good discussion so far. So please tell me if you still have
problems with that or if did not make everything clear enough. I really
appreciate _any_ comments.

Once again: My proposal is not directed against the Testing Team or QA
group. There are really doing a great job now. I was rathing thinking
about a way we can continue the excellent development process we have this
time when the release is out. (Actually, I was thinking that the Debian
Service Manager should be the same person as the Director of Testing--I
think that's you at the moment.) 


Thanks,

Chris

--                 Christian Schwarz
                    schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Don't know Perl?     schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
      
Visit                  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.perl.com     http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .