On Nov 7, 2012, at 10:49 AM, Jerome Velociter <[email protected]> wrote:
> On 11/07/2012 10:41 AM, Vincent Massol wrote: >> On Nov 7, 2012, at 10:38 AM, Jerome Velociter <[email protected]> wrote: >> >>> On 11/07/2012 10:33 AM, Vincent Massol wrote: >>>> On Nov 7, 2012, at 10:07 AM, Jerome Velociter <[email protected]> wrote: >>>> >>>>> On 11/07/2012 09:59 AM, Vincent Massol wrote: >>>>>> On Nov 7, 2012, at 9:53 AM, Jerome Velociter <[email protected]> wrote: >>>>>> >>>>>>> On 11/07/2012 09:03 AM, Vincent Massol wrote: >>>>>>>> On Nov 5, 2012, at 10:02 AM, Jerome Velociter <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 10/23/2012 09:33 AM, Vincent Massol wrote: >>>>>>>>>> On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> This should have been for devs Envoyé de mon iPhone Début du >>>>>>>>>>> message transféré : >>>>>>>>>>>> Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre >>>>>>>>>>>> 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users >>>>>>>>>>>> <[email protected]> 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+Usage+Guide >>>>>> >>>>>> 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. >>>> I know :) I'm talking about the same thing! Our Nexus proxies several >>>> repos including Maven Central. So if you push your artifact in Sonatype's >>>> OSS repo then you get it in XWiki's Extension Manager ;) >>> Yes but one could still want it in its own repos and not sonatype. >> Sure but then it's not our problem and I personally don't agree about >> proxying other people's remote repos (too much maintenance and too >> dangerous). FYI Maven Central stopped doing this after they had problems >> with it. > > Could you expand on why too dangerous/what problems it causes ? For example, > what's the difference with repos we are already proxying ? It's just too much maintenance. I'll give you one example: the jboss guys made a mistake in their remote repo and suddenly all our artifacts proxied were all wrong and it took us several days to fix this. Another issue is that we don't control what's put in these repo so the less we proxy the better. Actually when we proxy existing repos like the jboss one we should ideally only proxy the artifacts we use. More generally the more repos we had the more problems we'll have, the more space it'll take and the more maintenance it'll require (dead repos, slow repos, bad data in the repos, etc). I'm personally not willing to use my own time to help on this. We have enough work elsewhere and again this service is provided by Sonatype already so there's no reason/advantage for us to duplicate their effort (they have more resource than we have). Thanks -Vincent >>> BTW we're not proxying sonatype repos yet AFAIK. >> Sonatype's repos are synced to central AFAIK. And for the same reason we >> shouldn't proxy any Sonatype repo. > > OK not everything is synced it seems (c.f. > https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement) > that would explain why I had a dependency on sonatype's repos not resoved by > the EM by default (see > https://github.com/jvelo/xwiki-social-login/blob/master/pom.xml) > > Jerome > >> >> -Vincent >> >>> Jerome >>> >>>> -Vincent >>>> >>>>> Reserving hosting on the maven repos to xwiki-contrib is fine. >>>>> >>>>> Jerome >>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> Jerome. >>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> Jerome >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks -Vincent >>>>>>>>>>>> Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James >>>>>>>>>>>> DeLisle <[email protected]> a écrit : >>>>>>>>>>>>> One other thing, please report the features which you want and >>>>>>>>>>>>> what you imagine as best on the github tracker, it's easier to >>>>>>>>>>>>> close an issue as "won't fix" than it is to remember an important >>>>>>>>>>>>> issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 >>>>>>>>>>>>> PM, Caleb James DeLisle wrote: >>>>>>>>>>>>>> Hi, Thanks for the complement. I just updated it and fixed issue >>>>>>>>>>>>>> #1. Thanks for reporting it. Somehow showing who else is >>>>>>>>>>>>>> editing, showing where they are editing in the document and >>>>>>>>>>>>>> allowing the user to spawn a chat window with other editors on >>>>>>>>>>>>>> the page are all interesting possibilities. Right now I think >>>>>>>>>>>>>> the thing to do is decide where there is the most bang for your >>>>>>>>>>>>>> buck in terms of feature value and get an idea of what's most >>>>>>>>>>>>>> natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, >>>>>>>>>>>>>> Ryszard Łach wrote: >>>>>>>>>>>>>>> Great work! It looks like good starting point to give xwiki the >>>>>>>>>>>>>>> main (at least for me) feature, that makes googledoc sometimes >>>>>>>>>>>>>>> more suitable for collaborative editing. It would be really >>>>>>>>>>>>>>> great, if your editor would show somehow, where the other >>>>>>>>>>>>>>> editor (person) is now, where is his cursor. Maybe a highlight >>>>>>>>>>>>>>> (the whole line) showing the other's cursor placement? Do you >>>>>>>>>>>>>>> plan to work on such improvements? R. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
