Re: on better release and version management
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: Block Management [was Re: on better release and version management]
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: on better release and version management
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-devm=106434951718170w=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
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). h 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
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
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). h 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: Block Management [was Re: on better release and version management]
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: on better release and version management
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: Block Management [was Re: on better release and version management]
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
Re: Block Management [was Re: on better release and version management]
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: on better release and version management
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
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
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
--- Stefano Mazzocchi [EMAIL PROTECTED] 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
Timothy Larson wrote: --- Stefano Mazzocchi [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: on better release and version management
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
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: on better release and version management
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). h 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
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: on better release and version management
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
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). h 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
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
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-devm=106434951718170w=2) Reinhard
Re: on better release and version management
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
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
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-devm=106434951718170w=2) official? -- Stefano.
RE: on better release and version management
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-devm=106434951718170w=2) official? +1 Reinhard
Re: on better release and version management
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
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
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
From: Berin Loritsch [mailto:[EMAIL PROTECTED] * 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
Leo Sutic wrote: From: Berin Loritsch [mailto:[EMAIL PROTECTED] * 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
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
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 certifying is done on the statement of information about the block. Geoff
Re: on better release and version management
- Original Message - From: Timothy Larson [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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: on better release and version management
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-devm=106434951718170w=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
Block Management [was Re: on better release and version management]
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 sooo 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
Re: on better release and version management
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: on better release and version management
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
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
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: on better release and version management
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
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
Stefano Mazzocchi [EMAIL PROTECTED] writes: snip 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. Hmm, I think you don't mean final as in can't be touched, but more like, stable or certified as not being dangerous, or maybe certified as now being an official part of Cocoon?
Re: on better release and version management
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
Re: on better release and version management
On Tuesday, Sep 23, 2003, at 16:05 Europe/Rome, Hunsberger, Peter wrote: Stefano Mazzocchi [EMAIL PROTECTED] writes: snip 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. Hmm, I think you don't mean final as in can't be touched, but more like, stable or certified as not being dangerous, or maybe certified as now being an official part of Cocoon? 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 -- Stefano.
Re: on better release and version management
--- Stefano Mazzocchi [EMAIL PROTECTED] 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
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
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
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
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
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
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
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
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
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: on better release and version management
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
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
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
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
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
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: on better release and version management
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
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
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
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
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
--- Stefano Mazzocchi [EMAIL PROTECTED] 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
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: on better release and version management
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: on better release and version management
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
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.
Anteater tests (was Re: on better release and version management)
Bertrand Delacretaz [EMAIL PROTECTED] 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
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-devm=106076740711234w=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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: on better release and version management
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
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-devm=106076740711234w=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
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-devm=106076740711234w=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
RE: on better release and version management
From: Antonio Gallardo [mailto:[EMAIL PROTECTED] 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-devm=106076740711234w= 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
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-devm=106076740711234w=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 [EMAIL PROTECTED] [EMAIL PROTECTED]
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: on better release and version management
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-devm=106076740711234w=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
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: on better release and version management
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:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 1:39 PM To: [EMAIL PROTECTED] 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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: on better release and version management
From: Bruno Dumon [mailto:[EMAIL PROTECTED] 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
[OT] when is software finished [was: Re: on better release and version management]
Reinhard Poetz wrote: From: Bruno Dumon [mailto:[EMAIL PROTECTED] 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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: on better release and version management
On Thu, 2003-09-11 at 14:19, Reinhard Poetz wrote: From: Bruno Dumon [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: on better release and version management
From: Bruno Dumon On Thu, 2003-09-11 at 14:19, Reinhard Poetz wrote: From: Bruno Dumon [mailto:[EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: on better release and version management
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-devm=106076740711234w=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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: on better release and version management
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
Steven Noels [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] www.virbus.de
