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: why this marketing stuff is important

On Fri, 15 Aug 1997, Craig Sanders wrote:

> i'd like to see them in bookshops too - but not at the price of
> completely destroying debian's dynamic update nature (which is, imo, one
> of debian's best features)

We can do both. For the retailer it is a matter of not changing the
release numbers. The way we deal with prompt fixes and updates has little
to do with what order they go into the stable distribution, so why assign
any numbers to those changes (outside the version numbering of the
packages themselves)? It isn't necessary.

> 
> i think that the difference in production time between CDs/books and
> our ftp site are *always* going to be an issue. it's just the nature
> of the beast. we can't hold up our releases indefinitely, but we can
> make some compromises to meet the needs of tangible-media publishers AND
> suggest alternative routes around the problem (like the subscription
> idea above).

We can support both.

When hamm passes through "frozen" and becomes "stable", if it is called
2.0 then a link to hamm from 2.0 gets created, along with hamm-updates and
hamm-testing. Packages that their maintainer thinks will fix problems in
hamm are directed for installation in hamm-testing. When they have been
"adequately" tested, they become candidates for hamm-updates. The
directory, hamm-updates, should contain a ChangeLog that contains the
changes registered against each of the packages found in hamm-updates, so
that users can easily identify which packages they need from updates and
which they can leave alone, without having to download the whole pile of
packages.

In this way there is never another release after 2.0 until the next major
release. (2.1 or 3.0 depending) At the same time, as soon as fixed
packages are tested, they can appear in hamm-updates for use by any user
that needs the fix. No scheduling is necessary, no release announcement
required. Periodic download of the ChangeLog will keep the user informed
of the new fixes as they come in. Maintainers should be encouraged to
inform users who made bug reports, when those bugs are fixed, and where to
find the fixed package. These folks should be encouraged to help "vet" the
package by testing it to see if their problem has been fixed.

It seems to me that this process provides the quickest path to fixing
problems with a release, while keeping any "public" numbers from moving
too fast for the retailer.

Does this satisfy your needs for timely fixes? I know that for some,
unstable is their first recourse to problems with the stable release,
while others want those fixes to propogate into stable. (Some of these
just can't be moved "down" into stable, because of dependencies on
unstable packages that will never move into stable {like libc6})

Waiting is,

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 .