Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4186C985.4090201@brondsema.net>
Date: Mon, 01 Nov 2004 18:40:53 -0500
From: Dave Brondsema <dave@brondsema.net>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: SVN reorg: take 2
References: <cm5bn5$ueo$1@sea.gmane.org>
 <1099319202.418647a26d5c8@secure.solidusdesign.com>
 <cm5i6v$hqe$1@sea.gmane.org>
In-Reply-To: <cm5i6v$hqe$1@sea.gmane.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigF0A2B60BEC3D211F64849AA8"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF0A2B60BEC3D211F64849AA8
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Nicola Ken Barozzi wrote:
> 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.
> 

It'll be for a specific versions of the Forrest document DTDs.

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

What do you mean?  Release the XXE tool as a standalone .zip in addition 
to releasing it as part of the main forrest .zip?

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

If a tool can build and operate on it's own without forrest, it should 
be segregated to reflect that.  This would let people could "svn co" 
just that directory, or set up gump dependencies for it/on it. 
Actually, thinking of it in terms of a Gump projects is probably good. 
Anything that is a seperate project in a gump descriptor should be in 
it's own project directory.  That's basic project and codeline management.

Forrestbar, forrestdoc, and logos are the only examples I can think of. 
  But since we plan to incorporate the last two, and forrestbar isn't 
much to speak of, I guess this is currently a moot point.

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

Ok, I wasn't aware of that.  The subprojects we might have would be 
quite small though.

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

Good point.

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

No.  And I'm not aware of any redeeming value in it.  Would anybody shed 
a tear if it mysteriously dissappeared? :-)

> Same question: forrestbot?
> 

Yes, and this will (maybe) be part of the ASF website publishing process 
that David has proposed.

What is your point here?


I think I've been convinced.  I would've liked to see this second 
discussion before the changes went into SVN, though.

-- 
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal

--------------enigF0A2B60BEC3D211F64849AA8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBhsmFVvBSb5uzznARAvewAKDOagsBWifXqfnThh5GqinbaoidTwCfYaq+
/yPGaT7FGyhSKCPsZCPEOsw=
=FN+4
-----END PGP SIGNATURE-----

--------------enigF0A2B60BEC3D211F64849AA8--