> Ok, clearly we've sparked some good discussion.
> 
> At this time, I would like to ask the macppc community to discuss
> whether or not we should petition core to drop macppc from the RC cycle
> until we get a better handle on these bugs. 2.0 is a major milestone for
> NetBSD, and I don't think we should put something out that isn't as
> polished as possible. I understand through the grapevine that if we were
> to ask for the cycle freeze we would not be the only port to do this
> (actually, it might be imposed as opposed to voluntarily on a couple
> ports, but we are under consideration as well).

yes. if i had to decide ;), i'd drop a few ports from the 2.0 release in 
order to

i) stabilize those ports

ii) get 2.0 out (finally)

the ports which don't make it into 2.0 release should focus on 
bugfixing, not adding features like gfx board x runs X, y doesn't yet, 
so let's add support for y etc. etc.

that is, for the macppc port, fixing the mfs /tmp issue (as i read 
before, a patch seems to be available, but not committed yet), the SCSI 
sync stuff, MP related panics, and, as a patch is available (?), the 
vgahw issue on leaving X to console.

a nice way to go (IM very HO) would look like this:

* stable & enough polished ports -> 2.0

* ports dropped from 2.0 release -> 1.6.4, 1.7 or even 1.9?

* reunion in 2.0.n or 2.1

> 
(...)
> 
> My point is, we are in danger of holding up the 2.0 release. We can't do
> that. We are better off freezing the RC cycle until we meet our own
> milestones, like a rock solid X.

from the point of view mentioned above, this would be work on 
1.6.4/1.7/1.9...

> Then, when we are synced with the
> latest tag, we can announce that macppc is tagged.

2.0.nRC or 2.1RC ;)

> And when we finally
> reach -release quality, we do another announcement.

that would be the point to 'reunion'...

> Everytime we do an
> announcement it brings publicity for NetBSD. That is a lot better than
> releasing something as 2.0 that is probably a step backwards from 1.6.2,
> due to architectural/port issues and not due to the 2.0 kernel.
> 
> sincerely,
> tim

regards,

timo