Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Bug Report and Patchkit status
Message-ID: <1992Dec11.224735.23342@fcom.cc.utah.edu>
Keywords: time,school,need a life!
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1992Dec10.173351.11083@coe.montana.edu>
Date: Fri, 11 Dec 92 22:47:35 GMT
Lines: 254
In article <1992Dec10.173351.11083@coe.montana.edu> osynw@gemini.oscs.montana.edu (Nate Williams) writes:
>Here's the situation.
>
>I don't feel that I have done a very good job of keeping up the Bug
>Report and the Patchkit lately. Next semester is going to be worse, and
>I'm losing my network access on my 386BSD machine.
>
>Soooo,
> Does anyone in 386BSD land want to take over the Bug List
>co-ordination? I have been trying to put out another version of the
>patchkit, but because of lack of time and trying to re-format the old
>patchkit, I haven't added many patches. (I have LOTS of them, and more
>are coming every day) Someone who has more time than me needs to take
>over the co-ordination if this is going to be kept up to date. I don't
>mind doing it, but there is no way that I can stay afloat next year and
>still get the extra work done keeping everything up to date.
>
>Next, now that the patchkit fixes most bugs that everyone has, should
>the Bug Report be discontinued? Are the explanation's in the seperate
>patches good enough for people to know what has/hasn't been fixed? When
>I give this thing up, should the next person only have to work on the
>Patchkit, instead of doing both? The reason I am asking is because both
>of these projects are pretty intertwined, so having two people working
>on them would require alot of co-ordination, since they are both looking
>at bugs/fixes to 386BSD. (One is the fix, the other is the explanation)
Nate:
You've done a wonderful job with the bug report, and the work
you've done recently on updating the patchkit is something that probably
would not have been done otherwise. You deserve public thanks. Thanks.
----------------------------------------
I think a lot of us are feeling time pressure on what's supposedly a
volunteer effort to get items we see as necessary out the door before
we are ready.
This "rush" is due, I think, in large part to the amazing amount of new
work that has been released lately, but also to the fact that there are
enough people threatening to CDROM the code that we want "our best foot
forward", as it were.
It is probably a mistake to CDROM at this point (not that I wouldn't buy
one myself) because of this, and because many of us are close enough to
finishing significant work that we feel the crunch more than we would
have three months ago or probably will three months from now.
I am also wary of the USL reaction to large scale distribution of 386BSD
(or for that matter, Linux) prior to the suit being resolved one way or
the other.
One thing that would help alleviate the pressure would be an agreement
by the CDROM proponents to a "code freeze" at some recent "current level"
(preferrably prior to the Joerg shared libraries). This would, of course,
reduce the "competitiveness" of distributions from "nice guys" if the
CDROM were to be treated as a commercial product (I believe it will). I
consel waiting until at least the upcoming 0.2 release for which there is
no public commitment as yet. This again puts the "nice guys" at a
disadvantage.
I ask that the FAQ not be put on CDROM until I have a chance to update
it (which I have desperately been trying to do lately), and if I can't
update it before press date, it should probably be left off.
----------------------------------------
As to the bug list, I think it needs to continue. It provides not only
work arounds prior to an actual fix being available, but also fixes which
are mutually exclsive with correct operation on some systems, as well as
a comprehensive errata sheet.
I can't take over the bug report; it needs someone whose sole contribution
to 386BSD is its maintenance, or who has a lot more free time than Nate or
I do.
I can't deal with the patchkit that I released (and then basically dumped
on Nate by mutual consent) until I deal with the FAQ.
What I can do is make some "division of labor" suggestions for anyone
taking Nate up on his offer, and potentially for Nate and myself as well,
depending on whatever future involvement our schedules allow. Some of
this depends on automation, and some on single individuals willing to
accept management rather than active participatory roles.
>From personal experience in the software industry, I think the following
may be as close to a workable ideal as we can expect:
----------------------------------------
The bug list manager:
1) PATCHES SHOULD NOT BE SENT TO THE BUG LIST MANAGER; see below.
2) A central bug reporting mechanism is required.
3) Assignments (automaton based "checkout" of bug reports by bug
list team?) of bugs for repeat and write-up are made. An
"official" bug number is assigned at this time.
4) Editing of bug list write-ups for consistancy. An editorial
policy need to be applied *and published to team members*.
5) Versioning of the buglist for distribution.
6) Distribution of buglist in comp.unix.bsd (or replacement) and
key FTP archives.
7) The bug list manager may be a bug list team member (if he/she
has the time -- management comes first).
8) The bug list manager can "fire" a team member after a [TBD]
number of failures to meet "editorial policy". This should
not be wanton (ie: manager must allow opportunity for rewrite
by a team member); however, it's possible that a single team
member could monopolize the manager with editorial problems,
and this can not be allowed.
9) Netnews access to pull bugs not reported through email from
news postings. Many international sites have posting access
but not email access. NOTE: BUGS WHICH ARE POSTED WITH
PATCHES SHOULD NOT BE PULLED BY THE BUG LIST MANAGER! ONE OF
THE RESPONSIBILITIES OF THE PATCHKIT MANAGER IS TO SUBMIT
BUG REPORTS FOR THESE BUGS. This was seen as an equitable
division of responsibility, and makes more sense than requiring
the bug list and patchkit managers to seperate out "their" parts
of a netnews posting.
10) FTP archival of "validation test cases" for patchkit manager.
11) Coordinates list releases with the patchkit manager.
The bug list team member:
1) Rewrites submitted bugs for clarity (ie: the description "floppy
hangs mysteriously" is inadequate) and insures they are in "bug
report format" (per editorial policy).
2) Writes a validation test case (or cases). The source/executable/
shell script name is based on the "official" bug number with
a possibility of a single character suffix. For example, the
file "bug00035a.sh" would be a shell script testing for one
part of the bug in bug report 35. Note that this may have to be
done by the original submitter if it is peculiar to a hardware
configuration.
3) Mails the "processed" bug back to the manager. Packaging software
would help automate this process.
4) Email access is required to be a "bug list team member".
The patchkit manager:
1) Has email and netnews access for incoming patches.
2) Has FTP access for distribution of patchkit (distribution
potentially includes posting to netnews after news group
split).
3) Gets bug reports from bug list manager.
4) Runs buglist validation on each patch to determine which (if
any) bugs are fixed by a patch. PATCHES ARE NOT RELEASED
WITHOUT A BUG REPORT DESCRIBING THE NEED FOR THE PATCH.
5) Submits bug reports to bug list manager for patches without
bug reports.
6) Informs bug list manager of patches, and which bugs are
corrected by a given patch for update of bug list.
7) Keeps the "magic cookie" (or "token") to insure patches are
installed sequentially.
8) Decides which patches are "mandatory", "recommended", or
"configurable". The two other grades of patches "questionable"
and "not recommended" DO NOT GO IN THE PATCH KIT. Instead,
they are kept in "raw" form for archival, but not distributed.
9) Manages "processing" of patches by patchkit team members.
10) Maintains archive of:
i) Patchkit releases
ii) Raw patches
iii) dist.fs/fixit.fs disks with fully patched kernels
(patches may be updated more frequently than the
bootable disks, since a "release" is constituted
by a full patchkit, as opposed to "drop in" patches,
plus patched bootables.
11) The patchkit manager can "fire" a team member after [TBD]
number of failures to correctly integrate a patch or long term
holding of the "magic cookie"; this insures timely and accurate
releases, as well as preventing one patchkit team member from
monopolizing the "magic cookie" to the exclusion of work by
other team members.
12) Publishes a list of patches for distribution with the patchkit
release for each new release.
13) Coordinates kit releases with the bug list manager.
14) The patchkit manager may be a patchkit team member.
15) The patchkit manager is responsible for updating all team members
with the most recent validation tests from the bug list manager
and all patches to the current level before handing over the token
to a team member.
The patchkit team member:
1) Keeps a fully patched source tree (at the current patch level).
2) Gets a patch from the patchkit manager for integration; at the
same time, they acquire all existing patches up to that point
(including unreleased patches), as well as the "magic cookie"
to insure them there are no simultaneous patches to the same
files.
3) Integrates the patch; generally, this entails adding commented
header information for the patch program, and manually applying
the patch(es). This is because very few people generating
patches on the net are doing their diffs from fully patched
source trees (and you wondered why the long delay!).
4) Runs the validation programs against the patched programs; if
the patch does not fix anything, and is not a performance patch,
this information is related to the patchkit manager.
5) If the patch fixes anything or is a performance patch, a patchkit
format patch is generated and submitted to the patchkit manager.
6) Email access is require to be a "patchkit team member".
7) At the patchkit managers discretion, FTP access may also be
required.
------------------------------------------------
Of course, all this would be greatly improved by mailing lists, automated
checkout and checking procedures, a "token server" for automatic update
of fully patched trees, etc.
I would also suggest that while it is required that the buglist manager
update the patchkit manager of new bugs as soon as a validation
mechanism is available, courtesy dictates that the bug list manager and
team members be granted "early access" to all patches prior to them
being "bundled up" for release.
I would also suggest that the bug list and patchkit managers notify the
Jolitz's of information under conditions where they notify each other.
It should be possible to arrive at a "validation suite" to insure bugs
are fixed through revisions almostt as a side effect of the bug reporting
mechanism.
Another class of individual, the "bug fix programmer", should be able to
get access to the bug list and submit patches to the patchkit without
requiring that their activities be "managed" -- ie: your average 386BSD
person/comp.unix.bsd person. Early availability of patches and bug list
information should not be necessary, since both should be made public
in a timely manner.
-------------------------------------------------
Well, what does everyone think? Is it a plan? Volunteers? 8-).
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------