>> Building -current from the last release is not the supported way to
>> upgrade to current [...]

> #define RANT_MODE_ON

> That this statement could be delivered without any incredulity at all
> is what I mean about the lack of discipline in open source projects.

It sounds to me as though you'd be a whole lot happier if you'd just
forget -current exists at all.  If you see such problems with real
releases, that's a big issue.  If you see such problems with -current,
well, so what?  There's no guarantee *any* environment exists under
which any particular instant's -current builds.

-current exposes the Project's internal working tree.  If this
constitutes "lack of discipline" to you, well, as I said, you'd
probably be happier pretending we didn't make it accessible.

> At some point there will be _no_ environment where the "next" or
> "current" release of the system can be built.

The current release of NetBSD is 1.4.1 (or is it 1.4.2 by now? I don't
*think* I've seen a release announcement).

This has nothing to do with -current, which is what was being
discussed.  -current is not a release.

> The "build system" is the tool used to build the release, and in a
> properly managed development environment the current build tools
> would be sacrosanct and 100% stable.  This doesn't mean that the
> build tools can't evolve and change, just that they should be
> stablized _first_ then the build done.

> So -current should be built with *ONLY* 1.4.x systems (stable tools)
> and then once 1.5 gets cut, -current can switch over to being built
> with the 1.5 set. 

Point 1: why is *your* opinion of a "properly managed development
environment" necessarily the correct one for the Project?

Point 2: the paradigm you propose would require vastly more releng
cycles, because it would mean we would be forced to cut a release each
time our build tools change.  I see barely enough brains to handle
releng for what we're doing.  Where do you propose we get the human
time to support your proposed paradigm?  Are you volunteering?

Remember, this is a volunteer project.  We're making progress with the
paradigm we've got.  With yours, I see that slowing down drastically,
perhaps even stopping as people get fed up and switch to a
faster-moving system.

> Without this discipline you get to our current situation, and one
> that will only get worse, where you need -current to build -current.
> And if you don't have -current there is no straightforward way to
> build a release.

Each release builds under itself - or it's critically broken.  I don't
think we've ever promised that any release builds under anything but
itself, and I see no reason to try.

As far as I can see, this has nothing to do with -current, and I don't
see why you're trying to argue it does.

> Thus you impede new progress as new developers get "on board" with NO
> DEVELOPMENT VALUE IN TOOLS. 

That's why we have snapshots.

> Now this is important, if you don't "lose" anything by using the
> stable tools to build the new release and new tools and you gain a
> tremendous amount in terms of buildability.

If.  That's an awfully big if.  We would lose, big, by forcing
ourselves to stick with each release's build tools until the next
release; it would either force much more frequent releases (which we
don't have the releng time to support AFAICT) or it would severely slow
down feature uptake (which is slow enough as it is), because each new
"need to build the tool to build the tool" iteration would have to
block waiting for a release.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B