Re: RFC: Debian Service Team

[Dale Scheetz <dwarf@polaris.net>]

On Sun, 1 Jun 1997, Christian Schwarz wrote:

> 
> Hi!
> 
> To cut down the long mails, let me summarize the results so far (please
> correct me something if I got something wrong):
> 
> It seams to me that we all agree in the major point: We should set up a
> process of how "stable" uploads could be performed more "organized" in the
> future, so that we don't risk introducing new bugs.
> 
> That's why I suggested the new team, but I agree that it's probably too
> much work for us to maintain "two separate distributions" (stable and
> unstable). 
> 
> So what about this "process":
> 
>  - "stable/" (that is "bo/" for Debian 1.3) always contains the latest
> 1.3.x version, that has been officially released. 
> 
>  - "stable-frozen/" (preparation) contains the "1.3.(x+1) frozen" tree,
> that is, it contains lots of symlinks into "stable" and a few "real files"
> 
>  - a "stable" upload would be placed into "stable-frozen". This will be
> allowed for three weeks
> 
>  - in the fourth week, no "stable" uploads are allowed (they are kept in
> incoming) 
> 
>  - after the fourth week, the "real files" from "stable-frozen" will be
> copied into "stable-updates" and symlinks are created in "stable" to
> reference these files. Then the "real files" in "stable-frozen" are
> replaced by symlinks into "stable"
> 
> 
> Consequences:
> 
>   - every "stable" upload will be tested for at least a week
>   - there will be a new Debian 1.3.x release every four weeks
>   - "stable" (together with "stable-updates") will always contain the
> latest released version
>   - "stable-updates" will only contain changed packages that simplify the
> upgrade process for users with FTP access
>   - there will not be a "stable-fixed" distribution what we have now
>   
> Disadvantages:
> 
>   - when files are moved from "stable-frozen" into "stable-updates", the
> mirrors will have to get these files again
> 
> 
> With this process, the Testing Team could continue their work on
> "stable-frozen" and assure that 1.3.x will be become better and better.
> 
> 
> Any comments?
> 
I understand the "problem" you are trying to fix here. I just think that
your solution is to complex. There is no reason to abandon and rename the
structures that are currently being used for rex. All we need to do is add
one more stop action step into the current situation.

Currently there is rex, rex-fixed, and rex-updates. If memory serves,
rex-fixed started out at the 1.2 release as links to rex. As fixes make
their way into rex the new packages are put into rex-updates and a link is
moved in rex-fixed from the package in rex to the package in rex-updates.
(Note, this may not be "exactly" how it works at the moment...)
All that needs to be added to this process is a testing validation before
the package is linked into the fixed directory. Treating bo-updates as an
"Incoming" directory for bo-fixed. The criterion for moving from
bo-updates to bo-fixed would be validation from the QA/Testing groups.

I suspect in some sense we see this in the same fashion. If we are only
haggling of what things are named then I have gotten to the point of "I
don't care" ;-) otherwise you should feel free to try to penetrate my dull
brain with the distictive difference between my view an yours. My primary
position is that unnecessary management complexities quickly escalate the
problem to a level of unmanagableness. Kiss (Keep it simple stupid), is a
good guiding principle here.

Back at'cha ;-)

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 .