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 [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. >> - 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 structure. >> >> 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 - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
