Caveat: i don't speak for the i386 portmasters or the people who make
i386 binary releases. I'm only answering because i mentioned 1.3.1 in
the first place, and because I was explicit Cc:ed.  Please remember that.


Robert V. Baron writes:

>I too have asked about the 1.3.1 binaries a while back.  But for me
>its too late.  We have converted 4 machines to 1.3 and will do a whole
>slew soon.  Converting means lots of people have to rebuild their code
>and I can't tell them surprise 1.3.1 is now here lets rebuilt again.

Ummm, the point about minor releases is that you don't *have* to
recompile again. You can drop 1.3.1 kernel and /usr/lib into a 1.3
system and it should Just Work.  It did for me on pmaxes.

>But that's not what I want to talk about.  1.3 sysinst simply does not
>work reliably.

Not for creating MBR partitions, no. Otherwise (e.g., for upgrades),
or on other platforms, (e.g., on pmax) it works fine.



>  We all know this so I'll leave the gorry details till
>later if anyone cares. 

Yes, we care :-(.  Testing sysinst on i386 wassn't up to me.  People
did a conscientious job. But from the fallout, obviously, they didn't
have a wide enough range of machines and setups to test.


>Now I'm more than willing to believe that all
>these problems are worked out on 1.3.1; lots of us have helped to make
>sysinst better.  But if noone has a 1.3.1 install floppy it really
>does not matter.

I wish I was that confident ;).  But building binary releases is up to
the portmaster or the person designated to build binary releases.


As pmax portmaster, I try hard to let people know ahead of time what
my schedule is, what to expect, and when; and to let them know if that
changes.  That seems to work well for the pmax port; users know what
to expect, and when, and if there are changes to the anticpated
schedule, they know that ahead of time, too.  It's as if keeping
people informed of what to expect, is actually more important than
exactly when a binary release becomes available.  

That worked well for me withthe pmax 1.3 release, when I broke my arm
immediately before a planned trip back home to New Zealand, and before
I got the 1.3 pmax sets built. I think it's a good strategy.


Other NetBSD developers have very different attitudes.  Something like
this: that NetBSD is a volunteer project, they do netbsd stuff as and
when they have time; and they don't provide advance schedules (or only
very very soft ones, with no annoucenment of slippages).  Maybe its a
personal workstyle thing.  I dont know which is better, but I see much
fewer queries about availability on port-pmax, and a lot less unhappiness.

I also built a "1.3.1_BETA" pmax release about a month before the
final 1.3.1 announcement; that caught a lot of buglets, gave people a
taste of 1.3.1, and was probably a good idea.

If providing better announcements and binary release schedules would
help, then *ask* for them.  If providing early pretests of minor
relases is would help, *ask* for them.  It means more work, which
means changing the priorities of the developers (or finding more
developers!) and that won't happen unless it's very clear that it
means enough, to enough users, to allocate the effort.

(NB: see the disclaimer. I'm not speaking for Charles or Frank or Perry!)


>Let me be specific at what did not work, and maybe this affects a
>small enough base that we don't care. 

[snip]

No, I think we care very much. But 1.3.1 has fixed so much in sysinst
its hard to know what to do.  If you have one new machine that you can
redo this with, when 1.3.1 is available, that would be Really Cool.
If you do that, and send a PR, I'd be very grateful.
In fact,  send the PR, and email to the  list, either way.

--Jonathan.