Raphaël Luta wrote:
[commenting on mailing list directly because JIRA makes a poor tool for
long discussions...]
Agreed. Much easier this way.
Ate Douma (JIRA) wrote:
But Raphaël, could you elaborate a bit more about your option #3
suggestion:
- move rewriter to a new source root, either a Portals commons area or
>> simply Jakarta Commons and release rewriter from there.
...
Now option #3 is very easy to do, we can use [EMAIL PROTECTED] as our
>>"commons" mailing list just like I think "portlet-api" should be
moved there.
This isn't completely clear to me: are you suggesting now we create a new
> Portals Commons project in which we can host the portlet-api as well
> as generic components like the rewriter? I'm not saying I would be
> against it (on the contrary), but how is this (much) different from
> the Gems proposal?
If you are serious about this, could you write up a formal proposal?
OK, I'll ellaborate a bit on my statement:
- first, from the ASF organisational point of view, there's no
difference between Jetspeed, Bridges or Pluto. Everything is part
in the Apache Portals top level project (TLP) and how we manage
our "space" is our own business (Santiago being ultimately responsible
for everything a "Apache VP for Portals").
(You may have noted that the SVN authorization file doesn't make
any difference between jetspeed, pluto and bridges)
I hadn't :-).
This now means anyone with commit rights within Portals can commit anywhere?
I think its a good idea to bring the teams closer to each other,
but I'm not so sure the Pluto team would like me to commit changes to their
codebase without prior notification (not that I intend to do so)...
- historically, our Portals "space" has worked like Jakarta used to with
each sub-project defined by a set of mailing-lists + a repository.
This makes sense when each sub-project has (or may have in Bridges
case) a non-overlapping developer and user community. However, this is
*not* mandatory and there's actually a few existing examples at the
ASF already (for example, try looking for the mailing-lists matching
the Jakarta servlet-api repositories)
- What I proposed as solution #3 was simply to create a new "directory"
in the portals SVN to host shared code between the different Portals
codebases. Since I don't think we'd have a lot of code there and
there would be limited interest for external parties (ie parties not
already interested in Jetspeed, bridges or pluto), I propose that we
*don't* create new mailing-lists (or website) to start a new
sub-community and simply use the [email protected]
mailing-list as the common clearing-ground if needed.
Makes sense to me.
IMO we could have a SVN repository like this:
portals/
site/ -> the main Portals website
bridges/ -> the Portals "public" sub-projects
jetspeed-1/
jetspeed-2/
pluto/
portlet-api/ -> "private" sub-projects simply used
utils/ to cleanly organise shared dependencies
rewriter/ between all the sub-projects
The "private" sub-projects would not have dedicated mailing-lists
or website and simply use the global Portals resources (website and
mailing-list) as needed.
Note that any Portals committer has access to these repositories.
We don't need any proposal to organise like this since this is simple
artefact / dependency management, not an attempt to create a new
community.
Alright, clear to me.
Thanks for the explanation.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
