Brutus going down

[Leo Simons <ma...@leosimons.com>]

Hi gang,

Brutus will be going down somewhere today or tomorrow. It will be wiped to
start hosting Apache's SVN install.

Berin is working to get the people with admin privs those privs on vmgump;
we'll do the same for the gump zone on helios. When we've got those under
control we'll re-enable nagging from vmgump.

The forrest people have moved all their vital stuff to a new zone on helios
already.

It is likely that there won't be any e-mail sent out by gump for a few days.

It is likely that the non-standard workspaces (kaffe, testing and jdk15)
will be offline for quite a while.

All our URLs are going to change. Don't worry, we'll have the ability to set
up redirects from "the new brutus" later.


Cheers,


Leo



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Brutus going down

[Stefan Bodewig <bo...@apache.org>]

Leo,

this also means we won't have any more nightlies for Ant (I already
forwarded the mail to dev@ant).

>From my POV you don't need to bother with reinstalling it since we
should either set up a zone on helios to perform nightly builds for
interested projects (maybe that already exists?) or have Ant request a
zone for itself.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Brutus going down

[Stefano Mazzocchi <st...@apache.org>]

Leo Simons wrote:
> Adam wrote:
> 
>>Stefano wrote:
>>
>>>DON'T KILL THE LOGS!!!!!
> 
> 
> Hehehe. I already had mysql backed up locally.
> 
> 
>>Would that they'd be logs. We never had space (or haven't optimized
>>sufficiently) to keep the build logs. Gump's (internal) logs aren't worth a
>>lot, but exist, if wanted.
> 
> 
> I really doubt we'll be able to salvage much from those. And they take
> up a few 100 megs.

I will dump those out myself. I just bought a 250Gb firewire drive :-)
(and my group is buying a new box that has 1Tb of stuff in it, disk
space is not our problem any more ;-)

>>I hope we give good consideration to 'Net
>>history (and access for external services, e.g. google) with Gump3.
> 
> 
> Aye.
> 
> 
>>>Adam, can you give us (or leo) pointers to where is all the data that
>>>gump saves so that we can restore it on the new installation?
>>
>>Basically there is the MySQL database, and a DBM file (at
>>/usr/local/gump/public/gump/work/stats.db). These contain what history we
>>have. [Same DBM exists for Kaffe, JDK1.5, etc.]
> 
> 
> Got all of those. 1000kb, gzipped.

that's it?

>>BTW: Are we saving the crontab and any scripts in ~gump, Leo? Could be
>>valuable. Where ought we put these to be moved, into Gump SVN?
> 
> 
> yes. Also see http://wiki.apache.org/gump/VmgumpConfig
> 
> 
>>BTW: I hope '/usr/local/gump/packages' is being moved across.
> 
> 
> yep, those are on vmgump as well.

cool.

> 
> 
>>That'd remove
>>a huge chunk of the pain of a fresh install.
> 
> 
> Really, it'd be good to go through that pain. There is *so* *much* cruft
> in the packages dir. We've only added there (for many years), never
> pruned. No-one can really mirror our install and get a similar tree
> without that cruft.

very true, but it's going to be painful to replicate. you volunteering? ;-)

> 
> 
>>Also, if we kept
>>'/usr/local/gump/staging' (along w/ timestamps) then Gump might continue to
>>accurately records how long since a code update (on more stale projects.)
> 
> 
> Uh. Gump's been running on vmgump for a while. It'd mean throwing /that/
> info away.
> 
> ...
> 
> We shouldn't be /too/ fussed about being librarians. Or, alternatively,
> scratch your itch.

I will. Did I mention I work for the libraries :-)

> There's a full backup from second-half-of-march of all drives sitting on
> the firewire drive attached to brutus.

ah

> I hope to give that stuff a
> permanent home when we get the 1TB drive storage hooked up to helios.

kewl.

> Combined with the databases, I think that's "enough".

I'll do another round of saving myself, but yes, that reassures me.

> From a sysadmin POV, gump consumes too much disk space to be snapshotted
> in full, and its hard (see above) to figure out what bits do need to be
> saved, and near-impossible to do something with those bits. That needs
> to be neatly split out. If you (no-one in particular) wish perfect
> conservation of output, fix things so its easy to administer them that
> way. I.e.
> 
> /usr/local/gump/save-this-every-day
> /usr/local/gump/save-this-once-a-month
> /usr/local/gump/this-is-in-svn
> /usr/local/gump/this-is-just-cache-lose-it-if-needed

Yes, this is called for. Gump will be of incredible historical value in
the future, but things get saved only when they are well behaving and
now gump was not designed with digital preservation of its findings in
mind... but given the cost of storage, I think we should rethink that.

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Brutus going down

[Leo Simons <ma...@leosimons.com>]

Adam wrote:
> Stefano wrote:
>>DON'T KILL THE LOGS!!!!!

Hehehe. I already had mysql backed up locally.

> Would that they'd be logs. We never had space (or haven't optimized
> sufficiently) to keep the build logs. Gump's (internal) logs aren't worth a
> lot, but exist, if wanted.

I really doubt we'll be able to salvage much from those. And they take
up a few 100 megs.

> I hope we give good consideration to 'Net
> history (and access for external services, e.g. google) with Gump3.

Aye.

>>Adam, can you give us (or leo) pointers to where is all the data that
>>gump saves so that we can restore it on the new installation?
> 
> Basically there is the MySQL database, and a DBM file (at
> /usr/local/gump/public/gump/work/stats.db). These contain what history we
> have. [Same DBM exists for Kaffe, JDK1.5, etc.]

Got all of those. 1000kb, gzipped.

> BTW: Are we saving the crontab and any scripts in ~gump, Leo? Could be
> valuable. Where ought we put these to be moved, into Gump SVN?

yes. Also see http://wiki.apache.org/gump/VmgumpConfig

> BTW: I hope '/usr/local/gump/packages' is being moved across.

yep, those are on vmgump as well.

> That'd remove
> a huge chunk of the pain of a fresh install.

Really, it'd be good to go through that pain. There is *so* *much* cruft
in the packages dir. We've only added there (for many years), never
pruned. No-one can really mirror our install and get a similar tree
without that cruft.

> Also, if we kept
> '/usr/local/gump/staging' (along w/ timestamps) then Gump might continue to
> accurately records how long since a code update (on more stale projects.)

Uh. Gump's been running on vmgump for a while. It'd mean throwing /that/
info away.

...

We shouldn't be /too/ fussed about being librarians. Or, alternatively,
scratch your itch.

There's a full backup from second-half-of-march of all drives sitting on
the firewire drive attached to brutus. I hope to give that stuff a
permanent home when we get the 1TB drive storage hooked up to helios.
Combined with the databases, I think that's "enough".

>From a sysadmin POV, gump consumes too much disk space to be snapshotted
in full, and its hard (see above) to figure out what bits do need to be
saved, and near-impossible to do something with those bits. That needs
to be neatly split out. If you (no-one in particular) wish perfect
conservation of output, fix things so its easy to administer them that
way. I.e.

/usr/local/gump/save-this-every-day
/usr/local/gump/save-this-once-a-month
/usr/local/gump/this-is-in-svn
/usr/local/gump/this-is-just-cache-lose-it-if-needed

cheers!

LSD

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Brutus going down

["Adam R. B. Jack" <aj...@apache.org>]

> DON'T KILL THE LOGS!!!!!

Would that they'd be logs. We never had space (or haven't optimized
sufficiently) to keep the build logs. Gump's (internal) logs aren't worth a
lot, but exist, if wanted.  I hope we give good consideration to 'Net
history (and access for external services, e.g. google) with Gump3.

> Adam, can you give us (or leo) pointers to where is all the data that
> gump saves so that we can restore it on the new installation?

Basically there is the MySQL database, and a DBM file (at
/usr/local/gump/public/gump/work/stats.db). These contain what history we
have. [Same DBM exists for Kaffe, JDK1.5, etc.]

BTW: Are we saving the crontab and any scripts in ~gump, Leo? Could be
valuable. Where ought we put these to be moved, into Gump SVN?

BTW: I hope '/usr/local/gump/packages' is being moved across. That'd remove
a huge chunk of the pain of a fresh install. Also, if we kept
'/usr/local/gump/staging' (along w/ timestamps) then Gump might continue to
accurately records how long since a code update (on more stale projects.)

regards

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Brutus going down

[Stefano Mazzocchi <st...@apache.org>]

Adam R. B. Jack wrote:
>>Brutus will be going down somewhere today or tomorrow. It will be wiped to
>>start hosting Apache's SVN install.
> 
> 
> For somebody trying to play catch-up, where are the alternative places to
> run a Gump instance? I'd like to be able tinker with a Gump3 on some *nix
> type platform, and I could perhaps help a little w/ any Gump2 re-installs.
> Thanks in advance for any pointers to wiki pages (and/or ways I can find
> where/how I need to log in.)
> 
> Also, a random observation. It is interesting that we aren't wanting to save
> the database of 'historical information' that we've accumulated (in MySQL,
> or DBM). Sure, few really know it is there (given we don't have a
> presentation interface into it) but I also wonder at it's value. Is
> historical information really important to Gump's contributions, or is it
> more in the here an now? That, or if it isn't in a form that
> aggregators/index engines can consume, it doesn't fit today's world. I
> wonder if there is something in either of these.

DON'T KILL THE LOGS!!!!!

please, please, please, let's keep the logs!!! there is a goldmine of 
information there that is waiting to be explored!

Adam, can you give us (or leo) pointers to where is all the data that 
gump saves so that we can restore it on the new installation?

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Brutus going down

["Adam R. B. Jack" <aj...@apache.org>]

> Brutus will be going down somewhere today or tomorrow. It will be wiped to
> start hosting Apache's SVN install.

For somebody trying to play catch-up, where are the alternative places to
run a Gump instance? I'd like to be able tinker with a Gump3 on some *nix
type platform, and I could perhaps help a little w/ any Gump2 re-installs.
Thanks in advance for any pointers to wiki pages (and/or ways I can find
where/how I need to log in.)

Also, a random observation. It is interesting that we aren't wanting to save
the database of 'historical information' that we've accumulated (in MySQL,
or DBM). Sure, few really know it is there (given we don't have a
presentation interface into it) but I also wonder at it's value. Is
historical information really important to Gump's contributions, or is it
more in the here an now? That, or if it isn't in a form that
aggregators/index engines can consume, it doesn't fit today's world. I
wonder if there is something in either of these.

regards

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Move public onto JDK 1.5? (was Re: Brutus going down)

[Stefano Mazzocchi <st...@apache.org>]

Adam R. B. Jack wrote:
> Leo wrote:
> 
> 
>>It is likely that there won't be any e-mail sent out by gump for a few
> 
> days.
> 
>>It is likely that the non-standard workspaces (kaffe, testing and jdk15)
>>will be offline for quite a while.
> 
> 
> Does it make sense to move public (with nagging) to JDK 1.5?

-1, macosx still doesn't have 1.5 stable.

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Move public onto JDK 1.5?

[Stefan Bodewig <bo...@apache.org>]

On Mon, 23 May 2005, Adam R. B. Jack <aj...@apache.org> wrote:

>> I find this time quite interesting since we see projects embrace
>> JAXP 1.3 and in particular DOM3 at very different paces.
> 
> Yeah, in fact, I think it is one of the biggest deals in my memory
> of Gump.

You haven't been around for the 1.3 -> 1.4 transition 8-)

JDBC 3.0 or the fact that the JDK ships with JCE and JAXP have been
interesting as well.

> It has started to make me realize that the 'events' such as this,
> big discontinuities/big disruptions, are truely newsworthy ... and
> perhaps ought be publicized.

True.  But at the same time you cannot avoid them if you want to
evolve interfaces.

> I know you blogged about this Stefan [1], but I wonder if we ought
> have brought it up to the ASF board, and if the ASF board ought
> consider taking action based of the findings.

board would have been the wrong place for this.  Our JCP rep may have
been a better choice, but I don't think it would have changed
anything.

I don't see any way how JAXP could have embraced DOM3 without breaking
existing implementations of some interfaces.  Sure, they could have
used abstract classes instead of interfaces in the first place.

> Who knows, maybe Sun would respond to ASF highlighting a bunch of
> discontinuities. Maybe a dialogue ought occur.

If we want to do that, what we really need is Gump running on Mustang
nightlies.

> I figured a few nags might cause a few "enums" to be renamed, and
> add some value speeding up the conversion.

I already tried for Jakarta Commons and Dims committed all my patches.
There have been others, but most projects have been non-ASF projects
some of which looked stalled.

And then we had a few Maven built projects that needed to adapt to
make javac happy (specifying -target 1.1 but not setting -source at
all).  For Ant builds we've fixed them (i.e. Ant "fixes" javac's new
default for -source) with a change in Ant that went into 1.6.3.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Move public onto JDK 1.5?

["Adam R. B. Jack" <aj...@apache.org>]

> On Sun, 22 May 2005, Adam R. B. Jack <aj...@apache.org> wrote:
>
> > Does it make sense to move public (with nagging) to JDK 1.5?
>
> Not yet, IMHO.
>

Ok. I just didn't want us to give up on all the Gump flavours w/o having
asked the question.

> > Given that we can't support all configurations, and given the level
> > of turmoil the JAXP 1.3 seems to be causing, ought we not just dive
> > in w/ both feet & embrace change?
>
> I find this time quite interesting since we see projects embrace JAXP
> 1.3 and in particular DOM3 at very different paces.

Yeah, in fact, I think it is one of the biggest deals in my memory of Gump.
It has started to make me realize that the 'events' such as this, big
discontinuities/big disruptions, are truely newsworthy ... and perhaps ought
be publicized. Gump 'represents'a reasonable chunk of base Java code,
classes that are (no doubt) underneath a lot of Java applications, and if
this base suffers badly from a change, that will ripple significantly.

I know you blogged about this Stefan [1], but I wonder if we ought have
brought it up to the ASF board, and if the ASF board ought consider taking
action based of the findings. I don't know what could (or should) be done,
but I wonder if we need to be more vocal about the findings. It seems that
without nagging Gump is a passive observer, and -- like the tree falling in
the woods w/ nobody to see it -- did it happen?

[I know I'm overlooking the human factor here, the people who read the
output, but I think this is far fewer than the data could interest (we need
to market this information source).]

> > Since (I believe) JDK ought be compile compatible w/ older JDKs,
>
> Do you really belive this was true?  Or is this just what you whish
> would be true?  ;-)

Yup, bad wording. I don't beleive it ('cos I've learned that much from Gump
interacting w/ JDKs, from over the years) but I sure do wish it were true.
Gump has taught me that discontinuities happen -- even in the best
maintained projects, with the best intentions -- they have to be allowed
for "progress". That said, unintentional discontinuities are the pits, a
waste for everybody involved that slows progress, and I feel Gump needs to
help spotlight any such things. Who knows, maybe Sun would respond to ASF
highlighting a bunch of discontinuities. Maybe a dialogue ought occur.

> > Seems relatively healthy, and not too painful. That said, I'm not
> > expert, I'm just asking a question.

I thought about this (unfortunately) right after Brutus went down, so I
couldn't check what I was hoping. Kinda sad how the data disappears so
quickly. I figured a few nags might cause a few "enums" to be renamed, and
add some value speeding up the conversion. I'd not considered the nagatives
that you see. Time might help there, like you said, and we can give a little
to see if it does. Perhaps we ought nag (once a week/month) from a JDK 1.5
run.

All in all, I find the handling of the discontinuities -- the recording of
them, the bringing things to light -- the primary role of Gump, and I sure
wish we had a better way of documenting it/publicizing it. I think
individual failures in Gump (once stable in itself) ought generate a JIRA
entry (or database record) that gets worked/tracked to resolution. With some
level of consistency Gump's information would accumulate, not be lost, and
as a whole would be far more effective/valuable.

I think there is a lot to explore here, a lot to discuss, I just have a day
on diaper duty and breakfast to attend to [hence the no doubt
distracted/incomplete sentances].

regards,

Adam

[1] http://stefanbodewig.blogger.de/stories/167334/


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Move public onto JDK 1.5?

[Stefan Bodewig <bo...@apache.org>]

On Sun, 22 May 2005, Adam R. B. Jack <aj...@apache.org> wrote:

> Does it make sense to move public (with nagging) to JDK 1.5?

Not yet, IMHO.

> Given that we can't support all configurations, and given the level
> of turmoil the JAXP 1.3 seems to be causing, ought we not just dive
> in w/ both feet & embrace change?

I find this time quite interesting since we see projects embrace JAXP
1.3 and in particular DOM3 at very different paces.

> Since (I believe) JDK ought be compile compatible w/ older JDKs,

Do you really belive this was true?  Or is this just what you whish
would be true?  ;-)

> Seems relatively healthy, and not too painful. That said, I'm not
> expert, I'm just asking a question.

If you look through the latest JDK 1.5 Gump runs you'll see a few
projects which look more or less dead (jython) but don't build and are
important in Gump's chain.

Switching to JDK 1.5 now may cause the projects that don't build
because they are specifiying an incompatible combination of -source
and -target or don't specify -source at all to improve.  It may also
lead to projects rethinking their dependencies, but probably not
(they'll simply not notice that their won project doesn't get built at
all).

All in all I think we'd drop the number of projects we build every
night considerably with no real hope to get back quickly.  So I'm
rather +/-0 to the idea (not -1 since I don't believe our chances
would improve too much if we'd wait any longer either).

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Move public onto JDK 1.5? (was Re: Brutus going down)

[Leo Simons <ma...@leosimons.com>]

On 23-05-2005 04:43, "Adam R. B. Jack" <aj...@apache.org> wrote:
> Does it make sense to move public (with nagging) to JDK 1.5?

+0. I haven't been paying much attention to java5.

- Leo




---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Move public onto JDK 1.5? (was Re: Brutus going down)

["Adam R. B. Jack" <aj...@apache.org>]

Leo wrote:

> It is likely that there won't be any e-mail sent out by gump for a few
days.
>
> It is likely that the non-standard workspaces (kaffe, testing and jdk15)
> will be offline for quite a while.

Does it make sense to move public (with nagging) to JDK 1.5? Given that we
can't support all configurations, and given the level of turmoil the JAXP
1.3 seems to be causing, ought we not just dive in w/ both feet & embrace
change? It isn't as if folks run the jars that Gump generates, this is just
about early detection of compatibility issues.

Since (I believe) JDK ought be compile compatible w/ older JDKs, with the
exception of some new keyword stumbled (e.g. enum), and since I doubt as
many folks pay attention to Gump runs as they do Gump nags, ought  not give
as much notice as poissible?

Seems relatively healthy, and not too painful. That said, I'm not expert,
I'm just asking a question.

regards

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org