forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <>
Subject RE: escaping the ego trap [was: RE: import of main site into forrest]
Date Mon, 10 Jun 2002 09:32:22 GMT
> > > Stefano's remarks and our own belief in release early &
> > often, we could
> > > contribute this as-is to Forrest.
> >
> > Great.
> I'm not sure and I'd rather want Bruno or Marc to answer this, but there
> might be some issues. As previously stated, we are thinking of further

Only issue I see is that switching the order from 1-refactoring 2-'make
public' to the reverse could increase the number of patches required...
and this discussion just kinda proved that we favor this over the other,

> Avalonizing it (to make it more open to other implementations than
> Cocoon only), and I assume the current build system might not be
> sufficient for this - so we'll have to patch this too, import some more
> stuff from the Cocoon build environment, and I currently don't know

euh, just need to get into the centipede way of working still, hadn't done
comments on how this is best done are welcome
(current guess is an extra xtarget under scratchpad?)

practically I'm now just throwing libre as is in the /src/scratchpad/java
section and considering the required build.xml and *.xtargets additions to
get it in there
(and the needed extra pipelines to get it to show)

I'll probably better add some libre.TODO explaining the refactorings we had
in mind
(ie the shortcomings we see)

as for docs... do you really need them :-P
(just ask I would say, some examples and being around to answer questions
makes more sense I guess, we'll see where itches occur, promise to help out

> whether Nicola thinks upgrading the current build system to Centipede
> 1.0 is still necessary.

How much will it affect the work if we switch later?
Can I help in joint-realizing the upgrade first?  Any head start?
(Somebody else that already started on it?)

> > > * We believe Libre has a scope which can be broader than Forrest,
> > > however, given the fact the refactoring currently going on is mostly
> > > about Avalonizing the thing, the idea of traversing other
> > repositories,
> > > and also having other output implementations than the
> > Cocoon Generator
> > > (there is a CLI output already, others may follow). So we don't know
> > > whether this should be part of Forrest, Cocoon, Avalon, Krysalis or
> > > We could contribute the Jar of course, but that
> > > means only we have CVS-access to the (open) source, which
> > is not in the
> > > spirit of our donation.
> >
> > No, I would not like to accept a binary donation anyway. I
> > would suggest
> > to keep the thing here in forrest for now.
> I won't commit it right now, I'd prefer to send a patch to the list and
> have some fellow Forresteers check it out on their local copies and see
> if it is fit for committing.
> > > * Practical issue: I'm not the author of the thing, only
> > the cardboard
> > > engineer. Marc Portier <> is,
> > and it would be
> > > very impractical for him/us when the canonical version
> > resides in a CVS
> > > repository where he has no commit rights to. At the same time, we
> > > sincerely believe this should not be an easy way of gaining commit
> > > rights for him on Forrest. So it is much more likely that
> > we start with
> > > adding it to SF, and re-using the Jar within Forrest. This of course
> > > will mean that it won't be readily available for
> > Forresteers, they will
> > > have to look it up on SF instead.
> >
> > Hmmmm, to be entirely honest with you, I think that the
> > normal routines
> > apply: somebody makes a donation, keeps submitting patches, developers
> > get bored of applying the patches to they give commit access.
> >
> > That's as simple as that, no need for SF proxying.
> I know Marc was readying himself for SF, so he has to answer that one,
> too.

let's go for this, we'll see how it works out in practice soon enough...

> > > * We could send an archive with source, examples, etc to interested
> > > parties or the list, if that would help in the mean time. I
> > won't expect
> > > the refactoring be finished soon, and we now understand
> > that this would
> > > be better with some more eyeballs looking into our work. I
> > am not sure
> > > whether we'll find these eyeballs here, maybe cocoon-dev is a better
> > > place.
> >
> > I think those doco-headed people are subscribed to both lists, so it
> > doesn't really matter. for now, I would suggest keeping the
> > focus on the
> > functionality (not the code) and donate it here in the forrest
> > scratchpad.
> +1 on the functionality
> > > We feel we might be missing an opportunity window here, so
> > please help
> > > us out in resolving this issue.
> >
> > Hope this helps.
> >
> > > Thanks for your patience,
> >
> > No probs.
> I thought so ;-)
> </Steven>

practical question: any people with strong feelings on the org.outerj.*
prefixing on the current classes?

my suggestion would be to really offer the classes as they are now (only
focussing on integrating build, which I am) then discussing new features,
refactoring and package renaming once we've all actually seen it?


View raw message