Re: RFC: Debian Service Team

[Dale Scheetz <dwarf@polaris.net>]

On Thu, 29 May 1997, Christian Schwarz wrote:

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

Well, we certainly have no plans to pack up and go home after the 1.3
release ;-) I have always assumed the task would be continuous.

> 
> 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. 
> 
Well, although it isn't used for the purpose you suggest, there is already
a destinction between stable-updates and stable-fixed. It was my intention
to make the distinction clearer with this release. Packages intended to
fix bugs in stable would be uploaded to updates for testing. After testing
has verified the package the appropriate link is applied to stable-fixed.

> > 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.
> 
I'm not sure about what you say here. Every bug fix possible is moved into
frozen and tested where possible. Any policy that keeps bug fixes from
moving into the frozen distribution will only contribute to a bug filled
release. It is the goal of testing to find bugs and QA to get them fixed.
Only bugs that can't be fixed before the release and which don't effect
the "standard" distribution (or other visible packages). There is,
admitedly, an evolving criterion for making this decission, but the fact
that several people are involved in "making the decission" is helpful to
the process.

> 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)
> 
This is not the case, and not productive for coming to closure on a
release. During the frozen phase only bug fixes are allowed into the
distribution. Brian proposes a "short" list from time to time and, if no
strenuous objections are given and there is adequate support for
inclusion, those packages are moved into the distribution (often only
after they have been through a testing phase) and testing continues as the
release approaches.

>    - 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.
> 
I much prefer the updates -> fixed path for fixing problems with release
software. I also don't see much point to arbitrary schedules for, as yet,
undiscovered problems and their solutions.

> 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.) 
> 
While I certainly didn't take any of your comments as "directed against"
the QA/Testing group, your analysis is based on 1.2 experiences and
ignores the improvements to the stability of bo provided by this group. It
assumes that "critical" "ugly" bugs will get past the testing group, only
to be discovered after the release. Now I would never suggest that this is
impossible but I would suggest that the probablility is much lower than in
past releases.
We both agree that fixed packages in hamm can not necessarily propogate
into 1.3 and as hamm progresses toward its own release this will become
more an more obvious. Your suggestion to go back and fix 1.3 source and
rebuild in a 1.3 system creates a split in the version track creating all
the complexity of twin development.
Packages move from version to version within the context of the rest of
the development. Releases lock down that context, hopefully at a stable
position. 
I just don't think that managing a post release in the same fashion that
the development distribution is managed. Assuming someone (not me) could
find and manage the resources to do this, I would still suggest a less
torturous route than the one you propose.

Luck,

Dwarf
-- 
_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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