On Tue, 20 Apr 2004, Jeremy Hogan wrote:
> Good points, I've got them down now as well. FWIW he have a meeting this
> coming weekend/week with almost all RH personnel and these issues are
> going to come up loud and clear in front of everyone.
0. I assume s/he/we/. Here's a list
1. Print the August 15 2003 piece from Havoc Pennington on
rhl-devel-list@xxxxxxxxxx with subject line
Subject: Re: RHL Project Status? -- It appears stalled at the
and place it in each attendee's pre-meeting briefing folder
2. Print the January 10 2004 summary email from Gene C.
on fedora-devel-list@xxxxxxxxxx with subject line
Subject: fedora-d-rh] Re: QA process was Re: RPM submission procedure
and place it in each attendee's pre-meeting briefing folder.
Ask that each be read.
3. Brainstorm the action items and impediments preventing
completion of the stated goals of those aspirational pieces.
Winnow, and prepare a draft plan toward completion.
Circulate a review draft report and action plan to a subset of
the leading external beta RH testers for comment. Finalize
and implement it by dates certain.
- - - -
The posting in item 2 says in part:
On Friday 09 January 2004 19:22, Michael K. Johnson wrote:
> On Fri, Jan 09, 2004 at 02:42:38PM -0500, Gene C. wrote:
> > I am hopeful that the Red Hat folks will speak on the Fedora Extras
> > subject soon (their lack of comment is very noticeable). Some of this
> > discussion
>
> Well, I have two reasons for not commenting:
> o We don't have the CVS server up yet, and I believe that action
> should come before talk here.
> o I'm doing a lot of listening. Overall it is important to me that
> it not be so hard or confusing to do that people don't do it. I
> think that the rules can be simple and exceptions worked out on
> an individual basis; that's what we've done internally. We need
... and so on. Michael's right -- Running code counts; talk
is ... just talk. Passive listening has been possible for the
eight months since Havoc's post. The time for listening is
past. Solve it or say its not going to happen.
- - - - - - -
4. Assign someone to remove all remaining proprietary keying
on the Beehive and surrounding code by a date certain, and GPL
and release a tarball of it; The build submission tool clearly
is passing in build options; what is its backing store and how
is it maintained, beyond what is shown in the .spec, tarballs,
and patches. What content is in it? If computer assisted
control and reporting interfaces and integration to Bugzilla
or other process management tools exist, describe the API or
release the tools. Manual process documention (in electronic
form) to the extent it exists would be nice as well.
5. Assign someone to sanitize the internal QA protocols used
at RH for the (soon fully EOL'd) RHL line by a date certain,
and publish them electronically. Weeks and weeks of flamage,
and mish-mashed wiki could have been avoided on the mailing
lists with this guidance alone.
6. Assign someone to set up a CVS with RW priv's upon
application by a proposed committer, sufficient to do the
checkout and build (probably not on the RH internal production
builders), yielding testable 'as-is' results, by a date
certain, and meet the release date. Mark each such binary
with a Skull and Crossbones on install, but get a RW cvs with
builder access in place so non-RH people can do at least
familiarization with the RH builder approach.
- - - - - -
Much of this exists elsewhere by other Linux-ish projects --
Debian, Mezzanine, vserver+mach, cAos non-root one-off
pristine build chroots, the RHEL rebuild outlines -- more in
the (Free|Open|Net)BSD world; more still in general computing
[Tinderbox, the SF test farm, the Compaq and IBM public
buildfarms].
RMS and ESR may not see eye to eye, but each knows that free
access to sources is crucial; each knows that many approaches
to a problem and many eyes gets to better results faster.
[well... RMS may not agree that 'vi' is a better result ')]
Having implemented much of the foregoing over the last year
with the help of others, I know that I learned much from the
source availability of work of others. Won't Red Hat bring
its tools to the party?
My $ 0.02
- Russ Herrold
--
end
======================================+
.-- -... ---.. ... -.- -.-- |
Copyright (C) 2004 R P Herrold | Owl River Company
herrold@xxxxxxxxxxxx NIC: RPH5 (US) | "The World is Open to Linux (tm)"
My words are not deathless prose, | Open Source solutions ...
but they are mine. | info@xxxxxxxxxxxx -- Columbus, OH
gpg --keyserver pgp.mit.edu --recv-key 0x9B649644
gpg --list-keys 2> /dev/null | grep 9B649644
