On Mon, Jun 08, 1998 at 01:22:26PM +0100, Ian Jackson wrote:
> We should abandon attempts at `social engineering' through release
> management. So, `we must do X before we release' or `you must fix bug
> Y or we should remove the package' (for non-critical Y), have to stop.
Although I see problems I also see the need that our stable releases
are consistent in itself. If there are distribution release goals
they should[1] be fulfilled. After a pre-defined time they should
be re-ratified to see if they can be fulfilled, need to be softened
or even skipped.
Another thing is that in such cases we need to get away from the
"300-mini-cathedral-situation" and promote more actively the
bazaar method which will result in either more non-maintainer
uploads or teams that maintain a bunch of packages[2].
> This is a volunteer organisation and trying to coerce people into
> doing work by threatening to burn the house down just leaves you
> standing over undone work, holding a match, wondering whether to carry
> out your threat.
Well, I do see the problem, but we need to be able to depend on
our fellow developers. Although it should not be a problem if
a maintainer is unavailable for a while or for a longer time
and nmu's need to be made in such cases.
> We must decouple our development tracks much more. I propose that we
> resolve never again to plan a release with is not fully backward
> compatible with the current stable version.
Although I don't agree as mixed library releases succ afaik, that's
your power as leader to decide.
> We should abandon the idea of `release goals'. Instead, if someone
> thinks a thing definitely needs doing by the time of a release, they
> do it. If it doesn't get done then we release anyway.
This again means that we need to encourage more maintainers to work
on multi-package-solution and to skip the 300-mini-cathedral-situation.
Only few people are working on package that are not maintained by
them, this needs to be re-considered.
> Every three months (fixed date) we copy the current `unstable' into
> `frozen'. At this point `stable', `frozen' and `unstable' should all
> stay interoperable both in source and binary form.
As someone already said three months look too close. The frozen release
should at least be tested and checked (automatically where possible)
for consistency or we are going to produce non-usable snapshot
releases which would result in lots of bad press. It also needs to
be pressed on CD, OfficialCD's need to be made which costs at least
another half month. There would be only two months left for using
the stable release then.
Twice a year (freeze in may and november, release in june and december
or every 5 months) look much more reasonable for me.
Anyway I'm still of the oppinion that we should define goals. But
if we do snapshot releases more often and encourage non-maintainer work
more we also should be in the position to faster fix pkg-release critical
bugs or even revert the changes for the frozen->stable release.
> The need to retain complete compatibility will make it harder work to
> make big changes - they have to be phased in. However, it will result
> in a situation where we can safely release _halfway through_ such a
> big change. For example, I hope that the next time the libc is
> changed incompatibly we will release a distribution that's half new
> libc and half old libc. Probably our libc7 distribution will still
> have libc5 programs in it - but that's fine !
For the record: I object.
> If it's not fine with you then let's not hold up the releases -
> instead, go and fix those packages.
Seconded.
> We also need to make automatic building a real possibility.
Absolutely seconded.
Regards,
Joey
[1] Which means that if it it can't be fulfilled in a reasonable
time schedule we have to soften our goals or skipt this package
for this release.
[2] This could be some friends, or maintainers who have reasonable
interest that certain packages are well maintained or even some
"free" maintainers that don't have a major package but "only"
works for Quality Assurance of certain packges or the distribution
as a whole.
--
/ Martin Schulze * joey@infodrom.north.de * 26129 Oldenburg /
/ http://home.pages.de/~joey/
/ The only stupid question is the unasked one /
Attachment:
pgpxv5fPD8a1c.pgp
Description: PGP signature