forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: SVN reorg: take 2
Date Mon, 01 Nov 2004 14:45:55 GMT
Dave Brondsema wrote:
> Quoting Nicola Ken Barozzi <nicolaken@apache.org>:
> 
>>The first reorg ahs been needed but is not enough. Other dirs need 
>>placement and have not been yet discussed, and we need to define the 
>>subproject development. I have started, but let's talk about it here 
>>before I continue: below are the points.
>>
>>1 - Forrest projects are not indipendent
>>
>>We are delivering a single product called Forrest, that is internally 
>>composed of subprojects. Our release cycle is based on this product; 
>>however we may have interim releases of subprojects in case it's deemed 
>>necessary.
> 
> Forrestbar and logos are independent tools.

True.

This is also why I had reservations in keeping forrestbar in Forrest, 
remember?

As for logos, my intention is to integrate it as a plugin, and 
forrestdoc also.

> Forrestbot could be, if someone wrote a different "build" workstage.

Could be but should not be. the day it became an indipendent tool, it is 
not part of Forrest anymore.

> Editor configurations, like the one for
> XXE, are independant also.  Use case: document writers/editors install and use
> the XXE configuration to do their document writing, and save/commit changes to
> their documents.  They never run forrest, that is done on a elsewhere (perhaps
> part of forrestbot or doco or something).

I understand what you mean, but they will be doing it for a specific 
version of Forrest, and that is where they should take it from.

Maybe you want t multi-jar release? One thing is doing separate releases 
(in time), and another doing a single release of separate packages.

>>2 - We are not an umbrella project
>>
>>Umbrella projects are dying at Apache. Jakarta and XML have spun off 
>>many projects and are still doing so: we are one of them  :-)
>>This means that we must not reconfigure ourselves to be an umbrella 
>>project, and we must strive to remain unite.
> 
> Is the umbrella structure a problem because of the political & developer
> structure or because of the source code structure?  

Only because of political & developer structure. It has been an utter 
failure socially, and is one of the prime reasons Avalon collapsed so badly.

> I see value in having
> subprojects have their own src, docs, build directories. 

Please explain.

> I do think the Forrest TLP should remain united politically and
> developmentally.

As I see it, history has showed that making indipendent subprojects 
leads in one way or the other to fragmentation. Communities change, 
people come and go, and separating areas creates fragmentation that 
perpetuates.

> We also need to be prepared for a tool subproject to suddenly grow 
> rapidly and have to seperate
> cleanly from forrest and become its own TLP.

Is this something you actually forsee or just a possibility that you 
want to take into account? For the latter we can always refactor later on.

> Webservices, portals, logging, tcl, DB, and others are umbrella projects also. 
> Ant has an antidote subproject.  Are they too planning to break up?

Webservices projects are too small to break out. Portals are actually a 
couple of projects. Logging is the same project in different languages. 
DB is basically only OJB and tcl was created much earlier. Antidote is dead.

We had a discussion at Apache a year ago, and the result was that 
umbrella projects are not the future. AFAIK IIUC it's the current view 
of the board also now.

> I think if
> the subprojects are topically related it can work fine.  (XML and Jakarta house
> many subprojects and are technologically related but not topically related).

Avalon was basically the samme project built in components, and each 
component had become a feud. I'm scared to death in seeing it repeated.

>>3 - We shall have a single bin dir
> 
>>4 - Move the main documentation under the forrest root
> 
>>5 - have a single jar repository + no legal dir
> 
>>6 - Refactor forretcore
> 
> I like all of these.
> 
> I see value in having a one single project, but my primary concern is that it
> will eventually become too big. 

Let's not solve things too early.

> Some of our tools should be able to be
> downloaded, built, and used without forrest itself.

Let me ask you a question: have you ever used forrestbar?
Better: all Forrest developers that have used it raise your hands.

Same question: forrestbot?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message