From owner-freebsd-hackers Wed Apr 19 05:44:02 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA18156 for hackers-outgoing; Wed, 19 Apr 1995 05:44:02 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id FAA18150 ; Wed, 19 Apr 1995 05:43:58 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: core@freefall.cdrom.com cc: hackers@freefall.cdrom.com Subject: Minutes of the Thursday, April 13th core team meeting in Berkeley. Date: Wed, 19 Apr 1995 05:43:58 -0700 Message-ID: <18149.798295438@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: hackers-owner@FreeBSD.org Precedence: bulk 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