portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaël Luta <raph...@apache.org>
Subject Re: Reorganizing Jetspeed repository (Was Re: Some mean-spirited whining about the build...)
Date Mon, 02 Jan 2006 22:01:13 GMT
David H. DeWolf wrote:
> Raphaël Luta wrote:
>> David Sean Taylor wrote:
>>> Raphaël Luta wrote:
>>>> What about simply moving the applications code to a different SVN
>>>> branch,
>>>> so that core and apps are checked out separately.
>>>> <snip opion 1 & 2>
>>>> /portals/components/ -> core portal components
>>>>    /trunk
>>>>    /branches
>>>>    /tags
>>>> /portals/applications/ -> useful apps
>>>>    /trunk
>>>>    /branches
>>>>    /tags
>>>> /portals/demos/ -> demo stuff
>>>>    /trunk
>>>>    /branches
>>>>    /tags
>>>> /portals/jetspeed-2 -> full jetspeed 2 portal
>>>>    /trunk
>>>>        svn:externals components /portals/components/trunk
>>>>        svn:externals applications /portals/applications/trunk
>>>>        svn:externals bridges /portals/bridges/trunk
>>>>        svn:externals demos /portals/demos/trunk
>>>> (ie manage everything in separate hierarchies and tie everything under
>>>> jetspeed-2 using svn externals property)
>>> +1
>>> Should a propose a formal vote on this reorg?
>> Before a full blown proposal suitable for a vote I think there are quite
>> a few detaiuls to work out, like:
>> - making sure the svn:externals actually work as expected in the ASF
>> setup
>> - which mailing list(s) gets commits messages for the various directories
> My gut says the general list.

I'm not sure, general is meant for healthy discussion on global Portals
not commit reviews :)
If the goal is to broaden the participation of the whole Portals
developer tto these various components, I'd then rather have a
commits@portals.apache.org that gets commit messages from *all* the
/portals sub-directories instead of the current jetspeed-dev,
bridges-commits and pluto-scm.

That would make a lot of sense to me and could be a baby step towards
more cooperation between the different sub-projects.

>> - getting some input from other stakeholders like Pluto guys or Cocoon
>> portal guys (possibly Geronimo) about the optimal directory breakdown
> I think it will help spur cooperation between the groups . . .

yeah, but where would Pluto fit in such an organisation, after all with
1.1, it's also a Spring component based application, no ?
Maybe it would make sense to reorg Pluto at the same time.

>> - figure out a build system that actually works on such a beast
> Yes, this is a big consideration if we move everything at once.  I
> wonder if a better approach is to start with just one of the items (I'd
> recomend applications).  That seems like a baby step in the right
> direction.

Even if we don't move everything at once, I'm not comfortable enough
with svn:externals to be sure that there are no side-effects to such a move.

I'm all for incremental change instead of big bang, I'd just like to
know for a fact that the end goal is actually realistic and that we're
not going to land too roughly. Reorg/build change is disruptive so we
should aim for a stable situation that suits everyone as soon as possible.

I think I'll go and ask for help on the infra@ list. Some people
probably have experiences on svn:extrenals on a ASF-like repository

>> and then vote and implement the proposal.
>> Maybe we could start a poropsal draft on the wiki to start formalizing a
>> precise proposal while the discussion goes on.
> I'm all for working through the issues but I also wonder if bighting off
> one peice at a time is worth considering.  I'm affraid that addressing
> things like the mailing lists and redoing builds, and reorganizing
> directory structures within jetspeed is more than is required right now.
> Simply moving the applications directory is a first step in the right
> direction and it gives us a chance to "try" things out before taking on
> a much larger effort (modifying the build, etc. . .).
> Can we vote and begin to play with applications so that we have some
> "working knowledge" for the rest of our discussions?

If there's a consensus from the current active developers to go this way
and move applications as a test, I'm definitely +1 but then I'm not
active very often on the code so I'm not really the one impacted.

Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message