Re: Modest proposal for successful releases

[Dale Scheetz <dwarf@polaris.net>]

On Tue, 14 Jan 1997, Christoph Lameter wrote:

> On Tue, 14 Jan 1997, Dale Scheetz wrote:
> 
> dwarf >I have been thinking about this for some time, and have a modest proposal
> dwarf >which doesn't involve eating our young.
> dwarf >
> dwarf >First: Put less change into the release goals. A simpler set of goals
> dwarf >takes less time for development and provides more space for testing.
> 
> I think the release goals do not need to determine when a distribution is
> released. If those goals are not met but other goals have been
> accomplished then some goals have to be postphoned and the release should
> go ahead. We need frequent releases to get used to the process and improve
> it as we go along. 2 releases a year do not cut it.

I think my point was: Set more modest goals and have a better chance of
meeting them.

> 
> dwarf >Second: Set an "internal" release date far in advance of the "public"
> dwarf >release. This will let developers know that they must meet an earlier
> dwarf >target and so, bump their schedules to succeed.
> 
> We tried that. The problem was that people in high places decided to get
> some pieces changed in the last days before the release time. We made
> Brian responsible for managing the release and then pushed him into things
> he did not want.
> 
No. What we tried was destined for disaster. We didn't even begin talking
about the release (scheduled for the end of September) until half a month
past the date. We pushed things into the release that were totaly
unplanned and tried to do testing in a two week period just before the
holidays. None of this matches my idea of an advance internal release
date.

> There was barely any testing done during the frozen period. I got news of
> some big problems in some of my packages only when Debian 1.2 was
> released.
> 
> dwarf >Third: Cultivate a set of users, as beta test sites, who span the range of
> dwarf >"strange" machines and "difficult" system configurations, who will be
> dwarf >willing to "fully" test the installation of the new release.
> 
> Very important! Any ideas how to organize such a group?
> 
Well, start by scanning the debian-user list for the period after the
release and contact all those users who had major problems with boot
disks. Sort out those who have the disk space to build a test partition
and encourage them to participate with the payback of individual attention
to their problems.

> dwarf >We currently have no testing groups, either official or unofficial.
> 
> And the problem is that all developers probably are already running 1.3.
> We ourselves do not run our stable releases! I have begun running our
> mission critical servers with 1.3 since I have made the experience that
> what we run is more "stable" than what we call "stable"!
> 
This is becoming a major problem. It's ok to move ahead to the latest
xasteroids or even newer sendmail. But developers MUST hold at the release
runtime libraries until their packages in stable are as fixed as they are
going to be. This means sometime after the freeze date (note: unstable
needs no testing until after the release of frozen/stable) it will be
appropriate to move ahead.

> dwarf >3. Pick one or two major areas of improvement to complete.
> dwarf >	a. Shadow password support
> 
> This needs to go into unstable immediately! Why is not there?
> 
I think it fell into the black hole of "experimental". We really need to
move this into bo soonest. Much of the work on individual packages has
already been done. I have moved patches for shadow passwords into imap-4
and from discussions on devel it seems that most, if not all, of the other
packages involved.

> dwarf >	b. Impliment the new web server standard
> 
> I am wary of that standard. I would like to have simplicity and not that
> symlink tree adventure.
> 
Then this should be discussed in more detail and we should decide
whether or not to go for it this release. This list is a "choose one or
two of the above" kind of thing. 
This is where the hard decissions are located. We need to work this list
out as early as possible.

> What is the procedure on new policies by the way?
<sarcasm>
We discuss them to death. Everyone goes their own way. We resolve the
issue in the bug tracking system. Someone eventually writes something into
the docs.
<!sarcasm>
>                                                 There seems some changes
> that I have never seen discussed (too much traffic on debian-devel?). Who
> decides the policies?
> 
It is my understanding that Bruce has the final say about all policy
decissions.

Luck,

Dwarf

------------                                          --------------

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

------------ If you don't see what you want, just ask --------------


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com