Re: RFC: Debian Service Team

[Tom Lees <tom@lpsg.demon.co.uk>]

On Thu, 29 May 1997, Christian Schwarz wrote:

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

I wholly agree with this.

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

A good idea, but some developers may also need to be able to upload fixes.
Maybe through the Service Team (i.e. submit fixing patches to them, etc.).

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

Good idea.

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

Yes, this is good. One every 4 days is too fast.

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

What do we do about release naming. I propose we immediately rename the
"1.3.1", for example, to "1.3.1a", and immediately introduce the bugfix
from the frozen distribution after a short period (how short depends on
seriousness).

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

Agreed for hamm at least, after this it may be more acceptable. The
exception is documentation packages, such as doc-rfc, which are universal
to both distributions.

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

Agreed.

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

I would also propose automatic closing of a bug using a system which scans
the debian-(devel-)changes traffic, checking the installation reports.
This system should set the bug to a new state, "conditionally closed".
This should reduce the number of bugs left open simply because they were
forgotten about.

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

Again, documentation, java programs (java-lex, java-cup, etc.), and some
others (fonts) really are unaffected by the change to libc6.

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

Yes. I certainly would, as I generally end up tracking certain packages
in stable from unstable on some machines.

> 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

I agree, this is a silly policy. Criteria for uploads into stable should
be purely that it fixes _ANY_ bugs, and does not introduce new code
unnecesarily.

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

Exactly. This is why we haven't really needed to sort this out until now.

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

OK.

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

-- 
Tom Lees <tom@lpsg.demon.co.uk>			http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E  B8 A2 17 9D 4F 9B 89 D6
finger tom@master.debian.org for full public key (also available on keyservers)


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