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: Quality: some thoughts on achieving it (long)



>         When a release is prepared, a new version of the
>         distribution, parallel to stable and unstable, is made
>         by copying unstable to frozen. No new packages are
>         accepted into frozen, and new versions are accepted only
>         if they fix bugs -- the upload procedure for frozen is
>         the same as for stable. Unstable continues to accept
>         any new packages and versions of packages.

For 1.2, the upload procedure for frozen was actually the same
as that for unstable.  I do believe, though, that it should be
as you say where no package goes into frozen unless it fixes
bugs.

There is also the case of dealing with new code.  If a new upload
is a new upstream version that contains new features as well as
fixes old bugs, what happens?


>         Our methods for deciding when to make a release have
>         been flaky. Our goal is to make a release every three
>         months, but that we haven't ever done it. For the
>         previous release, and for the current one, we have an
>         official list of goals, which is modified during the
>         development of the next release.

I believe that the 3-month goal is achievable.  I think our
problem is that it in general wasn't started until a few weeks
before the end of that 3 month period (actually 4 months if you
count the overlap with the previous "frozen" release).

By the schedule I've been keeping, the end of January will mark
the end of month 1 with Bo being frozen at the end of month 2.

Do we want to start the three month period over again?  Note that
this will mean 5 months since the release of 1.2 before 1.3 is
released.


>         Proposal: Uploads need to be tested, and approved by
>         testers, before installed into stable or frozen. Unstable
>         will be used to share untested packages. Frozen should
>         be created by copying packages one by one from unstable,
>         after they have been tested and approved by testers.
> 
>         We need some dozens of people dedicated to testing. They
>         don't need programming skills, so we should have no
>         problem recruiting enthusiasts from debian-user. We
>         need two or three people who understand the packaging
>         guidelines and policy to organize the testing and the
>         testers, and to design testing procedures.

This sounds good to me.  The board will need to pick someone to
be in charge of it.  As you say, it will not be a small task.


>         This part is quite difficult, but if we can pull it
>         off, and I think we can, we might become _the_ best
>         tested free operating system.

Agreed.


>         Policy is decided by consensus, after discussion on
>         Debian mailing lists. The number of developers now makes
>         the shere volume on the lists huge, and discussions
>         tend to be endless.  Important statements are drowned
>         in chatter. Even if a consensus is reached, there is
>         no-one in charge to say so, and to add the new policy
>         to the policy manual.

Perhaps there should be a limit on discussions?  Say, as soon as
a decision is requested (this could be in the first email about
a subject or after it has been under discussion for a month) then
discussion will continue for 2 more weeks at which point the board
will make a decision.  If something is "vitally important", then
this time could be shortened to 1 week.


>         Existing policy is not enforced, except when someone
>         happens to notice it. It is probably not feasible to
>         conduct code reviews, but some parts of the policy
>         might be checked automatically.

Perhaps each policy should have someone responsible for
monitoring it.  This would logically be the most "pro" person
during the discussion.  There is a problem of transferring
this authority as people come and go, of course.  There is
also a problem managing such a widly distributed control
structure, but it should be doable.

Again, somebody would have to be an overseer.


>         Suggestion: Fix organizational and quality
>         assurance problems, and improve the policy and
>         packaging manuals.  Maybe write a separate packaging
>         guide for new developers.

Good suggestion, but a lot (not very exciting) work.


>         Have a new mailing list,
>         debian-devel-technical, where new and old developers
>         can discuss technical problems, without having to
>         deal with other issues, such as policy, publicity,
>         and planning of future releases.

Hmmm...  That's the way I always thought of "debian-devel".
Personally, I would prefer a different "debian-devel-policy"
list if anything.

Of course, the problem with new mailing lists is that it doesn't
help anything if everybody has to subscribe to all of them.  People
often post to one list when another would have been a better choice.
Recently, there has also been several occasions where messages were
posted to both debian-devel and debian-user.

A big help might be if someone agreed to moderate the lists.  This
would ensure that topics went to the right list.  It would also help
by refusing messages that were completely off topic or nothing but
flame or flame-bait.


>         Suggestion: Establish a CVS tree with all the source in
>         the distribution. Then any version will be recoverable.
>         If we standardize build environments, then binaries
>         will be recoverable too.
> 
>         I think CVS supports distributed development, and can
>         be configured to allow anyone to extract any version,
>         while restricting the people who are allowed to modify
>         the repository. Someone needs to study this, but the
>         BSD people do use CVS.

We use CVS here and it is really nice for concurrent development.
PHP is now developed this way.  Anybody can check out the source
over the internet.  Patches are submitted by mail through the author,
but once he trusts that person, they can be given access to submit
the patches directly.

I like this idea, but it will require a good deal of resources.  All
the source + all diffs are stored uncompressed.


New people:

It sounds like the board has to pick some people to actually run the
distribution.  So far, I count the following positions:

  project leader
  testing manager
  policy manager
  security manager

These people would be free to manage the pieces under them as they see
fit.  I cannot stress strongy enough that any decisions made by these
people must be PUBLICLY supported by all above them.  Privately, we can
disagree and suggest other courses of action, but publicly they must be
supported.  Without this, nobody will want to act for fear of being left
out to dry.  You CANNOT give responsibility without authority and expect
things to work out.

                                          Brian
                                 ( bcwhite@verisim.com )
                                             
-------------------------------------------------------------------------------
  Want to get it together?  We can help!  http://www.verisim.com/coordinator/



--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com