Raphaël Luta wrote:
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
[EMAIL PROTECTED] 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.
Ok, I agree!
- 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.
Yes, definately. I've I don't have my hands 100% around what pluto can
leverage, but I definately think that there's overlap to be gotten rid of.
- 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.
Fair enough.
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
structure.
I remember discussions about this on the struts mailing lists a while
back. I believe that the struts-chain branch uses (or used) them. A
quick google on "apache svn:externals" indicates that maven, and struts
use them and cocoon had a discussion about it. I wonder if any of the
cocoon guys on this list want to fill us in on their experience with
externals.
David
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
