You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Steven Noels <st...@outerthought.org> on 2003/09/10 10:38:38 UTC
on better release and version management
Hi folks,
forgive me for putting on my BOFH hat, while making the following
observations...
1) We suck at freezing and stabilizing the codebase prior to releases.
I would suggest that, from now on, the Release Manager puts forward a
release date after discussion on the dev list, and that there's a
two-day (!) freeze period where only glaring bugs can be fixed after a
vote (!) on the list.
The Release Manager him/herself is also only allowed to commit obvious
version number changes and all that during this two-day "Sperr-zone".
During the past few releases, there was a flurry of quick fixes and
commits happening just hours before Carsten made the tarball, and while
I'm not immediately aware of any nasty side-effects caused by this, it
sure doesn't look like there was time for any peer review on these late
commits, neither did it look organized at all.
2) We need to break from the impasse of 2.1.1 vs 2.2
I suggested yesterday night that the reshuffling of docs that Carsten
started really seems more apt for a 2.2 release. Also, the switch to
Fortress and Real Blocks are destined towards that 2.2 release. I
understand some Avalon peeps are glad to dive in and help us with that,
which is great, but we should facilitate them.
Some people want to start with a 2.2 CVS module right away, others seem
more relunctant and want the HEAD of 2.1 to evolve into 2.2. We need to
decide on this, since it's blocking progress.
My personal opinion is that 2.2 might warrant its own module, but we
need to discuss its structure and coexistence with old-style blocks code
in more depth before we ask for its creation to the infrastructure peeps.
3) Given the breakage in the Rhino stuff, and the lack of serious
testing on the 2.1.1 release, I would refrain from announcing 2.1.1 (not
retracting it, though) and go for a new target release date for 2.1.2 on
September 24th. That way, we can discuss at leisure what we are going to
do with the docs-reshuffling, and people can spend more time on testing
new stuff.
Please comment!
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: on better release and version management
Posted by Joerg Heinicke <jh...@virbus.de>.
Steven Noels wrote:
> Hi folks,
>
> forgive me for putting on my BOFH hat, while making the following
> observations...
>
> 1) We suck at freezing and stabilizing the codebase prior to releases.
>
> I would suggest that, from now on, the Release Manager puts forward a
> release date after discussion on the dev list, and that there's a
> two-day (!) freeze period where only glaring bugs can be fixed after a
> vote (!) on the list.
>
> The Release Manager him/herself is also only allowed to commit obvious
> version number changes and all that during this two-day "Sperr-zone".
>
> During the past few releases, there was a flurry of quick fixes and
> commits happening just hours before Carsten made the tarball, and while
> I'm not immediately aware of any nasty side-effects caused by this, it
> sure doesn't look like there was time for any peer review on these late
> commits, neither did it look organized at all.
+1 Yes, we should handle the release process more restrictive.
> 2) We need to break from the impasse of 2.1.1 vs 2.2
>
> I suggested yesterday night that the reshuffling of docs that Carsten
> started really seems more apt for a 2.2 release. Also, the switch to
> Fortress and Real Blocks are destined towards that 2.2 release. I
> understand some Avalon peeps are glad to dive in and help us with that,
> which is great, but we should facilitate them.
>
> Some people want to start with a 2.2 CVS module right away, others seem
> more relunctant and want the HEAD of 2.1 to evolve into 2.2. We need to
> decide on this, since it's blocking progress.
>
> My personal opinion is that 2.2 might warrant its own module, but we
> need to discuss its structure and coexistence with old-style blocks code
> in more depth before we ask for its creation to the infrastructure peeps.
But we should priorize all maintenance tasks first. For example the patches
in Bugzilla: it will be more and more effort to patch Cocoon's code. What
happens? The older Cocooon versions are as nearly as dead. See 2.0 - who
cares about it? The same will happen with 2.1 if we open a 2.2 CVS module.
c'est la vie? Evolution?
> 3) Given the breakage in the Rhino stuff, and the lack of serious
> testing on the 2.1.1 release, I would refrain from announcing 2.1.1 (not
> retracting it, though) and go for a new target release date for 2.1.2 on
> September 24th. That way, we can discuss at leisure what we are going to
> do with the docs-reshuffling, and people can spend more time on testing
> new stuff.
I guess the 2.1 had more and harder errors (e.g. the impossible undeployment
in Tomcat), so I think it's no problem to announce this as improvement
including the notice, that there is now another problem. It's ok IMO, if the
2.1.2 follows in a little while.
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: on better release and version management
Posted by Guido Casper <gc...@s-und-n.de>.
Steven Noels <st...@outerthought.org> wrote:
> 3) Given the breakage in the Rhino stuff, and the lack of serious
> testing on the 2.1.1 release, I would refrain from announcing 2.1.1
How about putting a hotfix on the dist site like Tomcat is doing
http://nagoya.apache.org/mirror/jakarta/tomcat-4/binaries/
Currently that would just be the Rhino jar.
Guido
RE: on better release and version management
Posted by Reinhard Poetz <re...@apache.org>.
Hi Steven,
Thank you very much for your answer. It opened my eyes in some respect
(especially the point with positive FUD). I thought again about our goal
and I found two of them:
- make it possible to continue with 2.1.x releases
- start ASAP with 2.2 without influencing 2.2
And the simplest solution (and probably the only that will work) is
Bruno's.
Find more comments in the answer to Bruno's posting.
Best regards,
Reinhard
> -----Original Message-----
> From: Steven Noels [mailto:stevenn@outerthought.org]
> Sent: Thursday, September 11, 2003 1:39 PM
> To: dev@cocoon.apache.org
> Subject: Re: on better release and version management
>
>
> Reinhard Poetz wrote:
>
> > I expect this and that's the reason why I think that a stable 2.2
> > release will take some time (I think that's not a matter of a few
> > months but much more) and why I like Carsten's proposal.
>
> Grmbl. Bruno and I were just trying to argumentize against each other
> about both scenarios, and I'm stuck with a few issues that I
> would like
> the repository reshuffling see resolve.
>
> Here's some feelings (not facts) I want to share with this discussion:
>
> 1) There's a decent amount of (positive!) FUD about the new
> blocks. All
> in all, I don't think that the actual coding of the new
> classloading and
> block deployment architecture code is much more cumbersome that what
> Sylvain once did with the TreeProcessor, and Stefano did with
> the build
> system. Yes, it will take time, but it's just a matter of
> finding time,
> motivation and energy to do the job. We tend to discuss for a
> long time
> about such issues, possibly longer than the actual coding actually
> requires. In the end, it's about getting on with it, and
> someone (which
> we will be very grateful for) diving deep into it and
> resurfacing when
> it's done. Ditto with Fortress. I'm naively hoping that some F2F time
> during the GT will help in finding that energy, and getting some
> commitment from people who need to shift between for-pay and for-free
> work on a daily basis.
>
> 2) My main concern with all this restructuring is however release
> management, and the user-facing perspective of our community work. We
> need to arrive to a situation where blocks can be
> independently released
> from Cocoon core releases, so that people who feel a faster drive to
> work on specific features can get on with the job, without being
> demotivated by long periods of no releases due to one zillion
> dependencies. So maybe we should move all blocks code into a separate
> module, and establish an independent release schedule (at the whim of
> the actual block release manager) for them.
>
> 3) This brings us to the eternal discussion about the
> definition of core
> and non-core. Maybe, be splitting out block code from the
> main module,
> and actively trying to slim down the main one even more, we
> will end up
> with a better community sense of what can be considered
> 'core', and what
> should be consired a block. We could even consider the
> TraxTransformer a
> block on its own, if we restrict the core to the pipeline, caching,
> sitemap and flow machinery. We could envision a packaged
> stable build of
> Cocoon which includes the core and then some core blocks. The rest is
> developed and released on its own schedule, and can, given the
> dependency checking in the new blocks paradigm shift (yes, it's more
> about a shift of perception than actual rearchitecturing) be safely
> released outside the main release schedule.
>
> This is just a quick braindump of my current feelings about all this.
> Hopefully it can contribute positively to this recurring discussion.
> Ending on a filosophical note: in the end, we should be
> driven by hope,
> not by fear. If we manage to come up with a stable 2.1.2
> release within
> some weeks, I'm pretty sure our users have plenty of new, stable
> releases to play with while we get our act together.
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source Java & XML An Orixo Member
> Read my weblog at http://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.org stevenn at apache.org
>
Re: on better release and version management
Posted by Steven Noels <st...@outerthought.org>.
Reinhard Poetz wrote:
> I expect this and that's the reason why I think that a stable 2.2
> release will take some time (I think that's not a matter of a few months
> but much more) and why I like Carsten's proposal.
Grmbl. Bruno and I were just trying to argumentize against each other
about both scenarios, and I'm stuck with a few issues that I would like
the repository reshuffling see resolve.
Here's some feelings (not facts) I want to share with this discussion:
1) There's a decent amount of (positive!) FUD about the new blocks. All
in all, I don't think that the actual coding of the new classloading and
block deployment architecture code is much more cumbersome that what
Sylvain once did with the TreeProcessor, and Stefano did with the build
system. Yes, it will take time, but it's just a matter of finding time,
motivation and energy to do the job. We tend to discuss for a long time
about such issues, possibly longer than the actual coding actually
requires. In the end, it's about getting on with it, and someone (which
we will be very grateful for) diving deep into it and resurfacing when
it's done. Ditto with Fortress. I'm naively hoping that some F2F time
during the GT will help in finding that energy, and getting some
commitment from people who need to shift between for-pay and for-free
work on a daily basis.
2) My main concern with all this restructuring is however release
management, and the user-facing perspective of our community work. We
need to arrive to a situation where blocks can be independently released
from Cocoon core releases, so that people who feel a faster drive to
work on specific features can get on with the job, without being
demotivated by long periods of no releases due to one zillion
dependencies. So maybe we should move all blocks code into a separate
module, and establish an independent release schedule (at the whim of
the actual block release manager) for them.
3) This brings us to the eternal discussion about the definition of core
and non-core. Maybe, be splitting out block code from the main module,
and actively trying to slim down the main one even more, we will end up
with a better community sense of what can be considered 'core', and what
should be consired a block. We could even consider the TraxTransformer a
block on its own, if we restrict the core to the pipeline, caching,
sitemap and flow machinery. We could envision a packaged stable build of
Cocoon which includes the core and then some core blocks. The rest is
developed and released on its own schedule, and can, given the
dependency checking in the new blocks paradigm shift (yes, it's more
about a shift of perception than actual rearchitecturing) be safely
released outside the main release schedule.
This is just a quick braindump of my current feelings about all this.
Hopefully it can contribute positively to this recurring discussion.
Ending on a filosophical note: in the end, we should be driven by hope,
not by fear. If we manage to come up with a stable 2.1.2 release within
some weeks, I'm pretty sure our users have plenty of new, stable
releases to play with while we get our act together.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
RE: on better release and version management
Posted by Reinhard Poetz <re...@apache.org>.
From: Antonio Gallardo [mailto:agallardo@agsoftware.dnsalias.com]
> Reinhard Poetz dijo:
> >
> >> From: Bruno Dumon
> >
> >> > Carsten made a good proposal how we can continue having 3
> >> repositories
> >> > and how this can be done with only little code duplicating:
> >> >
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106076740711234&w=
> >> > 2
> >> >
> >> > I'm +1 with his proposal - the reason is simple: Some people (and
> >> customers too!) asked me if we have gone crazy and how they can
> >> update
> >> > Cocoon in the future without being alpha/beta-tester for
> >> 'real' blocks
> >> > and Fortress. We *must* be able to maintain 2.1 without all new
> >> features like blocks and Fortress because IMNSHO these
> steps are to
> >> big for 2.1 and I'm -1 on the changes in the current repository.
> >>
> >> I'm also +1 for starting a new repository, but I don't
> like Carsten's
> >> proposal that much. I'd rather see the entire repository
> duplicated,
> >> and move all development effort to the 2.2 repository.
> Only bugfixes
> >> should be applied to the 2.1 repository, and occasional
> backports of
> >> new functionality if anyone wants to.
> >
> >
> > Let's look which new features are planned for the next time
> and when
> > they will be ready for beta and for final release?
> >
> > - real blocks
> > - virtual sitemap components
> > - intercepted flowscript
> > - use Fortress as container
> > - Cocoon Forms (aka Woody)
> > - Cocoon Portals (new portal block)
> >
> > IMO the first four items should be part of 2.2 but the two
> last items
> > should be released earlier. Let's assume a szenario that the
> > implementation of them takes very long (e.g. more than a
> year until we
> > reach a stable version). Do you really want to wait with
> Cocoon Forms
> > and Cocoon Portals such a long time (not to mention the many other
> > blocks)? You can say now that you develop under 2.2 and you do
> > occasional backports but IMO the problem is that e.g.
> Cocoon Forms is
> > tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable
> > branch! Additionally we get a great mess with all our
> blocks if they
> > are duplicated, some are backported, some not and we
> developers have
> > to do a lot of work twice, work which is not real fun.
> >
> > That's the reason why I'm +1 with Carstens proposal:
> >
> > - 2.1 repository containing all our blocks
> > - 2.2 repository contains only the new stuff introduced by
> the first
> > four points from above
> > - the 2.2 build mechanism is 'clever' enough to get all sources
> > from 2.1 that are missing
> >
> > What do you think?
>
> I think your proposal is OK. I was thinking for a while about
> this and for my point of view the 2.2 is a major relase
> (maybe it would be called 3.0). These 4 key points are a
> radical change of how we can see at cocoon.
>
> And as you pointed we can start the block construction and
> continue the improvement of the current 2.1 branch (in forms
> and portal) while starting a total new cocoon.
>
> Of course the user interface will be preserved the most.
Yes, the external contracts (must) remain mainly stable:
- the use of the sitemap and it's components
- cocoon.xconf
- hot to implement your custom components
I think moving from 2.1 to 2.2(3.0) will not be more difficult (maybe
easier) than moving from 2.0 to 2.1 which takes you a few hours. And
IIUC the changes from the old to the new cocoon.xconf which is necessary
for Fortress can be done automatically with a stylesheet.
(This brings me to the point that we should publish which are our stable
and external interfaces ...)
> But
> from the internals these is really a great new shaking if the
> current code.
>
> Is this correct?
I expect this and that's the reason why I think that a stable 2.2
release will take some time (I think that's not a matter of a few months
but much more) and why I like Carsten's proposal.
Reinhard
> Best Regards,
>
> Antonio Gallardo
>
>
RE: on better release and version management
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Reinhard Poetz dijo:
>
>> From: Bruno Dumon
>
>> > Carsten made a good proposal how we can continue having 3
>> repositories
>> > and how this can be done with only little code duplicating:
>> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106076740711234&w=2
>> >
>> > I'm +1 with his proposal - the reason is simple: Some people (and
>> customers too!) asked me if we have gone crazy and how they
>> can update
>> > Cocoon in the future without being alpha/beta-tester for
>> 'real' blocks
>> > and Fortress. We *must* be able to maintain 2.1 without all new
>> features like blocks and Fortress because IMNSHO these steps are to
>> big for 2.1 and I'm -1 on the changes in the current repository.
>>
>> I'm also +1 for starting a new repository, but I don't like
>> Carsten's proposal that much. I'd rather see the entire
>> repository duplicated, and move all development effort to the
>> 2.2 repository. Only bugfixes should be applied to the 2.1
>> repository, and occasional backports of new functionality if
>> anyone wants to.
>
>
> Let's look which new features are planned for the next time and when
> they will be ready for beta and for final release?
>
> - real blocks
> - virtual sitemap components
> - intercepted flowscript
> - use Fortress as container
> - Cocoon Forms (aka Woody)
> - Cocoon Portals (new portal block)
>
> IMO the first four items should be part of 2.2 but the two last items
> should be released earlier. Let's assume a szenario that the
> implementation of them takes very long (e.g. more than a year until we
> reach a stable version). Do you really want to wait with Cocoon Forms
> and Cocoon Portals such a long time (not to mention the many other
> blocks)? You can say now that you develop under 2.2 and you do
> occasional backports but IMO the problem is that e.g. Cocoon Forms is
> tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable
> branch! Additionally we get a great mess with all our blocks if they are
> duplicated, some are backported, some not and we developers have to do a
> lot of work twice, work which is not real fun.
>
> That's the reason why I'm +1 with Carstens proposal:
>
> - 2.1 repository containing all our blocks
> - 2.2 repository contains only the new stuff introduced by the first
> four points from above
> - the 2.2 build mechanism is 'clever' enough to get all sources
> from 2.1 that are missing
>
> What do you think?
I think your proposal is OK. I was thinking for a while about this and for
my point of view the 2.2 is a major relase (maybe it would be called 3.0).
These 4 key points are a radical change of how we can see at cocoon.
And as you pointed we can start the block construction and continue the
improvement of the current 2.1 branch (in forms and portal) while starting
a total new cocoon.
Of course the user interface will be preserved the most. But from the
internals these is really a great new shaking if the current code.
Is this correct?
Best Regards,
Antonio Gallardo
[OT] when is software finished [was: Re: on better release and version
management]
Posted by Steven Noels <st...@outerthought.org>.
Reinhard Poetz wrote:
> From: Bruno Dumon [mailto:bruno@outerthought.org]
>
> <snip/>
>
>>I expect Woody to also take another year or so before it can
>>be considered stable (in terms of interfaces, not code).
>
>
> ... that long? I expected it to be stable sooner (end of this year).
> What's open? (I already added this discussion point to
> http://wiki.cocoondev.org/Edit.jsp?page=GT2003Hackathon)
On a lighter note: we have a running joke over here about "when is
software considered 'finished'".
It can be because the community around it dies, or because the author
considers it to be perfect, and not requiring any fixes, refactorings or
feature additions anymore.
The funny thing is that an author sometimes declares its child finished
because the community has died.
OTOH, 'ls', 'tar' or 'deltree' could well be considered finished
software without any negative connotations.
Oh well, this is all geek humor (which is another running joke around
here [1]), which we all be glad to share with all of you on the 7th of
October (hint hint ;-))
[1] Geek humor being the kind of humor that erupts from male IT
professionals if they've spent too much time behind their terminals,
thinking what they have been doing will effectively change the
rotational direction of our green globe. Geek humor can have two side
effects: 1) you make a joke of yourself, being aware of the fact that
many other things in life can have much more effect on that rotation
than the lines of code and email you have been creating during the day,
or 2) others make fun of you since you, taking yourself to serious,
passionately start to explain how much fun it would be to change the
earth's rotation, "just because you can". Continuously swapping both
perspectives while working in an open source community caters for longer
periods between burn-outs. :-D
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
RE: on better release and version management
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-09-11 at 19:47, Reinhard Poetz wrote:
<snip/>
> > > What do you think?
> >
> > I think we're almost there. Lets wait a few more days to give
> > others a chance to comment, and then launch a vote.
>
> fine, go ahead when you think it's time for it.
ok. I'm not here though next week, so if it depends on me it will be the
week after that.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: on better release and version management
Posted by Reinhard Poetz <re...@apache.org>.
From: Bruno Dumon
> On Thu, 2003-09-11 at 14:19, Reinhard Poetz wrote:
> > From: Bruno Dumon [mailto:bruno@outerthought.org]
> >
> > <snip/>
> >
> > > I expect Woody to also take another year or so before it can
> > > be considered stable (in terms of interfaces, not code).
> >
> > ... that long? I expected it to be stable sooner (end of
> this year).
> > What's open? (I already added this discussion point to
> > http://wiki.cocoondev.org/Edit.jsp?page=GT2003Hackathon)
> >
>
> for one thing, there's all the stuff Sylvain's been proposing
> (namespaces mixing, expression language switch, various other
> things, I'll try to make a list before the hackaton).
Steven pointed out when he was writing about blocks that the
implementation is NOT the problem if we have the design. I think that
after the GT2003 we all will have a much better understanding where we
want to go to with Woody and implementation will be done very soon.
Then I would try to finalize (= find stable contracts) Woody ASAP and
release it with 2.1.x.
>
> <snip/>
>
> > > Anyhow, lots of stuff to think about, though it'd be nice if
> > > we get some interim solution in the meantime so that we can
> > > get started on 2.2.
> >
> > Yep, this interims solution is necessary and after reading
> Geoff's and
> > Steven's posts I changed my opinion because you are right that we
> > can't force block developer's to be backward compatible.
> >
> > So what's our plan? From my POV it looks like:
> >
> > - create a 2.2 repository as copy (incl. history) of 2.1
> > including all the blocks (so if somebody changes 2.2 core
> > in an incompatible way I see it if I monitor the changes
> > of the block I'm interested in)
>
> yep
>
> > - 2.1core only receives bug-fixes (like 2.0)
>
> I'd judge that on a case-by-case basis, i.e. if someone wants
> to backport a new 2.2 core feature to 2.1, that they simply
> propose that on the list and if nobody disagrees, they can go ahead.
+1
>
> > - find consensus on "What's Cocoon core?"
> > - find consensus on a road map (after we know where we want
> > to go?) and having milestones and target dates
> > (I know Cocoon is an OSS project and all those features and
> > dates are never binding for anyone but we should give our
> > user's a better overview about the project and when he/she
> > can expect a new feature)
Maybe this is a point for the GT? Steven?
> > - block developer's decide if they want to develop on 2.1 or 2.2
> > or when they want to switch
>
> hmm, I think that every change made to 2.1 should also be
> done to 2.2 (but not vice versa of course). It would be
> strange that 2.1 has features that are not in 2.2.
Ok, then we develop all our things in 2.2; what I want to see is more
backports from 2.2 to 2.1 than backports from 2.1 to 2.0. If we consider
Woody as stable I would really like to see it backported to 2.1 if 2.2
is not ready for prime time. This time it shouldn't be too difficult
because our internal interfaces will not change so much as from 2.1 to
2.0 - at least I hope so ;)
Then we have to decide if we need for every backport (not bugfix) a vote
or not.
What do you think?
> > - when the block implementation of 2.2 is "useable" we can think
> > about how we continue developing our real blocks (AFAIK
> versioning
> > is not a problem any more with real blocks)
>
> yep.
>
> >
> > What do you think?
>
> I think we're almost there. Lets wait a few more days to give
> others a chance to comment, and then launch a vote.
fine, go ahead when you think it's time for it.
Cheers,
Reinhard
RE: on better release and version management
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-09-11 at 14:19, Reinhard Poetz wrote:
> From: Bruno Dumon [mailto:bruno@outerthought.org]
>
> <snip/>
>
> > I expect Woody to also take another year or so before it can
> > be considered stable (in terms of interfaces, not code).
>
> ... that long? I expected it to be stable sooner (end of this year).
> What's open? (I already added this discussion point to
> http://wiki.cocoondev.org/Edit.jsp?page=GT2003Hackathon)
>
for one thing, there's all the stuff Sylvain's been proposing
(namespaces mixing, expression language switch, various other things,
I'll try to make a list before the hackaton).
<snip/>
> > Anyhow, lots of stuff to think about, though it'd be nice if
> > we get some interim solution in the meantime so that we can
> > get started on 2.2.
>
> Yep, this interims solution is necessary and after reading Geoff's and
> Steven's posts I changed my opinion because you are right that we can't
> force block developer's to be backward compatible.
>
> So what's our plan? From my POV it looks like:
>
> - create a 2.2 repository as copy (incl. history) of 2.1
> including all the blocks (so if somebody changes 2.2 core
> in an incompatible way I see it if I monitor the changes
> of the block I'm interested in)
yep
> - 2.1core only receives bug-fixes (like 2.0)
I'd judge that on a case-by-case basis, i.e. if someone wants to
backport a new 2.2 core feature to 2.1, that they simply propose that on
the list and if nobody disagrees, they can go ahead.
> - find consensus on "What's Cocoon core?"
> - find consensus on a road map (after we know where we want
> to go?) and having milestones and target dates
> (I know Cocoon is an OSS project and all those features and
> dates are never binding for anyone but we should give our
> user's a better overview about the project and when he/she
> can expect a new feature)
> - block developer's decide if they want to develop on 2.1 or 2.2
> or when they want to switch
hmm, I think that every change made to 2.1 should also be done to 2.2
(but not vice versa of course). It would be strange that 2.1 has
features that are not in 2.2.
> - when the block implementation of 2.2 is "useable" we can think
> about how we continue developing our real blocks (AFAIK versioning
> is not a problem any more with real blocks)
yep.
>
> What do you think?
I think we're almost there. Lets wait a few more days to give others a
chance to comment, and then launch a vote.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: on better release and version management
Posted by Reinhard Poetz <re...@apache.org>.
From: Bruno Dumon [mailto:bruno@outerthought.org]
<snip/>
> I expect Woody to also take another year or so before it can
> be considered stable (in terms of interfaces, not code).
... that long? I expected it to be stable sooner (end of this year).
What's open? (I already added this discussion point to
http://wiki.cocoondev.org/Edit.jsp?page=GT2003Hackathon)
> Fortress itself is already stable, and if all goes well its
> impact on Cocoon stability should be minimal.
I think so too.
>
> Real blocks will take some more time, though my impression is
> that it's mainly new stuff, and won't impact the stability of
> what we currently have that much.
>
> So people who want to get quick access to the latest and
> greatest will be able to use snapshots or milestone releases,
> just as before.
>
> But I get your point: it could be that e.g. Woody is
> "finished" halfway through 2.2 development.
>
> > You can say now that you develop under 2.2 and you do occasional
> > backports
>
> correction: I didn't say *I* will do occasional backports :-)
> These will only happen if someone's motivated to do so.
>
> > but IMO the problem is that e.g. Cocoon Forms is
> > tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable
> > branch!
>
> You'll always have to test it on all releases that you make
> it available on, that's unavoidable. If you make a Windows
> app, you also have to test it on all different Windows releases.
Yep, got your point.
>
> > Additionally we get a great mess with all our blocks if they are
> > duplicated, some are backported, some not and we developers
> have to do
> > a lot of work twice, work which is not real fun.
> >
> > That's the reason why I'm +1 with Carstens proposal:
> >
> > - 2.1 repository containing all our blocks
> > - 2.2 repository contains only the new stuff introduced by
> the first
> > four points from above
> > - the 2.2 build mechanism is 'clever' enough to get all sources
> > from 2.1 that are missing
> >
> > What do you think?
>
> There's lots of value in that proposal, but some problems too.
>
> I see the 2.1.x releases as patch releases, which must be
> releasable on very short notice. (but maybe that's wrong in
> itself, and the 2.1.x.x releases should be patch releases).
>
> What if I want to do "heavy development" on a block that will
> make it unstable for a while? If it's then suddenly required
> to release a patch release, that block will be part of it in
> its unstable state.
>
> Another problem: what if in my block I want to make use of
> features only available in 2.2. Or what if we make backwards
> incompatible changes in Cocoon 2.2 that require some changes
> (even if only minimal) to some blocks (we don't have #ifdef's).
Ok. We are back at the beginning of the discussion. I think all those
points made Stefano to publish his blocks proposal. Only 'real' blocks
will decouple block development from Cocoon development and that's the
major point (at least for me) making worth all the efforts of discussion
and implementation.
> A better solution might be to move the blocks to their own
> repository, give them their own release management, make each
> block define its own requirements in terms of required Cocoon
> version etc. But that will bring a whole lot of work with it
> too, and I'm not sure we really need that.
>
> Anyhow, lots of stuff to think about, though it'd be nice if
> we get some interim solution in the meantime so that we can
> get started on 2.2.
Yep, this interims solution is necessary and after reading Geoff's and
Steven's posts I changed my opinion because you are right that we can't
force block developer's to be backward compatible.
So what's our plan? From my POV it looks like:
- create a 2.2 repository as copy (incl. history) of 2.1
including all the blocks (so if somebody changes 2.2 core
in an incompatible way I see it if I monitor the changes
of the block I'm interested in)
- 2.1core only receives bug-fixes (like 2.0)
- find consensus on "What's Cocoon core?"
- find consensus on a road map (after we know where we want
to go?) and having milestones and target dates
(I know Cocoon is an OSS project and all those features and
dates are never binding for anyone but we should give our
user's a better overview about the project and when he/she
can expect a new feature)
- block developer's decide if they want to develop on 2.1 or 2.2
or when they want to switch
- when the block implementation of 2.2 is "useable" we can think
about how we continue developing our real blocks (AFAIK versioning
is not a problem any more with real blocks)
What do you think?
Reinhard
RE: on better release and version management
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-09-11 at 12:02, Reinhard Poetz wrote:
> > From: Bruno Dumon
>
> > > Carsten made a good proposal how we can continue having 3
> > repositories
> > > and how this can be done with only little code duplicating:
> > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106076740711234&w=2
> > >
> > > I'm +1 with his proposal - the reason is simple: Some people (and
> > > customers too!) asked me if we have gone crazy and how they
> > can update
> > > Cocoon in the future without being alpha/beta-tester for
> > 'real' blocks
> > > and Fortress. We *must* be able to maintain 2.1 without all new
> > > features like blocks and Fortress because IMNSHO these steps are to
> > > big for 2.1 and I'm -1 on the changes in the current repository.
> >
> > I'm also +1 for starting a new repository, but I don't like
> > Carsten's proposal that much. I'd rather see the entire
> > repository duplicated, and move all development effort to the
> > 2.2 repository. Only bugfixes should be applied to the 2.1
> > repository, and occasional backports of new functionality if
> > anyone wants to.
>
>
> Let's look which new features are planned for the next time and when
> they will be ready for beta and for final release?
>
> - real blocks
> - virtual sitemap components
> - intercepted flowscript
> - use Fortress as container
> - Cocoon Forms (aka Woody)
> - Cocoon Portals (new portal block)
>
> IMO the first four items should be part of 2.2 but the two last items
> should be released earlier. Let's assume a szenario that the
> implementation of them takes very long (e.g. more than a year until we
> reach a stable version). Do you really want to wait with Cocoon Forms
> and Cocoon Portals such a long time (not to mention the many other
> blocks)?
I expect Woody to also take another year or so before it can be
considered stable (in terms of interfaces, not code).
Fortress itself is already stable, and if all goes well its impact on
Cocoon stability should be minimal.
Real blocks will take some more time, though my impression is that it's
mainly new stuff, and won't impact the stability of what we currently
have that much.
So people who want to get quick access to the latest and greatest will
be able to use snapshots or milestone releases, just as before.
But I get your point: it could be that e.g. Woody is "finished" halfway
through 2.2 development.
> You can say now that you develop under 2.2 and you do
> occasional backports
correction: I didn't say *I* will do occasional backports :-) These will
only happen if someone's motivated to do so.
> but IMO the problem is that e.g. Cocoon Forms is
> tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable
> branch!
You'll always have to test it on all releases that you make it available
on, that's unavoidable. If you make a Windows app, you also have to test
it on all different Windows releases.
> Additionally we get a great mess with all our blocks if they are
> duplicated, some are backported, some not and we developers have to do a
> lot of work twice, work which is not real fun.
>
> That's the reason why I'm +1 with Carstens proposal:
>
> - 2.1 repository containing all our blocks
> - 2.2 repository contains only the new stuff introduced by the first
> four points from above
> - the 2.2 build mechanism is 'clever' enough to get all sources
> from 2.1 that are missing
>
> What do you think?
There's lots of value in that proposal, but some problems too.
I see the 2.1.x releases as patch releases, which must be releasable on
very short notice. (but maybe that's wrong in itself, and the 2.1.x.x
releases should be patch releases).
What if I want to do "heavy development" on a block that will make it
unstable for a while? If it's then suddenly required to release a patch
release, that block will be part of it in its unstable state.
Another problem: what if in my block I want to make use of features only
available in 2.2. Or what if we make backwards incompatible changes in
Cocoon 2.2 that require some changes (even if only minimal) to some
blocks (we don't have #ifdef's).
A better solution might be to move the blocks to their own repository,
give them their own release management, make each block define its own
requirements in terms of required Cocoon version etc. But that will
bring a whole lot of work with it too, and I'm not sure we really need
that.
Anyhow, lots of stuff to think about, though it'd be nice if we get some
interim solution in the meantime so that we can get started on 2.2.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: on better release and version management
Posted by Steven Noels <st...@outerthought.org>.
Geoff Howard wrote:
> I am undecided but something occurred to me in the shower this AM which
> made me wonder whether Carsten's proposal will work. As blocks evolve
> into real blocks, the changes will need to happen right in the
> src/blocks. Can we guarantee (or will it be too painful to ensure) that
> all changes will be back-compatible with 2.1? IOW, we will soon start
> having new configurations, etc. moving into the blocks source, possibly
> shuffling around of dir structure and probably deprecating some things
> currently necessary (like some of the configuration patching). Just
> thinking out loud...
Exactly, and also one of my concerns with Carsten's proposal. We can't
demand backwards-compatibility from block developers, and if blocks are
shared between version from inside the 2.1 workspace, this would be the
case.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: on better release and version management
Posted by Geoff Howard <co...@leverageweb.com>.
Reinhard Poetz wrote:
>>From: Bruno Dumon
>
>
>>>Carsten made a good proposal how we can continue having 3
>>repositories
>>>and how this can be done with only little code duplicating:
>>>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106076740711234&w=2
>>>
>>>I'm +1 with his proposal - the reason is simple: Some people (and
>>>customers too!) asked me if we have gone crazy and how they
>>can update
>>>Cocoon in the future without being alpha/beta-tester for
>>'real' blocks
>>>and Fortress. We *must* be able to maintain 2.1 without all new
>>>features like blocks and Fortress because IMNSHO these steps are to
>>>big for 2.1 and I'm -1 on the changes in the current repository.
>>
>>I'm also +1 for starting a new repository, but I don't like
>>Carsten's proposal that much. I'd rather see the entire
>>repository duplicated, and move all development effort to the
>>2.2 repository. Only bugfixes should be applied to the 2.1
>>repository, and occasional backports of new functionality if
>>anyone wants to.
>
> Let's look which new features are planned for the next time and when
> they will be ready for beta and for final release?
>
> - real blocks
> - virtual sitemap components
> - intercepted flowscript
> - use Fortress as container
> - Cocoon Forms (aka Woody)
> - Cocoon Portals (new portal block)
>
> IMO the first four items should be part of 2.2 but the two last items
> should be released earlier. Let's assume a szenario that the
> implementation of them takes very long (e.g. more than a year until we
> reach a stable version). Do you really want to wait with Cocoon Forms
> and Cocoon Portals such a long time (not to mention the many other
> blocks)? You can say now that you develop under 2.2 and you do
> occasional backports but IMO the problem is that e.g. Cocoon Forms is
> tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable
> branch! Additionally we get a great mess with all our blocks if they are
> duplicated, some are backported, some not and we developers have to do a
> lot of work twice, work which is not real fun.
>
> That's the reason why I'm +1 with Carstens proposal:
>
> - 2.1 repository containing all our blocks
> - 2.2 repository contains only the new stuff introduced by the first
> four points from above
> - the 2.2 build mechanism is 'clever' enough to get all sources
> from 2.1 that are missing
I am undecided but something occurred to me in the shower this AM which
made me wonder whether Carsten's proposal will work. As blocks evolve
into real blocks, the changes will need to happen right in the
src/blocks. Can we guarantee (or will it be too painful to ensure) that
all changes will be back-compatible with 2.1? IOW, we will soon start
having new configurations, etc. moving into the blocks source, possibly
shuffling around of dir structure and probably deprecating some things
currently necessary (like some of the configuration patching). Just
thinking out loud...
Geoff
RE: on better release and version management
Posted by Reinhard Poetz <re...@apache.org>.
> From: Bruno Dumon
> > Carsten made a good proposal how we can continue having 3
> repositories
> > and how this can be done with only little code duplicating:
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106076740711234&w=2
> >
> > I'm +1 with his proposal - the reason is simple: Some people (and
> > customers too!) asked me if we have gone crazy and how they
> can update
> > Cocoon in the future without being alpha/beta-tester for
> 'real' blocks
> > and Fortress. We *must* be able to maintain 2.1 without all new
> > features like blocks and Fortress because IMNSHO these steps are to
> > big for 2.1 and I'm -1 on the changes in the current repository.
>
> I'm also +1 for starting a new repository, but I don't like
> Carsten's proposal that much. I'd rather see the entire
> repository duplicated, and move all development effort to the
> 2.2 repository. Only bugfixes should be applied to the 2.1
> repository, and occasional backports of new functionality if
> anyone wants to.
Let's look which new features are planned for the next time and when
they will be ready for beta and for final release?
- real blocks
- virtual sitemap components
- intercepted flowscript
- use Fortress as container
- Cocoon Forms (aka Woody)
- Cocoon Portals (new portal block)
IMO the first four items should be part of 2.2 but the two last items
should be released earlier. Let's assume a szenario that the
implementation of them takes very long (e.g. more than a year until we
reach a stable version). Do you really want to wait with Cocoon Forms
and Cocoon Portals such a long time (not to mention the many other
blocks)? You can say now that you develop under 2.2 and you do
occasional backports but IMO the problem is that e.g. Cocoon Forms is
tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable
branch! Additionally we get a great mess with all our blocks if they are
duplicated, some are backported, some not and we developers have to do a
lot of work twice, work which is not real fun.
That's the reason why I'm +1 with Carstens proposal:
- 2.1 repository containing all our blocks
- 2.2 repository contains only the new stuff introduced by the first
four points from above
- the 2.2 build mechanism is 'clever' enough to get all sources
from 2.1 that are missing
What do you think?
Reinhard
Re: on better release and version management
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 11 sep 2003, à 11:33 Europe/Zurich, Bruno Dumon a écrit :
>
> .... I'd rather see the entire repository duplicated, and
> move all development effort to the 2.2 repository. Only bugfixes should
> be applied to the 2.1 repository, and occasional backports of new
> functionality if anyone wants to...
+1 - if it is a new repository as opposed to branches, this is what
makes the most sense IMHO.
-Bertrand
RE: on better release and version management
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-09-10 at 11:26, Reinhard Poetz wrote:
> From: Steven Noels
<snip/>
> > 2) We need to break from the impasse of 2.1.1 vs 2.2
> >
> > I suggested yesterday night that the reshuffling of docs that Carsten
> > started really seems more apt for a 2.2 release. Also, the switch to
> > Fortress and Real Blocks are destined towards that 2.2 release. I
> > understand some Avalon peeps are glad to dive in and help us
> > with that,
> > which is great, but we should facilitate them.
>
> Yep, I have the same concerns.
>
> >
> > Some people want to start with a 2.2 CVS module right away,
> > others seem
> > more relunctant and want the HEAD of 2.1 to evolve into 2.2.
> > We need to
> > decide on this, since it's blocking progress.
>
> Carsten made a good proposal how we can continue having 3 repositories
> and how this can be done with only little code duplicating:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106076740711234&w=2
>
> I'm +1 with his proposal - the reason is simple: Some people (and
> customers too!) asked me if we have gone crazy and how they can update
> Cocoon in the future without being alpha/beta-tester for 'real' blocks
> and Fortress. We *must* be able to maintain 2.1 without all new features
> like blocks and Fortress because IMNSHO these steps are to big for 2.1
> and I'm -1 on the changes in the current repository.
I'm also +1 for starting a new repository, but I don't like Carsten's
proposal that much. I'd rather see the entire repository duplicated, and
move all development effort to the 2.2 repository. Only bugfixes should
be applied to the 2.1 repository, and occasional backports of new
functionality if anyone wants to.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Anteater tests
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 11 sep 2003, à 08:41 Europe/Zurich, Guido Casper a écrit :
> ...How about the following change to the build?
> Uncomment the anteater-tests and remove the dependency of the test
> target on the anteater-tests target, so that if you run 'build test'
> only the unit tests are run. To run the Anteater tests you have to run
> 'build anteater-tests'....
I'd just add a warning to "build test" indicating that the anteater
tests must be run separately.
> ..This in turn has a dependency on the
> 'block-anteater-tests' target that copies all anteater tests (located
> in <block>/test/anteater) to 'build/test/anteater' where they are then
> executed. The anteater-tests target starts with a big attention message
> hinting to make sure the anteater.home property is correctly set.
>
> So we can see how Anteater usage develops and decide later whether to
> put Anteater into CVS.
Sounds good - make anteater tests fairly easy to run at first, then add
anteater to CVS if people bite to it!
- Bertrand
Anteater tests (was Re: on better release and version management)
Posted by Guido Casper <gc...@s-und-n.de>.
Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
> Le Mercredi, 10 sep 2003, à 11:26 Europe/Zurich, Reinhard Poetz a
> écrit
>>
>> ...Would it be enough to extend our Anteater scripts (see Guido's
>> mail) and
>> add Anteater to our codebase and include it automatically to our
>> build system? ...
>
> certainly a Good Thing it tests are not too hard to write - anteater
> tests things from the user's point of view which would make us very
> confident that things actually work.
>
>> ...BTW, unfortunatly the latest Anteater release needs Java 1.4.x ...
>
> Not too big a problem IMHO, as tests will probably not be required to
> do a normal build.
How about the following change to the build?
Uncomment the anteater-tests and remove the dependency of the test
target on the anteater-tests target, so that if you run 'build test'
only the unit tests are run. To run the Anteater tests you have to run
'build anteater-tests'. This in turn has a dependency on the
'block-anteater-tests' target that copies all anteater tests (located
in <block>/test/anteater) to 'build/test/anteater' where they are then
executed. The anteater-tests target starts with a big attention message
hinting to make sure the anteater.home property is correctly set.
So we can see how Anteater usage develops and decide later whether to
put Anteater into CVS.
Guido
Re: on better release and version management
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 10 sep 2003, à 11:26 Europe/Zurich, Reinhard Poetz a écrit
:
> ...Would it be enough to extend our Anteater scripts (see Guido's
> mail) and
> add Anteater to our codebase and include it automatically to our build
> system? ...
certainly a Good Thing it tests are not too hard to write - anteater
tests things from the user's point of view which would make us very
confident that things actually work.
> ...BTW, unfortunatly the latest Anteater release needs Java 1.4.x ...
Not too big a problem IMHO, as tests will probably not be required to
do a normal build.
-Bertrand
RE: on better release and version management
Posted by Reinhard Poetz <re...@apache.org>.
From: Steven Noels
> Hi folks,
>
> forgive me for putting on my BOFH hat, while making the following
> observations...
>
> 1) We suck at freezing and stabilizing the codebase prior to releases.
>
> I would suggest that, from now on, the Release Manager puts forward a
> release date after discussion on the dev list, and that there's a
> two-day (!) freeze period where only glaring bugs can be
> fixed after a
> vote (!) on the list.
+1
>
> The Release Manager him/herself is also only allowed to
> commit obvious
> version number changes and all that during this two-day "Sperr-zone".
+1
>
> During the past few releases, there was a flurry of quick fixes and
> commits happening just hours before Carsten made the tarball,
> and while
> I'm not immediately aware of any nasty side-effects caused by
> this, it
> sure doesn't look like there was time for any peer review on
> these late
> commits, neither did it look organized at all.
>
> 2) We need to break from the impasse of 2.1.1 vs 2.2
>
> I suggested yesterday night that the reshuffling of docs that Carsten
> started really seems more apt for a 2.2 release. Also, the switch to
> Fortress and Real Blocks are destined towards that 2.2 release. I
> understand some Avalon peeps are glad to dive in and help us
> with that,
> which is great, but we should facilitate them.
Yep, I have the same concerns.
>
> Some people want to start with a 2.2 CVS module right away,
> others seem
> more relunctant and want the HEAD of 2.1 to evolve into 2.2.
> We need to
> decide on this, since it's blocking progress.
Carsten made a good proposal how we can continue having 3 repositories
and how this can be done with only little code duplicating:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106076740711234&w=2
I'm +1 with his proposal - the reason is simple: Some people (and
customers too!) asked me if we have gone crazy and how they can update
Cocoon in the future without being alpha/beta-tester for 'real' blocks
and Fortress. We *must* be able to maintain 2.1 without all new features
like blocks and Fortress because IMNSHO these steps are to big for 2.1
and I'm -1 on the changes in the current repository.
(the -1 is of course no veto only a vote! BTW: Do we have voting
guidelines?)
> My personal opinion is that 2.2 might warrant its own module, but we
> need to discuss its structure and coexistence with old-style
> blocks code
> in more depth before we ask for its creation to the
> infrastructure peeps.
>
> 3) Given the breakage in the Rhino stuff, and the lack of serious
> testing on the 2.1.1 release, I would refrain from announcing
> 2.1.1 (not
> retracting it, though)
Technically it has been released and I think many users monitoring our
lists are already using it. But a release is a release ... So +1 for
leaving it where it is but we should add a warning to the dowload pages
and we should send an 'official' mail having a subject like "Cocoon
2.1.1 unstable" to our mailling lists.
> and go for a new target release date
> for 2.1.2 on
> September 24th.
I would prefer a release next week. I can help with tests.
> That way, we can discuss at leisure what we
> are going to
> do with the docs-reshuffling, and people can spend more time
> on testing
> new stuff.
>
> Please comment!
Additionally we have to think more about auto-testing our code. We have
some good unit tests and an Anteater script but that's not enough as we
have seen with 2.1.1.
Would it be enough to extend our Anteater scripts (see Guido's mail) and
add Anteater to our codebase and include it automatically to our build
system?
So my question is: What kind of problems can't be found with
- unit tests
- regression tests?
BTW, unfortunatly the latest Anteater release needs Java 1.4.x ...
Cheers,
Reinhard
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source Java & XML An Orixo Member
> Read my weblog at http://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.org stevenn at apache.org
>
RE: on better release and version management
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Giacomo Pati wrote:
>
> > 2 - copying all blocks to the 2.2 repo is not wanted since not all
> > blocks will evolve in the 2.2
>
> I think we have to clean up the build process from bottom again (see
> below).
>
In the long run, I believe yes (see below)
> > 3 - the "real blocks" may require some modifications of the current
> > "fake blocks".
> >
> > So what about the following (somewhat already expressed, BTW) :
> > - start a 2.2 repo with only the Cocoon core (i.e. src/java)
> > - copy blocks in the 2.2 repo only if they require substantial changes
> > that would break the ability to quickly do a 2.1.x release.
> > - have an intelligent 2.2 build that gets missing blocks from the 2.1
> > (IIRC Carsten talked about it)
> > - backport to the 2.1 non disruptive enhancements/bug fixes appearing in
> > the 2.2 repo
>
> A few days ago someone mentione something about "individually
> releasable units". I personally think this might be the way to go, peep
> over to Avalon land and see how they manage it.
>
> <SNIP/>
Yes, I also believe that this is the long term vision, but I fear that
we are not able to deal with the upcoming problems right now. I still
hope that we can have a smooth transition, which means, start 2.2 now
as outlined, take time to think about how to handle blocks in terms
of where they are in the cvs, how the build should look like etc. But
this will take time to think about.
Carsten
Re: on better release and version management
Posted by Giacomo Pati <gi...@apache.org>.
On Tue, 23 Sep 2003, Berin Loritsch wrote:
> Giacomo Pati wrote:
<snip/>
> > I assume you mean 'real block infrastructure'.
>
> I am telling you now, that use of a build infrastructure like Maven (or
> centipede for that matter), will make this a reality much quicker.
> I highly recommend that you start with one of those build infrastructure
> tools to make the block machinery a reality. Most of the work will be
> done for you.
>
> One of the things that these tools allow you to do is re-use build sequences.
> For instance, we could create a Maven-Cocoon plugin to generate the block
> JAR files, which can in turn resolve the dependencies and copy the dependent
> JARs into the block (if desired).
>
> It takes a bit to set up, but once it is done, it is done.
Exactly our experience.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: on better release and version management
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
> On Tue, 23 Sep 2003, Stefano Mazzocchi wrote:
>
>
>>On Monday, Sep 22, 2003, at 16:23 Europe/Rome, Giacomo Pati wrote:
>>
>
>
> <SNIP/>
>
>>I agree with you that even a 'naked cocoon' (a cocoon with no
>>functional blocks) can be further modularized, even if I personally
>>don't resonate with the modularization that you propose above.
>
>
> Could you explain why you don't resonate? Is it that you fear
> complexity?
>
> We're used to Centipede and Maven for some project we've done recently
> and our experience is that indeed a modularisation as I've proposed is
> quite complex with bare Ant as building tool but tools like Maven and
> Centipede are very helpfull for these kinda projects. We just need to
> make the step beyond Ant.
I can second that emotion. I recently did essentially this modularization
in my GUIApp project, and without introducing special classloader semantics
and such, the result was very encouraging. In fact my build environment
with that project currently fills in all the gaps, which is very good.
The Maven build system I have works very well, and it is simple to maintain.
>>I think that we should *NOT* try to bite more than we can chew for 2.2,
>>let's avoid doing everything in one huge step or this will take us
>>another 18 months to release 2.2 and this is going to hurt us badly.
>
>
> ET ;-)
Ok. So the list of features for 2.2 (and when can we start)....?
>> 1) start cocoon-2.2 with code and existing build system. No blocks, no
>>documentation.
>
>
> If you suggest starting with just more or less core code why not move to
> another build system we can build a modularized system upon?
>
>
>> 2) remove fake block machinery from the build system of 2.2
>
>
> Again, choosing another build system will help here as well.
>
>
>> 3) implements real block in 2.2
>
>
> I assume you mean 'real block infrastructure'.
I am telling you now, that use of a build infrastructure like Maven (or
centipede for that matter), will make this a reality much quicker.
I highly recommend that you start with one of those build infrastructure
tools to make the block machinery a reality. Most of the work will be
done for you.
One of the things that these tools allow you to do is re-use build sequences.
For instance, we could create a Maven-Cocoon plugin to generate the block
JAR files, which can in turn resolve the dependencies and copy the dependent
JARs into the block (if desired).
It takes a bit to set up, but once it is done, it is done.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: on better release and version management
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
...
>> - no need to have any jars in the CVS repository anymore or at least
>> only some exotic ones that are not distributed over the web (today
>> more than 40% of the cocoon cvs space is needed by jars and this is
>> even more in our zipped distributions)
>
> this is a good point.
I can set up autodownload of dependency jars quite easily, so that we
don't keep jars in CVS but only download them when building.
If nobody objects...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: on better release and version management
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Giacomo Pati wrote:
...
> The main part for me is
...
> - have multiple sub project in the repository which will be build all
> the same way with only one project.xml descriptor for name, version,
> etc. per sub project (this is Maven specific).
Not really. Centipede uses the Gump descriptor for this.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: on better release and version management
Posted by Giacomo Pati <gi...@apache.org>.
On Thu, 25 Sep 2003, Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>
> >>>
> >>> Contrast that with the parts that were ported over to use Maven, or
> >>> the GUIApp
> >>> project (http://d-haven.org). A world of difference. No longer is
> >>> there any
> >>> question about what is needed where. No longer is there a need to
> >>> have JARs
> >>> locally in the repository. No longer is there a need to have a 13 MB
> >>> download
> >>> for a full distributable. Not to mention, it makes it easier to find
> >>> out what
> >>> exactly is a dependency and what is dead weight.
> >>
> >>
> >> seconded!
> >
> >
> > are you (or Berin) volunteering? [again, not caustic, just curious]
>
> :O WHat me volunteer?
>
> Maybe I should learn to keep my mouth shut. ;P
>
> Seriously though, between Giacomo and I the build infrastructure would
> not be too hard to set up. In fact, we can get it started in parallel
> to what is currently there. When all are satisfied with the results,
> we remove the old build system.
I'd suggest to build up the new repo (if we go the Maven way) step by
step with a clear modularisation (read individual releasable units) in
mind and sketched out in a discussion here. I can think of someone (this
includes me, of course) starts moving class by class with the help of an
IDE like Eclipse that helps identifing the missing part until a module
is compilable.
> So when and where do we start on 2.2? (As I asked before with Fortress
> integration)....
Good question :-)
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: on better release and version management
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>>>
>>> Contrast that with the parts that were ported over to use Maven, or
>>> the GUIApp
>>> project (http://d-haven.org). A world of difference. No longer is
>>> there any
>>> question about what is needed where. No longer is there a need to
>>> have JARs
>>> locally in the repository. No longer is there a need to have a 13 MB
>>> download
>>> for a full distributable. Not to mention, it makes it easier to find
>>> out what
>>> exactly is a dependency and what is dead weight.
>>
>>
>> seconded!
>
>
> are you (or Berin) volunteering? [again, not caustic, just curious]
:O WHat me volunteer?
Maybe I should learn to keep my mouth shut. ;P
Seriously though, between Giacomo and I the build infrastructure would
not be too hard to set up. In fact, we can get it started in parallel
to what is currently there. When all are satisfied with the results,
we remove the old build system.
So when and where do we start on 2.2? (As I asked before with Fortress
integration)....
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Unit testing pipelines?
Posted by Guido Casper <gc...@s-und-n.de>.
Steve K <sh...@mm.st> wrote:
> Guido --
>
>> What exactly led you to propose HTTPUnit but prevents you from using
>> Anteater for the very same purpose (just curious)?
>
> I'm sorry if I gave that impression. Correct me if I'm wrong, but I
> believe HTTPUnit and the anteater scripts both test in a similar way
> -- they simulate an http based user-agent, sending requests to the
> site, and then test the result HTML for correctness. I am looking to
> do testing on the pipeline level, before the data is transformed into
> HTML and sent to the user.
>
> I think I explained what I'm looking for a little better in my reply
> to Upayavira.
>
> Sorry for the confusion,
No reason to be sorry.
Thanks for the explanation.
Guido
Re: Unit testing pipelines?
Posted by Steve K <sh...@mm.st>.
Guido --
> What exactly led you to propose HTTPUnit but prevents you from using
> Anteater for the very same purpose (just curious)?
I'm sorry if I gave that impression. Correct me if I'm wrong, but I
believe HTTPUnit and the anteater scripts both test in a similar way --
they simulate an http based user-agent, sending requests to the site,
and then test the result HTML for correctness. I am looking to do
testing on the pipeline level, before the data is transformed into HTML
and sent to the user.
I think I explained what I'm looking for a little better in my reply to
Upayavira.
Sorry for the confusion,
-steve
Re: Unit testing pipelines?
Posted by Guido Casper <gc...@s-und-n.de>.
Steve K <sh...@mm.st> wrote:
> Vadim --
>
>> Have you seen anteater tests in the cocoon-2.1\src\test\anteater? It
>> can do some of that, and may be all of that you want, I don't know
>> all the capabilities of anteater.
>
> Thank you for pointing out the anteater stuff. It isn't exactly what
> I'm looking for, but will be handy for testing stuff higher up on the
> stack.
What exactly led you to propose HTTPUnit but prevents you from using
Anteater for the very same purpose (just curious)?
Guido
Re: Unit testing pipelines?
Posted by Steve K <sh...@mm.st>.
Vadim --
> Have you seen anteater tests in the cocoon-2.1\src\test\anteater? It can
> do some of that, and may be all of that you want, I don't know all the
> capabilities of anteater.
Thank you for pointing out the anteater stuff. It isn't exactly what
I'm looking for, but will be handy for testing stuff higher up on the stack.
cheers,
-steve
Re: Unit testing pipelines?
Posted by Vadim Gritsenko <va...@verizon.net>.
Upayavira wrote:
> Steve K wrote:
>
>> Hello everyone --
>>
>> I am currently building a Cocoon application and so far I've extended
>> the ExcaliburTestCase class to write my JUnit tests for the
>> components I'm creating. However, I'm now at the point where I am
>> starting to write pipelines that generate XML based on the database
>> manipulations the previously mentioned components perform, and it
>> appears that there is no easy way to test these. For example, my
>> ideal test code might look like:
>>
>> myCustomComponent.doSomething();
>> Document actualXml = cocoon.process("/path/to/my/pipeline");
>> Diff diff = new Diff(actualXml, expectedXml);
>> assertTrue("pipeline test", diff.identical());
>>
Have you seen anteater tests in the cocoon-2.1\src\test\anteater? It can
do some of that, and may be all of that you want, I don't know all the
capabilities of anteater.
Vadim
Re: Unit testing pipelines?
Posted by Steve K <sh...@mm.st>.
Upayavira wrote:
> "Putting test stuff in cocoon itself"? What do you mean?
In my experience writing tests, generally you regard the thing you are
testing as a "black box" -- the thing being tested should have no
knowledge that it is being tested rather than running in a production
environment. For example, the ExaclburTestCase is used to set up an
Avlon environment for you to test Avalon components without changing
them. I feel that adding "unittest" transformers to the sitemap or
using a custom pipeline processor violates this principle. However, I
am not overly religious about this -- if there already was a
UnitTestPipeline and the appropriate hooks into the CocoonBean I would
probably use it.
It seems to me that the closest thing to what I really want would be the
processURI() method in CocoonWrapper. Assuming this could be
instantiated and called from a JUnit test, it would give me the black
box effect I'm looking for. Ideally I'd like to be able to call any
pipeline (including internal-only ones) and get back the result XML
rather than the serialized form. I am not very familiar with the
internals of Cocoon, but I suspect this would not be an easy thing to
do. So we're probably back to a custom pipeline processor that can
gather the XML from each step of the pipeline and return it in the
environment somewhere (where would that be?).
It also might be possible to host the Cocoon component in the
EcaliburTestCase environment -- but I'm not sure if this gets me any
closer to the internal-only pipelines and XML as I'm still at the mercy
of the process() method.
cheers,
-steve
Re: Unit testing pipelines?
Posted by Upayavira <uv...@upaya.co.uk>.
Steve K wrote:
> > Upayavira wrote:
>
>> I think the bit that Vadim didn't perhaps mention is that you could
>> use something like HTTPUnit with cocoon views, thus getting at the
>> content at a certain point in a pipeline. You could even build views
>> that have transformations to simplify this XML, so that when you get
>> XML out of your view, you can do an identity comparision with your
>> expected XML.
>
>
> That is a good use of the view, however I have this strong desire to
> have the testing of pipelines more integrated with my JUnit tests. I
> like being able to click the "run" button on Eclipse and watch the
> little green bar move across the screen without having to worry about
> starting up cocoon, etc. Also, my tests would be more like "do x with
> component a, and check the results of pipeline y" which would require
> putting test code within cocoon if I wanted to use anteater, etc.
>
>> The challenge would be how to link a particular XML that has been
>> 'intercepted' within a pipeline with an expected XML. How do you
>> 'annotate' a pipeline to identify what XMLs you're expecting?
>
>
> Hm... how about a custom pass-through transformer that will validate
> the xml against a document in the environment referenced by some id?
> something like:
What I was talking about was doing something like that transparently -
i.e. so you don't need to make changes in your sitemap.
> <map:generate src="sql.xml"/>
> <map:transform type="sql"/>
> <map:transform type="xmlunit">
> <map:parameter name="expected-xml-id" value="sqlresult"/>
> </map:transform>
> ...
>
> The "sqlresult" document would be placed in the environment by the
> test before the pipeline is called. And perhaps the xmlunit
> transformer could be part of a view made for testing.
That sounds sensible. Have the Bean add a 'something' to the
ObjectModel, which is then used by the UnitTransformer, which you've
placed into a view. The UnitTransformer then uses this object in some
way to evaluate whether or not the XML is valid. Then you can pass back
the result to the caller, either as XML, or using a text serializer.
This would be much simpler than a UnitTestingPipeline, but would have
the downside that each stage you test in a pipeline would require a page
to be generated, whereas with a UnitTestingPipeline, you could test all
stages in the pipeline in one go, but it would be much harder to configure.
> This might be easier than the custom pipeline processor, but I'm still
> not happy with putting test stuff in cocoon itself.
"Putting test stuff in cocoon itself"? What do you mean?
Regards, Upayavira
Re: Unit testing pipelines?
Posted by Steve K <sh...@mm.st>.
> Upayavira wrote:
> I think the bit that Vadim didn't perhaps mention is that you could use
> something like HTTPUnit with cocoon views, thus getting at the content
> at a certain point in a pipeline. You could even build views that have
> transformations to simplify this XML, so that when you get XML out of
> your view, you can do an identity comparision with your expected XML.
That is a good use of the view, however I have this strong desire to
have the testing of pipelines more integrated with my JUnit tests. I
like being able to click the "run" button on Eclipse and watch the
little green bar move across the screen without having to worry about
starting up cocoon, etc. Also, my tests would be more like "do x with
component a, and check the results of pipeline y" which would require
putting test code within cocoon if I wanted to use anteater, etc.
> The challenge would be how to link a particular XML that has been
> 'intercepted' within a pipeline with an expected XML. How do you
> 'annotate' a pipeline to identify what XMLs you're expecting?
Hm... how about a custom pass-through transformer that will validate the
xml against a document in the environment referenced by some id?
something like:
<map:generate src="sql.xml"/>
<map:transform type="sql"/>
<map:transform type="xmlunit">
<map:parameter name="expected-xml-id" value="sqlresult"/>
</map:transform>
...
The "sqlresult" document would be placed in the environment by the test
before the pipeline is called. And perhaps the xmlunit transformer
could be part of a view made for testing. This might be easier than the
custom pipeline processor, but I'm still not happy with putting test
stuff in cocoon itself.
cheers,
-steve
Re: Unit testing pipelines?
Posted by Upayavira <uv...@upaya.co.uk>.
Steve K wrote:
> Upayavira --
>
>> So, a UnitTestingPipeline in combination with extensions to the
>> CLI/Bean to be able to configure this pipeline, wouldn't be too hard
>> to implement. Are you interested?
>
>
> That is an angle I had not considered -- it does provide a flexible
> way to test not only the end result, but also the intermediate steps
> of a pipeline. My only concern would be that using a different
> pipeline may taint the testing process as you wouldn't use the
> UnitTestingPipeline in a live application.
>
> When I was first thinking about this, I was imagining testing short
> internal-only pipelines -- the types of pipelines that would be
> aggregated in other pipelines. For example, just testing the result
> of a FileGenerator + SQLTransformer pipeline. In contrast, testing
> the result of complete pipelines seems best handled by existing tools
> such as HTTPUnit, Cactus, or the anteater scripts that Vadim pointed
> out to me.
I think the bit that Vadim didn't perhaps mention is that you could use
something like HTTPUnit with cocoon views, thus getting at the content
at a certain point in a pipeline. You could even build views that have
transformations to simplify this XML, so that when you get XML out of
your view, you can do an identity comparision with your expected XML.
That way you could do 'unit testing' of pipeline stages with a
functional testing tool such as HTTPUnit or Anteater, just using cocoon
views when generating the page.
> Since I'm still a few days away from actually writing pipelines for my
> application, it is hard for me to say which style of testing would be
> most useful. I plan on isolating all my logic in flow (that calls
> other components) and using the pipelines strictly for gathering xml
> and transforming it for display.
>
> Do you feel the CocoonBean could be modified to grab the output from
> the short, internal only type pipelines that I described?
The challenge would be how to link a particular XML that has been
'intercepted' within a pipeline with an expected XML. How do you
'annotate' a pipeline to identify what XMLs you're expecting? If you can
just say:
<generator-xml src="..."/>
<transformer-xml src=".../"/>
<transformer-xml src=".../"/>
<transformer-xml src=".../"/>
<serializer-xml src=".../"/>
It might work, but how would you deal with aggregation, etc. I suspect
that building the pipeline wouldn't be too hard, but working out how to
build the configuration side of things would be quite a challenge.
> I imagine I'd have to expose those internal pipelines to the outside
> somehow...
See above stuff on views.
> perhaps your solution would be the easiest.
Not sure. I'd try anteater and view first.
> Maybe when I reach the point where I need something I'll to cobble
> together a UnitTestingPipeline.
I'd be interested to see it if you do!
Regards, Upayavira
Re: Unit testing pipelines?
Posted by Steve K <sh...@mm.st>.
Upayavira --
> So, a UnitTestingPipeline in combination with extensions to the CLI/Bean
> to be able to configure this pipeline, wouldn't be too hard to
> implement. Are you interested?
That is an angle I had not considered -- it does provide a flexible way
to test not only the end result, but also the intermediate steps of a
pipeline. My only concern would be that using a different pipeline may
taint the testing process as you wouldn't use the UnitTestingPipeline in
a live application.
When I was first thinking about this, I was imagining testing short
internal-only pipelines -- the types of pipelines that would be
aggregated in other pipelines. For example, just testing the result of
a FileGenerator + SQLTransformer pipeline. In contrast, testing the
result of complete pipelines seems best handled by existing tools such
as HTTPUnit, Cactus, or the anteater scripts that Vadim pointed out to me.
Since I'm still a few days away from actually writing pipelines for my
application, it is hard for me to say which style of testing would be
most useful. I plan on isolating all my logic in flow (that calls other
components) and using the pipelines strictly for gathering xml and
transforming it for display.
Do you feel the CocoonBean could be modified to grab the output from the
short, internal only type pipelines that I described? I imagine I'd
have to expose those internal pipelines to the outside somehow...
perhaps your solution would be the easiest. Maybe when I reach the
point where I need something I'll to cobble together a UnitTestingPipeline.
cheers,
-steve
Re: Unit testing pipelines?
Posted by Upayavira <uv...@upaya.co.uk>.
Steve K wrote:
> Hello everyone --
>
> I am currently building a Cocoon application and so far I've extended
> the ExcaliburTestCase class to write my JUnit tests for the components
> I'm creating. However, I'm now at the point where I am starting to
> write pipelines that generate XML based on the database manipulations
> the previously mentioned components perform, and it appears that there
> is no easy way to test these. For example, my ideal test code might
> look like:
>
> myCustomComponent.doSomething();
> Document actualXml = cocoon.process("/path/to/my/pipeline");
> Diff diff = new Diff(actualXml, expectedXml);
> assertTrue("pipeline test", diff.identical());
>
> I suppose I could use something like HTTPUnit here, and set up a test
> script to start cocoon, request the uri and parse the result into
> XML... but that seems a little messier than it should be.
>
> I've looked at the CocoonBean stuff, and while it is close, it seems
> geared toward publishing pages rather than embedding cocoon and
> directly calling pipelines.
>
> Does this sound like a good idea, or is everyone just using HTTPUnit
> for this level of testing? Might it be possible to modify CocoonBean
> to allow direct access to the result of calling a pipeline? Does
> anyone think unit testing pipelines this way is actually valuable?
Steve,
The bean is intended to be a programmatic interface to Cocoon, not just
for publishing. There is a method (I'm not sure how well it works
though, but I can check), to write the contents of a pipeline to an
output stream, which is closer to what you are talking about.
You could do what you're talking about by implementing a
UnitTestingPipeline, to replace the default CachingProcessingPipeline.
So what you'd do is, in the Bean, pass in a set of 'expected' XMLs'. for
each stage of the pipeline. The Bean puts these details into the
environment, available for the pipeline. When generating a page, the
UnitTestingPipeline, as well as passing the content of the stage on to
the next stage, takes a copy and compares it to the relevant 'expected
XML' for that stage. If you look at AbstractCachingPointPipeline, I
think you'll see a pipeline that more or less does this, in order to
cache the content. You could replace that with code to test the XML.
So, a UnitTestingPipeline in combination with extensions to the CLI/Bean
to be able to configure this pipeline, wouldn't be too hard to
implement. Are you interested?
Regards, Upayavira
Unit testing pipelines?
Posted by Steve K <sh...@mm.st>.
Hello everyone --
I am currently building a Cocoon application and so far I've extended
the ExcaliburTestCase class to write my JUnit tests for the components
I'm creating. However, I'm now at the point where I am starting to
write pipelines that generate XML based on the database manipulations
the previously mentioned components perform, and it appears that there
is no easy way to test these. For example, my ideal test code might
look like:
myCustomComponent.doSomething();
Document actualXml = cocoon.process("/path/to/my/pipeline");
Diff diff = new Diff(actualXml, expectedXml);
assertTrue("pipeline test", diff.identical());
I suppose I could use something like HTTPUnit here, and set up a test
script to start cocoon, request the uri and parse the result into XML...
but that seems a little messier than it should be.
I've looked at the CocoonBean stuff, and while it is close, it seems
geared toward publishing pages rather than embedding cocoon and directly
calling pipelines.
Does this sound like a good idea, or is everyone just using HTTPUnit for
this level of testing? Might it be possible to modify CocoonBean to
allow direct access to the result of calling a pipeline? Does anyone
think unit testing pipelines this way is actually valuable?
thanks for any advice,
-steve
Re: [Vote] Build infrastructure
Posted by Stephen McConnell <mc...@apache.org>.
Having been though the process of setting up Maven for several projects
- and during the process experienced the evolution form Maven 0.7 to the
current 0.10, I can confirm that Maven in its current form is usable and
functional.
There are bugs in the Maven 10 release, many of which have been resolved
under the imminent beta 11/RC1. There are also a number of defensive
practices that can be employed to minimise problems. There are several
examples of maven based builds in Avalon - the Framework 4.1.5 release,
the recently released Avalon Meta 1.1 package, a number of recently
converted Excalibur packages (i18n 1.1 and configuration and 1.1), and
the new Merlin 3.0 container release. These collectively represent a
total of more than 40 maven subprojects consolidated under 5 parent
project.
Stephen.
Joerg Heinicke wrote:
> Giacomo Pati wrote:
>
>>>
>>>> 3) Maven
>>>> ATM this is my preferred build infrastructure and I could help
>>>> building the 2.2 repo based on it
>>>
>>>
>>> Heard interesting things it (besides the opinion that there is
>>> nearly no
>>
>
> ^^^^^ ^^^^^^^
>
>>> documentation ;-) ), so +1 from here too. Jelly/Maven seem to bring the
>>> necessary flexibility into Ant.
>>
>>
>>
>> What do you mean with 'there is nearly no documentation'? About Maven
>> itself? I've found the web site and other resources quite enough to
>> start using it for sever projects now. What do you miss?
>
>
> See above. I didn't have a look on it myself. It was about Maven and
> especially Jelly. And as far Maven uses Jelly ...
>
> Joerg
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: [Vote] Build infrastructure
Posted by Joerg Heinicke <jh...@virbus.de>.
Giacomo Pati wrote:
>>
>>>3) Maven
>>> ATM this is my preferred build infrastructure and I could help
>>> building the 2.2 repo based on it
>>
>>Heard interesting things it (besides the opinion that there is nearly no
^^^^^ ^^^^^^^
>>documentation ;-) ), so +1 from here too. Jelly/Maven seem to bring the
>>necessary flexibility into Ant.
>
>
> What do you mean with 'there is nearly no documentation'? About Maven
> itself? I've found the web site and other resources quite enough to
> start using it for sever projects now. What do you miss?
See above. I didn't have a look on it myself. It was about Maven and
especially Jelly. And as far Maven uses Jelly ...
Joerg
Re: [Vote] Build infrastructure
Posted by Giacomo Pati <gi...@apache.org>.
On Sun, 28 Sep 2003, Joerg Heinicke wrote:
> Giacomo Pati wrote:
>
> > Well, as my time permits it and Berin could give a hand as well, why
> > not.
> >
> > But first we need to come to a consensus about which build
> > infrastructure we would support to use:
> >
> > 1) Ant
> > in this case we can use the current build system and tune it to the
> > needs we have for the 2.2 and maybe add some ruper task to get rid
> > of jars in our repository (suggested by Nicola Ken IIRC) and some
> > more for modularisation ease
>
> IMO Ant is inflexible in general and adding flexibility (e.g. by using
> parameterized antcall) slows down the build process.
>
> > 2) Centipede
> > in this case I could not volunteer as I'm out of Centipede since
> > their move from Cents to Antlibs (we still have some customer
> > project using a Cents based version of it but they will never move
> > to Antlibs)
>
> Can not evaluate it.
>
> > 3) Maven
> > ATM this is my preferred build infrastructure and I could help
> > building the 2.2 repo based on it
>
> Heard interesting things it (besides the opinion that there is nearly no
> documentation ;-) ), so +1 from here too. Jelly/Maven seem to bring the
> necessary flexibility into Ant.
What do you mean with 'there is nearly no documentation'? About Maven
itself? I've found the web site and other resources quite enough to
start using it for sever projects now. What do you miss?
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: [Vote] Build infrastructure
Posted by Joerg Heinicke <jh...@virbus.de>.
Giacomo Pati wrote:
> Well, as my time permits it and Berin could give a hand as well, why
> not.
>
> But first we need to come to a consensus about which build
> infrastructure we would support to use:
>
> 1) Ant
> in this case we can use the current build system and tune it to the
> needs we have for the 2.2 and maybe add some ruper task to get rid
> of jars in our repository (suggested by Nicola Ken IIRC) and some
> more for modularisation ease
IMO Ant is inflexible in general and adding flexibility (e.g. by using
parameterized antcall) slows down the build process.
> 2) Centipede
> in this case I could not volunteer as I'm out of Centipede since
> their move from Cents to Antlibs (we still have some customer
> project using a Cents based version of it but they will never move
> to Antlibs)
Can not evaluate it.
> 3) Maven
> ATM this is my preferred build infrastructure and I could help
> building the 2.2 repo based on it
Heard interesting things it (besides the opinion that there is nearly no
documentation ;-) ), so +1 from here too. Jelly/Maven seem to bring the
necessary flexibility into Ant.
Joerg
Re: [Vote] Build infrastructure
Posted by Giacomo Pati <gi...@apache.org>.
On Mon, 29 Sep 2003, Nicola Ken Barozzi wrote:
> Antonio Gallardo wrote:
> ...
> > I think it is better to save our efforts by using any of the projects
> > related to this tasks. The idea, is to have a better project management
> > with less effort than we currently have with Ant. Is that right?
>
> Correct.
>
> I strongly think that moving to Maven now will be a major and
> unnecessary disruption in our development process, and I don't want to
> see it.
>
> As I said, it's quite easy to have almost all that Maven provides by
> using other stuff.
>
> What do we want from Maven?
Or Centipede (it's still proposed, isn't it?)
> 1 - jar downloads: use Ruper or Ant <get>
Nobody said Ant wasn't capable doing so
> 2 - generic targets? Heck, we already have them.
What you mean with generic targets? The Maven reactor?
> 3 - what else? Don't tell me activity reports, because it's an
> Ant task that Maven simply uses.
No, no, reports and document generation in Maven suck from our POV as
they are using different build tools (Anakia vs. Forrest) and DTDs.
Just:
- simpler build scripts (because of cents/antlibs/plugins)
ATM we have 1500+ line spread into 14 differet files included by
XML-Entity definitions
- deployment of created stuff like jars to repositories for other to
be used
- snapshot dependancy resolution (which we have used alot in the past)
- ease of modularisation capabilities
> Let's not go into a massive build-system change that will make it even
> harder to sense what's happening, and lay out what we need.
>
> NOTE: I'm the original Centipede author, so yes, I'm definately baised
:-) I knew this would happen
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: [Vote] Build infrastructure
Posted by Berin Loritsch <bl...@apache.org>.
Nicola Ken Barozzi wrote:
> Antonio Gallardo wrote:
> ...
>
>> I think it is better to save our efforts by using any of the projects
>> related to this tasks. The idea, is to have a better project management
>> with less effort than we currently have with Ant. Is that right?
>
>
> Correct.
>
> I strongly think that moving to Maven now will be a major and
> unnecessary disruption in our development process, and I don't want to
> see it.
>
> As I said, it's quite easy to have almost all that Maven provides by
> using other stuff.
>
> What do we want from Maven?
>
> 1 - jar downloads: use Ruper or Ant <get>
> 2 - generic targets? Heck, we already have them.
> 3 - what else? Don't tell me activity reports, because it's an
> Ant task that Maven simply uses.
>
> Let's not go into a massive build-system change that will make it even
> harder to sense what's happening, and lay out what we need.
>
> NOTE: I'm the original Centipede author, so yes, I'm definately baised
>
Once it is set up it works. It can be set up in parallel to the existing
build system--so impact for the migration only really happens after all
the bugs have been worked out. I am not an author for either Centipede
or Maven, just someone who has used Maven and had it satisfy my needs.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [Vote] Build infrastructure
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Lundi, 29 sep 2003, à 10:00 Europe/Zurich, Nicola Ken Barozzi a
écrit :
> ...What do we want from Maven?
>
> 1 - jar downloads: use Ruper or Ant <get>
Seems like the only thing that's really missing from the current build
system.
> 2 - generic targets? Heck, we already have them.
> 3 - what else? Don't tell me activity reports, because it's an
> Ant task that Maven simply uses.
Agreed.
If jar downloads can be added with minimal disruption, I'm -0.5 on
moving to either Maven or Centipede.
-Bertrand
Re: [Vote] Build infrastructure
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Antonio Gallardo wrote:
...
> I think it is better to save our efforts by using any of the projects
> related to this tasks. The idea, is to have a better project management
> with less effort than we currently have with Ant. Is that right?
Correct.
I strongly think that moving to Maven now will be a major and
unnecessary disruption in our development process, and I don't want to
see it.
As I said, it's quite easy to have almost all that Maven provides by
using other stuff.
What do we want from Maven?
1 - jar downloads: use Ruper or Ant <get>
2 - generic targets? Heck, we already have them.
3 - what else? Don't tell me activity reports, because it's an
Ant task that Maven simply uses.
Let's not go into a massive build-system change that will make it even
harder to sense what's happening, and lay out what we need.
NOTE: I'm the original Centipede author, so yes, I'm definately baised
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Vote] Build infrastructure (was: on better release and version management)
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Giacomo Pati dijo:
> On Sun, 28 Sep 2003, Antonio Gallardo wrote:
>> Then Ant can be present in the 3 options presented. I share with you
>> the need to move to a better project management. In that case I think
>> the question is related to Centiped vs. Maven.
>
> Well, all three infrastructure mentioned above are Ant, Ant based or use
> Ant. I mentiond 1) because Stefano argumented that the build
> infratruction at present is good enough in his eyes.
Hmm. On one side it is true. Since Ant is doing his job right now, we does
not need more probes of the current build system. It is good, because it
is working.
On the other way, I think our job (as Cocoon developers) is to enhance and
mantain the Cocoon project, we dont need to create a build system or a
project management tool. For these taks there are Maven or Centipede
project. I though the guys behind both projects really likes they do and
know what they are doing. We can benefits from this. Note, we are not
building or trying to build an Ant-like tool. The Ant guys do this work.
I think it is better to save our efforts by using any of the projects
related to this tasks. The idea, is to have a better project management
with less effort than we currently have with Ant. Is that right?
Note: I am not a Maven nor Centipede guru. But the promise behind any of
both projects is good.
Best Regards,
Antonio Gallardo.
Re: [Vote] Build infrastructure (was: on better release and version
management)
Posted by Giacomo Pati <gi...@apache.org>.
On Sun, 28 Sep 2003, Antonio Gallardo wrote:
> Giacomo Pati dijo:
> > But first we need to come to a consensus about which build
> > infrastructure we would support to use:
> >
> > 1) Ant
> > in this case we can use the current build system and tune it to the
> > needs we have for the 2.2 and maybe add some ruper task to get rid
> > of jars in our repository (suggested by Nicola Ken IIRC) and some
> > more for modularisation ease
> >
> > 2) Centipede
> > in this case I could not volunteer as I'm out of Centipede since
> > their move from Cents to Antlibs (we still have some customer
> > project using a Cents based version of it but they will never move
> > to Antlibs)
> >
> > 3) Maven
> > ATM this is my preferred build infrastructure and I could help
> > building the 2.2 repo based on it
>
> Hi:
>
> I think this Ant vs. (Centipede or Maven) is a not fair comparation. Check
> this: http://www-106.ibm.com/developerworks/java/library/j-maven/
>
> From the above document:
> <snip>
> A Maven goal can contain any valid Ant task in its definition, which will
> help you quickly learn Maven and protect your Ant investments.
> </snip>
>
> Then Ant can be present in the 3 options presented. I share with you the
> need to move to a better project management. In that case I think the
> question is related to Centiped vs. Maven.
Well, all three infrastructure mentioned above are Ant, Ant based or use
Ant. I mentiond 1) because Stefano argumented that the build
infratruction at present is good enough in his eyes.
> With this options presented, my vote is:
>
> Maven +1
>
> Best Regards,
>
> Antonio Gallardo.
>
>
>
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: [Vote] Build infrastructure (was: on better release and version management)
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Giacomo Pati dijo:
> But first we need to come to a consensus about which build
> infrastructure we would support to use:
>
> 1) Ant
> in this case we can use the current build system and tune it to the
> needs we have for the 2.2 and maybe add some ruper task to get rid
> of jars in our repository (suggested by Nicola Ken IIRC) and some
> more for modularisation ease
>
> 2) Centipede
> in this case I could not volunteer as I'm out of Centipede since
> their move from Cents to Antlibs (we still have some customer
> project using a Cents based version of it but they will never move
> to Antlibs)
>
> 3) Maven
> ATM this is my preferred build infrastructure and I could help
> building the 2.2 repo based on it
Hi:
I think this Ant vs. (Centipede or Maven) is a not fair comparation. Check
this: http://www-106.ibm.com/developerworks/java/library/j-maven/
>From the above document:
<snip>
A Maven goal can contain any valid Ant task in its definition, which will
help you quickly learn Maven and protect your Ant investments.
</snip>
Then Ant can be present in the 3 options presented. I share with you the
need to move to a better project management. In that case I think the
question is related to Centiped vs. Maven.
With this options presented, my vote is:
Maven +1
Best Regards,
Antonio Gallardo.
Re: [Vote] Build infrastructure
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
> On Thu, 25 Sep 2003, Stefano Mazzocchi wrote:
>
>>On Thursday, Sep 25, 2003, at 10:47 Europe/Rome, Giacomo Pati wrote:
>>
>>
>>>On Wed, 24 Sep 2003, Berin Loritsch wrote:
>
>
> <snipped>discussion on build infrastructure</snipped>
>
>>>>We tried to have a unified build system with ANT, and all excalibur
>>>>projects
>>>>re-using part of the central build file, etc. NIGHTMARE CITY.
>>>>
>>>>Contrast that with the parts that were ported over to use Maven, or
>>>>the GUIApp
>>>>project (http://d-haven.org). A world of difference. No longer is
>>>>there any
>>>>question about what is needed where. No longer is there a need to
>>>>have JARs
>>>>locally in the repository. No longer is there a need to have a 13 MB
>>>>download
>>>>for a full distributable. Not to mention, it makes it easier to find
>>>>out what
>>>>exactly is a dependency and what is dead weight.
>>>
>>>seconded!
>>
>>are you (or Berin) volunteering? [again, not caustic, just curious]
>
>
> Well, as my time permits it and Berin could give a hand as well, why
> not.
>
> But first we need to come to a consensus about which build
> infrastructure we would support to use:
>
> 1) Ant
> in this case we can use the current build system and tune it to the
> needs we have for the 2.2 and maybe add some ruper task to get rid
> of jars in our repository (suggested by Nicola Ken IIRC) and some
> more for modularisation ease
>
> 2) Centipede
> in this case I could not volunteer as I'm out of Centipede since
> their move from Cents to Antlibs (we still have some customer
> project using a Cents based version of it but they will never move
> to Antlibs)
>
> 3) Maven
> ATM this is my preferred build infrastructure and I could help
> building the 2.2 repo based on it
>
> Please show your preferences (if you don't have a clue about Maven
> and/or Centipede have a look at their sites at http://maven.apache.org
> and http://www.krysalis.org/centipede/ respectively)
If I were to do it: Maven. I have been able to get it to work, and it
does the job really well. Anything else, and I wouldn't be able to lend
hand due to ignorance, or the avoidance of pain. I.e. for ANT, it would
be the avoidance of pain and for Centipede it would be ignorance.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
RE: [Vote] Build infrastructure (was: on better release and version management)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Giacomo Pati wrote:
>
> But first we need to come to a consensus about which build
> infrastructure we would support to use:
>
> 1) Ant
> in this case we can use the current build system and tune it to the
> needs we have for the 2.2 and maybe add some ruper task to get rid
> of jars in our repository (suggested by Nicola Ken IIRC) and some
> more for modularisation ease
>
> 2) Centipede
> in this case I could not volunteer as I'm out of Centipede since
> their move from Cents to Antlibs (we still have some customer
> project using a Cents based version of it but they will never move
> to Antlibs)
>
> 3) Maven
> ATM this is my preferred build infrastructure and I could help
> building the 2.2 repo based on it
>
> Please show your preferences (if you don't have a clue about Maven
> and/or Centipede have a look at their sites at http://maven.apache.org
> and http://www.krysalis.org/centipede/ respectively)
>
Currently I prefer Maven as it is already used by many other Apache
projects.
Carsten
[Vote] Build infrastructure (was: on better release and version
management)
Posted by Giacomo Pati <gi...@apache.org>.
On Thu, 25 Sep 2003, Stefano Mazzocchi wrote:
> On Thursday, Sep 25, 2003, at 10:47 Europe/Rome, Giacomo Pati wrote:
>
> > On Wed, 24 Sep 2003, Berin Loritsch wrote:
<snipped>discussion on build infrastructure</snipped>
> >>
> >> We tried to have a unified build system with ANT, and all excalibur
> >> projects
> >> re-using part of the central build file, etc. NIGHTMARE CITY.
> >>
> >> Contrast that with the parts that were ported over to use Maven, or
> >> the GUIApp
> >> project (http://d-haven.org). A world of difference. No longer is
> >> there any
> >> question about what is needed where. No longer is there a need to
> >> have JARs
> >> locally in the repository. No longer is there a need to have a 13 MB
> >> download
> >> for a full distributable. Not to mention, it makes it easier to find
> >> out what
> >> exactly is a dependency and what is dead weight.
> >
> > seconded!
>
> are you (or Berin) volunteering? [again, not caustic, just curious]
Well, as my time permits it and Berin could give a hand as well, why
not.
But first we need to come to a consensus about which build
infrastructure we would support to use:
1) Ant
in this case we can use the current build system and tune it to the
needs we have for the 2.2 and maybe add some ruper task to get rid
of jars in our repository (suggested by Nicola Ken IIRC) and some
more for modularisation ease
2) Centipede
in this case I could not volunteer as I'm out of Centipede since
their move from Cents to Antlibs (we still have some customer
project using a Cents based version of it but they will never move
to Antlibs)
3) Maven
ATM this is my preferred build infrastructure and I could help
building the 2.2 repo based on it
Please show your preferences (if you don't have a clue about Maven
and/or Centipede have a look at their sites at http://maven.apache.org
and http://www.krysalis.org/centipede/ respectively)
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Sep 25, 2003, at 10:47 Europe/Rome, Giacomo Pati wrote:
> On Wed, 24 Sep 2003, Berin Loritsch wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>
>>>> - have multiple sub project in the repository which will be build
>>>> all
>>>> the same way with only one project.xml descriptor for name,
>>>> version,
>>>> etc. per sub project (this is Maven specific).
>>>
>>>
>>> hmmmm
>>>
>>> I would strongly suggest to wait to refactor the build system until
>>> we
>>> are finished implementing the block architecture.... let's work
>>> incrementally.
>>>
>>> At that point, we'll see what we can improve on what we have.
>>
>> Ok. But without getting into modularizing the Core of Cocoon, we
>> already
>> have blocks. The Maven/Centipede style build system will make
>> managing
>> those independant blocks (which are already separated) really easy.
>> Just
>> my two cents.
>>
>> As impirical evidence:
>>
>> Avalon Excalibur
>>
>> We tried to have a unified build system with ANT, and all excalibur
>> projects
>> re-using part of the central build file, etc. NIGHTMARE CITY.
>>
>> Contrast that with the parts that were ported over to use Maven, or
>> the GUIApp
>> project (http://d-haven.org). A world of difference. No longer is
>> there any
>> question about what is needed where. No longer is there a need to
>> have JARs
>> locally in the repository. No longer is there a need to have a 13 MB
>> download
>> for a full distributable. Not to mention, it makes it easier to find
>> out what
>> exactly is a dependency and what is dead weight.
>
> seconded!
are you (or Berin) volunteering? [again, not caustic, just curious]
--
Stefano.
Re: on better release and version management
Posted by Giacomo Pati <gi...@apache.org>.
On Wed, 24 Sep 2003, Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>
>
> >> - have multiple sub project in the repository which will be build all
> >> the same way with only one project.xml descriptor for name, version,
> >> etc. per sub project (this is Maven specific).
> >
> >
> > hmmmm
> >
> > I would strongly suggest to wait to refactor the build system until we
> > are finished implementing the block architecture.... let's work
> > incrementally.
> >
> > At that point, we'll see what we can improve on what we have.
>
> Ok. But without getting into modularizing the Core of Cocoon, we already
> have blocks. The Maven/Centipede style build system will make managing
> those independant blocks (which are already separated) really easy. Just
> my two cents.
>
> As impirical evidence:
>
> Avalon Excalibur
>
> We tried to have a unified build system with ANT, and all excalibur projects
> re-using part of the central build file, etc. NIGHTMARE CITY.
>
> Contrast that with the parts that were ported over to use Maven, or the GUIApp
> project (http://d-haven.org). A world of difference. No longer is there any
> question about what is needed where. No longer is there a need to have JARs
> locally in the repository. No longer is there a need to have a 13 MB download
> for a full distributable. Not to mention, it makes it easier to find out what
> exactly is a dependency and what is dead weight.
seconded!
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: on better release and version management
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>> - have multiple sub project in the repository which will be build all
>> the same way with only one project.xml descriptor for name, version,
>> etc. per sub project (this is Maven specific).
>
>
> hmmmm
>
> I would strongly suggest to wait to refactor the build system until we
> are finished implementing the block architecture.... let's work
> incrementally.
>
> At that point, we'll see what we can improve on what we have.
Ok. But without getting into modularizing the Core of Cocoon, we already
have blocks. The Maven/Centipede style build system will make managing
those independant blocks (which are already separated) really easy. Just
my two cents.
As impirical evidence:
Avalon Excalibur
We tried to have a unified build system with ANT, and all excalibur projects
re-using part of the central build file, etc. NIGHTMARE CITY.
Contrast that with the parts that were ported over to use Maven, or the GUIApp
project (http://d-haven.org). A world of difference. No longer is there any
question about what is needed where. No longer is there a need to have JARs
locally in the repository. No longer is there a need to have a 13 MB download
for a full distributable. Not to mention, it makes it easier to find out what
exactly is a dependency and what is dead weight.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: on better release and version management
Posted by Geoff Howard <co...@leverageweb.com>.
Upayavira wrote:
> Geoff Howard wrote:
>
>> Berin Loritsch wrote:
>>
>>> Geoff Howard wrote:
>>>
>>>> Stefano Mazzocchi wrote:
>>>>
>>>>>
>>>>>> - no need to have any jars in the CVS repository anymore or at
>>>>>> least
>>>>>> only some exotic ones that are not distributed over the web
>>>>>> (today
>>>>>> more than 40% of the cocoon cvs space is needed by jars and
>>>>>> this is
>>>>>> even more in our zipped distributions)
>>>>>
>>>>>
>>>>>
>>>>> this is a good point.
>>>>
>>>>
>>>>
>>>> JMHO but I hated this feature of maven in trying to get avalon built
>>>> before I got broadband at home. I downloaded all night and started
>>>> to build and it had to download a significant amount of new stuff.
>>>> If we do this, I'd still want to provide an "everything you need"
>>>> option for download.
>>>
>>>
>>>
>>> Do bear in mind that Maven downloads a number of things itself the first
>>> time you use it. Avalon (Framework) has very few dependencies itself
>>
>>
>
> Does it then cache that locally, so that next time it needs it, it has it?
>
> I do a lot of Cocoon development without a 'net connection, so relying
> on a 'download' feature would be a real pain.
Yes, it does cache IIRC and can be configured to not download in the
first place if you already have the dependencies locally. Did I get
that right maven gurus?
Geoff
Re: on better release and version management
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>* If you want to bypass that feature add the "-e" parameter
>> to tell Maven not to expect a network connection. It won't try
>> to download anything.
>
>
> Correction: -o not -e
Thanks.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
RE: on better release and version management
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> * If you want to bypass that feature add the "-e" parameter
> to tell Maven not to expect a network connection. It won't try
> to download anything.
Correction: -o not -e
/LS
Re: on better release and version management
Posted by Berin Loritsch <bl...@apache.org>.
Upayavira wrote:
>>>
>>>
>>> Do bear in mind that Maven downloads a number of things itself the first
>>> time you use it. Avalon (Framework) has very few dependencies itself
>>
>>
>
> Does it then cache that locally, so that next time it needs it, it has it?
Absolutely. There are two things to note:
* If you depend on a "SNAPSHOT" JAR file, Maven will always attempt to download
a newer version.
* If you want to bypass that feature add the "-e" parameter to tell Maven not
to expect a network connection. It won't try to download anything.
>
> I do a lot of Cocoon development without a 'net connection, so relying
> on a 'download' feature would be a real pain.
Not a problem.
>
> Regards, Upayavira
>
>
>
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: on better release and version management
Posted by Upayavira <uv...@upaya.co.uk>.
Geoff Howard wrote:
> Berin Loritsch wrote:
>
>> Geoff Howard wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>>>
>>>>> - no need to have any jars in the CVS repository anymore or at
>>>>> least
>>>>> only some exotic ones that are not distributed over the web
>>>>> (today
>>>>> more than 40% of the cocoon cvs space is needed by jars and
>>>>> this is
>>>>> even more in our zipped distributions)
>>>>
>>>>
>>>> this is a good point.
>>>
>>>
>>> JMHO but I hated this feature of maven in trying to get avalon built
>>> before I got broadband at home. I downloaded all night and started
>>> to build and it had to download a significant amount of new stuff.
>>> If we do this, I'd still want to provide an "everything you need"
>>> option for download.
>>
>>
>> Do bear in mind that Maven downloads a number of things itself the first
>> time you use it. Avalon (Framework) has very few dependencies itself
>
Does it then cache that locally, so that next time it needs it, it has it?
I do a lot of Cocoon development without a 'net connection, so relying
on a 'download' feature would be a real pain.
Regards, Upayavira
Re: on better release and version management
Posted by Berin Loritsch <bl...@apache.org>.
Geoff Howard wrote:
>
> PS (are you flooded out?)
>
No. I had some minor flooding in my basement--the area rug down there got
pretty wet, but we aren't talking about inches of standing water either.
The only evidence of the flooding we have in our home is a wet carpet.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: on better release and version management
Posted by Geoff Howard <co...@leverageweb.com>.
Berin Loritsch wrote:
> Geoff Howard wrote:
>
>> Stefano Mazzocchi wrote:
>>>
>>>> - no need to have any jars in the CVS repository anymore or at least
>>>> only some exotic ones that are not distributed over the web (today
>>>> more than 40% of the cocoon cvs space is needed by jars and this is
>>>> even more in our zipped distributions)
>>>
>>> this is a good point.
>>
>> JMHO but I hated this feature of maven in trying to get avalon built
>> before I got broadband at home. I downloaded all night and started to
>> build and it had to download a significant amount of new stuff. If we
>> do this, I'd still want to provide an "everything you need" option for
>> download.
>
> Do bear in mind that Maven downloads a number of things itself the first
> time you use it. Avalon (Framework) has very few dependencies itself
Point taken (though I may have been building something else from avalon*
and not the framework proper).
I have to admit that my perspective is tainted by my general feeling
that too much bleeding edge can be bad from a marketing/evaluating
perspective for a project that is trying to transition from "promising
but early" to a more mature status (which is how I think a lot of people
see Cocoon).
However, when we can resume binary dists again in 2.2 our build system
will not affect that issue nearly as much and I'd be game to try
anything new.
Geoff
PS (are you flooded out?)
Re: on better release and version management
Posted by Berin Loritsch <bl...@apache.org>.
Geoff Howard wrote:
> Stefano Mazzocchi wrote:
>
>>
>>> - no need to have any jars in the CVS repository anymore or at least
>>> only some exotic ones that are not distributed over the web (today
>>> more than 40% of the cocoon cvs space is needed by jars and this is
>>> even more in our zipped distributions)
>>
>>
>> this is a good point.
>
>
> JMHO but I hated this feature of maven in trying to get avalon built
> before I got broadband at home. I downloaded all night and started to
> build and it had to download a significant amount of new stuff. If we
> do this, I'd still want to provide an "everything you need" option for
> download.
Do bear in mind that Maven downloads a number of things itself the first
time you use it. Avalon (Framework) has very few dependencies itself.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: on better release and version management
Posted by Geoff Howard <co...@leverageweb.com>.
Stefano Mazzocchi wrote:
>
>> - no need to have any jars in the CVS repository anymore or at least
>> only some exotic ones that are not distributed over the web (today
>> more than 40% of the cocoon cvs space is needed by jars and this is
>> even more in our zipped distributions)
>
> this is a good point.
JMHO but I hated this feature of maven in trying to get avalon built
before I got broadband at home. I downloaded all night and started to
build and it had to download a significant amount of new stuff. If we
do this, I'd still want to provide an "everything you need" option for
download.
Geoff
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Sep 24, 2003, at 15:41 Europe/Rome, Giacomo Pati wrote:
> On Wed, 24 Sep 2003, Stefano Mazzocchi wrote:
>
>>
>> On Tuesday, Sep 23, 2003, at 19:41 Europe/Rome, Giacomo Pati wrote:
>>
>>> On Tue, 23 Sep 2003, Stefano Mazzocchi wrote:
>>>
>>>>
>>>> On Monday, Sep 22, 2003, at 16:23 Europe/Rome, Giacomo Pati wrote:
>>>>
>>>
>>> <SNIP/>
>>>
>>>> I agree with you that even a 'naked cocoon' (a cocoon with no
>>>> functional blocks) can be further modularized, even if I personally
>>>> don't resonate with the modularization that you propose above.
>>>
>>> Could you explain why you don't resonate? Is it that you fear
>>> complexity?
>>
>> From what you outlined, it seems unnecessarely complex to separate
>> cocoon in so many parts. But maybe you are proposing a solution for a
>> problem that I don't see.
>
> Is it the intention to deploy different implementation of stuff you'd
> only need one (or could configure only one) in your cocoon server
> (TreeProcessor vs. "compile sitemap", JavascritpFlow vs. others)? That
> was my thinking. It is not the same with SitemapComponents of course.
While I think that modularization of the cocoon core might make sense
in the future, I think we do not have enough knowledge about that just
yet, also because modularization of the core might well require some
refactoring (for example, in order to remove the instrumentation).
> As a linux guy I know the 'make xconfig' to configure a kernel and I
> could imagine that such a GUI could come in handly for our users as
> long as we don't ship binares (yes, users like to click and jelly-swing
> comes to my mind).
but you are making a pretty wrong assumption here: we don't ship
binaries with 2.1, but we *WILL* ship binaries with 2.2 as all
build-time action was required for blocks and now will be dealt with by
the block deployer (running outside) /block manager (running inside
cocoon) couple at run time.
while I agree that a naked cocoon might require modularization, I'm not
sure I want to deal with this just yet. [let's not put too many irons
in the fire!!]
>>> We're used to Centipede and Maven for some project we've done
>>> recently
>>> and our experience is that indeed a modularisation as I've proposed
>>> is
>>> quite complex with bare Ant as building tool but tools like Maven and
>>> Centipede are very helpfull for these kinda projects. We just need to
>>> make the step beyond Ant.
>>
>> I'm in favor of having an easy to manage build system... but probably
>> since I never used anything else but ant I'm don't know what I'd gain
>> since I'm fine with the build system we have (which I wrote, so I'm
>> admittedly biased).
>
> I'm not going to tell you the story about Centipede/Maven but maybe
> you find some time to have a look at http://maven.apache.org or
> http://www.krysalis.org/centipede/
>> But if anybody wants to show me the light, I'll be glad to learn
>> something new ;-)
>
> The main part for me is
> - lots of predefined targets/goals to use (compile, package,
> test, dist, etc.) which of course can be parametrized or extended.
we already have those, don't we?
> - no need to have any jars in the CVS repository anymore or at least
> only some exotic ones that are not distributed over the web (today
> more than 40% of the cocoon cvs space is needed by jars and this is
> even more in our zipped distributions)
this is a good point.
> - have multiple sub project in the repository which will be build all
> the same way with only one project.xml descriptor for name,
> version,
> etc. per sub project (this is Maven specific).
hmmmm
I would strongly suggest to wait to refactor the build system until we
are finished implementing the block architecture.... let's work
incrementally.
At that point, we'll see what we can improve on what we have.
> --
Stefano.
Re: on better release and version management
Posted by Giacomo Pati <gi...@apache.org>.
On Wed, 24 Sep 2003, Stefano Mazzocchi wrote:
>
> On Tuesday, Sep 23, 2003, at 19:41 Europe/Rome, Giacomo Pati wrote:
>
> > On Tue, 23 Sep 2003, Stefano Mazzocchi wrote:
> >
> >>
> >> On Monday, Sep 22, 2003, at 16:23 Europe/Rome, Giacomo Pati wrote:
> >>
> >
> > <SNIP/>
> >
> >> I agree with you that even a 'naked cocoon' (a cocoon with no
> >> functional blocks) can be further modularized, even if I personally
> >> don't resonate with the modularization that you propose above.
> >
> > Could you explain why you don't resonate? Is it that you fear
> > complexity?
>
> From what you outlined, it seems unnecessarely complex to separate
> cocoon in so many parts. But maybe you are proposing a solution for a
> problem that I don't see.
Is it the intention to deploy different implementation of stuff you'd
only need one (or could configure only one) in your cocoon server
(TreeProcessor vs. "compile sitemap", JavascritpFlow vs. others)? That
was my thinking. It is not the same with SitemapComponents of course.
As a linux guy I know the 'make xconfig' to configure a kernel and I
could imagine that such a GUI could come in handly for our users as
long as we don't ship binares (yes, users like to click and jelly-swing
comes to my mind).
> > We're used to Centipede and Maven for some project we've done recently
> > and our experience is that indeed a modularisation as I've proposed is
> > quite complex with bare Ant as building tool but tools like Maven and
> > Centipede are very helpfull for these kinda projects. We just need to
> > make the step beyond Ant.
>
> I'm in favor of having an easy to manage build system... but probably
> since I never used anything else but ant I'm don't know what I'd gain
> since I'm fine with the build system we have (which I wrote, so I'm
> admittedly biased).
I'm not going to tell you the story about Centipede/Maven but maybe
you find some time to have a look at http://maven.apache.org or
http://www.krysalis.org/centipede/
> But if anybody wants to show me the light, I'll be glad to learn
> something new ;-)
The main part for me is
- lots of predefined targets/goals to use (compile, package,
test, dist, etc.) which of course can be parametrized or extended.
- no need to have any jars in the CVS repository anymore or at least
only some exotic ones that are not distributed over the web (today
more than 40% of the cocoon cvs space is needed by jars and this is
even more in our zipped distributions)
- have multiple sub project in the repository which will be build all
the same way with only one project.xml descriptor for name, version,
etc. per sub project (this is Maven specific).
>
> just don't know why we should modularize that much, that's all.
>
> >> I think that we should *NOT* try to bite more than we can chew for
> >> 2.2,
> >> let's avoid doing everything in one huge step or this will take us
> >> another 18 months to release 2.2 and this is going to hurt us badly.
> >
> > ET ;-)
> >
> >> I would simply suggest to:
> >>
> >> 1) start cocoon-2.2 with code and existing build system. No blocks,
> >> no
> >> documentation.
> >
> > If you suggest starting with just more or less core code why not move
> > to
> > another build system we can build a modularized system upon?
>
> but what do we gain? [I'm not caustic, just curious]
Easier modularisation capabilities.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Sep 23, 2003, at 19:41 Europe/Rome, Giacomo Pati wrote:
> On Tue, 23 Sep 2003, Stefano Mazzocchi wrote:
>
>>
>> On Monday, Sep 22, 2003, at 16:23 Europe/Rome, Giacomo Pati wrote:
>>
>
> <SNIP/>
>
>> I agree with you that even a 'naked cocoon' (a cocoon with no
>> functional blocks) can be further modularized, even if I personally
>> don't resonate with the modularization that you propose above.
>
> Could you explain why you don't resonate? Is it that you fear
> complexity?
From what you outlined, it seems unnecessarely complex to separate
cocoon in so many parts. But maybe you are proposing a solution for a
problem that I don't see.
> We're used to Centipede and Maven for some project we've done recently
> and our experience is that indeed a modularisation as I've proposed is
> quite complex with bare Ant as building tool but tools like Maven and
> Centipede are very helpfull for these kinda projects. We just need to
> make the step beyond Ant.
I'm in favor of having an easy to manage build system... but probably
since I never used anything else but ant I'm don't know what I'd gain
since I'm fine with the build system we have (which I wrote, so I'm
admittedly biased).
But if anybody wants to show me the light, I'll be glad to learn
something new ;-)
just don't know why we should modularize that much, that's all.
>> I think that we should *NOT* try to bite more than we can chew for
>> 2.2,
>> let's avoid doing everything in one huge step or this will take us
>> another 18 months to release 2.2 and this is going to hurt us badly.
>
> ET ;-)
>
>> I would simply suggest to:
>>
>> 1) start cocoon-2.2 with code and existing build system. No blocks,
>> no
>> documentation.
>
> If you suggest starting with just more or less core code why not move
> to
> another build system we can build a modularized system upon?
but what do we gain? [I'm not caustic, just curious]
>> 2) remove fake block machinery from the build system of 2.2
>
> Again, choosing another build system will help here as well.
since this is a basically a cvs checkout, I don't see the issue there
at all, but probably because I don't see the benefits of the proposed
move.
>> 3) implements real block in 2.2
>
> I assume you mean 'real block infrastructure'.
yes
--
Stefano.
Re: on better release and version management
Posted by Giacomo Pati <gi...@apache.org>.
On Tue, 23 Sep 2003, Stefano Mazzocchi wrote:
>
> On Monday, Sep 22, 2003, at 16:23 Europe/Rome, Giacomo Pati wrote:
>
<SNIP/>
> I agree with you that even a 'naked cocoon' (a cocoon with no
> functional blocks) can be further modularized, even if I personally
> don't resonate with the modularization that you propose above.
Could you explain why you don't resonate? Is it that you fear
complexity?
We're used to Centipede and Maven for some project we've done recently
and our experience is that indeed a modularisation as I've proposed is
quite complex with bare Ant as building tool but tools like Maven and
Centipede are very helpfull for these kinda projects. We just need to
make the step beyond Ant.
> I think that we should *NOT* try to bite more than we can chew for 2.2,
> let's avoid doing everything in one huge step or this will take us
> another 18 months to release 2.2 and this is going to hurt us badly.
ET ;-)
> I would simply suggest to:
>
> 1) start cocoon-2.2 with code and existing build system. No blocks, no
> documentation.
If you suggest starting with just more or less core code why not move to
another build system we can build a modularized system upon?
> 2) remove fake block machinery from the build system of 2.2
Again, choosing another build system will help here as well.
> 3) implements real block in 2.2
I assume you mean 'real block infrastructure'.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Sep 22, 2003, at 16:23 Europe/Rome, Giacomo Pati wrote:
> A few days ago someone mentione something about "individually
> releasable units". I personally think this might be the way to go, peep
> over to Avalon land and see how they manage it.
>
> By individually releasable units (IRU) I can see the following:
>
> - The Core.
> My undestanding of the Cocoon core starts at the o.a.c.Cocoon class
> and doesn't go into any implementation of some contracts
> (interfaces) it uses. Admittedly, such an implementation wouldn't
> run by itself because important part are missing, but please read
> ahead.
>
> - Cocoon core API (set of interfaces)
> We do have abstracted alot in cocoon to have the possibility to
> create core part by more than just one implementation like
> TreeProcessor vs. compiled sitemap, or JavascriptFlow vs.
> SchemeFlow vs. JavaFlow (the later one was just a discussion not a
> real implementation, but you get what I mean). This of course is
> the
> basic set of interfaces for the Core.
>
> - Each implementation of the Contract mentioned above could make it
> into
> a IRU because some people want the TreeProcessor other the "compiled
> sitemap" implementation but rarely both.
>
> - Cocoon Environment API
> The abstration of this part also manifests im different
> implementation we have so far (CLI, Servlet, Bean).
>
> - Again, each implementaion of the Environment API above could make a
> IRU. And also for some use cases the one or the other is suitable
> (Forrest will prefer the CLI environment, most of us the Servlet one,
> etc.)
>
> - Block API
> IIUC the blocks we're discussing intensively these days need a
> solid
> base so block developpers can start building upon. Probably all the
> rest of the interface we have will fall into this category (ie.
> all SitemapComponents etc.)
>
> - A Block implementation
> Each block implementation will be a IRU of course. It has for
> sure it's own development cycle.
>
> This of course are my personal oppinios about a better version
> management, release management and resource management. It'll break
> apart the monilitic release process we have today and allows much more
> flexibility and also more compact composition of a Cocoon System.
>
> The drawback is that we need another system to compose (as we have
> today
> with the local.* files) a running core system: The real core, core
> implemetations of abstracted parts, environment implementaion and the
> core block implementation (I'm thinking of the BlockDeployerBlock which
> was mentioned by someone)
>
> What do you think about this?
I agree with you that even a 'naked cocoon' (a cocoon with no
functional blocks) can be further modularized, even if I personally
don't resonate with the modularization that you propose above.
I think that we should *NOT* try to bite more than we can chew for 2.2,
let's avoid doing everything in one huge step or this will take us
another 18 months to release 2.2 and this is going to hurt us badly.
I would simply suggest to:
1) start cocoon-2.2 with code and existing build system. No blocks, no
documentation.
2) remove fake block machinery from the build system of 2.2
3) implements real block in 2.2
4) see what happens next
--
Stefano.
Re: on better release and version management
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 19 Sep 2003, Sylvain Wallez wrote:
> Steven Noels wrote:
>
> > Carsten Ziegeler wrote:
> >
> > <snip type="happy agreement"/>
<even-more-snipped/>
> Let me try to make a synthesis and proposal :
>
> 1 - creating a 2.2 repository is necessary to start working while still
> be able to issue 2.1.x maintainance releases,
This is just a physical working necessity, right?
> 2 - copying all blocks to the 2.2 repo is not wanted since not all
> blocks will evolve in the 2.2
I think we have to clean up the build process from bottom again (see
below).
> 3 - the "real blocks" may require some modifications of the current
> "fake blocks".
>
> So what about the following (somewhat already expressed, BTW) :
> - start a 2.2 repo with only the Cocoon core (i.e. src/java)
> - copy blocks in the 2.2 repo only if they require substantial changes
> that would break the ability to quickly do a 2.1.x release.
> - have an intelligent 2.2 build that gets missing blocks from the 2.1
> (IIRC Carsten talked about it)
> - backport to the 2.1 non disruptive enhancements/bug fixes appearing in
> the 2.2 repo
A few days ago someone mentione something about "individually
releasable units". I personally think this might be the way to go, peep
over to Avalon land and see how they manage it.
By individually releasable units (IRU) I can see the following:
- The Core.
My undestanding of the Cocoon core starts at the o.a.c.Cocoon class
and doesn't go into any implementation of some contracts
(interfaces) it uses. Admittedly, such an implementation wouldn't
run by itself because important part are missing, but please read
ahead.
- Cocoon core API (set of interfaces)
We do have abstracted alot in cocoon to have the possibility to
create core part by more than just one implementation like
TreeProcessor vs. compiled sitemap, or JavascriptFlow vs.
SchemeFlow vs. JavaFlow (the later one was just a discussion not a
real implementation, but you get what I mean). This of course is the
basic set of interfaces for the Core.
- Each implementation of the Contract mentioned above could make it into
a IRU because some people want the TreeProcessor other the "compiled
sitemap" implementation but rarely both.
- Cocoon Environment API
The abstration of this part also manifests im different
implementation we have so far (CLI, Servlet, Bean).
- Again, each implementaion of the Environment API above could make a
IRU. And also for some use cases the one or the other is suitable
(Forrest will prefer the CLI environment, most of us the Servlet one,
etc.)
- Block API
IIUC the blocks we're discussing intensively these days need a solid
base so block developpers can start building upon. Probably all the
rest of the interface we have will fall into this category (ie.
all SitemapComponents etc.)
- A Block implementation
Each block implementation will be a IRU of course. It has for
sure it's own development cycle.
This of course are my personal oppinios about a better version
management, release management and resource management. It'll break
apart the monilitic release process we have today and allows much more
flexibility and also more compact composition of a Cocoon System.
The drawback is that we need another system to compose (as we have today
with the local.* files) a running core system: The real core, core
implemetations of abstracted parts, environment implementaion and the
core block implementation (I'm thinking of the BlockDeployerBlock which
was mentioned by someone)
What do you think about this?
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: on better release and version management
Posted by Steven Noels <st...@outerthought.org>.
Sylvain Wallez wrote:
> Yeah. That's one of my qualities/defaults (depending on the context) : I
> hear all opinions, make a synthesis and sometimes claim that it's my own
> idea ;-)
Ha. :-)
You couldn't get away with it this time! :-D
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: on better release and version management
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Geoff Howard wrote:
> +1 let's give it a shot. This is probably what Carsten was picturing
> all along. :)
Yeah. That's one of my qualities/defaults (depending on the context) : I
hear all opinions, make a synthesis and sometimes claim that it's my own
idea ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: on better release and version management
Posted by Timothy Larson <ti...@yahoo.com>.
--- Stefano Mazzocchi <st...@apache.org> wrote:
...
> I propose a much simpler scheme. A block can be:
>
> 1) certified
> 2) not certified
>
> A certified block is said to be guaranteed by the certifier (not only
> the Apache Cocoon project, but any organization willing to certify
> their blocks) that this block is usable in production and will be
> maintained in the future.
...
> certification is meant to guarantee the "backup" of a community or
> company behind the block.
>
> This allows other entities to do certification (and this would mean
> that *they* provide support and community/company backup of future
> development) [if they lie, well, users will know and news will spread],
> but, more important, it will require a single 'all encompassing' vote
> from the community which would be: "are we ready to support this from
> now on?"
And from another Stefano email:
>yes, something like "certified that this is an official cocoon block,
>it can be used in production and will be supported by the cocoon
>community in the future"
Beautiful. Simple administration, good community dynamics designed in,
and a clear way to identify the maintainer, whether it is the Cocoon
community or an external community or company. I like it very much.
--Tim Larson
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: on better release and version management
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Wednesday, September 24, 2003, at 02:09 PM, Giacomo Pati wrote:
> On Wed, 24 Sep 2003, Stefano Mazzocchi wrote:
>
>>
>> On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin Loritsch wrote:
>>
>>> I would highly recommend steering away from the use of the word
>>> certified
>>> unless you intend to establish a standards body to oversee an
>>> official
>>> certification process.
>>
>> Good point. "Supported" sounds less marketing intrusive.
>
> +1 for "supported"
Mine too
+1
regards Jeremy
Re: on better release and version management
Posted by Giacomo Pati <gi...@apache.org>.
On Wed, 24 Sep 2003, Stefano Mazzocchi wrote:
>
> On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin Loritsch wrote:
>
> > I would highly recommend steering away from the use of the word
> > certified
> > unless you intend to establish a standards body to oversee an official
> > certification process.
>
> Good point. "Supported" sounds less marketing intrusive.
+1 for "supported"
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: on better release and version management
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Timothy Larson wrote:
> --- Stefano Mazzocchi <st...@apache.org> wrote:
>
>>Good point. "Supported" sounds less marketing intrusive.
>>
>>comments?
>
> Yes, "supported" matches the concept better. It says someone
> still cares about the block, that the community has not moved
> on and left it behind.
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: on better release and version management
Posted by David Crossley <cr...@indexgeo.com.au>.
Reinhard Poetz wrote:
> Stefano Mazzocchi
> > Berin Loritsch wrote:
> >
> > > I would highly recommend steering away from the use of
> > > the word certified
> > > unless you intend to establish a standards body to oversee
> > > an official certification process.
> >
> > Good point. "Supported" sounds less marketing intrusive.
> >
> > comments?
>
> What happens if we find out that a certain block is not supported any
> more (technology outdated, we have a better block, any active
> developers) *after* we marked it as supported. The first question I had
> was "how long does supported mean"? The former proposed *certified*
> relates to a certain point of time without saying something about the
> future.
>
> Another point is that Cocoon is open source and nobody can be forced to
> support a single line of code ...
>
> Maybe we can find a word that relates to a point of time and does not
> have all the meanings "certified" has (see Berin's mail
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106434951718170&w=2)
>
> Reinhard
How about "verified" ... together with a verification-date and
expected-review-date and the other metadata.
We would verify that it has an active community, verify that it
plays nicely with the rest of the Cocoon, verify its cvs commit-rate
(or verify that it is so stable that it does not need a high rate),
verify other stuff ... while KISS.
With this word we stop short of saying that we certify or support.
--David
Re: on better release and version management
Posted by Geoff Howard <co...@leverageweb.com>.
Timothy Larson wrote:
> Maybe we are having a hard time finding the "right" word because we are
> mixing concerns. I can think of roughly four separate things the user
> of a module would want to know:
>
> (1) Is the module stable?
> (i.e. is it considered to generally work properly with no critical bugs?)
> (2) Will code written against it will work with future releases?
> (i.e. will there be a back-compatibility effort made in new releases?)
> (3) Will there likely be any future versions?
> (i.e. is there still an active development person or community?)
> (4) Are they the only guinea pigs actually using the module?
> (i.e. is there an active user community?)
>
> On another tack, this information is mostly dynamic:
>
> While case (1) is usually static, but see the planned cocoon-2.1.1 -> 2.1.2
> release for an example of this being a little dynamic. For a stronger
> example, think of a crypto module after a security hole is found and
> fixed in a new release. The old version transitions from stable to condemed.
>
> Case (2) starts out as only an expression of intent and then transitions
> when a new release is made to being an attribute of the new release that
> reflects back on the release in question.
>
> Cases (3) and (4) are not direct attributes of the module, but rather are
> attributes of the community that reflect back on the module.
>
> In all these cases, any meta-info included in a release can only represent
> a snapshot in time. This is useful, but it would be better if it could be
> combined with live meta-info retrieved from the module's source site upon
> download, to account for reality drift over time.
>
> <side-note>
> Eventually it would be helpful for the source website to include the static
> meta-info, live meta-info, and some pretty, graphical data from some community
> data miners like Agora, etc. to help evaluate the liveliness of a module and
> its developer and user communities. This could even be used by the developers
> to help track what is used, what is causing problems, what can be retired, etc.
> </side-note
What about providing this or whatever info is needed (even Stefano's
original "strawman" proposal that he pointed out is self certifying but
"sign" the information by an authority. The "certification" we've been
discussing would then really "signed" by Cocoon. Perhaps there could be
cobs in Cocoon's repository which are not signed, and perhaps there are
one man shows which are "signed" because they are labeled as such. The
"certify"ing is done on the statement of information about the block.
Geoff
Re: on better release and version management
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Wednesday, September 24, 2003, at 08:46 PM, Timothy Larson wrote:
>
>> Which solution should I select : Woody or JXForms? FOP or iText? Just
>> look
>> at the activity to determine the health of a module/block.
>
> Exactly. Of course, no measure is going to be perfect, but something
> like
> this could help. Votes could be used to set the values for the
> released
> and the live meta-info. This would express the intent of the
> community.
> The automatic community data-mining would go hand-in-hand with this to
> give
> a live view of the actual, realized level of community development and
> support.
>
This could end up getting divisive, as Stefano suggested before.
In some cases it is a matter of taste, not capability.
For instance, (ignoring the fact Woody is currently going through major
review) the choice between say JXForms and Woody is one of which
paradigm you prefer, not which one is 'better', because they are both
perfectly capable of doing the job well.
I am not sure that 'activity' in itself is an accurate metric. Woody
may look more 'active' but that would be because JXForms does not have
much work left to do on it.
regards Jeremy
Re: on better release and version management
Posted by Timothy Larson <ti...@yahoo.com>.
--- Litrik De Roy <co...@litrik.com> wrote:
> From: "Timothy Larson" <ti...@yahoo.com>
> > <side-note>
> > Eventually it would be helpful for the source website to
> > include the static meta-info, live meta-info, and some pretty,
> > graphical data from some community data miners like Agora, etc.
> > to help evaluate the liveliness of a module and its developer
> > and user communities. This could even be used by the developers
> > to help track what is used, what is causing problems, what can
> > be retired, etc.
> > </side-note>
>
> A little bit like the "Activity Percentile" used by SourceForge ?
> That would help to prevent a lot of mistakes and confusion!
Yes, but with more detail. For the specific module you are interested in it
could tell you who is active and what else they are active on. It would let
you know which modules are experiencing cross-pollination and which modules
are islands in the storm, disconnected with the mass of the developers.
> Which solution should I select : Woody or JXForms? FOP or iText? Just look
> at the activity to determine the health of a module/block.
Exactly. Of course, no measure is going to be perfect, but something like
this could help. Votes could be used to set the values for the released
and the live meta-info. This would express the intent of the community.
The automatic community data-mining would go hand-in-hand with this to give
a live view of the actual, realized level of community development and support.
--Tim Larson
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: on better release and version management
Posted by Litrik De Roy <co...@litrik.com>.
----- Original Message -----
From: "Timothy Larson" <ti...@yahoo.com>
To: <de...@cocoon.apache.org>
Sent: Wednesday, September 24, 2003 8:34 PM
Subject: Re: on better release and version management
<snip/>
>
> <side-note>
> Eventually it would be helpful for the source website to include the
static
> meta-info, live meta-info, and some pretty, graphical data from some
community
> data miners like Agora, etc. to help evaluate the liveliness of a module
and
> its developer and user communities. This could even be used by the
developers
> to help track what is used, what is causing problems, what can be retired,
etc.
> </side-note>
A little bit like the "Activity Percentile" used by SourceForge ? That would
help to prevent a lot of mistakes and confusion!
Which solution should I select : Woody or JXForms? FOP or iText? Just look
at the activity to determine the health of a module/block.
I consider myself an experienced user, but whenever I'm looking at doing
something new with Cocoon -- and there are two alternatives available -- I'm
"scared" that I pick the unsupported/dead/obsolete alternative instead of
the one with the ongoing active development. (Can you say "Murphy" ?)
>
> --Tim Larson
>
Litrik De Roy
www.litrik.com
RE: Block Management [was Re: on better release and version management]
Posted by Reinhard Poetz <re...@apache.org>.
> From: Stefano Mazzocchi
<snip/>
> So:
>
> contributed -> no broad community support
>
> supported -> broad community support
>
> deprecated -> community either moved onto something else or dropped
> the concept alltogether.
>
> NOTE: a contributed block might find itself deprecated without never
> being supported. This is the full state/transition diagram:
>
> +------------------(rebirth)-----------------+
> v |
> -(birth)-> [contributed] ----------(death)---------> [deprecated]
> | ^
> +--(maturity)-> [supported] --(retirement)---+
>
> the transitions that require community vote (majority) are:
>
> - maturity
> - retirement
>
> the other transitions can be done by every committer in every project
> under control of the cocoon PMC and require only a "proposal" to be
> discussed on the cocono development mail list.
>
> thoughts?
I think it is a very well-thought proposal. With this lifecycle
(state/transition diagram) we also don't have problems with possible
interpretations of "supported" because in this context it is very clear
and has also the meaning of "official" you proposed yesterday.
Reinhard
Re: Block Management [was Re: on better release and version management]
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 25 sep 2003, à 12:45 Europe/Zurich, Stefano Mazzocchi a écrit
:
> ...I think that "contributed" and "experimental" are somewhat
> orthogonal, in fact, linotype can be considered both contributed and
> experimental....
Agreed.
> ...So:
>
> contributed -> no broad community support
>
> supported -> broad community support
>
> deprecated -> community either moved onto something else or dropped
> the concept alltogether....
>
> NOTE: a contributed block might find itself deprecated without never
> being supported. This is the full state/transition diagram:
>
> +------------------(rebirth)-----------------+
> v |
> -(birth)-> [contributed] ----------(death)---------> [deprecated]
> | ^
> +--(maturity)-> [supported] --(retirement)---+
+1, looks good!
> the transitions that require community vote (majority) are:
>
> - maturity
> - retirement
>
> the other transitions can be done by every committer in every project
> under control of the cocoon PMC and require only a "proposal" to be
> discussed on the cocono development mail list.
+1 as well.
-Bertrand
Re: Block Management [was Re: on better release and version management]
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Sep 25, 2003, at 08:51 Europe/Rome, Bertrand Delacretaz
wrote:
> Le Mercredi, 24 sep 2003, à 23:08 Europe/Zurich, Stefano Mazzocchi a
> écrit :
>> On Wednesday, Sep 24, 2003, at 20:34 Europe/Rome, Timothy Larson
>> wrote:
>
> <lots-of-snips cause="agree"/>
>
>> The above suggests one simple, but really important thing:
>>
>> the block 'health' metadata should *NOT* be included in the block,
>> but should be looked up from a centralized 'weather reporter' part of
>> the block librarian.
>
> Yes - and maybe we shouldn't impose too much structure on this weather
> report, just require that block providers have one "block status"
> documentation page, where they tell people about contract stability,
> API stability, future plans, active contributors and the like.
Yeah, that might do the job.
> If this is somewhat narrative rather than checkboxes, users should be
> able to get a feel of how seriously the block authors take their work,
> and not finding the expected info will be a sufficiently bad sign.
Very true.
>> ...The best way to judge is to make a vote.
>>
>> And the vote should not, in any circumstance, make the block being
>> voted bad if the vote doesn't pass.
>>
>> So, the answer to
>>
>> 3) is the community healthy?
>>
>> is misposed. I would like to have somethign a little less judging:
>> something like
>>
>> 3) is the cocoon community officially supporting this block?
>
> Agreed.
>
>> The risk is to come up with something which is not really meaningful.
>> Because "official support" doesn't really mean anything.
>
> Agreed as well. I still like "supported", meaning that the community
> cares for a particular component.
>
> Many projects use also "contributed" to mean that a piece of software
> is distributed along with the main code but comes from outside.
>
> How about "supported", "contributed", "experimental" and "deprecated"
> blocks?
I think that "contributed" and "experimental" are somewhat orthogonal,
in fact, linotype can be considered both contributed and experimental.
"experimental" judges the technical concepts included in the block. We
should, following the years-old Apache spirit, that we made judgement
on community health and let users judge technological merits.
[also, developers tend to be more rational about sociology evaluation
than they are about technology evaluation, because they care more about
the second, normally]
So:
contributed -> no broad community support
supported -> broad community support
deprecated -> community either moved onto something else or dropped
the concept alltogether.
NOTE: a contributed block might find itself deprecated without never
being supported. This is the full state/transition diagram:
+------------------(rebirth)-----------------+
v |
-(birth)-> [contributed] ----------(death)---------> [deprecated]
| ^
+--(maturity)-> [supported] --(retirement)---+
the transitions that require community vote (majority) are:
- maturity
- retirement
the other transitions can be done by every committer in every project
under control of the cocoon PMC and require only a "proposal" to be
discussed on the cocono development mail list.
thoughts?
--
Stefano.
Re: Block Management [was Re: on better release and version management]
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 24 sep 2003, à 23:08 Europe/Zurich, Stefano Mazzocchi a
écrit :
> On Wednesday, Sep 24, 2003, at 20:34 Europe/Rome, Timothy Larson wrote:
<lots-of-snips cause="agree"/>
> The above suggests one simple, but really important thing:
>
> the block 'health' metadata should *NOT* be included in the block, but
> should be looked up from a centralized 'weather reporter' part of the
> block librarian.
Yes - and maybe we shouldn't impose too much structure on this weather
report, just require that block providers have one "block status"
documentation page, where they tell people about contract stability,
API stability, future plans, active contributors and the like.
If this is somewhat narrative rather than checkboxes, users should be
able to get a feel of how seriously the block authors take their work,
and not finding the expected info will be a sufficiently bad sign.
> ...The best way to judge is to make a vote.
>
> And the vote should not, in any circumstance, make the block being
> voted bad if the vote doesn't pass.
>
> So, the answer to
>
> 3) is the community healthy?
>
> is misposed. I would like to have somethign a little less judging:
> something like
>
> 3) is the cocoon community officially supporting this block?
Agreed.
> The risk is to come up with something which is not really meaningful.
> Because "official support" doesn't really mean anything.
Agreed as well. I still like "supported", meaning that the community
cares for a particular component.
Many projects use also "contributed" to mean that a piece of software
is distributed along with the main code but comes from outside.
How about "supported", "contributed", "experimental" and "deprecated"
blocks?
Here are some suggested examples with blocks that I know (more or less)
about:
"supported":
Considered part of the "mainstream use" of Cocoon and supported as
such, documented, tested before each release: axis, batik, chaperon,
cron, databases, fop, hsqldb, html, itext, jfor, lucene, mail, portal,
velocity, woody
"contributed":
Either one-man shows, outside contributions with no broad community
support or samples with no additional functionality: deli, midi, qdox,
linotype, petstore
"experimental":
Either wild experiments, or use experimental technologies, or waiting
for feedback: slop,stx,eventcache,scratchpad,asciiart
"deprecated":
Not recommended for new projects, support will likely go away: xmlform
Please don't flame on particular classifications at this point, I'm
just trying to get the idea across ;-)
-Bertrand
Re: Block Management [was Re: on better release and version management]
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Sep 25, 2003, at 16:09 Europe/Rome, Timothy Larson wrote:
> I was doing wiring and sleeping during part of this discussion, but
> please
> let me jump in again. We could say something like this about a module:
> Code Stability: alpha/beta/final
> API/Contract Stability: alpha/beta/final
> Support Level: contributed/supported/deprecated
> Community Info:
> Text writeup plus an Agora-like visual community explorer that
> includes
> info gleaned from the user and dev lists, commits, and downloads.
>
> The text writeup allows more info than just the
> contributed/supported/deprecated
> indicator. It could explain the module's relationship with other
> modules, and
> tell where development is currently headed. For the JXForms/Woody
> example that
> keeps coming up, it could explain that JXForms and Woody are both
> live, parallel
> projects that make different tradeoffs and are attempting to
> cross-pollinate each
> other with good ideas and designs.
My idea is much simpler: the cocoon community defines a workflow for
block management and provides a page (which could reside on the URL
pointed by the block ID URI) that includes metadata about that block
(what it does, who writes it) and the 'community status'
[contributed/supported/deprecated]
the format of that page and the metadata that includes are up to the
community behind the block.
> The Agora-like part would be to give a visual feel of the project's
> pulse.
> No numbers, no numbered scale on graphs, just a visual flow of
> networks.
well, this is all nice and fancy, but I think you greatly underestimate
the effort of doing such datamining and come up with meaningful data
that doesn't create frustration and friction.
> It would be helpful for it to have a time dimension to see how
> interest has
> swelled over time in relation to the repository commits, and the dev
> and user
> lists. For instance, lots of early activity on the commits and dev
> list followed
> by a slowdown there and a steady increase of related activity on the
> user list
> and downloads (later, when this can be measured by the separate
> download of blocks)
> could indicate the code is maturing and being adopted.
"could" is the key word. statistics (no matter how smart) gives you
numbers, how you give those numbers a meaning is a separate concern.
> The text writeup above
> could give clues to help lead to a correct interpretation.
"correct" is the other key word. there is no such thing as "correct
interpretation" on the status of the development of a software. Trying
to achieve objectivity in such a subjective matter is asking for
community trouble.
> I only suggest all this because I often find myself wishing for a
> visual overview
> of the different aspects of project activity when I first meet a
> project.
Me too! Don't get me wrong: I'm continously working on this area (one
of my three apachecon presentations will be on 'virtual community
dynamics' where I'll present the new version of agora [which I'm
currently working on as we speak])
> Numbers
> do not work for this, because they tell so little of the story.
> Numbers are one-
> dimensional and thereby cannot properly represent the separation of
> concerns that
> a community presents.
Agreed. But agora shows that is hard enough to datamine mail headers
(without touching content!). I don't even imagine the complexity of
dealing with cross-correlating information from different sources (say
mail and CVS or wiki) [not even counting the 'identification' problem
which is already hard enough (impossible?) to tackle in email]
> Agreed, this whole area of research is potentially very
> dangerous and is not absolutely required, so if we skip it for now,
> that is fine.
that would be my suggestion: while doing research on this direction is
a goal I will keep up with, this has nothing to do with cocoon (it's
about OSS sociology in general). For sure cocoon might want to use
visualization tools, once they are polished and established.... but I
wouldn't want to hurt the adoption of blocks (or the friendlyness of
the communities behind them) because we used advanced-research
sociology tools to promote them.
--
Stefano.
Re: Block Management [was Re: on better release and version management]
Posted by Timothy Larson <ti...@yahoo.com>.
I was doing wiring and sleeping during part of this discussion, but please
let me jump in again. We could say something like this about a module:
Code Stability: alpha/beta/final
API/Contract Stability: alpha/beta/final
Support Level: contributed/supported/deprecated
Community Info:
Text writeup plus an Agora-like visual community explorer that includes
info gleaned from the user and dev lists, commits, and downloads.
The text writeup allows more info than just the contributed/supported/deprecated
indicator. It could explain the module's relationship with other modules, and
tell where development is currently headed. For the JXForms/Woody example that
keeps coming up, it could explain that JXForms and Woody are both live, parallel
projects that make different tradeoffs and are attempting to cross-pollinate each
other with good ideas and designs.
The Agora-like part would be to give a visual feel of the project's pulse.
No numbers, no numbered scale on graphs, just a visual flow of networks.
It would be helpful for it to have a time dimension to see how interest has
swelled over time in relation to the repository commits, and the dev and user
lists. For instance, lots of early activity on the commits and dev list followed
by a slowdown there and a steady increase of related activity on the user list
and downloads (later, when this can be measured by the separate download of blocks)
could indicate the code is maturing and being adopted. The text writeup above
could give clues to help lead to a correct interpretation.
I only suggest all this because I often find myself wishing for a visual overview
of the different aspects of project activity when I first meet a project. Numbers
do not work for this, because they tell so little of the story. Numbers are one-
dimensional and thereby cannot properly represent the separation of concerns that
a community presents. Agreed, this whole area of research is potentially very
dangerous and is not absolutely required, so if we skip it for now, that is fine.
--Tim Larson
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Block Management [was Re: on better release and version management]
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Sep 24, 2003, at 20:34 Europe/Rome, Timothy Larson wrote:
> Maybe we are having a hard time finding the "right" word because we are
> mixing concerns.
I came to the same conclusion.
> I can think of roughly four separate things the user
> of a module would want to know:
>
> (1) Is the module stable?
> (i.e. is it considered to generally work properly with no
> critical bugs?)
Stability should be divided in two different concerns:
1a) functional stability
1b) contract stability
the two are orthogonal and both, well, used as an artificial safety
that is sooooooo appreciated by managers.
At the same time, estimating those is painful, if ever possible. Note
that 1b) somewhat overlaps with 3) and below
> (2) Will code written against it will work with future releases?
> (i.e. will there be a back-compatibility effort made in new
> releases?)
this question overlap greatly with 3) so much that I think it's the
same question: if there is a community around it, the community will
decide what is better for the evolution, including deciding if it's
worth to keep back compatibility or not.
I personally like an active and balanced community more than an
artificial safety on back-compatibility... because if I trust a
community, I trust the fact that many people will be having the same
problems that I'm facing, thus, will probably want the community to
behave as I would. Community pressure keeps project honest... but,
unlike, marketing doesn't hinter evolution for legacy.
> (3) Will there likely be any future versions?
> (i.e. is there still an active development person or community?)
this is, IMO, the most significant question: is there a community
around it?
> (4) Are they the only guinea pigs actually using the module?
> (i.e. is there an active user community?)
this is part of 3)
The concerns you outlined are not so separate, IMO. So, in fact they
are:
1) is the code stable?
2) is the API stable?
3) is the community healthy?
we could come up with a multiple rating for the above:
1) code stability status
- under development (alpha)
- under final testing (beta)
- ready for production (final)
2) contract stability status
- under design (alpha)
- under final testing (beta)
- ready for production (final)
these two can be signed without creating community friction, the third
question is the one that worries me the most.
> On another tack, this information is mostly dynamic:
>
> While case (1) is usually static, but see the planned cocoon-2.1.1 ->
> 2.1.2
> release for an example of this being a little dynamic. For a stronger
> example, think of a crypto module after a security hole is found and
> fixed in a new release. The old version transitions from stable to
> condemed.
The above suggests one simple, but really important thing:
the block 'health' metadata should *NOT* be included in the block, but
should be looked up from a centralized 'weather reporter' part of the
block librarian.
> Case (2) starts out as only an expression of intent and then
> transitions
> when a new release is made to being an attribute of the new release
> that
> reflects back on the release in question.
>
> Cases (3) and (4) are not direct attributes of the module, but rather
> are
> attributes of the community that reflect back on the module.
>
> In all these cases, any meta-info included in a release can only
> represent
> a snapshot in time. This is useful, but it would be better if it
> could be
> combined with live meta-info retrieved from the module's source site
> upon
> download, to account for reality drift over time.
You raise a very good point: health information drifts with time and
this information cannot be contained with the block.
> <side-note>
> Eventually it would be helpful for the source website to include the
> static
> meta-info, live meta-info, and some pretty, graphical data from some
> community
> data miners like Agora, etc. to help evaluate the liveliness of a
> module and
> its developer and user communities. This could even be used by the
> developers
> to help track what is used, what is causing problems, what can be
> retired, etc.
> </side-note>
The ability to make sense out of complex datasets (such as mailboxes or
CVS commits) is the holy grail of datamining. Agora is one attempt to
provide useful information but without "pointing" fingers.
One thing that I would be *seriously* against is the establishment of
any kind of mechanical "metric" about the health of a community.
This is asking for trouble. A *LOT* of trouble.
While alpha/beta/final status don't hurt the community because nobody
really cares if one block was released as final and later a serious bug
was found, having users scared away from your block because there is no
community will make it even harder for that block to have a community
around.
The 'winner takes all' effect. One of the first behaviors exhibited by
power-law distributions (and each social community is one of them).
Power-law distributions are natural and cannot be avoided, but what we
can do is to 'reduce' the risk of aggregation, lowering the coefficient
of that power-law curve.
In Agora, for example, I didn't have any number shown. Nothing that can
be used to say "I'm more inflential than you are". Everything is fuzzy
and undefined, just like in real life. You get the "impression" but
impressions are not measurable and, even more, are not 'confrontable'
in a ordering way.
But using data-emergence patterns to estimate the health of a
community, well, it's a nightmare. Agora works on a few mechanical
severely strong assumptions:
1) one mail list -> one community
2) a reply -> social relationship between the two individuals
the rest is lots of math. Doing the same for CVS is much harder. I
think it is possible to estimate the health of a particular code by
looking at "patterns" of checkins, convolved with fourier analysis of
the sequences in time, confronted with the reply mail patterns.
But no matter *how* complex is the algorithm that comes out with some
numbers, those numbers will make someone happy and somebody unhappy...
and friction is created.
So, while accademically intriguing (I will continue to spend time
thinking at ways to create useful social datamining tools and
algorithms that come up with reasonble patterns), they are a social
minefield and I would like this community to stay away from them as
much as possible as everyday tools to judge people.
- o -
The best way to judge is to make a vote.
And the vote should not, in any circumstance, make the block being
voted bad if the vote doesn't pass.
So, the answer to
3) is the community healthy?
is misposed. I would like to have somethign a little less judging:
something like
3) is the cocoon community officially supporting this block?
The risk is to come up with something which is not really meaningful.
Because "official support" doesn't really mean anything.
But, at least, it's a distinction and a label of 'community health',
without necessarely implying that the community around (yet?)
unsupported blocks is not healthy.
Note that I'm in favor of changing the wording to whatever we might
find more appropriate, but one thing must be clear: we must try to
reduce the friction that a negative vote might create and we should try
to reduce the change that users will not want to try out un-stamped
blocks because scared by them.
Thoughts?
--
Stefano.
Re: on better release and version management
Posted by Timothy Larson <ti...@yahoo.com>.
Maybe we are having a hard time finding the "right" word because we are
mixing concerns. I can think of roughly four separate things the user
of a module would want to know:
(1) Is the module stable?
(i.e. is it considered to generally work properly with no critical bugs?)
(2) Will code written against it will work with future releases?
(i.e. will there be a back-compatibility effort made in new releases?)
(3) Will there likely be any future versions?
(i.e. is there still an active development person or community?)
(4) Are they the only guinea pigs actually using the module?
(i.e. is there an active user community?)
On another tack, this information is mostly dynamic:
While case (1) is usually static, but see the planned cocoon-2.1.1 -> 2.1.2
release for an example of this being a little dynamic. For a stronger
example, think of a crypto module after a security hole is found and
fixed in a new release. The old version transitions from stable to condemed.
Case (2) starts out as only an expression of intent and then transitions
when a new release is made to being an attribute of the new release that
reflects back on the release in question.
Cases (3) and (4) are not direct attributes of the module, but rather are
attributes of the community that reflect back on the module.
In all these cases, any meta-info included in a release can only represent
a snapshot in time. This is useful, but it would be better if it could be
combined with live meta-info retrieved from the module's source site upon
download, to account for reality drift over time.
<side-note>
Eventually it would be helpful for the source website to include the static
meta-info, live meta-info, and some pretty, graphical data from some community
data miners like Agora, etc. to help evaluate the liveliness of a module and
its developer and user communities. This could even be used by the developers
to help track what is used, what is causing problems, what can be retired, etc.
</side-note>
--Tim Larson
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
RE: on better release and version management
Posted by Jeff Ramsdale <je...@earthlink.net>.
See below...
> > What happens if we find out that a certain block is not supported any
> > more (technology outdated, we have a better block, any active
> > developers) *after* we marked it as supported. The first question I had
> > was "how long does supported mean"? The former proposed *certified*
> > relates to a certain point of time without saying something about the
> > future.
Whatever word is chosen will have to apply in situations where an
active/certified/supported/official block falls out of currency. That is, a
certified block can be decertified or a once-supported block can be later
designated unsupported.
> > Another point is that Cocoon is open source and nobody can be forced to
> > support a single line of code ...
> >
> > Maybe we can find a word that relates to a point of time and does not
> > have all the meanings "certified" has (see Berin's mail
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106434951718170&w=2)
>
> official?
I prefer supported. It doesn't have the same weight of organizational
obligation that official and certified do. It simply says that the community
impression is that there are people who care about and know about the block
to the degree that they won't allow it to lie fallow. There's not an
explicit or implicit promise of support, simply an impression of community
support.
> --
> Stefano.
Jeff
RE: on better release and version management
Posted by Reinhard Poetz <re...@apache.org>.
From: Stefano Mazzocchi
> On Wednesday, Sep 24, 2003, at 17:29 Europe/Rome, Reinhard
> Poetz wrote:
>
> >
> > From: Stefano Mazzocchi
> >
> >> On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin
> Loritsch wrote:
> >>
> >>> I would highly recommend steering away from the use of the word
> >>> certified unless you intend to establish a standards body
> to oversee
> >> an official
> >>> certification process.
> >>
> >> Good point. "Supported" sounds less marketing intrusive.
> >>
> >> comments?
> >
> > What happens if we find out that a certain block is not
> supported any
> > more (technology outdated, we have a better block, any active
> > developers) *after* we marked it as supported. The first question I
> > had was "how long does supported mean"? The former proposed
> > *certified* relates to a certain point of time without saying
> > something about the future.
> >
> > Another point is that Cocoon is open source and nobody can
> be forced
> > to support a single line of code ...
> >
> > Maybe we can find a word that relates to a point of time
> and does not
> > have all the meanings "certified" has (see Berin's mail
> >
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106434951718170&w=2)
>
> official?
+1
Reinhard
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Sep 24, 2003, at 17:29 Europe/Rome, Reinhard Poetz wrote:
>
> From: Stefano Mazzocchi
>
>> On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin Loritsch wrote:
>>
>>> I would highly recommend steering away from the use of the word
>>> certified
>>> unless you intend to establish a standards body to oversee
>> an official
>>> certification process.
>>
>> Good point. "Supported" sounds less marketing intrusive.
>>
>> comments?
>
> What happens if we find out that a certain block is not supported any
> more (technology outdated, we have a better block, any active
> developers) *after* we marked it as supported. The first question I had
> was "how long does supported mean"? The former proposed *certified*
> relates to a certain point of time without saying something about the
> future.
>
> Another point is that Cocoon is open source and nobody can be forced to
> support a single line of code ...
>
> Maybe we can find a word that relates to a point of time and does not
> have all the meanings "certified" has (see Berin's mail
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106434951718170&w=2)
official?
--
Stefano.
Re: on better release and version management
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Wednesday, September 24, 2003, at 04:29 PM, Reinhard Poetz wrote:
>
> From: Stefano Mazzocchi
>
>> On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin Loritsch wrote:
>>
>>> I would highly recommend steering away from the use of the word
>>> certified
>>> unless you intend to establish a standards body to oversee
>> an official
>>> certification process.
>>
>> Good point. "Supported" sounds less marketing intrusive.
>>
>> comments?
>
> What happens if we find out that a certain block is not supported any
> more (technology outdated, we have a better block, any active
> developers) *after* we marked it as supported. The first question I had
> was "how long does supported mean"? The former proposed *certified*
> relates to a certain point of time without saying something about the
> future.
Then we would vote to deprecate the block?
> Another point is that Cocoon is open source and nobody can be forced to
> support a single line of code ...
>
> Maybe we can find a word that relates to a point of time and does not
> have all the meanings "certified" has (see Berin's mail
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106434951718170&w=2)
'candidate'
- a block that has support in the 'community', but is not
considered production-ready
'supported'
- a production-ready block, that has community-support, was once
a 'candidate'
'deprecated'
- was once 'supported', but for some reason is no longer,
probably either for technological or community reasons
regards Jeremy
RE: on better release and version management
Posted by Reinhard Poetz <re...@apache.org>.
From: Stefano Mazzocchi
> On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin Loritsch wrote:
>
> > I would highly recommend steering away from the use of the word
> > certified
> > unless you intend to establish a standards body to oversee
> an official
> > certification process.
>
> Good point. "Supported" sounds less marketing intrusive.
>
> comments?
What happens if we find out that a certain block is not supported any
more (technology outdated, we have a better block, any active
developers) *after* we marked it as supported. The first question I had
was "how long does supported mean"? The former proposed *certified*
relates to a certain point of time without saying something about the
future.
Another point is that Cocoon is open source and nobody can be forced to
support a single line of code ...
Maybe we can find a word that relates to a point of time and does not
have all the meanings "certified" has (see Berin's mail
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106434951718170&w=2)
Reinhard
Re: on better release and version management
Posted by Timothy Larson <ti...@yahoo.com>.
--- Stefano Mazzocchi <st...@apache.org> wrote:
> Good point. "Supported" sounds less marketing intrusive.
>
> comments?
Yes, "supported" matches the concept better. It says someone
still cares about the block, that the community has not moved
on and left it behind.
--Tim Larson
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: on better release and version management
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 24 sep 2003, à 12:44 Europe/Zurich, Stefano Mazzocchi a
écrit :
> ..Good point. "Supported" sounds less marketing intrusive.
I like it too - "supported" vs. "unsupported" is very clear.
-Bertrand
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin Loritsch wrote:
> I would highly recommend steering away from the use of the word
> certified
> unless you intend to establish a standards body to oversee an official
> certification process.
Good point. "Supported" sounds less marketing intrusive.
comments?
--
Stefano.
Re: on better release and version management
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
> Certification, more than anything is a stamp on "trust".
>
> When installing something, the question a user poses wants answered: can
> I trust this? can I build my software on this?
>
> Certification provides an answer to this simple (yet vital!) question,
> expecially in an environment where, potentially, *TONS* of blocks,
> written by all sorts of companies, will come into existance.
Certification is a procedural thing. It can also be an administrative
nightmare. Some of these things can be addressed through version numbers,
etc. However, in the end it is always up to the application assembler
to validate whether the block is usable and stable. Even if it isn't,
the assembler may still choose to use it knowing the risks.
> A certified block will not be bugfree (no software can be!) but we
> guarantee that is supported, which means that we'll continue to maintain
> and improve on that functionality, which we consider important enough to
> support it officially.
>
> A certified block is a block that is here today and is guaranteed to be
> evolved tomorrow.
Really all we are talking about is some marker on a web page for any
particular block?
>
> Any other block is here today, but might not evolve at all tomorrow.
Hmm. This could be something along the lines of BCEL where it just
works, and there is very little to do for evolving it. It is still
"supported" in that sense.
> We will make the blocks officially supported, "certified", only when the
> cocoon development community feels this is good to do and it's *safe*
> from a community management perspective.
>
> Certification says nothing else.
I would use a different work. For example: if all we are saying is that
a block is supported, then use the word "supported".
Certification has some connotations that are not included in what you
are describing. For example:
* There is an official standards body that is in charge of certification.
* The block has undergone acceptance testing, and an official standards
body has declared that it has passed that testing.
* There is a certain contract that any issues with the certified object/
person can be mediated by that standards body.
For example, when you think of someone who is Java Certified or MSSE
Certified (or just plain certifiable ;P ), what comes to mind? When
you think of J2EE certification, what comes to mind?
I would highly recommend steering away from the use of the word certified
unless you intend to establish a standards body to oversee an official
certification process.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Sep 23, 2003, at 17:27 Europe/Rome, Bertrand Delacretaz
wrote:
> Le Mardi, 23 sep 2003, à 16:31 Europe/Zurich, Stefano Mazzocchi a
> écrit :
>> ...The system I outlined above seems really nice, but, IMO, has a few
>> serious drawbacks:
>>
>> 1) it requires a central authorithy of certification
>> 2) it creates an incredible amount of friction..
>
> Right. Nightmares in the making ;-)
exactly
>> ...I propose a much simpler scheme. A block can be:
>>
>> 1) certified
>> 2) not certified
>>
>> A certified block is said to be guaranteed by the certifier (not only
>> the Apache Cocoon project, but any organization willing to certify
>> their blocks) that this block is usable in production and will be
>> maintained in the future.
>>
>> In short, it's safe.
>
> Sounds good - it might be hard to decide whether to certify some of
> the current blocks which are simple but depend on external libraries
> on which the Cocoon team has no control, though.
Certification, more than anything is a stamp on "trust".
When installing something, the question a user poses wants answered:
can I trust this? can I build my software on this?
Certification provides an answer to this simple (yet vital!) question,
expecially in an environment where, potentially, *TONS* of blocks,
written by all sorts of companies, will come into existance.
A certified block will not be bugfree (no software can be!) but we
guarantee that is supported, which means that we'll continue to
maintain and improve on that functionality, which we consider important
enough to support it officially.
A certified block is a block that is here today and is guaranteed to be
evolved tomorrow.
Any other block is here today, but might not evolve at all tomorrow.
It is a statement about community dynamics.
We will make the blocks officially supported, "certified", only when
the cocoon development community feels this is good to do and it's
*safe* from a community management perspective.
Certification says nothing else.
> But this is way better than the current status anyway.
Yep
--
Stefano.
Re: on better release and version management
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mardi, 23 sep 2003, à 16:31 Europe/Zurich, Stefano Mazzocchi a écrit
:
> ...The system I outlined above seems really nice, but, IMO, has a few
> serious drawbacks:
>
> 1) it requires a central authorithy of certification
> 2) it creates an incredible amount of friction..
Right. Nightmares in the making ;-)
> ...I propose a much simpler scheme. A block can be:
>
> 1) certified
> 2) not certified
>
> A certified block is said to be guaranteed by the certifier (not only
> the Apache Cocoon project, but any organization willing to certify
> their blocks) that this block is usable in production and will be
> maintained in the future.
>
> In short, it's safe.
Sounds good - it might be hard to decide whether to certify some of the
current blocks which are simple but depend on external libraries on
which the Cocoon team has no control, though.
But this is way better than the current status anyway.
-Bertrand
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Sep 23, 2003, at 14:46 Europe/Rome, Bertrand Delacretaz
wrote:
> Le Mardi, 23 sep 2003, à 14:33 Europe/Zurich, Nicola Ken Barozzi a
> écrit :
>
>> Bertrand Delacretaz wrote:
>>
>>> Le Mardi, 23 sep 2003, à 14:26 Europe/Zurich, Nicola Ken Barozzi a
>>> écrit :
>>>> ...And maybe also use a low-tech way of adding a
>>>> WARNING_BETA_BLOCK.txt or WARNING_SCRATCHPAD_BLOCK.txt file in the
>>>> block source dir to make it clear to CVS browsers and coders of the
>>>> status of the code.
>>> Or rather an XML block description file?
>>> The upcoming block descriptor could include meta-information
>>> relating to the block's "stamping" status.
>>
>> The problem I see with having only a descriptor is that one hat to
>> open the file to see the status, and few will do, as the current
>> situation shows.
>>
>> That's why a file with a descriptive name can initially alert users
>> better...
>
> Why not, I see your point.
>
> But I also think blocks "quality descriptors" need to move beyond just
> "marked alpha", to more precise descriptions of how
> mature/usable/certified a block is.
>
> This info should also be used by the block deployer for warnings when
> installing non-certified, alpha or unstable blocks.
Say we had a rating system like this:
1) Development status:
a) design
b) under operation
c) maintainance
2) API status:
a) unstable
b) stable
3) Community level:
a) open individual effort
b) open plural effort from same affiliation
c) open diverse community
d) closed effort
Now, for example, you want to deploy
http://mycompany.com/blocks/myblock/1.0
in your system. This block depends on the block behavior
http://apache.org/cocoon/block/pdf/1.2
so, after you have deployed your block, the block deployer will ask the
block librarian:
Request:
who implements http://apache.org/cocoon/block/pdf/1.2?
Response:
a) http://apache.org/cocoon/block/FOP/2.3.343
implements http://apache.org/cocoon/block/pdf/1.4
has rating [1c,2b,3c]
b) http://apache.org/cocoon/block/FOP/3.0.24
implements http://apache.org/cocoon/block/pdf/1.12
has rating [1b,2b,3a]
c) http://apache.org/cocoon/block/iText/1.0.3
implements http://apache.org/cocoon/block/pdf/1.3
has rating [1c,2b,3b]
and prompts the user for a choice.
- o -
The system I outlined above seems really nice, but, IMO, has a few
serious drawbacks:
1) it requires a central authorithy of certification
2) it creates an incredible amount of friction
If we use http: block-id URI, the block librarian will, probably, be
connected to the URI used as a URL to localize a service that provides:
1) description of what that behavior does
2) list of available implementations of that behavior
This means that if the behavior is
http://mycompany.com/block/whatever/1.0, we don't have control (nor
should!) on what they say. It is entirely possible that they pretend
that they have blocks which are developped by a diverse community when
they do not.... and, if questioned, they would simply say that "diverse
community" doesn't have an objective meaning and they used their own.
But such quality metering would disturb even here: there are situations
(even today on our current blocks!) where the "diversity" of the
community around a single block is not so easy to measure and might
very well be considered "marketing" by some people that are investing
in the blocks... thus creating friction between blocks that perform
similar implementations.
- o -
I propose a much simpler scheme. A block can be:
1) certified
2) not certified
A certified block is said to be guaranteed by the certifier (not only
the Apache Cocoon project, but any organization willing to certify
their blocks) that this block is usable in production and will be
maintained in the future.
In short, it's safe.
NOTE: this certification process does *NOT* imply that not-certified
blocks are unsafe and might contain viral code or spyware. not at all.
the block deployment mechanism will do a signature verification with
the block librarian even for uncertified blocks. certification is meant
to guarantee the "backup" of a community or company behind the block.
So, the new librarian response would be
Request:
who implements http://apache.org/cocoon/block/pdf/1.2?
Response:
a) http://apache.org/cocoon/block/FOP/2.3.343
implements http://apache.org/cocoon/block/pdf/1.4
certified by: Apache Cocoon
b) http://apache.org/cocoon/block/FOP/3.0.24
implements http://apache.org/cocoon/block/pdf/1.12
c) http://apache.org/cocoon/block/iText/1.0.3
implements http://apache.org/cocoon/block/pdf/1.3
certified by: Apache Cocoon
NOTE: if a block is not maintained anymore, the librarian should not
list it up front.
This allows other entities to do certification (and this would mean
that *they* provide support and community/company backup of future
development) [if they lie, well, users will know and news will spread],
but, more important, it will require a single 'all encompassing' vote
from the community which would be: "are we ready to support this from
now on?"
Which, IMO, is a much easier question to ask than a myriad of small
non-objective questions like the above.
Thoughts?
--
Stefano.
Re: on better release and version management
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mardi, 23 sep 2003, à 14:33 Europe/Zurich, Nicola Ken Barozzi a
écrit :
> Bertrand Delacretaz wrote:
>
>> Le Mardi, 23 sep 2003, à 14:26 Europe/Zurich, Nicola Ken Barozzi a
>> écrit :
>>> ...And maybe also use a low-tech way of adding a
>>> WARNING_BETA_BLOCK.txt or WARNING_SCRATCHPAD_BLOCK.txt file in the
>>> block source dir to make it clear to CVS browsers and coders of the
>>> status of the code.
>> Or rather an XML block description file?
>> The upcoming block descriptor could include meta-information relating
>> to the block's "stamping" status.
>
> The problem I see with having only a descriptor is that one hat to
> open the file to see the status, and few will do, as the current
> situation shows.
>
> That's why a file with a descriptive name can initially alert users
> better...
Why not, I see your point.
But I also think blocks "quality descriptors" need to move beyond just
"marked alpha", to more precise descriptions of how
mature/usable/certified a block is.
This info should also be used by the block deployer for warnings when
installing non-certified, alpha or unstable blocks.
-Bertrand
Re: on better release and version management
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Bertrand Delacretaz wrote:
> Le Mardi, 23 sep 2003, à 14:26 Europe/Zurich, Nicola Ken Barozzi a écrit :
>
>> ...And maybe also use a low-tech way of adding a
>> WARNING_BETA_BLOCK.txt or WARNING_SCRATCHPAD_BLOCK.txt file in the
>> block source dir to make it clear to CVS browsers and coders of the
>> status of the code.
>
> Or rather an XML block description file?
> The upcoming block descriptor could include meta-information relating to
> the block's "stamping" status.
The problem I see with having only a descriptor is that one hat to open
the file to see the status, and few will do, as the current situation shows.
That's why a file with a descriptive name can initially alert users better.
Then there is also a descriptor and signature and all that, but it's
more about protecting the users than the developers IMHO.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Sep 23, 2003, at 14:26 Europe/Rome, Nicola Ken Barozzi
wrote:
> Stefano Mazzocchi wrote:
> ...
>> Instead of associating 'maturity levels' to the actual location of a
>> block, I would state that as a 'label' attached to it, a label that
>> the block deployer reacts to and prompt the user for action in case
>> the block is not considered "final" by the community.
>
> And maybe also use a low-tech way of adding a WARNING_BETA_BLOCK.txt
> or WARNING_SCRATCHPAD_BLOCK.txt file in the block source dir to make
> it clear to CVS browsers and coders of the status of the code.
Sure, good idea.
> ...
>> so, the only thing left is to define how you get those blocks
>> "stamped", but I think it would just require a community vote with a
>> majority.
>> Such "stamping" should be done thru the use of a digital certificate
>> so that the block deployer can say "this is a block certified by the
>> cocoon community as final".
>
> This is a novel and interesting proposal. I think we should try it. +1
Very happy you like it :-)
--
Stefano.
Re: on better release and version management
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mardi, 23 sep 2003, à 14:26 Europe/Zurich, Nicola Ken Barozzi a
écrit :
> ...And maybe also use a low-tech way of adding a
> WARNING_BETA_BLOCK.txt or WARNING_SCRATCHPAD_BLOCK.txt file in the
> block source dir to make it clear to CVS browsers and coders of the
> status of the code.
Or rather an XML block description file?
The upcoming block descriptor could include meta-information relating
to the block's "stamping" status.
-Bertrand
Re: on better release and version management
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
...
> Instead of associating 'maturity levels' to the actual location of a
> block, I would state that as a 'label' attached to it, a label that the
> block deployer reacts to and prompt the user for action in case the
> block is not considered "final" by the community.
And maybe also use a low-tech way of adding a WARNING_BETA_BLOCK.txt or
WARNING_SCRATCHPAD_BLOCK.txt file in the block source dir to make it
clear to CVS browsers and coders of the status of the code.
...
> so, the only thing left is to define how you get those blocks "stamped",
> but I think it would just require a community vote with a majority.
>
> Such "stamping" should be done thru the use of a digital certificate so
> that the block deployer can say "this is a block certified by the cocoon
> community as final".
This is a novel and interesting proposal. I think we should try it. +1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Sep 23, 2003, at 08:38 Europe/Rome, Nicola Ken Barozzi
wrote:
> Stefano Mazzocchi wrote:
>>
>> I fear one-man-shows.
>
> May I guess where this fear comes from... Avalon? ;-)
yeah
> I have the same fear.
>
>> At the same time, we need 'sort-of incubation' practices for blocks,
>> as it is impractical to think that a cocoon committer would develop
>> his/her code outside and submit it only when there is a community
>> around a block.
>
> Yes, I agree.
>
> This is why I had proposed to keep scratchpad blocks in the scratchpad
> and not mix them with released ones. This makes one-man shows easier
> to do and more difficult to manage.
Agreed.
At the same time, I want to avoid the "move things around" dance that
happens when something 'matures'.
As 'maturity' is not a black/white process (there is no point in time
where a community turns into maturity, it's just a feeling)
Instead of associating 'maturity levels' to the actual location of a
block, I would state that as a 'label' attached to it, a label that the
block deployer reacts to and prompt the user for action in case the
block is not considered "final" by the community.
That would:
1) keep the freedom to initiate as many blocks developers want
2) avoid the 'move things around' CVS dance
3) allow easy and mechanizable checking of which blocks are considered
"stamped" by the cocoon community.
so, the only thing left is to define how you get those blocks
"stamped", but I think it would just require a community vote with a
majority.
Such "stamping" should be done thru the use of a digital certificate so
that the block deployer can say "this is a block certified by the
cocoon community as final".
>> the block system will work effectively *ONLY* if there is strong
>> cross-pollination between blocks and if the cocoon community keeps
>> strong oversight over what happens.
>> this hasn't been so for many blocks so far and I see this as a
>> potential problem.
>
> It's just the beginning.
> I would suggest to:
>
> 1) keep the voting system and responsibility over blocks as now, that
> is
> open to all Cocoon committers
+1, I would just suggest, for 2.2, that all blocks that want
"certification" are required to obtain this thru a vote. And, before
the certification can happen, a few things must be done, mostly,
community diversity checking and documentation availability.
> 2) make a scratchpad-incubaton-callitwhatyouwant directory or even
> better CVS module where alpha blocks or features are done
-1 on this, as for the cvs-dance argument above.
> 3) partition commit acces like this:
> 1) only core cocoon committers can commit to the core
> 2) all committers have access to Lenya, Forrest and Blocks
+1
> (when/is Forrest going to actually move?)
don't know the status of this
--
Stefano.
Re: on better release and version management
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
>
> On Sunday, Sep 21, 2003, at 12:39 Europe/Rome, Upayavira wrote:
>
>> Steven Noels wrote:
>>
>>> Joerg Heinicke wrote:
>>>
>>>> IMO this is difficult to maintain. If someone wants to look on the
>>>> code base of a block he has to search for its dependencies first or
>>>> search for the code at different places. Can't we extract the blocks
>>>> from 2.1 "as they are" at the moment and move them to cocoon-blocks
>>>> module, so that they are collected at one place.
>>>
>>> I like this: +1
>>
>> +1 I like this too. Minimal changes to 2.1 to make it work with the
>> new blocks repository, and we can then get on with 2.2 core.
>
> to be clear: I'm not against this, but only after people realize the
> problems that might come up and we come up with consensus on how we are
> going to deal with those problems *when* they come up
>
> Not if, because you can bet that over-blockization is going to happen...
> or, at least, asked for.
>
> As it is today, blocks are not only modular packages to extend cocoon
> (as fop and batik, for example, who triggered the creation of the fake
> block system), but also a way to propose new stuff as one-man-shows.
>
> I fear one-man-shows.
May I guess where this fear comes from... Avalon? ;-)
I have the same fear.
> At the same time, we need 'sort-of incubation' practices for blocks, as
> it is impractical to think that a cocoon committer would develop his/her
> code outside and submit it only when there is a community around a block.
Yes, I agree.
This is why I had proposed to keep scratchpad blocks in the scratchpad
and not mix them with released ones. This makes one-man shows easier to
do and more difficult to manage.
> the block system will work effectively *ONLY* if there is strong
> cross-pollination between blocks and if the cocoon community keeps
> strong oversight over what happens.
>
> this hasn't been so for many blocks so far and I see this as a potential
> problem.
It's just the beginning.
I would suggest to:
1) keep the voting system and responsibility over blocks as now, that is
open to all Cocoon committers
2) make a scratchpad-incubaton-callitwhatyouwant directory or even
better CVS module where alpha blocks or features are done
3) partition commit acces like this:
1) only core cocoon committers can commit to the core
2) all committers have access to Lenya, Forrest and Blocks
(when/is Forrest going to actually move?)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: on better release and version management
Posted by Joerg Heinicke <jh...@virbus.de>.
Stefano Mazzocchi wrote:
>
>>> Joerg Heinicke wrote:
>>>
>>>> IMO this is difficult to maintain. If someone wants to look on the
>>>> code base of a block he has to search for its dependencies first or
>>>> search for the code at different places. Can't we extract the blocks
>>>> from 2.1 "as they are" at the moment and move them to cocoon-blocks
>>>> module, so that they are collected at one place.
>
> to be clear: I'm not against this, but only after people realize the
> problems that might come up and we come up with consensus on how we are
> going to deal with those problems *when* they come up
>
> Not if, because you can bet that over-blockization is going to happen...
> or, at least, asked for.
>
> As it is today, blocks are not only modular packages to extend cocoon
> (as fop and batik, for example, who triggered the creation of the fake
> block system), but also a way to propose new stuff as one-man-shows.
>
> I fear one-man-shows.
>
> At the same time, we need 'sort-of incubation' practices for blocks, as
> it is impractical to think that a cocoon committer would develop his/her
> code outside and submit it only when there is a community around a block.
>
> the block system will work effectively *ONLY* if there is strong
> cross-pollination between blocks and if the cocoon community keeps
> strong oversight over what happens.
>
> this hasn't been so for many blocks so far and I see this as a potential
> problem.
So it's a community issue on the one hand and a "we do not know which
problems could be arise" on the other hand. The first thing we can of
course handle now, the other thing we will see ...
Joerg
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Sep 21, 2003, at 12:39 Europe/Rome, Upayavira wrote:
> Steven Noels wrote:
>
>> Joerg Heinicke wrote:
>>
>>> IMO this is difficult to maintain. If someone wants to look on the
>>> code base of a block he has to search for its dependencies first or
>>> search for the code at different places. Can't we extract the blocks
>>> from 2.1 "as they are" at the moment and move them to cocoon-blocks
>>> module, so that they are collected at one place.
>>
>>
>> I like this: +1
>
> +1 I like this too. Minimal changes to 2.1 to make it work with the
> new blocks repository, and we can then get on with 2.2 core.
to be clear: I'm not against this, but only after people realize the
problems that might come up and we come up with consensus on how we are
going to deal with those problems *when* they come up
Not if, because you can bet that over-blockization is going to
happen... or, at least, asked for.
As it is today, blocks are not only modular packages to extend cocoon
(as fop and batik, for example, who triggered the creation of the fake
block system), but also a way to propose new stuff as one-man-shows.
I fear one-man-shows.
At the same time, we need 'sort-of incubation' practices for blocks, as
it is impractical to think that a cocoon committer would develop
his/her code outside and submit it only when there is a community
around a block.
the block system will work effectively *ONLY* if there is strong
cross-pollination between blocks and if the cocoon community keeps
strong oversight over what happens.
this hasn't been so for many blocks so far and I see this as a
potential problem.
--
Stefano.
Re: on better release and version management
Posted by Upayavira <uv...@upaya.co.uk>.
Steven Noels wrote:
> Joerg Heinicke wrote:
>
>> IMO this is difficult to maintain. If someone wants to look on the
>> code base of a block he has to search for its dependencies first or
>> search for the code at different places. Can't we extract the blocks
>> from 2.1 "as they are" at the moment and move them to cocoon-blocks
>> module, so that they are collected at one place.
>
>
> I like this: +1
+1 I like this too. Minimal changes to 2.1 to make it work with the new
blocks repository, and we can then get on with 2.2 core.
Upayavira
Re: on better release and version management
Posted by Steven Noels <st...@outerthought.org>.
Joerg Heinicke wrote:
> IMO this is difficult to maintain. If someone wants to look on the code
> base of a block he has to search for its dependencies first or search
> for the code at different places. Can't we extract the blocks from 2.1
> "as they are" at the moment and move them to cocoon-blocks module, so
> that they are collected at one place.
I like this: +1
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Sep 21, 2003, at 01:40 Europe/Rome, Joerg Heinicke wrote:
> Stefano Mazzocchi wrote:
>>> OTOH if it is the case, then we're back to needing an uninhibited
>>> way to experiment with them, and the block.xml and the whole block
>>> content may need to be duplicated in 2.2 until cocoon-blocks is
>>> worked out.
>> yes. if the fop block, for example, requires dependencies on batik,
>> it cannot behave the same as a fake block and a real one. it has to
>> move.
>>> But if we agree that any blocks in 2.2 will be kicked out later
>>> either to find a home at cocoon-blocks or elsewhere our hands still
>>> will be free.
>> Yes, I think this is a good compromise:
>> 1) keep blocks that don't have subdependencies on cocoon-2.1
>> 2) move blocks that have dependencies in cocoon-2.2
>> 3) when the block architecture is finished, design the procedures on
>> how blocks are
>> - submitted
>> - accepted
>> - developped
>> - released
>> - frozen
>> i expect this to be a can of community worms and personal interests,
>> so i don't want to tacle this until we have something that works in
>> place.
>
> IMO this is difficult to maintain. If someone wants to look on the
> code base of a block he has to search for its dependencies first or
> search for the code at different places. Can't we extract the blocks
> from 2.1 "as they are" at the moment and move them to cocoon-blocks
> module, so that they are collected at one place. Is the above proposal
> only because of community issues? What prevents us from doing the move
> to cocoon-blocks as first step?
First of all, because I'm not sure if one CVS module for blocks is a
good thing to do.
For example, you can't tag parts of a module.
But also, asking a new CVS module to be created for every cocoon block
seems a little bit excessive.
Besides, what happens if blocks evolve in a back-incompatible way and
require two branches? do we branch the entire module? do we move the
block in its own module?
If cocoon ends up having 230 different CVS modules, the ASF
infrastructure will start streaming and the board will fear that cocoon
is exploding.
These are only a few of the reasons why I want to be very cautious with
this block move: when the block implementation is finished, I fear
over-blockization.
before everybody and their sisters start to branch off their single
stylesheets into a different block, we need at least a few rough
policies in place. keeping them in cocoon-2.1 will, at least, force
people to think twice before adding and moving things around.
Blocks will unleash the power of an incredibly scalable parallel
development. Given the amount of activity this community has, I'm more
concerned on how to avoid it gains too much speed before it can be
safely slowed down and guided thru useful directions.
--
Stefano.
Re: on better release and version management
Posted by Joerg Heinicke <jh...@virbus.de>.
Stefano Mazzocchi wrote:
>
>> OTOH if it is the case, then we're back to needing an uninhibited way
>> to experiment with them, and the block.xml and the whole block content
>> may need to be duplicated in 2.2 until cocoon-blocks is worked out.
>
> yes. if the fop block, for example, requires dependencies on batik, it
> cannot behave the same as a fake block and a real one. it has to move.
>
>> But if we agree that any blocks in 2.2 will be kicked out later either
>> to find a home at cocoon-blocks or elsewhere our hands still will be
>> free.
>
> Yes, I think this is a good compromise:
>
> 1) keep blocks that don't have subdependencies on cocoon-2.1
>
> 2) move blocks that have dependencies in cocoon-2.2
>
> 3) when the block architecture is finished, design the procedures on how
> blocks are
>
> - submitted
> - accepted
> - developped
> - released
> - frozen
>
> i expect this to be a can of community worms and personal interests, so
> i don't want to tacle this until we have something that works in place.
IMO this is difficult to maintain. If someone wants to look on the code
base of a block he has to search for its dependencies first or search
for the code at different places. Can't we extract the blocks from 2.1
"as they are" at the moment and move them to cocoon-blocks module, so
that they are collected at one place. Is the above proposal only because
of community issues? What prevents us from doing the move to
cocoon-blocks as first step?
Joerg
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Sep 19, 2003, at 15:54 Europe/Rome, Geoff Howard wrote:
> Hmmm... I've been assuming that the way a block actually gets coded
> may need to change in order to interact with other real blocks, etc.
> If this is not the case, then the whole issue of back-compatibility of
> blocks goes away and keeping them in 2.1 is fine.
No. I took great care in designing the system so that it could work
with existing blocks and incrementally adjust to the new features that
the infrastructure provide.
it is true, however, that once a block starts depending on another
block, it can no longer be considered a 'fake block' as the cocoon 2.1
system is not designed to handle subdependencies (batik and fop, for
example)
>
> OTOH if it is the case, then we're back to needing an uninhibited way
> to experiment with them, and the block.xml and the whole block content
> may need to be duplicated in 2.2 until cocoon-blocks is worked out.
yes. if the fop block, for example, requires dependencies on batik, it
cannot behave the same as a fake block and a real one. it has to move.
> But if we agree that any blocks in 2.2 will be kicked out later either
> to find a home at cocoon-blocks or elsewhere our hands still will be
> free.
Yes, I think this is a good compromise:
1) keep blocks that don't have subdependencies on cocoon-2.1
2) move blocks that have dependencies in cocoon-2.2
3) when the block architecture is finished, design the procedures on
how blocks are
- submitted
- accepted
- developped
- released
- frozen
i expect this to be a can of community worms and personal interests, so
i don't want to tacle this until we have something that works in place.
--
Stefano.
Re: on better release and version management
Posted by Geoff Howard <co...@leverageweb.com>.
Stefano Mazzocchi wrote:
> On Friday, Sep 19, 2003, at 15:05 Europe/Rome, Geoff Howard wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Steven Noels wrote:
...
>>> The only problem is if "real blocks" require to modify the directory
>>> structure of blocks. I'm not sure of this, as I mostly envision it as
>>> an augmentation of the current structure, e.g. with a new "web"
>>> directory that would contain the block's sitemap and resources.
>>
>> I don't think this will be necessary - at least Stefano certainly
>> didn't seem to think it necessary because he was planning on doing all
>> this right in 2.1.
>
> After a little more thinking, I think that we should avoid placing block
> code in cocoon-2.2 alltogether because we need to start talking about
> the 'community process' of accepting new blocks, where they fit, how
> they get 'certified' and all these things.
>
> So, I agree: let's make cocoon-2.2 and keep all the block code out for
> now (the build process can construct the code from the cocoon-2.1
> repository.
>
> This leaves open a single question: where do we put the various
> block.xml descriptor files? I would say cocoon-2.1 for now and later
> moved them into a new cocoon-blocks module.
Hmmm... I've been assuming that the way a block actually gets coded may
need to change in order to interact with other real blocks, etc. If
this is not the case, then the whole issue of back-compatibility of
blocks goes away and keeping them in 2.1 is fine.
OTOH if it is the case, then we're back to needing an uninhibited way to
experiment with them, and the block.xml and the whole block content may
need to be duplicated in 2.2 until cocoon-blocks is worked out. But if
we agree that any blocks in 2.2 will be kicked out later either to find
a home at cocoon-blocks or elsewhere our hands still will be free.
Geoff
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Sep 19, 2003, at 15:57 Europe/Rome, Timothy Larson wrote:
> Development would proceed roughly like this:
>
> Step 1:
> cocoon-2.1
> Contains its own blocks
> cocoon-2.2
> Retrieves blocks from cocoon-2.1
> cocoon-blocks
> Empty or non-existent
>
> Step 2:
> cocoon-2.1
> Contains its own blocks
> Learns to retrieve additional blocks from cocoon-blocks
> cocoon-2.2
> Retrieves blocks from cocoon-2.1
> Learns to retrieve additional blocks from cocoon-blocks
> cocoon-blocks
> Contains blocks markedup with version compatibility information
> Some community review setup for contributed blocks
>
> Step 3:
> cocoon-2.1
> Retrieves blocks from cocoon-blocks
> cocoon-2.2
> Retrieves blocks from from cocoon-blocks
> cocoon-blocks
> Contains blocks markedup with version compatibility information
> Some community review setup for contributed blocks
That's a possible scenario of various phases, yes.
but I don't think that cocoon-2.1 will ever be able to work with real
blocks (that's not what we plan to do), so step 3 is unlikely to happen
for cocoon-2.1
As for cocoon-blocks and how it works, as I said in my previous email,
I don't want to think about it just yet.
--
Stefano.
Re: on better release and version management
Posted by Timothy Larson <ti...@yahoo.com>.
--- Stefano Mazzocchi <st...@apache.org> wrote:
> After a little more thinking, I think that we should avoid placing
> block code in cocoon-2.2 alltogether because we need to start talking
> about the 'community process' of accepting new blocks, where they fit,
> how they get 'certified' and all these things.
>
> So, I agree: let's make cocoon-2.2 and keep all the block code out for
> now (the build process can construct the code from the cocoon-2.1
> repository.
>
> This leaves open a single question: where do we put the various
> block.xml descriptor files? I would say cocoon-2.1 for now and later
> moved them into a new cocoon-blocks module.
>
> What do you think?
>
> --
> Stefano.
>
Lets see if I understood.
We would have three compartments: cocoon-2.1, cocoon-2.2, and cocoon-blocks.
Development would proceed roughly like this:
Step 1:
cocoon-2.1
Contains its own blocks
cocoon-2.2
Retrieves blocks from cocoon-2.1
cocoon-blocks
Empty or non-existent
Step 2:
cocoon-2.1
Contains its own blocks
Learns to retrieve additional blocks from cocoon-blocks
cocoon-2.2
Retrieves blocks from cocoon-2.1
Learns to retrieve additional blocks from cocoon-blocks
cocoon-blocks
Contains blocks markedup with version compatibility information
Some community review setup for contributed blocks
Step 3:
cocoon-2.1
Retrieves blocks from cocoon-blocks
cocoon-2.2
Retrieves blocks from from cocoon-blocks
cocoon-blocks
Contains blocks markedup with version compatibility information
Some community review setup for contributed blocks
--Tim Larson
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
RE: on better release and version management
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> <SNIP/>
> > +1 let's give it a shot. This is probably what Carsten was picturing
> > all along. :)
>
> +1 as well. the magic "build script that gets missing blocks from 2.1"
> would simply be a cvs checkout, followed with a few file copy
> operations.
>
Yes, I thought of that, too, so:
+1 (of course ;) )
>
> After a little more thinking, I think that we should avoid placing
> block code in cocoon-2.2 alltogether because we need to start talking
> about the 'community process' of accepting new blocks, where they fit,
> how they get 'certified' and all these things.
>
> So, I agree: let's make cocoon-2.2 and keep all the block code out for
> now (the build process can construct the code from the cocoon-2.1
> repository.
>
+100
> This leaves open a single question: where do we put the various
> block.xml descriptor files? I would say cocoon-2.1 for now and later
> moved them into a new cocoon-blocks module.
>
Ok.
Carsten
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Sep 19, 2003, at 15:05 Europe/Rome, Geoff Howard wrote:
> Sylvain Wallez wrote:
>> Steven Noels wrote:
>>> Carsten Ziegeler wrote:
>>>
>>> <snip type="happy agreement"/>
>>>
>>>> I tried to address this issue several times in the last weeks,
>>>> well, without much success.
>
> ...
>
>>>> So, whatever we decide, I'm -1 on duplicating the block code.
>>>
>>> My problem with the blocks code is that reusing the 2.1 blocks code
>>> would force people to make blocks upwards-compatible, slowing down
>>> transitioning between old- and new-style blocks.
>
> ...
>
>> Let me try to make a synthesis and proposal :
>> 1 - creating a 2.2 repository is necessary to start working while
>> still be able to issue 2.1.x maintainance releases,
>> 2 - copying all blocks to the 2.2 repo is not wanted since not all
>> blocks will evolve in the 2.2
>> 3 - the "real blocks" may require some modifications of the current
>> "fake blocks".
>> So what about the following (somewhat already expressed, BTW) :
>> - start a 2.2 repo with only the Cocoon core (i.e. src/java)
>> - copy blocks in the 2.2 repo only if they require substantial
>> changes that would break the ability to quickly do a 2.1.x release.
>> - have an intelligent 2.2 build that gets missing blocks from the 2.1
>> (IIRC Carsten talked about it)
>> - backport to the 2.1 non disruptive enhancements/bug fixes appearing
>> in the 2.2 repo
>
> +1 let's give it a shot. This is probably what Carsten was picturing
> all along. :)
+1 as well. the magic "build script that gets missing blocks from 2.1"
would simply be a cvs checkout, followed with a few file copy
operations.
>> About blocks, we can envision that some block evolutions can happen
>> into the 2.2 repo and, if back-compatible, be fully copied back to
>> the 2.1. In that case, the block would be removed from the 2.2 repo,
>> until a new evolution cycle comes again on that block.
>
> ok
>
>> The only problem is if "real blocks" require to modify the directory
>> structure of blocks. I'm not sure of this, as I mostly envision it as
>> an augmentation of the current structure, e.g. with a new "web"
>> directory that would contain the block's sitemap and resources.
>
> I don't think this will be necessary - at least Stefano certainly
> didn't seem to think it necessary because he was planning on doing all
> this right in 2.1.
After a little more thinking, I think that we should avoid placing
block code in cocoon-2.2 alltogether because we need to start talking
about the 'community process' of accepting new blocks, where they fit,
how they get 'certified' and all these things.
So, I agree: let's make cocoon-2.2 and keep all the block code out for
now (the build process can construct the code from the cocoon-2.1
repository.
This leaves open a single question: where do we put the various
block.xml descriptor files? I would say cocoon-2.1 for now and later
moved them into a new cocoon-blocks module.
What do you think?
--
Stefano.
Re: on better release and version management
Posted by Geoff Howard <co...@leverageweb.com>.
Sylvain Wallez wrote:
> Steven Noels wrote:
>
>> Carsten Ziegeler wrote:
>>
>> <snip type="happy agreement"/>
>>
>>> I tried to address this issue several times in the last weeks, well,
>>> without much success.
...
>>> So, whatever we decide, I'm -1 on duplicating the block code.
>>
>> My problem with the blocks code is that reusing the 2.1 blocks code
>> would force people to make blocks upwards-compatible, slowing down
>> transitioning between old- and new-style blocks.
...
> Let me try to make a synthesis and proposal :
>
> 1 - creating a 2.2 repository is necessary to start working while still
> be able to issue 2.1.x maintainance releases,
> 2 - copying all blocks to the 2.2 repo is not wanted since not all
> blocks will evolve in the 2.2
> 3 - the "real blocks" may require some modifications of the current
> "fake blocks".
>
> So what about the following (somewhat already expressed, BTW) :
> - start a 2.2 repo with only the Cocoon core (i.e. src/java)
> - copy blocks in the 2.2 repo only if they require substantial changes
> that would break the ability to quickly do a 2.1.x release.
> - have an intelligent 2.2 build that gets missing blocks from the 2.1
> (IIRC Carsten talked about it)
> - backport to the 2.1 non disruptive enhancements/bug fixes appearing in
> the 2.2 repo
+1 let's give it a shot. This is probably what Carsten was picturing
all along. :)
> About blocks, we can envision that some block evolutions can happen into
> the 2.2 repo and, if back-compatible, be fully copied back to the 2.1.
> In that case, the block would be removed from the 2.2 repo, until a new
> evolution cycle comes again on that block.
ok
> The only problem is if "real blocks" require to modify the directory
> structure of blocks. I'm not sure of this, as I mostly envision it as an
> augmentation of the current structure, e.g. with a new "web" directory
> that would contain the block's sitemap and resources.
I don't think this will be necessary - at least Stefano certainly didn't
seem to think it necessary because he was planning on doing all this
right in 2.1.
Geoff
Re: on better release and version management
Posted by Timothy Larson <ti...@yahoo.com>.
I like it. We can have unhindered progress, without the duplication of
blocks being all-or-nothing.
--Tim Larson
--- Sylvain Wallez <sy...@anyware-tech.com> wrote:
> So what about the following (somewhat already expressed, BTW) :
> - start a 2.2 repo with only the Cocoon core (i.e. src/java)
> - copy blocks in the 2.2 repo only if they require substantial changes
> that would break the ability to quickly do a 2.1.x release.
> - have an intelligent 2.2 build that gets missing blocks from the 2.1
> (IIRC Carsten talked about it)
> - backport to the 2.1 non disruptive enhancements/bug fixes appearing in
> the 2.2 repo
>
> About blocks, we can envision that some block evolutions can happen into
> the 2.2 repo and, if back-compatible, be fully copied back to the 2.1.
> In that case, the block would be removed from the 2.2 repo, until a new
> evolution cycle comes again on that block.
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: on better release and version management
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Vendredi, 19 sep 2003, à 14:47 Europe/Zurich, Sylvain Wallez a écrit
:
> ...So what about the following (somewhat already expressed, BTW) :
> - start a 2.2 repo with only the Cocoon core (i.e. src/java)
> - copy blocks in the 2.2 repo only if they require substantial changes
> that would break the ability to quickly do a 2.1.x release.
> - have an intelligent 2.2 build that gets missing blocks from the 2.1
> (IIRC Carsten talked about it)
> - backport to the 2.1 non disruptive enhancements/bug fixes appearing
> in the 2.2 repo
Sounds perfect from here!
I'd just add a first (obvious) step:
-Tag the 2.1 repository before the move
> ..The only problem is if "real blocks" require to modify the directory
> structure of blocks. I'm not sure of this, as I mostly envision it as
> an augmentation of the current structure, e.g. with a new "web"
> directory that would contain the block's sitemap and resources...
I think the above structure allows us to take care of this in due time,
should the need arise.
-Bertrand
Re: on better release and version management
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Steven Noels wrote:
> Carsten Ziegeler wrote:
>
> <snip type="happy agreement"/>
>
>> I tried to address this issue several times in the last weeks, well,
>> without much success.
>> One thing I want to stress again: *if* we would make a new repository
>> for 2.2 and duplicate all code, this would include the blocks as well.
>> So we would not only end up with the two versions to maintain for the
>> core
>> but for each and every block as well! And this makes imho no sense.
>> It's ok for the core, if we say 2.1 is only bug-fixing from now on.
>> But it makes absolutely no sense for blocks. I think the development
>> of blocks should be independent from the
>> development of the core. With duplicating the code we loose this.
>>
>> So, whatever we decide, I'm -1 on duplicating the block code.
>
>
> My problem with the blocks code is that reusing the 2.1 blocks code
> would force people to make blocks upwards-compatible, slowing down
> transitioning between old- and new-style blocks.
>
> During the Hackathon on the 6th, I will be busy with GT preparations,
> so I won't be able to participate much with the discussions. :-(
> Anyway, please be assured that Bruno and I discussed the aspect of
> compatibility at length, and IIRC Bruno has been jotting down notes
> for this bound-to-be-happening IRL discussion. I don't think that we
> can 1) require 2.2 compatibility by all blocks, since some of them are
> only worked on by a few people, and 2) we should hinder progress on
> 2.2 blocks by requiring them to be stuck in the 2.1 repository. I know
> that we will try and do our best to keep the 2.1 version of Woody in a
> sane state after 2.2 development starts, most probably also
> backporting new things that happen along the 2.2 'branch'. Still, we
> want a freeway for 2.2 development, should the need arise.
>
> Does that help? Or do I misunderstand your view on this matter?
>
> (me being happy to at least being able to contribute _something_ this
> days)
Let me try to make a synthesis and proposal :
1 - creating a 2.2 repository is necessary to start working while still
be able to issue 2.1.x maintainance releases,
2 - copying all blocks to the 2.2 repo is not wanted since not all
blocks will evolve in the 2.2
3 - the "real blocks" may require some modifications of the current
"fake blocks".
So what about the following (somewhat already expressed, BTW) :
- start a 2.2 repo with only the Cocoon core (i.e. src/java)
- copy blocks in the 2.2 repo only if they require substantial changes
that would break the ability to quickly do a 2.1.x release.
- have an intelligent 2.2 build that gets missing blocks from the 2.1
(IIRC Carsten talked about it)
- backport to the 2.1 non disruptive enhancements/bug fixes appearing in
the 2.2 repo
About blocks, we can envision that some block evolutions can happen into
the 2.2 repo and, if back-compatible, be fully copied back to the 2.1.
In that case, the block would be removed from the 2.2 repo, until a new
evolution cycle comes again on that block.
The only problem is if "real blocks" require to modify the directory
structure of blocks. I'm not sure of this, as I mostly envision it as an
augmentation of the current structure, e.g. with a new "web" directory
that would contain the block's sitemap and resources.
What do you think ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: on better release and version management
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> A few points:
>
> 1) there is no *block* code in cocoon 2.1, everything is done by the
> builder.
Hey, I knew that already! ;-)
> 2) blocks in 2.1 and blocks in 2.2 are a single block.xml file away.
Given all this stuff of block-specific classloading and much more
technical details that I'd love to understand all about, I'm seriously
wondering whether a block.xml will be the only difference between a 2.1
and a 2.2 block. Or am I completely misguided by my phantasy? (could
well be, I have a vivid imagination)
Help?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: on better release and version management
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Sep 19, 2003, at 11:39 Europe/Rome, Steven Noels wrote:
> Carsten Ziegeler wrote:
>
> <snip type="happy agreement"/>
>
>> I tried to address this issue several times in the last weeks, well,
>> without much success.
>> One thing I want to stress again: *if* we would make a new repository
>> for 2.2 and duplicate all code, this would include the blocks as well.
>> So we would not only end up with the two versions to maintain for the
>> core
>> but for each and every block as well! And this makes imho no sense.
>> It's ok for the core, if we say 2.1 is only bug-fixing from now on.
>> But it makes absolutely no sense for blocks. I think the development
>> of blocks should be independent from the
>> development of the core. With duplicating the code we loose this.
>> So, whatever we decide, I'm -1 on duplicating the block code.
>
> My problem with the blocks code is that reusing the 2.1 blocks code
> would force people to make blocks upwards-compatible, slowing down
> transitioning between old- and new-style blocks.
>
> During the Hackathon on the 6th, I will be busy with GT preparations,
> so I won't be able to participate much with the discussions. :-(
> Anyway, please be assured that Bruno and I discussed the aspect of
> compatibility at length, and IIRC Bruno has been jotting down notes
> for this bound-to-be-happening IRL discussion. I don't think that we
> can 1) require 2.2 compatibility by all blocks, since some of them are
> only worked on by a few people, and 2) we should hinder progress on
> 2.2 blocks by requiring them to be stuck in the 2.1 repository. I know
> that we will try and do our best to keep the 2.1 version of Woody in a
> sane state after 2.2 development starts, most probably also
> backporting new things that happen along the 2.2 'branch'. Still, we
> want a freeway for 2.2 development, should the need arise.
>
> Does that help? Or do I misunderstand your view on this matter?
A few points:
1) there is no *block* code in cocoon 2.1, everything is done by the
builder.
2) blocks in 2.1 and blocks in 2.2 are a single block.xml file away.
This shows that it's entirely possible to implement real blocks in the
cocoon-2.1 module, would we wish to do so
--
Stefano.
Re: on better release and version management
Posted by Steven Noels <st...@outerthought.org>.
Carsten Ziegeler wrote:
<snip type="happy agreement"/>
> I tried to address this issue several times in the last weeks, well,
> without much success.
> One thing I want to stress again: *if* we would make a new repository
> for 2.2 and duplicate all code, this would include the blocks as well.
> So we would not only end up with the two versions to maintain for the core
> but for each and every block as well!
> And this makes imho no sense. It's ok for the core, if we say 2.1 is only
> bug-fixing from now on. But it makes absolutely no sense for blocks.
> I think the development of blocks should be independent from the
> development of the core. With duplicating the code we loose this.
>
> So, whatever we decide, I'm -1 on duplicating the block code.
My problem with the blocks code is that reusing the 2.1 blocks code
would force people to make blocks upwards-compatible, slowing down
transitioning between old- and new-style blocks.
During the Hackathon on the 6th, I will be busy with GT preparations, so
I won't be able to participate much with the discussions. :-( Anyway,
please be assured that Bruno and I discussed the aspect of compatibility
at length, and IIRC Bruno has been jotting down notes for this
bound-to-be-happening IRL discussion. I don't think that we can 1)
require 2.2 compatibility by all blocks, since some of them are only
worked on by a few people, and 2) we should hinder progress on 2.2
blocks by requiring them to be stuck in the 2.1 repository. I know that
we will try and do our best to keep the 2.1 version of Woody in a sane
state after 2.2 development starts, most probably also backporting new
things that happen along the 2.2 'branch'. Still, we want a freeway for
2.2 development, should the need arise.
Does that help? Or do I misunderstand your view on this matter?
(me being happy to at least being able to contribute _something_ this days)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: docs disruption
Posted by Joerg Heinicke <jh...@virbus.de>.
Bertrand Delacretaz wrote:
> Le Vendredi, 19 sep 2003, à 11:25 Europe/Zurich, Carsten Ziegeler a écrit :
>
>> ...Now to the docs:
>> Yes, looking back it was a very stupid idea to reorganize the docs. I
>> didn't thought about links pointing to the old docs. I'm very sorry
>> for that!
>
> I don't think it was a stupid idea - after so much talk on how to
> organize the docs, your were the one to jump in and actually do something.
> Maybe using a CVS branch for this would have been better, but IMHO the
> docs beg to be reorganized.
+1 The old docs were unuseful (overstating of course). They needed a
restructure and you have done it - so I'm ok with it.
>> ...What do to if you move a document?...
>
> We had some talks on the docs list [1], David Crossley has some
> interesting ideas in [2] ("special generator").
>
> I think any static way of redirecting from old to new docs will fail, as
> people will be too lazy to handle it properly.
> Even without a dynamic Cocoon instance to serve the website, it would be
> possible to generate redirect pages or .htaccess files from the registry
> suggested by David.
Is it such a big issue to have broken links? As far as I'm guided to the
new page I have no problems with them. This does not only mean a
redirect, but also providing a useful search page with the results of a
default search taken from the broken link. Almost all our links provide
semantic hints to do a useful search.
At the moment our search on the "root" website does not work (404), the
2.1 module uses Google. And we have ugly 404 pages, which every possible
Cocoon users will leave immediately.
>> ...If you all want, I could try to reinstantiate the old doc structure,
>> this will take some days, but it's possible....
>
> I don't want it, I think some disruption is needed to make the docs happen.
> But if people want it, maybe you could reinstate the last released CVS
> version of the docs and put your new stuff in a branch?
-.5 not necessary IMO
Joerg
docs disruption (was: on better release and version management)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Vendredi, 19 sep 2003, à 11:25 Europe/Zurich, Carsten Ziegeler a
écrit :
> ...Now to the docs:
> Yes, looking back it was a very stupid idea to reorganize the docs. I
> didn't thought about links pointing to the old docs. I'm very sorry
> for that!
I don't think it was a stupid idea - after so much talk on how to
organize the docs, your were the one to jump in and actually do
something.
Maybe using a CVS branch for this would have been better, but IMHO the
docs beg to be reorganized.
> ...then I decided to just rearrange everything and commit it
> if noone is against it (that's why I asked on the list before)....
Doing, not talking. I like it ;-)
Only those who do nothing don't make mistakes.
> ...What do to if you move a document?...
We had some talks on the docs list [1], David Crossley has some
interesting ideas in [2] ("special generator").
I think any static way of redirecting from old to new docs will fail,
as people will be too lazy to handle it properly.
Even without a dynamic Cocoon instance to serve the website, it would
be possible to generate redirect pages or .htaccess files from the
registry suggested by David.
> ...If you all want, I could try to reinstantiate the old doc structure,
> this will take some days, but it's possible....
I don't want it, I think some disruption is needed to make the docs
happen.
But if people want it, maybe you could reinstate the last released CVS
version of the docs and put your new stuff in a branch?
Maybe it would be good to have a talk about the docs at the GT?
I find it a pain to write and organize docs with the current xdocs
system, there has to be a better way.
We need to find a middle ground between the ease of the wiki and the
accountability of the CVS xdocs.
-Bertrand
[1]
http://marc.theaimsgroup.com/?l=xml-cocoon-docs&m=106274913021712&w=2
[2]
http://marc.theaimsgroup.com/?l=xml-cocoon-docs&m=106300856810833&w=2
RE: on better release and version management
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Steven Noels wrote:
>
> Hi folks,
>
> forgive me for putting on my BOFH hat, while making the following
> observations...
>
> 1) We suck at freezing and stabilizing the codebase prior to releases.
>
> I would suggest that, from now on, the Release Manager puts forward a
> release date after discussion on the dev list, and that there's a
> two-day (!) freeze period where only glaring bugs can be fixed after a
> vote (!) on the list.
>
> The Release Manager him/herself is also only allowed to commit obvious
> version number changes and all that during this two-day "Sperr-zone".
>
> During the past few releases, there was a flurry of quick fixes and
> commits happening just hours before Carsten made the tarball, and while
> I'm not immediately aware of any nasty side-effects caused by this, it
> sure doesn't look like there was time for any peer review on these late
> commits, neither did it look organized at all.
>
+1
(PS: I always checked and rated (or better tried to) every commit in the
last two/three days before the release, if they could do harm. But that's
of course no guarantee.)
> 2) We need to break from the impasse of 2.1.1 vs 2.2
>
Yupp.
I tried to address this issue several times in the last weeks, well,
without much success.
One thing I want to stress again: *if* we would make a new repository
for 2.2 and duplicate all code, this would include the blocks as well.
So we would not only end up with the two versions to maintain for the core
but for each and every block as well!
And this makes imho no sense. It's ok for the core, if we say 2.1 is only
bug-fixing from now on. But it makes absolutely no sense for blocks.
I think the development of blocks should be independent from the
development of the core. With duplicating the code we loose this.
So, whatever we decide, I'm -1 on duplicating the block code.
> 3) Given the breakage in the Rhino stuff, and the lack of serious
> testing on the 2.1.1 release, I would refrain from announcing 2.1.1 (not
> retracting it, though) and go for a new target release date for 2.1.2 on
> September 24th. That way, we can discuss at leisure what we are going to
> do with the docs-reshuffling, and people can spend more time on testing
> new stuff.
>
I have not followed all mails in the last ten days (as I was on holidays),
so what's the current state here?
I just checked that I'm able to do a 2.1.2 release from my couch here
at home although I still enjoy my vacation (as long as the VPN to my
company is working). So if required I can do the release next week.
Now to the docs:
Yes, looking back it was a very stupid idea to reorganize the docs. I
didn't thought about links pointing to the old docs. I'm very sorry
for that!
To my defense I have to say, that originally I wanted to write an
"online book" as a getting started manual for cocoon. I wanted to use
the existing docs as a starting point, rearrange them and enhance them
to get a complete guide. My first idea was to host this somewhere
else than the cocoon cvs to avoid any problems. But then I came
to the conclusion that this wouldn't be so wise and that this
might lead to some nice flame wars and writing of long emails. Bah.
So, I thought, why not starting this in the cocoon cvs? I wrote
a ten page intro, rearranged the parts and managed to delete every-
thing accidentally.........damn......ok, to keep a boring story
short: then I decided to just rearrange everything and commit it
if noone is against it (that's why I asked on the list before).
Ok, but I think this shows a general problem (perhaps for forrest?):
What do to if you move a document?
I'm just thinking of adding a "moved" doc at the old place. Example:
you move a "index.xml" from directory a to b. You add the moved
document at the old place, so you end up with this:
- a + index.moved
- b + index.xml
The index.moved is a text (xml?) doc, containing the new location.
If someone requests the old document (a/index.xxx), forrest detects
the index.moved file and makes a redirect.
This is just a rough idea. What do you think?
If you all want, I could try to reinstantiate the old doc structure,
this will take some days, but it's possible. It's my fault that we
have this situation now, and I'm willing to do everything possible
to fix it again.
Carsten
Re: on better release and version management
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 10 sep 2003, à 10:38 Europe/Zurich, Steven Noels a écrit :
> ...1) We suck at freezing and stabilizing the codebase prior to
> releases.
Yes.
> I would suggest that, from now on, the Release Manager puts forward a
> release date after discussion on the dev list, and that there's a
> two-day (!) freeze period where only glaring bugs can be fixed after a
> vote (!) on the list.
Sounds good - and during this two-day period everybody should be
frantically testing stuff (and docs) to make sure we put out decent
releases. Not pointing any fingers here but there should be systematic
(if not automatic) testing before releases.
Did I say I will do it? Yes, unless this two-day period comes at at
time where X projects are competing for my overstuffed agenda (like
right now ;-)
> ...2) We need to break from the impasse of 2.1.1 vs 2.2...
> ...Some people want to start with a 2.2 CVS module right away, others
> seem more relunctant and want the HEAD of 2.1 to evolve into 2.2. We
> need to decide on this, since it's blocking progress...
Yes - I didn't follow previous discussions about CVS modules vs.
branches, but there must be an agreement soon on this.
As 2.2 seems to change a lot of internal things and thus might need
some time before a release, it *must*be possible to fix things in 2.1.x
and make interim releases easily before 2.2 is released.
I'd do it with branches but again if there were good reasons to go for
separate repositories, why not.
> ...3) Given the breakage in the Rhino stuff, and the lack of serious
> testing on the 2.1.1 release, I would refrain from announcing 2.1.1
> (not retracting it, though) and go for a new target release date for
> 2.1.2 on September 24th.
Sounds good, but I won't be able to help with the docs - overstuffed
agenda out here.
-Bertrand