8 Jan
2012
8 Jan
'12
3:43 p.m.
On Sun, Jan 8, 2012 at 2:21 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Jan 7, 2012, at 5:49 PM, Sergiu Dumitriu wrote:
The possible amendment here would be the other way around : enforcing
contrib projects SCM in xwiki-contrib github organization.
Right now on contrib.xwiki.org nothing explicitely says contrib
projects should use xwiki-contrib github project as their SCM. It
actually says "[..] project hosting forge can provide contributors
with some or all of the following tools". Later : "Finally, let us
know which of the listed tools you need. For GitHub access, you will
need to register a user on http://github.com and let us know about
it".
If we want to enforce contrib project to be hosted on xwiki-contrib
organization, this is what should be discussed/voted.
Jerome
On 01/07/2012 06:15 AM, Ludovic Dubost wrote:
> Hi,
>
> As there are now more projects using the Curriki Distribution, in the
> Curriki mailing list we have voted for the following changes for the
> Curriki Project:
>
> * Rename the main project xwiki-learning-cms
> * Call the core: xwiki-learning-cms-core:
> http://svn.xwiki.org/svnroot/xwiki/xwiki-learning-cms/xwiki-learning-cms-co…
> * Call the curriki specific code : curriki:
> http://svn.xwiki.org/svnroot/xwiki/xwiki-learning-cms/curriki
> * Call the planete sankoré specific code : sankore:
> http://svn.xwiki.org/svnroot/xwiki/xwiki-learning-cms/sankore
>
> The curriki 1.8 branches would go into the curriki area, except for the
> latest branch which would be duplicated in xwiki-kearning-cms-core as the
> 1.0 branch
> The 2.x branches would go into xwiki-learning-cms-core
>
> We would then publish the sankore core to the repository.
> As you can see these plans are based on SVN. A separate discussion is
> undergoing to see if we can easily move to GitHub.
>
> In this case we would ask for one or more repositories in the xwiki-contrib
> area. It's not clear to me in this case if we should use only one or 3
> different repositories. I tend to think it should be 3.
The # of repositories mainly depend on the release cycles. If you consider them 3
different projects with different release cycles, I think 3 repos make more sense.
> Finally we would rename curriki.xwiki.org
into lcms.xwiki.org.
>
> We're asking the goahead from the XWiki commiters to make these changes.
>
> Here's my +1
Non binding +1 from me (since I'm not a committer on the curriki project).
It would be great that the curriki/sankore/lcms projects move to GitHub in a not too
distant future.
Here's my not so relevant +1, I didn't
interact much with this area of XWiki, but I welcome the extraction of a more generic core
on which projects like Curriki and Sankore are built.
For the GitHub discussion, I agree that three repositories would be better, but I'm
not sure xwiki-contrib is the best home. On SVN it was a top level directory, not one
inside contrib, so we could make it part of the xwiki organization. Plus, these projects
are big enough not to be considered mere contributions. On the other hand, it is not
something maintained by the XWiki committers, so we might not want to send the wrong
message: "it's a project maintained by the XWiki organization". So a third
option would be to create a new organization for it, since it's free. I'm no
voting on this point, since I don't have a strong preference, I'll let others
decide.
Here's my POV regarding xwiki vs xwiki-contrib:
* Everything in the xwiki main repository is coded and maintained by the XWiki
development team according to the XWiki development practices defined at
http://dev.xwiki.org
* Curriki doesn't fit with this
* In order to allow easy contributions to develop projects around the XWiki project
we've created a xwiki-contrib project/organization with the rules defined at
http://contrib.xwiki.org.
* To repeat those rules:
** projects in xwiki-contrib can be developed by anyone (no need to be committer on the
main xwiki project) and following any methodology (no need to follow the
http://dev.xwiki.org methodology)
** xwiki-contrib is NOT an incubator. It's a final location for small to large
projects. Projects which start small there stay as xwiki-contrib projects even they grow
very large.
** projects in xwiki-contrib start with shared resources (shared wiki on
extensions.xwiki.org, shared jira project on jira.wiki.org, shared mailing list using the
user/dev mailing list of the main xwiki projects, shared maven groupid, etc
** projects in xwiki-contrib can have their own dedicated resources when they grow larger
(own wiki, own mailing list, own jira, own maven groupid, etc)
** This is all documented already on http://contrib.xwiki.org
So to summarize, for me the difference between a project in the "xwiki"
organization vs a project in the "xwiki-contrib" organization is purely based on
the development team and on the development practices followed
Now what are the options for Curriki/Sankore/LCMS…
Option 1: Join XWiki Platform
=======================
Now there could be a VOTE to include lcms into xwiki platform but that's a separate
discussion and for this to happen, the current curriki developers would need to:
* agree to fully follow the dev practices defined at dev.xwiki.org, including release
practices of course
* agree to become platform committers, i.e. participate to all VOTE/proposals and in
general development of XWiki platform
* be voted individually as an XWiki committer
* follow some incubation process to ensure that the points above are done well
AFAICS there's no wish ATM from the curriki developers to do any of that.
Option 2: Join XWiki-Contrib
======================
This means making Curriki/Sankore and LCMS xwiki-contrib projects. This doesn't
change much at all.
Right now xwiki-contrib projects are supposed to be hosted on GitHub but we could make an
exception and since we allow successful xwiki-contrib projects to have their own resources
we could amend contrib.xwiki.org to also allow large contrib projects to have their own
organizations on github. That said I'd be tempted to keep them in the
xwiki-contrib org for now, I don't really see any issue with that.
For me option 2 is clearly the best ATM.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/