The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Debian Service Team

On Sun, 1 Jun 1997, Dale Scheetz wrote:

[snip]
> 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 agree partly. A few points though:

1. It has been pointed out in the past that "rex" is obsolete if
"rex-fixed" exists. Thus, perhaps we can use "rex" instead of "rex-fixed"
in the future (actually, replace "rex" with "bo" :-) to save some disk
space.

2. Testing files from "rex-updates" has one problem: There is no
"Packages.gz" file for "rex-fixed"+changes from "rex-updates". Thus, it's
hard to detect inconsistencies in the archive, as unresolved dependencies,
for example.

3. Why do you consider my proposal with the "stable-frozen" directory as
too complicated? This should only affect Guy's installer script (he's the
only one that could complain about it being to complicated :-)

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

:-) Yes, I think we both want nearly the same, though are ways to solve
the problems are a bit different (at least, they look different). So, what
do all the others think?

But please don't let us forget the main idea: I thought of a group of
maintainers "maintaing the stable release". IMHO, that would be an 
advantage over the current development process. I don't think most
maintainers (including myself :-) do really care about the stable release
when it's out of the door. 

Just look around at all the mails on our mailing lists: There are lots of
mails where people point out bugs still existing in "frozen" but the fixes
will likely not be included in 1.3 because of the (IMHO very good) upload
policy for frozen now. (That's ISDN-utils, X, NIS, etc.) If 1.3 is out
people will install "hamm" and continue development and forget about "bo".
(This may sound negativ but it was this way for "rex".)

Of course, that's a little more work to do than what we have now. But we
would get the advantage of a "much better stable release." And I don't
think that would be important for all our users.

And I think that's our main difference: you (Dale) think (at least that's
what I read from your mails in this thread) that once 1.3 is out there
should not be much changes to it, just major security fixes, but no minor
bug fixes. But I still think it would be good to have a few minor bug
fixes included in 1.3.x too.

So, what do the others think about it?


Thanks,

Chris

--                 Christian Schwarz
Do you know         schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian GNU/Linux?    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.debian.org   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 .