You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Diana Shannon <sh...@apache.org> on 2003/03/21 21:42:56 UTC
cvs disruption (was: Re: Setting up a PMC mailinglist)
On Friday, March 21, 2003, at 08:15 AM, Steven Noels wrote:
> There's movement on the -docs list and perhaps also a Forrest quantum
> leap blossoming, so we'd better do this before or after this assumably
> disruptive step.
I also wanted to state strongly that I don't believe Forrest transition
needs to "disrupt" the Cocoon 2.1 repo. In spite of recent work that was
just committed, and in spite of the fact this already impacts doc
building, it remains possible to test the transition completely outside
of the cvs and check in files only when we are finished -- and if the
Cocoon project decides it **wants** Forrest (which has never been
subject to a vote). Up to now, I and a few others were pursuing a more
cvs-friendly approach where transition files were checked into Forrest
cvs for others to expand/test. Problem is, this approach doesn't attract
much positive attention, although at least it doesn't attract any
negative attention either.
I'm just concerned that some people may remain "bruised" from the recent
cvs problems that came about from upgrading the build. If anyone has a
problem with in-process Forrest files in the Cocoon cvs, we can adjust
course and pursue a more cvs-sensitive approach. Still, I think I may be
too conservative about these things. Perhaps the best thing is to simply
throw it in the cvs and let everyone help finish the work -- as is
happening right now.
Just looking for some advice.
-- Diana
Re: cvs disruption (was: Re: Setting up a PMC mailinglist)
Posted by Torsten Curdt <tc...@dff.st>.
> I'm just concerned that some people may remain "bruised" from the recent
> cvs problems that came about from upgrading the build.
I think as long as we decide/vote to go a specific trail there is no
reason to be "bruised" whether it is unpleasant for a while or not.
At least for HEAD :)
> If anyone has a
> problem with in-process Forrest files in the Cocoon cvs, we can adjust
> course and pursue a more cvs-sensitive approach.
No problem
> Still, I think I may be
> too conservative about these things. Perhaps the best thing is to simply
> throw it in the cvs and let everyone help finish the work -- as is
> happening right now.
Doesn't sound too bad :)
...just go ahead
--
Torsten
Re: cvs disruption
Posted by Torsten Curdt <tc...@dff.st>.
> You can't cook without making a mess in the chitchen. But as long as you
> are the one cleaning up, nobody can complain, expecially if the food
> comes up great :)
exactly!
> [and those of you who experienced my cooking know what I'm talking about :)]
lol :))
--
Torsten
Re: cvs disruption
Posted by Stefano Mazzocchi <st...@apache.org>.
Diana Shannon wrote:
>>> All right. Since there is circular dependency between cocoon and
>>> forrest, I would suggest we release cocoon 2.1 first, allow forrest to
>>> release a new version based on 2.1 and at that point forrestize our
>>> docs.
>>>
>>> how does that sound?
>>
>>
>> But this circular dependency will always be there, so why not
>> just get on with it. Anyway, Forrest uses a recent stable
>> version of cocoon-2.1-dev, i.e. just off the bleeding-edge.
>
>
> I agree we should get on with it too, as long as we don't break existing
> doc build capability. I think we should rely on the cvs version only for
> this transition stage. In the future, I don't want the docs build
> dependent on a cvs which from time to time will break. While the
> responsiveness of Forrest committers is incredible, I think Stefano's
> principle stated above is a best practice we should follow, especially
> for something like doc building (given the fact users just want docs,
> not necessarily the latest-greatest code which produces such docs).
All right, I think we need a vote on this. Please see next email.
Stefano.
Re: cvs disruption
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Dimanche, 23 mars 2003, à 14:20 Europe/Zurich, David Crossley a
écrit :
> ....If the mantra "only use released version of a product" was
> applied by Forrest then we would not be doing very well.
> We now need, and probably always will need, a recent Cocoon head.
> Perhaps we can relax this rule for Forrest and Cocoon can use
> recent "recommended" versions.
I think so too, the relationship between Forrest and Cocoon is not like
Avalon and Cocoon for example.
IMHO using a CVS tag in the Forrest CVS to identify the version used to
generate the Cocoon docs is fine (as suggested by Jeff on cocoon-docs),
the aim in this case being that everyone can use the same version of
Forrest to generate the docs.
-Bertrand
Re: cvs disruption
Posted by David Crossley <cr...@indexgeo.com.au>.
Diana Shannon wrote:
<snip/>
> I'm not saying it isn't working. I'm saying the **only** reason it works
> now is because we are using a cvs-based version of an outside project,
> not a released version. Stefano recently stated in:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104619931816392&w=2
> "never commit code that depends on non-released stuff"
> and I'm just pointing out that we are doing that here.
Ah, i understand you now.
Dianna Shannon wrote:
> > Stefano Mazzocchi wrote:
> David Crossley wrote:
<snip/>
> > Stephan and others have done one excellent step: getting Forrest
> > to process the Cocoon docs as they are now (DTD v1.0). Going to
> > the next stage is what Diana is rightly concerned about.
> >
> >> All right. Since there is circular dependency between cocoon and
> >> forrest, I would suggest we release cocoon 2.1 first, allow forrest to
> >> release a new version based on 2.1 and at that point forrestize our
> >> docs.
> >>
> >> how does that sound?
> >
> > But this circular dependency will always be there, so why not
> > just get on with it. Anyway, Forrest uses a recent stable
> > version of cocoon-2.1-dev, i.e. just off the bleeding-edge.
>
> I agree we should get on with it too, as long as we don't break existing
> doc build capability. I think we should rely on the cvs version only for
> this transition stage. In the future, I don't want the docs build
> dependent on a cvs which from time to time will break. While the
> responsiveness of Forrest committers is incredible, I think Stefano's
> principle stated above is a best practice we should follow, especially
> for something like doc building (given the fact users just want docs,
> not necessarily the latest-greatest code which produces such docs).
Nicely stated, thanks. Yes this is very important.
Just as Forrest uses a recent but stable head release
of Cocoon, so can Cocoon developers use the best available
release of Forrest. When Cocoon also does the release early
and often then we will be all in a better state.
If the mantra "only use released version of a product" was
applied by Forrest then we would not be doing very well.
We now need, and probably always will need, a recent Cocoon head.
Perhaps we can relax this rule for Forrest and Cocoon can use
recent "recommended" versions.
--David
Re: cvs disruption
Posted by Diana Shannon <sh...@apache.org>.
On Sunday, March 23, 2003, at 02:59 AM, David Crossley wrote:
<snip />
> Stefano Mazzocchi wrote:
>> Diana Shannon wrote:
>
>>> For example, current forrest build capability with cocoon's cvs
>>> is only possible with Forrest CVS, not the last Forrest release.
>>> This violates your "building on sand" philosophy.
>
> I am not sure what you mean here Diana, it is working now.
I'm not saying it isn't working. I'm saying the **only** reason it works
now is because we are using a cvs-based version of an outside project,
not a released version. Stefano recently stated in:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104619931816392&w=2
"never commit code that depends on non-released stuff"
and I'm just pointing out that we are doing that here.
<snip />
>
> Stephan and others have done one excellent step: getting Forrest
> to process the Cocoon docs as they are now (DTD v1.0). Going to
> the next stage is what Diana is rightly concerned about.
>
>> All right. Since there is circular dependency between cocoon and
>> forrest, I would suggest we release cocoon 2.1 first, allow forrest to
>> release a new version based on 2.1 and at that point forrestize our
>> docs.
>>
>> how does that sound?
>
> But this circular dependency will always be there, so why not
> just get on with it. Anyway, Forrest uses a recent stable
> version of cocoon-2.1-dev, i.e. just off the bleeding-edge.
I agree we should get on with it too, as long as we don't break existing
doc build capability. I think we should rely on the cvs version only for
this transition stage. In the future, I don't want the docs build
dependent on a cvs which from time to time will break. While the
responsiveness of Forrest committers is incredible, I think Stefano's
principle stated above is a best practice we should follow, especially
for something like doc building (given the fact users just want docs,
not necessarily the latest-greatest code which produces such docs).
Diana
Re: cvs disruption
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> Diana Shannon wrote:
> > Stefano Mazzocchi wrote:
> >> Diana Shannon wrote:
> >>
> >>> Perhaps it's just the nature of open source software, that a
> >>> tremendous amount of energy is unleashed right before a release date.
Actually i do not think that there is a "release date" yet.
That is just "as soon as we can".
I think that the current spurt of activity is from excitement that
we are getting toward a much more stable foundation in general, and
so many people can get productive again.
> >>> Perhaps there's no other way. Still, it feels, to be honest, like
> >>> poor planning. If we follow the maxim of "release early, release
> >>> often" I fail to see why there needs to be this kind of disruption
> >>> before releases.
However, when is it a "good time"? As someone said in another
email ... let us get the disruption over and done with earlier.
> >>> If the releases weren't spaced so far apart, what
> >>> difference would it make if we need to wait a little longer for some
> >>> new capability?
> >>
> >> This is a very good point. So, do you suggest to postpone
> >> forrestization for post-2.1? say for 2.1.1?
> >
> > Not necessarily. It depends on how much time we still have. And
> > forrestization can occur in stages.
Yeah, i do not see that we need to wait. This can all
be done in stages.
> > For example, current forrest build capability with cocoon's cvs
> > is only possible with Forrest CVS, not the last Forrest release.
> > This violates your "building on sand" philosophy.
I am not sure what you mean here Diana, it is working now.
> > We can change our cvs to work with
> > 0.4 Forrest, but it involves committing doc-v11 versions of many files
> > and deciding what to do with doc-v10-related files. If we simply
> > eliminate the doc-v10 files, we will break the separate doc-building
> > capabilities of our webapp documentation set. If we keep both versions,
> > we have a maintenance nightmare. This is being discussed on cocoon-docs,
> > with debate on how/if to include Forrest itself in our cvs, but there's
> > no consensus yet, IMHO. Whatever solution is decided may take some time
> > and tweaking to implement, that's all. And I would hate for it to hold
> > up a release.
Yes, this is the main issue. We really wanted to transform
all of the documentation to v1.1 DTD and this has many
ramifications as noted on the Wiki pages. The full job of
transition to the new DTD is rather big. This is the stage
where one person needs to transition the xdocs, then commit
and we all dive in to fix the stylesheets and sitemaps and stuff.
Stephan and others have done one excellent step: getting Forrest
to process the Cocoon docs as they are now (DTD v1.0). Going to
the next stage is what Diana is rightly concerned about.
> All right. Since there is circular dependency between cocoon and
> forrest, I would suggest we release cocoon 2.1 first, allow forrest to
> release a new version based on 2.1 and at that point forrestize our docs.
>
> how does that sound?
But this circular dependency will always be there, so why not
just get on with it. Anyway, Forrest uses a recent stable
version of cocoon-2.1-dev, i.e. just off the bleeding-edge.
--David
Re: cvs disruption
Posted by Stefano Mazzocchi <st...@apache.org>.
Diana Shannon wrote:
>
> On Saturday, March 22, 2003, at 11:13 AM, Stefano Mazzocchi wrote:
>
>>
>>> Perhaps it's just the nature of open source software, that a
>>> tremendous amount of energy is unleashed right before a release date.
>>> Perhaps there's no other way. Still, it feels, to be honest, like
>>> poor planning. If we follow the maxim of "release early, release
>>> often" I fail to see why there needs to be this kind of disruption
>>> before releases. If the releases weren't spaced so far apart, what
>>> difference would it make if we need to wait a little longer for some
>>> new capability?
>>
>>
>> This is a very good point. So, do you suggest to postpone
>> forrestization for post-2.1? say for 2.1.1?
>
>
> Not necessarily. It depends on how much time we still have. And
> forrestization can occur in stages.
>
> For example, current forrest build capability with cocoon's cvs is ony
> possible with Forrest CVS, not the last Forrest release. This violates
> your "building on sand" philosophy. We can change our cvs to work with
> 0.4 Forrest, but it involves committing doc-v11 versions of many files
> and deciding what to do with doc-v10-related files. If we simply
> eliminate the doc-v10 files, we will break the separate doc-building
> capabilities of our webapp documentation set. If we keep both versions,
> we have a maintenance nightmare. This is being discussed on cocoon-docs,
> with debate on how/if to include Forrest itself in our cvs, but there's
> no consensus yet, IMHO. Whatever solution is decided may take some time
> and tweaking to implement, that's all. And I would hate for it to hold
> up a release.
All right. Since there is circular dependency between cocoon and
forrest, I would suggest we release cocoon 2.1 first, allow forrest to
release a new version based on 2.1 and at that point forrestize our docs.
how does that sound?
Stefano.
Re: cvs disruption
Posted by Diana Shannon <sh...@apache.org>.
On Saturday, March 22, 2003, at 11:13 AM, Stefano Mazzocchi wrote:
>
>> Perhaps it's just the nature of open source software, that a
>> tremendous amount of energy is unleashed right before a release date.
>> Perhaps there's no other way. Still, it feels, to be honest, like poor
>> planning. If we follow the maxim of "release early, release often" I
>> fail to see why there needs to be this kind of disruption before
>> releases. If the releases weren't spaced so far apart, what difference
>> would it make if we need to wait a little longer for some new
>> capability?
>
> This is a very good point. So, do you suggest to postpone
> forrestization for post-2.1? say for 2.1.1?
Not necessarily. It depends on how much time we still have. And
forrestization can occur in stages.
For example, current forrest build capability with cocoon's cvs is ony
possible with Forrest CVS, not the last Forrest release. This violates
your "building on sand" philosophy. We can change our cvs to work with
0.4 Forrest, but it involves committing doc-v11 versions of many files
and deciding what to do with doc-v10-related files. If we simply
eliminate the doc-v10 files, we will break the separate doc-building
capabilities of our webapp documentation set. If we keep both versions,
we have a maintenance nightmare. This is being discussed on cocoon-docs,
with debate on how/if to include Forrest itself in our cvs, but there's
no consensus yet, IMHO. Whatever solution is decided may take some time
and tweaking to implement, that's all. And I would hate for it to hold
up a release.
We have a list of outstanding issues, some already outdated by recent
activity, posted at
http://wiki.cocoondev.org/Wiki.jsp?page=ForrestProposal
Ongoing thanks to Jeff and Stephan for their work to date on this.
Diana
Re: cvs disruption
Posted by Stefano Mazzocchi <st...@apache.org>.
Diana Shannon wrote:
> On Saturday, March 22, 2003, at 04:53 AM, Stefano Mazzocchi wrote:
>
>> Inside, we are all equal so once you get it can either be a democracy
>> (ask first, wait for momentum to build, potentially forever) or a
>> do-ocracy (do first, rollback if they jump on you or keep going if you
>> feel you're right).
>>
>> Diana or anybody else: there is something that bugs you and nobody is
>> stepping up to the plate to do it and no momentum is building and
>> nobody seems to care?
>>
>> just do it!
>
>
> Ah, but I did "do" something. The in-process content and configuration
> files simply didn't "live" in the cvs because doing so would have broken
> the existing and future docs build indefinitely. Granted, most of that
> was due to the fact Forrest, at that time, didn't yet convert doc-v10
> docs on the fly which is no longer the case (i.e. I would have had to
> check in doc-v11 versions of all docs).
>
> Please understand, I'm **not** trying to judge how you refactored the
> build. Perhaps in your case, there was no other way to implement the
> changes. I guess I was hoping to suggest -- given the power of ant --
> that we can set up prototype cvs environments where we can learn about
> the implications of our changes over time, even if the cvs changes under
> our feet, without disrupting the work of others. While our cvs was
> "officially" alpha (even though not all committers knew that) it is
> clear from the past few weeks of feedback that a number of people
> **perceived** our cvs as "almost beta" (thanks to all the great
> bug-fixing we have here) and were using it as "beta" -- right or wrong.
>
> I guess I'm questioning the timing of disruptive cvs changes, so close
> to a beta release date.
*close* is a matter of perception and a matter of removing the stuff on
the todo list.
I think forrestization is one thing to do *before* release, so better
sooner and messier than later and cleaner. but that's just me, I have
high tollerance against mess :)
> Perhaps it's just the nature of open source
> software, that a tremendous amount of energy is unleashed right before a
> release date. Perhaps there's no other way. Still, it feels, to be
> honest, like poor planning. If we follow the maxim of "release early,
> release often" I fail to see why there needs to be this kind of
> disruption before releases. If the releases weren't spaced so far apart,
> what difference would it make if we need to wait a little longer for
> some new capability?
This is a very good point. So, do you suggest to postpone forrestization
for post-2.1? say for 2.1.1?
> Again, I'm just trying to learn here. Not trying to pass judgment.
I know, don't worry.
Stefano.
Re: cvs disruption
Posted by Diana Shannon <sh...@apache.org>.
Responding to Steven and Stefano here:
On Friday, March 21, 2003, at 05:23 PM, Steven Noels wrote:
> there's a lot of stuff out there and we should be able to work on this
> as a team. Even if the transition is carefully documented (as you
> already did at great length), I assume there might be issues, and then
> it would be good to have a common set of working files, in CVS, when
> issues arise.
See below. It's not only about carefully documenting a transition but
also about completing the transition outside of the cvs. Whether the
working files (build files and a few configuration files) lived in
Forrest or Cocoon cvs, didn't matter to me. It was the idea of using ant
to set up a virtual cvs environment until changes were complete and then
checking them into cvs. The idea was not to break existing builds until
transition was complete. Nothing more.
AND
On Saturday, March 22, 2003, at 04:53 AM, Stefano Mazzocchi wrote:
> Inside, we are all equal so once you get it can either be a democracy
> (ask first, wait for momentum to build, potentially forever) or a
> do-ocracy (do first, rollback if they jump on you or keep going if you
> feel you're right).
>
> Diana or anybody else: there is something that bugs you and nobody is
> stepping up to the plate to do it and no momentum is building and
> nobody seems to care?
>
> just do it!
Ah, but I did "do" something. The in-process content and configuration
files simply didn't "live" in the cvs because doing so would have broken
the existing and future docs build indefinitely. Granted, most of that
was due to the fact Forrest, at that time, didn't yet convert doc-v10
docs on the fly which is no longer the case (i.e. I would have had to
check in doc-v11 versions of all docs).
Please understand, I'm **not** trying to judge how you refactored the
build. Perhaps in your case, there was no other way to implement the
changes. I guess I was hoping to suggest -- given the power of ant --
that we can set up prototype cvs environments where we can learn about
the implications of our changes over time, even if the cvs changes under
our feet, without disrupting the work of others. While our cvs was
"officially" alpha (even though not all committers knew that) it is
clear from the past few weeks of feedback that a number of people
**perceived** our cvs as "almost beta" (thanks to all the great
bug-fixing we have here) and were using it as "beta" -- right or wrong.
I guess I'm questioning the timing of disruptive cvs changes, so close
to a beta release date. Perhaps it's just the nature of open source
software, that a tremendous amount of energy is unleashed right before a
release date. Perhaps there's no other way. Still, it feels, to be
honest, like poor planning. If we follow the maxim of "release early,
release often" I fail to see why there needs to be this kind of
disruption before releases. If the releases weren't spaced so far apart,
what difference would it make if we need to wait a little longer for
some new capability?
Again, I'm just trying to learn here. Not trying to pass judgment.
Diana
Re: cvs disruption
Posted by Stefano Mazzocchi <st...@apache.org>.
Diana Shannon wrote:
> Perhaps the best thing is to simply
> throw it in the cvs and let everyone help finish the work -- as is
> happening right now.
Apache is a meritocracy but that's from the outside.
Inside, we are all equal so once you get it can either be a democracy
(ask first, wait for momentum to build, potentially forever) or a
do-ocracy (do first, rollback if they jump on you or keep going if you
feel you're right).
Diana or anybody else: there is something that bugs you and nobody is
stepping up to the plate to do it and no momentum is building and nobody
seems to care?
just do it!
momentum doesn't build by itself. it *never* does. it takes energy and
time and effort to have that wheel turning.
I want forrestbot, I want a better publishing infrastructure, I want the
ability to have a wiki on top of forrest that dumps documents in xdocs
and uses Sylvain CVS writeablesource to save them into the CVS repository!
So, either you do it or I'll do it. Disruptive or not I don't care: just
let's move on, for &deity;'s sake.
You can't cook without making a mess in the chitchen. But as long as you
are the one cleaning up, nobody can complain, expecially if the food
comes up great :)
[and those of you who experienced my cooking know what I'm talking about :)]
Stefano.
Re: cvs disruption
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
> I guess so. We, the doco people, also have the right to do disruptive
> things! ;-)
There is no such things as 'doco people', Steven. I got already busted
once for that ;-)
Stefano.
Re: cvs disruption
Posted by Steven Noels <st...@outerthought.org>.
On 21/03/2003 21:42 Diana Shannon wrote:
> On Friday, March 21, 2003, at 08:15 AM, Steven Noels wrote:
>
>> There's movement on the -docs list and perhaps also a Forrest quantum
>> leap blossoming, so we'd better do this before or after this assumably
>> disruptive step.
>
>
> I also wanted to state strongly that I don't believe Forrest transition
> needs to "disrupt" the Cocoon 2.1 repo. In spite of recent work that was
> just committed, and in spite of the fact this already impacts doc
> building, it remains possible to test the transition completely outside
> of the cvs and check in files only when we are finished -- and if the
sure, but when we never check in a temporarily, possibly broken state of
the docs mid-process, this will be a one (wo)man job
there's a lot of stuff out there and we should be able to work on this
as a team. Even if the transition is carefully documented (as you
already did at great length), I assume there might be issues, and then
it would be good to have a common set of working files, in CVS, when
issues arise.
am I right?
> Cocoon project decides it **wants** Forrest (which has never been
> subject to a vote). Up to now, I and a few others were pursuing a more
> cvs-friendly approach where transition files were checked into Forrest
> cvs for others to expand/test. Problem is, this approach doesn't attract
> much positive attention, although at least it doesn't attract any
> negative attention either.
yeah. Honestly, I'm a bit dispassionate about them since they only serve
Cocoon's progress, and Forrest, while intimately linked to Cocoon and
its community, should be 'customer'-neutral IMHO
Already, we see plenty of fixes in Forrest because of Cocoon coming in
and making use of it, and these should be made to Forrest proper, and
not to some Cocoon-private area
> I'm just concerned that some people may remain "bruised" from the recent
> cvs problems that came about from upgrading the build. If anyone has a
> problem with in-process Forrest files in the Cocoon cvs, we can adjust
> course and pursue a more cvs-sensitive approach. Still, I think I may be
> too conservative about these things. Perhaps the best thing is to simply
> throw it in the cvs and let everyone help finish the work -- as is
> happening right now.
I guess so. We, the doco people, also have the right to do disruptive
things! ;-)
> Just looking for some advice.
Does it help? Just trying to figure out myself...
Cheers, Diaña! ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org