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: Modest proposal for successful releases

Christoph Lameter <clameter@waterf.org> writes:

> We might also think about restricting the distribution to a "core" that is
> tested well and then the non essentials of packages available but not
> under the strict release regiment. The distribution is just too big to
> test it all. Perhaps we could have stable/unstable releases only for the
> core release and maintainers of packages outside of the core release have
> their own responsibility of releasing stable/unstable packages whenever
> they wish?
> 
> I am very much opposed to restricting releases. If we want the mainstream
> to use Debian then we need regular releases. We need to work out a scheme
> to make this to a routine matter, have establish boundaries of authority
> and most of all simplify the matter as much as possible.
> 

Testing the "core" well is very good idea, but the distribution should
include the entire Debian set of packages.  I see 2 possibilities:

1.  Allow non-core developers to declare any release as ready for
frozen.  On the next freeze date, the most recent ready-for-frozen
version of each package will be moved to frozen.  Everything else
stays the same.  Developers may keep up with freeze dates and plan
releases accordingly.

2.  Follow the current procedure and allow all developers to be ready
for a frozen release.  Occasionally, this may mean pulling out a buggy
version of software and replacing it with an older working version.
Occasionally, developers will screw up and leave buggy versions in
frozen.

Under either method, I suggest that the testing emphasize the core
packages.  I suspect that many developers are willing to download
frozen and stay with it for a week or two, maybe a month, with only a
few non-frozen packages.  A de facto, non-rigorous, group of testers
results from that.  While #1 is a better approach, it requires
software support we do not currently have.  Method #2 is the approach
I suggest for the next release.

-- 
Kevin Dalley
kevin@aimnet.com


--
This message was delayed because the list mail delivery agent was down.