home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / bsd / 10114 < prev    next >
Encoding:
Text File  |  1992-12-11  |  12.0 KB  |  267 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!spool.mu.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
  3. From: terry@cs.weber.edu (A Wizard of Earth C)
  4. Subject: Re: Bug Report and Patchkit status
  5. Message-ID: <1992Dec11.224735.23342@fcom.cc.utah.edu>
  6. Keywords: time,school,need a life!
  7. Sender: news@fcom.cc.utah.edu
  8. Organization: Weber State University  (Ogden, UT)
  9. References: <1992Dec10.173351.11083@coe.montana.edu>
  10. Date: Fri, 11 Dec 92 22:47:35 GMT
  11. Lines: 254
  12.  
  13. In article <1992Dec10.173351.11083@coe.montana.edu> osynw@gemini.oscs.montana.edu (Nate Williams) writes:
  14. >Here's the situation.
  15. >
  16. >I don't feel that I have done a very good job of keeping up the Bug
  17. >Report and the Patchkit lately.  Next semester is going to be worse, and
  18. >I'm losing my network access on my 386BSD machine.
  19. >
  20. >Soooo,
  21. >    Does anyone in 386BSD land want to take over the Bug List
  22. >co-ordination?  I have been trying to put out another version of the
  23. >patchkit, but because of lack of time and trying to re-format the old
  24. >patchkit, I haven't added many patches.  (I have LOTS of them, and more
  25. >are coming every day)  Someone who has more time than me needs to take
  26. >over the co-ordination if this is going to be kept up to date.  I don't
  27. >mind doing it, but there is no way that I can stay afloat next year and
  28. >still get the extra work done keeping everything up to date.
  29. >
  30. >Next, now that the patchkit fixes most bugs that everyone has, should
  31. >the Bug Report be discontinued?  Are the explanation's in the seperate
  32. >patches good enough for people to know what has/hasn't been fixed?  When
  33. >I give this thing up, should the next person only have to work on the
  34. >Patchkit, instead of doing both?  The reason I am asking is because both
  35. >of these projects are pretty intertwined, so having two people working
  36. >on them would require alot of co-ordination, since they are both looking
  37. >at bugs/fixes to 386BSD.  (One is the fix, the other is the explanation)
  38.  
  39.  
  40. Nate:
  41.  
  42.     You've done a wonderful job with the bug report, and the work
  43. you've done recently on updating the patchkit is something that probably
  44. would not have been done otherwise.  You deserve public thanks.  Thanks.
  45.  
  46.  
  47. ----------------------------------------
  48.  
  49. I think a lot of us are feeling time pressure on what's supposedly a
  50. volunteer effort to get items we see as necessary out the door before
  51. we are ready.
  52.  
  53. This "rush" is due, I think, in large part to the amazing amount of new
  54. work that has been released lately, but also to the fact that there are
  55. enough people threatening to CDROM the code that we want "our best foot
  56. forward", as it were.
  57.  
  58. It is probably a mistake to CDROM at this point (not that I wouldn't buy
  59. one myself) because of this, and because many of us are close enough to
  60. finishing significant work that we feel the crunch more than we would
  61. have three months ago or probably will three months from now.
  62.  
  63. I am also wary of the USL reaction to large scale distribution of 386BSD
  64. (or for that matter, Linux) prior to the suit being resolved one way or
  65. the other.
  66.  
  67. One thing that would help alleviate the pressure would be an agreement
  68. by the CDROM proponents to a "code freeze" at some recent "current level"
  69. (preferrably prior to the Joerg shared libraries).  This would, of course,
  70. reduce the "competitiveness" of distributions from "nice guys" if the
  71. CDROM were to be treated as a commercial product (I believe it will).  I
  72. consel waiting until at least the upcoming 0.2 release for which there is
  73. no public commitment as yet.  This again puts the "nice guys" at a
  74. disadvantage.
  75.  
  76. I ask that the FAQ not be put on CDROM until I have a chance to update
  77. it (which I have desperately been trying to do lately), and if I can't
  78. update it before press date, it should probably be left off.
  79.  
  80.  
  81. ----------------------------------------
  82.  
  83. As to the bug list, I think it needs to continue.  It provides not only
  84. work arounds prior to an actual fix being available, but also fixes which
  85. are mutually exclsive with correct operation on some systems, as well as
  86. a comprehensive errata sheet.
  87.  
  88. I can't take over the bug report; it needs someone whose sole contribution
  89. to 386BSD is its maintenance, or who has a lot more free time than Nate or
  90. I do.
  91.  
  92. I can't deal with the patchkit that I released (and then basically dumped
  93. on Nate by mutual consent) until I deal with the FAQ.
  94.  
  95.  
  96. What I can do is make some "division of labor" suggestions for anyone
  97. taking Nate up on his offer, and potentially for Nate and myself as well,
  98. depending on whatever future involvement our schedules allow.  Some of
  99. this depends on automation, and some on single individuals willing to
  100. accept management rather than active participatory roles.
  101.  
  102. From personal experience in the software industry, I think the following
  103. may be as close to a workable ideal as we can expect:
  104.  
  105. ----------------------------------------
  106.  
  107. The bug list manager:
  108.  
  109. 1)    PATCHES SHOULD NOT BE SENT TO THE BUG LIST MANAGER; see below.
  110. 2)    A central bug reporting mechanism is required.
  111. 3)    Assignments (automaton based "checkout" of bug reports by bug
  112.     list team?) of bugs for repeat and write-up are made.  An
  113.     "official" bug number is assigned at this time.
  114. 4)    Editing of bug list write-ups for consistancy.  An editorial
  115.     policy need to be applied *and published to team members*.
  116. 5)    Versioning of the buglist for distribution.
  117. 6)    Distribution of buglist in comp.unix.bsd (or replacement) and
  118.     key FTP archives.
  119. 7)    The bug list manager may be a bug list team member (if he/she
  120.     has the time -- management comes first).
  121. 8)    The bug list manager can "fire" a team member after a [TBD]
  122.     number of failures to meet "editorial policy".  This should
  123.     not be wanton (ie: manager must allow opportunity for rewrite
  124.     by a team member); however, it's possible that a single team
  125.     member could monopolize the manager with editorial problems,
  126.     and this can not be allowed.
  127. 9)    Netnews access to pull bugs not reported through email from
  128.     news postings.  Many international sites have posting access
  129.     but not email access.  NOTE:  BUGS WHICH ARE POSTED WITH
  130.     PATCHES SHOULD NOT BE PULLED BY THE BUG LIST MANAGER!  ONE OF
  131.     THE RESPONSIBILITIES OF THE PATCHKIT MANAGER IS TO SUBMIT
  132.     BUG REPORTS FOR THESE BUGS.  This was seen as an equitable
  133.     division of responsibility, and makes more sense than requiring
  134.     the bug list and patchkit managers to seperate out "their" parts
  135.     of a netnews posting.
  136. 10)    FTP archival of "validation test cases" for patchkit manager.
  137. 11)    Coordinates list releases with the patchkit manager.
  138.  
  139.  
  140. The bug list team member:
  141.  
  142. 1)    Rewrites submitted bugs for clarity (ie: the description "floppy
  143.     hangs mysteriously" is inadequate) and insures they are in "bug
  144.     report format" (per editorial policy).
  145. 2)    Writes a validation test case (or cases).  The source/executable/
  146.     shell script name is based on the "official" bug number with
  147.     a possibility of a single character suffix.  For example, the
  148.     file "bug00035a.sh" would be a shell script testing for one
  149.     part of the bug in bug report 35.  Note that this may have to be
  150.     done by the original submitter if it is peculiar to a hardware
  151.     configuration.
  152. 3)    Mails the "processed" bug back to the manager.  Packaging software
  153.     would help automate this process.
  154. 4)    Email access is required to be a "bug list team member".
  155.  
  156.  
  157. The patchkit manager:
  158.  
  159. 1)    Has email and netnews access for incoming patches.
  160. 2)    Has FTP access for distribution of patchkit (distribution
  161.     potentially includes posting to netnews after news group
  162.     split).
  163. 3)    Gets bug reports from bug list manager.
  164. 4)    Runs buglist validation on each patch to determine which (if
  165.     any) bugs are fixed by a patch.  PATCHES ARE NOT RELEASED
  166.     WITHOUT A BUG REPORT DESCRIBING THE NEED FOR THE PATCH.
  167. 5)    Submits bug reports to bug list manager for patches without
  168.     bug reports.
  169. 6)    Informs bug list manager of patches, and which bugs are
  170.     corrected by a given patch for update of bug list.
  171. 7)    Keeps the "magic cookie" (or "token") to insure patches are
  172.     installed sequentially.
  173. 8)    Decides which patches are "mandatory", "recommended", or
  174.     "configurable".  The two other grades of patches "questionable"
  175.     and "not recommended" DO NOT GO IN THE PATCH KIT.  Instead,
  176.     they are kept in "raw" form for archival, but not distributed.
  177. 9)    Manages "processing" of patches by patchkit team members.
  178. 10)    Maintains archive of:
  179.     i)    Patchkit releases
  180.     ii)    Raw patches
  181.     iii)    dist.fs/fixit.fs disks with fully patched kernels
  182.         (patches may be updated more frequently than the
  183.         bootable disks, since a "release" is constituted
  184.         by a full patchkit, as opposed to "drop in" patches,
  185.         plus patched bootables.
  186. 11)    The patchkit manager can "fire" a team member after [TBD]
  187.     number of failures to correctly integrate a patch or long term
  188.     holding of the "magic cookie"; this insures timely and accurate
  189.     releases, as well as preventing one patchkit team member from
  190.     monopolizing the "magic cookie" to the exclusion of work by
  191.     other team members.
  192. 12)    Publishes a list of patches for distribution with the patchkit
  193.     release for each new release.
  194. 13)    Coordinates kit releases with the bug list manager.
  195. 14)    The patchkit manager may be a patchkit team member.
  196. 15)    The patchkit manager is responsible for updating all team members
  197.     with the most recent validation tests from the bug list manager
  198.     and all patches to the current level before handing over the token
  199.     to a team member.
  200.  
  201.  
  202. The patchkit team member:
  203.  
  204. 1)    Keeps a fully patched source tree (at the current patch level).
  205. 2)    Gets a patch from the patchkit manager for integration; at the
  206.     same time, they acquire all existing patches up to that point
  207.     (including unreleased patches), as well as the "magic cookie"
  208.     to insure them there are no simultaneous patches to the same
  209.     files.
  210. 3)    Integrates the patch; generally, this entails adding commented
  211.     header information for the patch program, and manually applying
  212.     the patch(es).  This is because very few people generating
  213.     patches on the net are doing their diffs from fully patched
  214.     source trees (and you wondered why the long delay!).
  215. 4)    Runs the validation programs against the patched programs; if
  216.     the patch does not fix anything, and is not a performance patch,
  217.     this information is related to the patchkit manager.
  218. 5)    If the patch fixes anything or is a performance patch, a patchkit
  219.     format patch is generated and submitted to the patchkit manager.
  220. 6)    Email access is require to be a "patchkit team member".
  221. 7)    At the patchkit managers discretion, FTP access may also be
  222.     required.
  223.  
  224. ------------------------------------------------
  225.  
  226. Of course, all this would be greatly improved by mailing lists, automated
  227. checkout and checking procedures, a "token server" for automatic update
  228. of fully patched trees, etc.
  229.  
  230. I would also suggest that while it is required that the buglist manager
  231. update the patchkit manager of new bugs as soon as a validation
  232. mechanism is available, courtesy dictates that the bug list manager and
  233. team members be granted "early access" to all patches prior to them
  234. being "bundled up" for release.
  235.  
  236. I would also suggest that the bug list and patchkit managers notify the
  237. Jolitz's of information under conditions where they notify each other.
  238.  
  239. It should be possible to arrive at a "validation suite" to insure bugs
  240. are fixed through revisions almostt as a side effect of the bug reporting
  241. mechanism.
  242.  
  243. Another class of individual, the "bug fix programmer", should be able to
  244. get access to the bug list and submit patches to the patchkit without
  245. requiring that their activities be "managed" -- ie: your average 386BSD
  246. person/comp.unix.bsd person.  Early availability of patches and bug list
  247. information should not be necessary, since both should be made public
  248. in a timely manner.
  249.  
  250.  
  251. -------------------------------------------------
  252.  
  253. Well, what does everyone think?  Is it a plan?  Volunteers?  8-).
  254.  
  255.  
  256.                     Terry Lambert
  257.                     terry@icarus.weber.edu
  258.                     terry_lambert@novell.com
  259. ---
  260. Any opinions in this posting are my own and not those of my present
  261. or previous employers.
  262. -- 
  263. -------------------------------------------------------------------------------
  264.                                         "I have an 8 user poetic license" - me
  265.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  266. -------------------------------------------------------------------------------
  267.