response 486 of 547:

Oct 21 17:14 UTC 2003

Now, now, let's not mince our position.  We *did* buy top of the line
new hardware, with the intention of moving to the newer machine sooner
than later.  I will agree it wasn't our primary goal to have a super-
computer to run grex on, but that doesn't excuse us being this slow.
We really do have to do better.

I'm going to suggest that, if staff agrees to move to nextgrex within
three months, we end this thread of discussion.  Pointing fingers and
complaining about what we didn't do isn't going to help us achieve the
goal of moving to the new machine sooner than later.  Let's not lose
sight of what's important here: getting nextgrex running.

That said, I think we have a limited amount of time available until
OpenBSD 3.4 comes out.  Let's make profitable use of that time by trying
to hash out some of the remaining technical issues before we have to
start slinging away with configuring and documenting the new machine.

Let's just get this thing done and move on to other issues.

response 488 of 547:

Oct 24 03:55 UTC 2003

Let me clarify my position a little bit.

It's my intention to ask questions and to get the answers.  I just 
wanted to find out why NextGrex isn't being used yet, and when it will 
be used.  I still don't know either of those things.  Dan Cross is 
certainly stepping forward and setting expectations, but I don't know 
if the staff as a whole is going to accept and meet those expectations.

It's not my intention to bash anyone.  I don't think the NextGrex 
implementation needs to be about personal feelings.  If person A isn't 
going to get the job done -- for *whatever* reasons; I haven't asked 
for the reasons and no one has volunteered them -- then if there is a 
person B, that person should allowed to give it a shot.

There are "person B" people available, by the way.  Grex is lucky that 
it doesn't have to be dependent on one individual for it's survival 
and future direction.

re resp:485: I apologize for any of my comments which may seem to 
stretch a point or two.  Grex could have bought a 3.0 GHz machine in 
February, instead of a 2.2 GHz machine, so in that sense it's new 
hardware is not "state of the art".  And I don't care if it's state of 
the art in that sense; that wasn't my point.

It *was* new then, and is not new now.  If we had waited a year to 
buy, we'd be better off.  That's what probably should and would have 
happened, had we known there was no commitment to put Grex on the new 
hardware last winter and spring.  Having the NextGrex hardware sitting 
unused is hurting Grex.  *That* was my point.

re resp:487: Yeah, the warranty remark was a stretch.  A hardware 
warranty isn't of that much relevance.

response 490 of 547:

Oct 24 13:22 UTC 2003

Re #488:
> It *was* new then, and is not new now.  If we had waited a year to 
> buy, we'd be better off.  That's what probably should and would have 
> happened, had we known there was no commitment to put Grex on the new 
> hardware last winter and spring.

Honestly, I think this is a bit of a catch-22.  You're not going to get
people to commit time and effort until they know there's a will to spend
money on the hardware.

response 492 of 547:

Oct 25 01:10 UTC 2003

Well we tried waiting, for over a year, with the idea that we would install
the OS on two different types of hardware and then pick one.  Nothing
happened.  Last winter the consensus was that we should commit to Intel
hardware and buy what we need, because then staff would be more likely to do
something.  So we bought it.  We made some progress at first, but now we're
stalled.  I'm glad cross is trying to jumpstart the process.

response 494 of 547:

Oct 25 12:50 UTC 2003

Errr, last line 491 software=hardware.

response 496 of 547:

Oct 25 23:37 UTC 2003

They have not stalled it on purpose.  Both are in the midst of other time
crunches at work.  Between volunteer work and salaried work, salaried work
wins out.  I, personally, know that if STeve spends much more time away from
home and family, there will be no home or family.  I have seen very little
of him since about 2 weeks before the big power outage because he is spending
all of his awake time fighting various incarnations of Microsoft yuckiness.

That, coupled with my insane class/work schedule means we get no 'us' time
as it is.  He is not dragging his feet on the NextGrex.  There is only so much
time available and right now it is onverfull.  Believe me, he feels badly that
he doesn't have more time.  But, I have put my foot down.  I don't want him
to have another stroke because he is pushing the envelope too far.  As much
as I love Grex, it just isn't worth it.

response 498 of 547:

Oct 26 01:05 UTC 2003

Glenda, I don't want to slight either STeve or Marcus.  I definitely 
don't wish either of them bad health.  They have done a lot of things 
for Grex that I appreciate.  I understand about having a life, as well.

However, if there's something that needs doing, that's waiting on you, 
that you can't do, there is nothing wrong with saying, "Someone else 
do this.  I can't."  It occurred to me that that could possibly 
resemble the situation here.

response 500 of 547:

Oct 26 02:51 UTC 2003

Other structural issues such as those raised by Mary (in #463) and
others need to be discussed but that really ought to be
separated from discussion on the tactics of getting nextgrex into 
production as soon as possible.

Seems to me you have X amount of work waiting to be done, Y number of
staff trusted and capable of doing this kind of work and only a subset
available to do it.

We want to promote nextgrex into production in as little time T as
possible.  How much time that is can (and has) be(en) argued but it
remains that to reduce the time you can:

1) Reduce the amount of work required for go live

Possible.  Depends on what is critical-path.  Throwing in
non-critical-path distractions like replacing Picospan as was suggested by
someone earlier does little to reduce T.  Shortcuts may be an option
in some areas, but must be weighed against security/integrity
risks and a call made whether the deferred cost in staff time (remember
short cuts need to be cleaned up) is worth it.  Personally, I'm willing
to give up some time to insure our new system is well documented, stable
and secure.

2) Increase the number of people working on the upgrade

This is tougher.  You can't just expand the pool of trusted technical
staff overnight.  Trust is something earned over time and a track record
of delivering.

Basically to reduce T here we either discover underutilized people
resources within the existing group of trusted or semitrusted staff, or
possibly implement some system of work delegation non-staff volunteers
that applies limited staff time to reviewing work done by them.  However,
there may practical limitations on the value of mixing in more people
or farming out the work.

Moving forward, we should take a hard look how to redistribute technical
responsibilities to reduce the pressure on individual staff and avoid
single points of failure but our options for the immediate term are
limited by the above.  From what I gather, the main tasks remaining are:

* Recompile Picospan for OpenBSD
* Setup newuser
* Configuration tuning, whatever smallish tasks janc refers to in #472.
* Mail
* Transfer the data

Mail seems to be the only significant one.  Perhaps we can sort out an
agreement from Jan and Marcus that Dan move ahead on what he would like
to do with the understanding he document as he builds it out and they
make some time to review.

For the record, if there are tasks that can be delegated to non-staff,
please add my name to the roster of volunteers.

My apologies for letting this get so long.  Price of having lurked for
so long, I guess :-)

response 502 of 547:

Oct 26 03:21 UTC 2003

My understanding is that OpenBSD is totally changing their binary format and
breaking backwards compatibility, so it will have to be recompiled. 
However, if he's already compiled it once, there's probably nothing
time-consuming to do.

response 504 of 547:

Oct 26 04:11 UTC 2003

What's the big deal with Picospan?  From what I've heard, Marcus has control
of the source.  He can put it where he wants.  Switching now doesn't gain us
anything.

response 506 of 547:

Oct 26 15:02 UTC 2003

Re #495 - Intel vs. Sun.  Marcus and STeve are in favor of moving from
Sun to Intel hardware.  In fact, at the meeting where we decided on what
type of hardware to purchase, STeve made that recommendation, speaking
for himself and Marcus.  Subsequent to that, STeve was actively involved
in the hardware acquisition process.

If I had to speculate on the reasons for slow progress - the fact is
that several key staff members had unexpected situations come up in
their lives that limited the time they had available to work on
NextGrex.  I think everyone on staff is committed to getting the
work done and is making an honest effort to do so within the
time constraints they have to deal with.

response 508 of 547:

Oct 26 19:08 UTC 2003

Regarding #506; I think the thing that's upsetting some folks, and
perhaps rightfully so, is this idea that there are some staff members
who are `key' at all.  In reality, that's the way it's always going
to be, but that doesn't mean the rest of us should be paralized by
it.

response 510 of 547:

Oct 26 21:08 UTC 2003

I concur.  I just wanted to attempt to clarify.