On Nov 7, 2012, at 9:53 AM, Jerome Velociter
<jerome(a)velociter.fr> wrote:
> On 11/07/2012 09:03 AM, Vincent Massol wrote:
>> On Nov 5, 2012, at 10:02 AM, Jerome Velociter <jerome(a)velociter.fr> wrote:
>>
>>> On 10/23/2012 09:33 AM, Vincent Massol wrote:
>>>> On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <ludovic(a)xwiki.com>
wrote:
>>>>> This should have been for devs Envoyé de mon iPhone Début du message
transféré :
>>>>>> Expéditeur: Ludovic Dubost <ludovic(a)xwiki.com> Date: 23
octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <users(a)xwiki.org> Objet:
Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just
a quick. You seem to introduce a practice to use the github tracker instead of
xwiki.org
jira's Not sure it's a good thing. I'm sure Vincent will agree
>>>> Well, what I would prefer personally is that contrib projects be in the
xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that
this allows: * to group together projects around XWiki (they're not scattered
everywhere on the web and harder to find) * make it a neutral location for people to
collaborate together on xwiki projects. That's a key element to contribution IMO * is
more long term. If you stop working on the project it's not going to be a dead project
in someone's github repo and it'll have more chance of being maintained/seen in
the xwiki-contrib repo I know Jerome also puts his contributions in his own github project
and I had the same reservation about it. We can't force anyone of course since this is
a contribution but it's more collaborative to make them xwiki-contrib project,
following the rules defined at
http://contrib.xwiki.org I understand you may want to beef
up your github profile but for collaboration I feel the xwiki-contrib is better with the 2
arguments listed above. Jerome, Caleb let me know what you think.
>>> Hi Vincent,
>>>
>>> This is a interesting topic and there are several aspects to it.
>>>
>>> For me the "discoverability" argument for having projects on
https://github.com/xwiki-contribdoes not make much sense. The centralized place for
projects around XWiki is
http://extensions.xwiki.org, not github. There's the
"view source" button that tells where the sources are. Github is a convenience
here, and it's always possible to "copy" (or fork) a project in
xwiki-contrib, for whatever reason (original project not active, etc.).
>>>
>>> That being said I understand why you think it's better to have as much
projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with
the same tools, same workflow, same permissions, etc.
>>>
>>> Here are the arguments I see for why one contributor or contributing
organization would want to host its projects itself :
>>> - use of own tools and own workflow (github issues vs. JIRA for example).
>>> - it allows a contributor or contributing organization to have it's own
place to centralize its contribution(s) (the "beef up" argument as you say). I
think this can make sense in some circonstances, especially for contributing organizations
(companies for example).
>>>
>>> The bottom line comes down to : what rules do we want for using the
"org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ?
>>> If we want a rule saying that the project should be hosted on
github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to
decide on it (right now there is no such rule according to
http://contrib.xwiki.org/).
>> My take on this:
>>
>> * Either the project is a xwiki-contrib project and then it gets the tools and
niceties included for being an xwiki-contrib project (jira, CI, web site, ability to
collaborate equally between contributors, email notifications on xwiki lists, sonar
dashboard coming soon, maven remote repository, etc) or it's not and then it uses
whatever tools it wants but not xwiki's project resources. It seems fair to me.
>> * If we agree we should then update
contrib.xwiki.org to explain better all that
the user will get by being an xwiki-contrib project and explain the alternative. And also
explain that if the user wants to host it himself then give him some direction for the
maven groupid/artifactid that he should or rather the ones he shouldn't use since
it's reserved (basicallty the rule is his groupid cannot start with org.xwiki, not
sure if we want to also say that his artifact id shouldn't start with
"xwiki-" as its done for maven plugins in apache land).
>>
>> WDYT?
> Makes sense to me.
>
> One thing to consider also is the fact projects outside contrib will play less well
with XWiki extension manager since they won't be in XWiki nexus (unless the repository
they are in is added to nexus). Personnally I think we should allow contributing
organization repositories being added in XWiki's nexus so that it's not a
differentiator.
I mentioned that already in my reply when I said that xwiki-contrib projects get a maven
remote repo.
Re allowing external projects to be hosted in our remote maven repo, maybe but it's
dangerous. We need some oversight of the project we host because we're then legally
responsible for what we host. So we'd some way for people to request hosting and have
manual operation.
TBH I'm not sure if we should provide this since Sonatype already provides it for any
open source project, see
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+…
They already have all the tools to verify that poms are correct and more so I don't
think we should duplicate the effort.
Right now, I'd say we only offer a remote maven repo for our own projects and we
direct others to the Sonatype OSS repo.
Actually I wasn't talking about
hosting, but about having their (external repositories of contributing
individuals/organizations that is not xwiki-contrib) repositories proxied in XWiki's
nexus so that they are found by the extension manager with the default configuration.