Re: escaping the ego trap [was: RE: import of xml.apache.org main site into forrest]

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

Steven Noels wrote:
> 
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> 
> > NOTE: I do this to avoid Steven and his colleagues to waste time. I
> > would be simple for me to vote -1 to libre and keep going with what we
> > have, but that would be very rude and unrespectful of their
> > contributed
> > effort.
> 
> Indeed :-)
> 
> OK - how do we proceed from here. Some points & issues.
> 
> * We have a pre-refactored version of libre in our own CVS, which does
> basically what I have described in
> http://marc.theaimsgroup.com/?l=forrest-dev&m=102336035108059&w=2. Given
> Stefano's remarks and our own belief in release early & often, we could
> contribute this as-is to Forrest.

Great.

> * 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
> outerthought.sf.net. 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.

> * Practical issue: I'm not the author of the thing, only the cardboard
> engineer. Marc Portier <ma...@outerthought.org> 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.

> * 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.
 
> 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.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

RE: escaping the ego trap [was: RE: import of xml.apache.org main site into forrest]

[Marc Portier <mp...@outerthought.org>]

> > > 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,
so...

> 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
that.
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
scratching)

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

Nicola?
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
> > > outerthought.sf.net. 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 <ma...@outerthought.org> 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?

-marc=

RE: escaping the ego trap [was: RE: import of xml.apache.org main site into forrest]

[Steven Noels <st...@outerthought.org>]

> From: Stefano Mazzocchi [mailto:stefano@apache.org]

> Steven Noels wrote:

> > OK - how do we proceed from here. Some points & issues.
> >
> > * We have a pre-refactored version of libre in our own CVS,
> which does
> > basically what I have described in
> >
> http://marc.theaimsgroup.com/?l=forrest-dev&m=102336035108059&
> w=2. Given
> > 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
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
whether Nicola thinks upgrading the current build system to Centipede
1.0 is still necessary.

> > * 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
> > outerthought.sf.net. 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 <ma...@outerthought.org> 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.

> > * 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>