|
|
| Author |
Message |
| 25 new of 547 responses total. |
jp2
|
|
response 477 of 547:
| 
Oct 20 18:02 UTC 2003 |
This response has been erased.
|
jep
|
|
response 478 of 547:
|
Oct 20 19:00 UTC 2003 |
I'd like to think we aren't waiting for new software to be developed
for NextGrex, because that would appear to me to be an indication of
major further delays. Why were we in such a hurry to buy the hardware
if we're so far away from using it?
My expectation, when I saw we were buying new hardware, is that "we"
(the staff) knew how it was going to be used, or thought they would
know soon and had reason to believe they could begin using it. If we
know we're using Picospan and that it's going to be ready in small
amounts of time, that's terrific; it doesn't need to be worried about.
Resp:474 implies the holdup is designing a mail system. Folks, this is
not the right time to be designing a new mail system! The right time
was before the hardware was bought. Maybe Next^2Grex can have the
perfect mail system, after a few years of development. I'd like to
respectfully request you quit screwing around with garbage like that,
at least quit allowing it to hold up the new Grex machine, and install
something available now.
|
cross
|
|
response 479 of 547:
|
Oct 20 19:07 UTC 2003 |
Regarding #477; If you can get it done in the next three months, we'll
consider it. We'll consider anything. However, the priority now should
be doing whatever will take the least amount of time.
Regarding #478; That's what I said. I plan on just building a mail system
and moving on. If it's imperfect, we can fix it later. But right now,
the goal *has* to be getting something reasonable up in short order.
The only thing it would be silly not to do is wait for OpenBSD 3.4 to
come out. That's less than two weeks ago, though, so won't be a huge
deal. On that, we're hamstrung by a megalomaniac in Canada, though.
|
jep
|
|
response 480 of 547:
|
Oct 20 21:48 UTC 2003 |
re resp:479: Dan, it's my impression you need buy-infrom the rest of
the staff for the new mail system and that you don't have it. I think
I was speaking to the staff as a whole rather than to you, indicating
that, in my opinion, we have to go ahead.
If my impressions are wrong, you have enough freedom to go ahead with
implementing a standard mail system, have committed to doing so, and
that that major roadblock (as described earlier in this item) is not
going to be a hold-up... that's terrific. Congratulations to you and
to all of us.
But it still leaves open the question, which I raised on Friday...
what's the next hold-up? What's going to be done about it?
Finally, in the end... when do we, the non-staff users, get to be on
the new hardware? However pointedly, brusquely (or other euphemisms
for rudely) I've asked it, I think it's a valid question to be asking,
and I don't feel like I have received an answer yet.
|
cross
|
|
response 481 of 547:
|
Oct 20 22:32 UTC 2003 |
You're right, I do need buy-in from the rest of staff. But what I
think we need buy-in for is to just *do* things without a huge amount
of debate and public discussion. Something needs to be done, let's just
do it instead of trying to appease everyone. That can come later.
Like I said, I think three months is a reasonable timeline. But again,
that's dependent on staff buying into it, and on us agreeing to just do
the work.
|
gull
|
|
response 482 of 547:
|
Oct 21 13:27 UTC 2003 |
For those who are worried the new hardware will be obsolete before we
get onto it:
I don't see this as a concern. We're not building a system to play the
latest shoot 'em up game here. It doesn't matter if our hardware is
obsolete as long as it's fast enough to do what we need it to. Grex has
been running on obsolete hardware for as long as I've been using it.
There are reasons to be unhappy about the delays, but fear of
obsolescence is not one of them.
It's important that we get this system up and running soon. But it's
also vitally important that it be set up right, and documented
thoroughly. Thorough documentation is our only way out of the "we need
to wait for person X to fix it, because only they know how that works"
syndrome that curses us right now. That's worth spending extra time on,
and I'm willing to wait for it.
|
cross
|
|
response 483 of 547:
|
Oct 21 14:54 UTC 2003 |
There's a difference between doing a thorough, but *speedy* job, and
continuing to do what we have been, which is nothing, while we make
noises about needing more time to do it right. Remember, it doesn't
matter whether we do it right or wrong if we don't do it at all!
|
jep
|
|
response 484 of 547:
|
Oct 21 16:25 UTC 2003 |
We bought brand new equipment with the idea of running Grex on hardware
that *wasn't* several years old. That brand new equipment will have
passed it's warranty period before NextGrex is anywhere close to being
up and running.
|
other
|
|
response 485 of 547:
|
Oct 21 16:32 UTC 2003 |
The idea was to make a significant infrastructure improvement, and of the
ways to do that, the best investment was in new hardware.
The relative age of the Grex hardware versus the current standard has *
never* been an issue of concern (except as it relates to the ability of
Grex to provide even the basic services for which it exists), and very
likely never will be.
|
cross
|
|
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.
|
aruba
|
|
response 487 of 547:
|
Oct 21 23:26 UTC 2003 |
John - ifit's any consolation, NextGrex has been up and running since not
long after we got the hardware. So most waranteeable problems would have
showed up by now.
|
jep
|
|
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.
|
gelinas
|
|
response 489 of 547:
|
Oct 24 04:03 UTC 2003 |
I don't think the current state is "hurting" grex, but I do agree it's not
really helping. And waiting a year to buy the hardware wouldn't have helped,
either.
We are setting up a checklist of things to be done. The next step is to
install OpenBSD 3.4, which janc agreed to do.
|
gull
|
|
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.
|
cmcgee
|
|
response 491 of 547:
|
Oct 24 21:40 UTC 2003 |
I disagree that we should have waited to buy. As I understand the process,
you have to make sure the software runs correctly on a specific hardware
configuration, not a hypothetical one.
While we might have moved faster if we weren't a volunteer organization, or
if more people had more time, I just don't see that we should have waited on
the software.
|
aruba
|
|
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.
|
asddsa
|
|
response 493 of 547:
|
Oct 25 05:46 UTC 2003 |
Oh boy...time drags on...
re 489 There are dozens of reasons that show the current state is hurting
GreX.
|
cmcgee
|
|
response 494 of 547:
|
Oct 25 12:50 UTC 2003 |
Errr, last line 491 software=hardware.
|
jep
|
|
response 495 of 547:
|
Oct 25 23:26 UTC 2003 |
I agree with moving ahead if we were ready. I'm piqued that we spent
the money then stopped.
I'll raise another point, too. For years, there have been two people
who have been most adamantly against switching from Sun to Intel
hardware; Marcus and STeve. These are the two people who were most
needed to do anything new with Grex. I am on the outside; I'm not
involved with the process, but... these are the two people who have
stalled the move. Right?
|
glenda
|
|
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.
|
gelinas
|
|
response 497 of 547:
|
Oct 26 00:26 UTC 2003 |
Neither STeve nor Marcus, in my opinion, have been the roadblock; we
just haven't made as much progress as we would like. There are things we
could have used Marcus for, but we've been making some progress despite
his not being available.
|
jep
|
|
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.
|
cross
|
|
response 499 of 547:
|
Oct 26 01:49 UTC 2003 |
There's no one person who has stalled things. Marcus had some things he
wanted to do that we've been waiting on that I don't think are realistic
at this point: moving to Kerberos being the primary one.
I'm interested in what happened at the staff meeting. Obviously, I
can't attend them since I'm so far away, but I'm hoping some concensus
was reached on how to proceed. Joe mentioned in party the other night
that Jan is going to install OpenBSD 3.4 on nextgrex; hopefully we can
proceed from there.
|
bhoward
|
|
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 :-)
|
gelinas
|
|
response 501 of 547:
|
Oct 26 03:02 UTC 2003 |
(I thought I had heard that Marcus has already compiled Picospan for OpenBSD.
He'll probably have to do it again, before the migration, but it doesn't seem
to be a show-stopper.)
|
