Re: [RFC] Enhanced Garbage Collection Probe Points

[Mark Wielaard <mark at klomp dot org>]

On Thu, 2012-11-01 at 14:32 -0400, Jon VanAlten wrote:
> I would also prefer the 7 stuff to go to the forest, but...
> 
> > From: "Mark Wielaard" <mark@klomp.org>
> 
> <SNIP>
> > 
> > Adding patches directly to the tree is fine with me.
> > My only hesitation was my own confusion since the default
> > configure/make setup doesn't pick up a patched forest.
> > You don't have that issue with patches, which are directly
> > applied. If we are going for a complete forest setup it
> > might make sense to also add the tapsets and testsuite
> > directly there.
> > 
> > I'll try and figure it all out again and also port the existing
> > patches to the forest. Hints and tips appreciated.
> 
> So about this patch and 7, I'm getting mixed messages here.

What is the mixed message? I am fine with adding patches directly to the
forest and even adding the other stuff like the tapsets and the
staptests there. I just don't know the workflow when I would work
against the forest directly and not just have patches in the tree. And I
just haven't found the time to create a new workflow. I am sure it is
just a different ./configure flag, just haven't figured out which one.
So, how do people work against the forest directly? What configure flags
do they use? What does your edit/build/test/commit/pull cycle look like?

Basically the only step I seem to miss is how to make sure the tree is
in sync with what I push to the forest. Somehow I am missing how when I
commit to the forest the icedtea tree is updated so people who update
their tree get the new patch. Knowing how that works would also help
with making sure the buildbot rebuilds the tree each time the forest is
changed and not only when a patch is added to the tree.

Cheers,

Mark