Date: Wed, 19 Apr 1995 05:43:58 -0700 From: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> To: core@freefall.cdrom.com Cc: hackers@freefall.cdrom.com Subject: Minutes of the Thursday, April 13th core team meeting in Berkeley. Message-ID: <18149.798295438@freefall.cdrom.com>
next in thread | raw e-mail | index | archive | help
On last Thursday, the 13th of April, we happened to have enough core
team members together (7) in one place to warrant a meeting. The
meeting was somewhat hastily convened, and some of the members who
were forced to miss it due to insufficient warning have since
expressed concern that future meetings not be held in such an ad-hoc
fashion. This wish is understandable and will be respected, so any
future core team meetings of a quasi-official nature will be planned
at least 3 months in advance, to be held in whichever country is most
convenient at the time (core members will still be expected to get
themselves there by whatever means they are capable of arranging for
themselves, at least until we establish a travel budget).
Such complaints about the lack of proper procedure aside, a number of
items of importance were discussed and decided, and though these
minutes have been somewhat delayed in getting out (for which I take
full responsibility), and this has in turn raised some ire in core, I
certainly hope we can put all of that behind us now and simply focus
on the issues raised herein. Since much of the criticism I've
received over the last few days has centered on "closed door decision
making" and the generally unpleasant image of a small "star chamber"
of core members making all the important decisions, I'm also widening
the distribution of this from "core" to "core and hackers" - all
parties are thus free to comment.
NOTE: Julian was the "scribe" for this meeting and had only a small
notepad. His notes were thus, of necessity, somewhat condensed.
Since some of those notes didn't make much sense out of the context of
having actually been there, I went to additional lengths to provide
more background information from my own memories of the meeting. Any
errors in content so introduced are mine alone. - Jordan
Here we go..
----------------------------------------------------------
Title: Minutes from the FreeBSD core team meeting of April 13th, 1995.
Attendees: David Greenman
Gary Palmer
Jordan K. Hubbard
Julian Elischer[*]
Justin Gibbs
Poul-Henning Kamp
Satoshi Asami
Soren Schmidt
[*] Julian's sort of quasi-core, and would be a full member if only we
could manage to twist his arm far enough in that direction. :)
Agenda:
1. Core team structure for releases and general "peacetime" operation.
2. 2.1 Objectives
3. 2.0.5?
4. 2.1 Release date
AGENDA: 1. Core team structure
-------------------------------
Jordan opens with comments to the effect that we're still running
around without clear zones of responsibility in certain critical areas
and thus a number of releases (e.g. *all* of them so far) have gone
out with portions half-baked and/or generally broken. He calls for
the appointment of "managers" to break ties in situations where the
individual engineers cannot reach consensus, or are about to let
something vital drop on the floor.
Justin follows-up to this with comments to the effect that this is
what has happened with his proposed /sys/dev changes - he needs to
move his AIC code from the gnu directory into the main tree now due to
copyright changes but has no idea of where it should go or who to ask
for some sort of "final decision."
Scattered group discussion on what sorts of roles there are to be
played in the construction of a truly *good* release, and which
individuals might be entrusted with final decision-making capabilities
in those areas. The following provisional "appointments" are made:
System Architect[1]: David
Standards Guard[2]: vacant (terry?)
Resource Mgr[3]: Jordan + ?
Release Mgr[4]: Poul
Release Engineeer[5]: long-term vacant, Jordan for 2.1R
Test Mgr[6]: Julian
Test Engineer[7]: Rod
Public Relations & Marketing[8]: Jordan
Ports Mgr[9]: Satoshi
Support Mgr[10]: vacant (possibly PAY someone)
Doc Mgr[11]: John Fieber + ?
NetBSD Liason/Industrial Spy[12]: vacant
Linux Liason/Industrial Spy[13]: vacant
Source code tree god[14]: Rod?
Detail for above:
[1]. Has overall control of the technical side of things. Final arbiter
of what goes in the tree in times of dispute.
[2]. Needs to track standards like POSIX and XPG, doing the work and reporting
back to the other "managers" when something in their area of
responsibility is not in compliance with a well-defined standard.
[3]. Keeps "filofax" of important FreeBSD contacts and testers with
different configurations, collects commercial contacts, manages the
"FreeBSD document library" and is generally a resource for all other
managers. The advantage of having this centralized in someone is
that they also become an "index" for such information.
[4]. Makes sure that each release "checks off" against an array of acceptance
tests that he's also responsible for collecting and/or preparing in
association with the testing manager. Ensures that the release framework
is of sufficient quality and produces additional software (or
"commissions" such work) as necessary to improve the general installation
and system administration framework.
[5]. Does the actual work of putting each release together for handing
off to the test manager.
[6]. Assembles a battery of tests for constantly exercising FreeBSD in
interesting ways. Works closely with #7 to ensure that each and every
supported bit of hardware has its driver tested under actual installation
and "typical use" conditions.
[7]. Collects oddball hardware of every description and runs tests for
#6.
[8]. Does the obvious - tries to "sell" this whole thing to new users,
cultivates corporate contacts and puts together an increasingly more
substantial FreeBSD "organization" to support the general advancement of
FreeBSD as a UNIX-workalike product. A SPEC 1170 cert so that we can
stop calling it a `UNIX-workalike' also wouldn't be a bad project for
this man! :)
[9]. Manages the ports and packages collection.
[10]. Handles technical support questions over the phone and in email.
Makes sure that customer complaints are dealt with in a timely
fashion. Since this is a horrible job, we probably should pay someone
to do it as soon as that's possible.
[11]. Preparation of documentation and on-line help.
[12]. Keep track of what's going on in the Linux camp, actively working _with_
Linux developers to mutual benefit whenever possible (code sharing)
and simply "borrowing" liberally from what's freely available when
it's not.
[13]. Same, but for the NetBSD code base. We were just joking when we called
them "spies", honest! :-)
[14]. Makes sure that the "life and history" of the source tree itself is
properly preserved and that people do not commit gross acts of CVS
destruction on it through ignorance or stupidity. Also manage
on-going efforts to improve the ability for outside people to make
contributions and stay sync'd with FreeBSD-current, if they so desire
it.
All of these positions were provisional appointments and, as many here
can see, are in many instances not even properly filled. This also
represents an "ideal" list of positions, and as it's highly unlikely
that we'll be able to fill all of them effectively for some time yet,
you'll see "doubling up" of certain positions by a single person.
This simply represents the structure we at the meeting thought it'd be
someday nice to see.
There was then some discussion on how to file 'changes' and 'fixes'
back to the system from a remote user, and a discussion was had about
some sort of database with a Mail front-end for queries and
submissions (e.g. something along the lines of cvs commits and updates
by mail - DavidG has too little connectivity to use interactive stuff
sometimes and it's an impediment to getting work done). The status of
this topic is open and is pending someone coming forward and actually
helping to do the work of setting up such a system. See core for
details if you're truly interested - it's a challenging problem!
1.15. A decision was reached that README files in the kernel tree will be
encouraged.
1.16. Persuant to "chief architect" powers, it was felt that it we should try
to agree that "What the Architect says in a dispute is final.." David
is not generally a guy to throw is weight around, and we're getting
involved in simply too many disputes where the principles are unable
to agree and waste a lot of everyone's time in plowing through
endless debate. We need a tie-breaker.
AGENDA: 2. Objectives of 2.1 categorised by importance/status:
--------------------------------------------------------------
Needed:
Slices
bad144
sysinstall (new) with slice/bad144 support
lynx for help
ATAPI support (IDE CDROM)
/etc revamp needs finishing.
sysconfig & MIB integration - should be able to set variables from -c.
SCSI-magtape fixes
All-singing 'unreadable' PS2 Mouse improvement
Nice-to-have:
Better buggy hardware detection
boot from and on CD
boot from and on DOS
SCSI-TCP
Firewall completion.. (look at DEC stuff too)
Experimental:
devfs
rfork
kzip
pthreads
Linux emulation
SCO emulation
cyclades serial driver
In but known-to-be-broken (and documented as such!):
LFS
UNIONFS
NULLFS
VN (may work now)
AGENDA: 3. 2.0.5??
--------------------
Jordan notes that Walnut Creek CDROM is somewhat alarmed at the new
release date for 2.1R and would really much rather ship something in
the interim that's a little more up-to-date than 2.0 if it's going to
take that long (a July 1st net release means a mid-July CD, at best).
The assembled core team members concur that still shipping 2.0R all
the way up through mid-summer is a pretty horrible thought since
numerous bugs with 2.0R are known to exist, many of which have been
fixed in -current. Counterbalancing this concern is the worry that an
interim release will take too much critical time away from 2.1R, which
is the true and proper priority.
After some discussion, a compromise is decided. An interim snapshot,
"2.0.5", will be quickly prepared if it's at all possible to produce
something significantly better than 2.0R (which is not that hard) with
very little impact on 2.1R's schedule. It is furthermore decided to
do this quickly if at all, since drawing it out will only narrow its
window of usefulness and negatively impact 2.1R.
The following provisional schedule for 2.0.5 (now perhaps 2.0.6 due to
the fact that the pcvt people jumped too quickly on the last cancelled
2.0.5 release :-( ) is proposed:
April 17th: Begin CODE 'FREEZE' on NEW features on a branch copy
of 2.0-950412-SNAP.
April 21: SNAPSHOT for testing.
April 24th: 2.0.5 CDROM mastered.
Group discussion ensues on whether it was better to have regular
imperfect releases or irregular 'perfect' releases.. The following
interesting facts are debated:
4.1. Linux releases are almost always imperfect, yet they seem to have no
shortage of willing victims. Proponents all claim rapid release
schedule as major feature of Linux, where we typical see it as a bug.
4.2. We haven't managed anything close to a perfect release yet, despite our
additional "fussiness", and it's wondered whether or not we simply
use high standards as an excuse to procrastinate, only to generally panic
at the last minute and shove out an inferior product anyway.
4.3. As things move forward, it's hard to support old code. Fresher releases
do free us from much of that burden among the new-user population.
4.4. Our "upgrade" policy is a complete mess and needs a serious visit
[action: Jordan is working on organizing this with some other folks]
4.5 WC desire something a little more up-to-date to sell (hey they
supply the machines and Jordan).
Decisions:
X.Y is a 'perfect' (or as close as we can) release with a full
alpha/beta/release cycle..
X.Y.Z is an imperfect 'SNAPSHOT release' with a '5 day'
branch/freeze/check cycle..
We should put out SOMETHING more often than we are:
So we will release 2.0.5.. (on CDROM & NET)
It doesn't matter if therelease itself is not perfect..
it should state CLEARLY on the package that it is
an upgrade for 2.0 but not a 'perfect' release.
We should look at X.Y.Z releases every N months (3?) (2.5?)
AGENDA: 4. 2.1 schedule
-----------------------
ALPHA: May 31, 1995
[30 full days of testing]
Release: July 1, 1995
This is a somewhat more advanced schedule that previously thought, but
no one can argue with Jordan's revised estimates to core (original
email available on request) it seems, so we have to accept that it's
simply going to be this late.
[ END OF MINUTES - THIS FILE HAS NOT BEEN TRUNCATED ]
====================================
That pretty much sums up the meeting. We broke it up around midnight
and didn't even get any ice cream afterwards. Gary felt especially
cheated by this! :-)
I'm sorry that these minutes took so long to get out, but I'm swamped
as usual. On the bright side, it looks like my house was finally
purchased today, and so fairly soon I'll finally have a place to live
after 8 months of sleeping in a corner of the floor! Hurrah! :-)
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18149.798295438>