Re: Release Process [was: Re: Red Hat 5.0 Release date]
On 22-Nov-97, Christian Leutloff <leutloff@sundancer.oche.de> wrote:
>
> please keep in mind that your product must be read by *all* developers
> -> each page is read by 200 people, in this time they can't work on
> the release. You slowdown the release process by writing long
> documents. Please keep it short. Everything that's longer than two A4
> pages (140 lines) isn't acceptable for the Debian release process!
> Please don't try to increase the bureaucracy of Debian. IMHO it's very
> easy to write 100 pages. But it's more difficult to express the same
> thing on 1 page. Please work in this direction. Thanks.
Something I've found that helps a great deal when writing
software-engineering documents is separating process from
justification.
For example (an imaginary example):
Step 47: Email the project leader and check that release notices
have been written. The stops us from getting to the
point of telling everyone the release is happening
today, and then having to postphone because when we get
to step 54 we're going to need them pretty quickly.
So that we don't lose the notices, or get into trouble
if we can't find the project leader later, put them
in the directory X on master.
This becomes:
Step 47: Email project leader to check release notices are ready.
Put them in directory X on master.
The rest of the justification can be useful (in many cases the steps
may seem a bit mysterious and difficult to know whether they are
actually necessary), but it should be put in a different document
(a hyperlink to/from would be nice), or as a footnote or something -- a
bit like the way the C standard is set up.
If your document is still too large, then it should be partitioned,
possibly upon the basis of responsibility (e.g. here is the complete
list -- you don't have to read it, but here is the list that *you* have
to worry about, in your position as X -- where X might be package
maintainer or integrator or tester or web page maintainer or whatever).
> And keep in mind that the work you propose must be done by
> *volunteers*. The main focus shouldn't be the time line, because
> people can't be forced to do something. Instead you should try to make
> individuals responsible for each single task. Responsible doesn't mean
> that the person must do the work, instead he must try to coordinate
> the process. At the moment I would say that Richard Brackmann is
> responsible for the migration process from libc5 to libc6, because he
> post regularly the status and shows the difficulties that needs to be
> solved. Other aspects, like the PAM, needs a coordinator, too.
But timelines and "deadlines" are useful, even if they are flexible,
because they create goals. Saying "we aim to have all libc6 by January
2nd, if you don't think you'll make it or need help, mail X" is better
than "go libc6 whenever you have time". Timelines also help people
decide where volunteer effort should be focused.
But you are right, personal responsibility is important too.
--
Tyson Dowd #
# Linux versus Windows is a
trd@cs.mu.oz.au # Win lose situation.
http://www.cs.mu.oz.au/~trd #
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: