Speaking of centralized view of all issues, GitHub just released this: https://github.com/blog/1901-managing-issues-and-pull-requests-across-repositories
On Wed, Oct 1, 2014 at 7:42 AM, Eduard Moraru <[email protected]> wrote: > On Wed, Oct 1, 2014 at 11:22 AM, Thomas Mortagne < > [email protected]> > wrote: > > > On Wed, Oct 1, 2014 at 10:15 AM, Marius Dumitru Florea > > <[email protected]> wrote: > > > On Wed, Oct 1, 2014 at 10:00 AM, Eduard Moraru <[email protected]> > > wrote: > > >> As mentioned to Vincent in a previous private discussion, perhaps a > > great > > >> improvement more or less related to this topic, if we are to keep > > >> recommending/forcing jira for contrib projects, would be to use some > > jira > > >> plugin that allows logging in with GitHub credentials. > > >> > > >> Would be nice if we would have such an extension for xwiki.org as > well > > so > > >> that a developer can seamlessly integrate into the XWiki ecosystem > > without > > >> creating 3 accounts: > > >> - 1 jira account > > > > >> - 1 xwiki.org account (for e.x.o) > > > > As far as I understand github support OAuth so it's pretty much about > > reuse/improve > > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Social+Login+Application > > on xwiki.org I guess (and maybe add a filter based on > > https://github.com/orgs/xwiki-contrib/people). > > > > Or maybe we could ditch the filter and just make xwiki.org GitHub friendly > overall. IMO, it should not only be about contrib users, but about anyone > willing to contribute, in any way. > > BTW, I just remembered/re-noticed that we need yet another (4th) account > for l10n.xwiki.org. This too could benefit from the OAuth stuff. > > Thanks, > Eduard > > > > > > >> - 1 nexus account > > >> ... when he already has a "developer" account on GitHub. > > >> > > >> WDYT? > > > > > > That would be awesome! > > > > > > Thanks, > > > Marius > > > > > >> > > >> Thanks, > > >> Eduard > > >> > > >> On Mon, Sep 29, 2014 at 12:49 PM, [email protected] < > > [email protected]> > > >> wrote: > > >> > > >>> > > >>> > > >>> > > >>> On 29 Sep 2014 at 11:24:19, Caleb James DeLisle ([email protected] > (mailto: > > >>> [email protected])) wrote: > > >>> > > >>> > To be clear, I think both decisions are valid in their own time. > > >>> > Someone who always picks A is flitting from one tool to another, > > never > > >>> > getting any work done, someone who always picks B is stuck in a > > previous > > >>> > century. > > >>> > The question is not If but When. > > >>> > > >>> What’s below is slightly off topic since this is sliding away from > the > > >>> issue tracker to use for xwiki-contrib. OTOH since I said I believe > we > > >>> should use the same tool for both, it’s not so off topic ;) > > >>> > > >>> To answer Caleb on "The question is not If but When”, this is true > for > > >>> everything... Of course GitHub will go away in due time (and so will > GH > > >>> issues) and of course the XWiki project will move away from Git when > a > > next > > >>> and better SCM appears in a few years ;) (as we did move from CVS to > > >>> Subversion to Git already). The same will happen for JIRA but usually > > you > > >>> only move when there’s a compelling-enough reason since the cost of > > moving > > >>> is pretty high in general. > > >>> > > >>> ATM in term of issue tracker there are really only 2 real contenders > > (ie > > >>> with enough features for us) that I know of that could be used by the > > XWiki > > >>> project: > > >>> - JIRA > > >>> - youtrack > > >>> > > >>> There’s also Mantis that I don’t really know about but from the few > > >>> screenshots I’ve seen it doesn’t look as nice as either JIRA or > > youtrack. > > >>> > > >>> Youtrack was missing quite a lot of features compared to jira when I > > >>> evaluated it some years ago but I’ve just noticed it’s coming on par > > now, > > >>> especially with http://www.jetbrains.com/youtrack/nextversion/ > > >>> > > >>> Thanks > > >>> -Vincent > > >>> > > >>> > On 09/29/2014 10:23 AM, Jeremie BOUSQUET wrote: > > >>> > > Funny to see this kind of discussions in xwiki or another OSS > > >>> community, > > >>> > > after seeing them during my work so many times :) > > >>> > > Seems when it comes to issue tracking, always the same arguments > > and > > >>> > > counter-arguments come and go. > > >>> > > Funny also to see that after all the web 2.0 buzz, the rich web > > >>> interfaces, > > >>> > > a simple issue form can frighten so many people ;-) > > >>> > > Funny also to see all these discussions for something as "simple" > > as an > > >>> > > issue tracker. Basically, it's just filling a table, through some > > forms > > >>> > > containing some basic fields (title, description, version...). > Even > > >>> with > > >>> > > all fancy features as in Jira, it's really less complex to use > than > > >>> most > > >>> > > source code management tools. > > >>> > > > > >>> > > If new devs "come and go", you could also say that as > contributors > > they > > >>> > > will also "come and go". Said differently, what would you be > > willing to > > >>> > > loose, knowing that you may let it go for people that may... not > > stay > > >>> very > > >>> > > long ? And with recent discussions about moving some contributed > > >>> extensions > > >>> > > closer to the core xwiki maintainers, having different tools may > > have > > >>> more > > >>> > > impacts. > > >>> > > > > >>> > > I'm also from category "A" as defined by Vincent, but I must > admit > > >>> that all > > >>> > > arguments seem valid, and I may be wrong thinking that - these > are > > >>> > > never-ending discussions. Usually it ends up with people trying > to > > put > > >>> in > > >>> > > place automatic synchronizations between jira and github, to > > satisfy > > >>> > > everyone - more maintenance and more headaches :-) > > >>> > > > > >>> > > In my work we used for a long time another issue tracking tool, > and > > >>> forms > > >>> > > used to create new issues counted maybe 10 times more fields than > > what > > >>> you > > >>> > > have in JIRA (counting the optional fields). > > >>> > > As a modest extension contributor on xwiki, I was so glad to find > > JIRA > > >>> - I > > >>> > > always wished I could use it for my work, instead of the plethora > > of > > >>> > > (no-so-good) tools we tried ... But I understand your points. > > >>> > > > > >>> > > I'd say that it's a difficult choice around contributions, but if > > at > > >>> least > > >>> > > the xwiki team is satisfied globally with the jira issue tracking > > tool > > >>> for > > >>> > > themselves, it's already something valuable as it's not always > the > > >>> case. > > >>> > > > > >>> > > > > >>> > > > > >>> > > 2014-09-29 9:32 GMT+02:00 Caleb James DeLisle : > > >>> > > > > >>> > >> Nice summary of the technical costs/benefits. > > >>> > >> What I think is missing is compatibility between XWiki project > > and the > > >>> > >> developer community. > > >>> > >> > > >>> > >> For good or for ill, kids these days use github. > > >>> > >> > > >>> > >> The days of svn, jira and tight knit developer communities are > > gone, > > >>> devs > > >>> > >> are their own > > >>> > >> free agents, they come and go as they please and asking them to > > learn > > >>> a > > >>> > >> new bugtracker > > >>> > >> is like asking them to learn a new language. > > >>> > >> > > >>> > >> It's hard to accept that #1 jira has no future in OSS and #2 we > > are > > >>> using > > >>> > >> jira for OSS, > > >>> > >> but the world is always changing, anything which has reached > > >>> "stability" > > >>> > >> has begun to > > >>> > >> lose the market and a bit of cognitive dissidence is the cost of > > >>> avoiding > > >>> > >> delusions. > > >>> > >> > > >>> > >> > > >>> > >> Not that it matters much our decision today, if we keep jira > we'll > > >>> just > > >>> > >> end up having > > >>> > >> this conversation again in a year :) > > >>> > >> > > >>> > >> Thanks, > > >>> > >> Caleb > > >>> > >> > > >>> > >> > > >>> > >> On 09/28/2014 06:36 PM, [email protected] wrote: > > >>> > >>> Hi everyone, > > >>> > >>> > > >>> > >>> I’ve read again the full thread and here are some thoughts I > > have: > > >>> > >>> > > >>> > >>> 1) First, I’d like to state again that when someone wishes to > > join > > >>> > >> xwiki-contrib it’s not a neutral act. It means: “I’d like to > join > > a > > >>> > >> community, develop my extension collaboratively with others and > > abide > > >>> by > > >>> > >> the project rules”. It’s thus normal that we set up some rules > > even > > >>> for > > >>> > >> xwiki-contrib (these rules can be at code level or at the level > > of the > > >>> > >> tools used to develop the software). They are needed because as > > soon > > >>> as the > > >>> > >> code is developed by more than 1 person it’s required. If the > > person > > >>> > >> doesn’t want to be bothered and is not ready to follow those > > rules, > > >>> it’s > > >>> > >> fine, they don’t need to be in xwiki-contrib because they can > > still > > >>> make > > >>> > >> their extension have the same visibility as others simply by > > >>> publishing > > >>> > >> them on http://extensions.xwiki.org (e.x.o). That said, of > > course, we > > >>> > >> should still provide development tools that are the simplest > > possible. > > >>> > >> Actually this should be true also when developing XWiki “core” > so > > in > > >>> > >> general I don’t see much differences between b > > >>> > >> o > > >>> > >> th. If it’s hard for contributors it’s also hard for core > > developers > > >>> and > > >>> > >> we might as well fix the issue for everyone. Last point is > > >>> maintenance: > > >>> > >> lots of people (including some committers) don’t see the > > maintenance > > >>> > >> involved (cleaning up issues, maintaining the infrastructure - > > >>> monitoring, > > >>> > >> restarts, upgrades of tools, ensuring the quality of the > > extensions, > > >>> fixing > > >>> > >> documentation mistakes/missing items on e.x.o, etc). In practice > > >>> there are > > >>> > >> very few committers who do this maintenance and we shouldn’t > > >>> overburden > > >>> > >> them either. Offering too many choices means more burden on > > >>> > >> infrastructure/maintenance. This is why BTW that forges are > > usually > > >>> > >> reticent to offer more than one tool to use for each domain. > > >>> > >>> > > >>> > >>> 2) Seems we have 2 categories of people on this thread: > > >>> > >>> A- those who consider that a single place for issues with the > > >>> ability to > > >>> > >> have a global dashboard/search feature is key > > >>> > >>> B- those who consider that it’s more important to offer freedom > > of > > >>> issue > > >>> > >> tracker choice to contributors than the single place to > > search/view > > >>> all > > >>> > >> issues > > >>> > >>> > > >>> > >>> Personally I’m more more in the category A because: > > >>> > >>> - it means less maintenance > > >>> > >>> - I believe global search and a global place for issues is > > important > > >>> > >>> - I believe JIRA can be configured to be as simple as GH if > > that’s > > >>> what > > >>> > >> we want (more below) > > >>> > >>> > > >>> > >>> 3) I agree that we should try to make our issue creation > > experience > > >>> as > > >>> > >> simple as possible (some ideas below) > > >>> > >>> > > >>> > >>> 4) Note: If we were to allow using GH issues, we would also > need > > to > > >>> > >> develop a {{ghissue}} macro for release notes on e.x.o similar > to > > the > > >>> > >> {{jira}} macro. Not a big deal but would need to be done. > > >>> > >>> > > >>> > >>> 5) Sergiu mentioned: “ Supplementing Jean's answer, creating a > > Jira > > >>> > >> issue is a lot of work, having to decide what version is > > affected, the > > >>> > >> relevant components, labels, environment, priority... A GitHub > > issue > > >>> can be > > >>> > >> just a title, and it takes seconds to create.”. > > >>> > >>> > > >>> > >>> I think this has more to do with how we setup our JIRA: > > >>> > >>> - "having to decide what version is affected”. This is always > > needed > > >>> for > > >>> > >> bugs, be it on JIRA or on GH issues. Also note that on JIRA the > > >>> “affects > > >>> > >> version” field is NOT mandatory. We have a best practice of > always > > >>> filling > > >>> > >> it ourselves but we could change that rule and decide that we > > should > > >>> fill > > >>> > >> it only for bugs for example. > > >>> > >>> - "the relevant components”. Again this is optional in JIRA > too. > > >>> > >> Actually now that JIRA makes it easy in the UI to edit fields > > (without > > >>> > >> having to go in edit mode) we could make all optional field not > be > > >>> visible > > >>> > >> in the Basic Issue Creation Field Scheme (what you see when you > > click > > >>> on > > >>> > >> “Create Issue”). The only possible downside is that we will > > receive > > >>> more > > >>> > >> mails. > > >>> > >>> - “labels, environment”. Again this is optional too in JIRA. > BTW > > in > > >>> your > > >>> > >> link (https://github.com/phenotips/phenotips/issues/1116) you > > seem to > > >>> > >> also use that on GH issues so I don’t see the difference. > > >>> > >>> - “priority” is also optional. > > >>> > >>> - "A GitHub issue can be just a title, and it takes seconds to > > >>> create”. > > >>> > >> And it’s exactly the same for a JIRA issue. All you need to fill > > in > > >>> is the > > >>> > >> “summary" field :) > > >>> > >>> > > >>> > >>> In conclusion: this is not a differentiator between JIRA and GH > > >>> issues. > > >>> > >> If we think it’s scary for a user to see the optional fields in > > the > > >>> Basic > > >>> > >> Issue Creation Field Scheme, then let’s remove them from that > > screen > > >>> now. > > >>> > >>> > > >>> > >>> 6) Regarding traceability by putting issue reference in commits > > it’s > > >>> for > > >>> > >> us to decide whether we want this as a best practice or not. It > > does’t > > >>> > >> depend on the issue tracker we use. For example > > >>> > >> https://github.com/phenotips/phenotips/issues/1116 shows that > it > > also > > >>> > >> exists in GH issues. Personally I think that it’s part of the > best > > >>> > >> practices we should keep in the XWiki ecosystem but it could be > > >>> discussed. > > >>> > >> Jean feels it a burden apparently. However I don’t know how > often > > >>> Jean has > > >>> > >> had to fix other people’s issues several months after their > > commits. > > >>> It’s > > >>> > >> really handy and saves you hours when you can quickly link issue > > and > > >>> code. > > >>> > >> Again remember that xwiki-contrib is NOT for solo projects. When > > you > > >>> put > > >>> > >> your project there you want it to be developed collaboratively > and > > >>> join a > > >>> > >> community. > > >>> > >>> > > >>> > >>> 7) Edy said: "when all he wants to do is to fix a typo in > > XWiki's UI > > >>> or > > >>> > >> align some labels, all through a simple GitHub fork & pull > > request.”. > > >>> This > > >>> > >> is still possible right now. It’s more a question of best > > practice. > > >>> Would > > >>> > >> we want to apply a PR without a JIRA? For a label name change > or a > > >>> typo I’d > > >>> > >> say definitely. BTW we don’t create jira issues for this either > > in the > > >>> > >> “core”… (at least it’s not mandatory, see dev.xwiki.org). > > >>> > >>> > > >>> > >>> In conclusion: > > >>> > >>> - I’m also tempted by the GH issues approach because it’s close > > to > > >>> the > > >>> > >> code. If we were to decide to let contrib projects use GH issues > > then > > >>> I > > >>> > >> would also like to switch the “core” to GH issues. I see the > whole > > >>> xwiki > > >>> > >> contributing/committers as a single community using the same > > >>> > >> tools/practices as much as possible. > > >>> > >>> - However, so far I see more drawbacks than pros: global > search, > > >>> global > > >>> > >> view of all issues, advanced features of jira when they are > > needed, > > >>> graphs, > > >>> > >> stats, single tool to support > > >>> > >>> - I’d be for improving our configuration of JIRA (less fields > > visible > > >>> > >> when creating issues, work on creating a template for more > easily > > >>> creating > > >>> > >> jira projects) > > >>> > >>> - I’d like to keep a high level of quality of the XWiki > > ecosystem, > > >>> not > > >>> > >> just at code level but at also tool level. When people go to our > > jira > > >>> they > > >>> > >> see it’s well organized and well maintained (no missing > versions, > > >>> issues > > >>> > >> are closed when they should be, issues are sorted, they have > > labels > > >>> > >> applied, etc). This is part of what the XWiki project shows to > the > > >>> outside > > >>> > >> and I’m proud of it and I think when contributors join the > project > > >>> it’s > > >>> > >> also because they want to learn all this and they’re interested > in > > >>> joining > > >>> > >> a select community with strong software development rules. > > >>> > >>> > > >>> > >>> Thanks > > >>> > >>> -Vincent > > >>> > >>> > > >>> > >>> On 24 Sep 2014 at 16:43:58, Sergiu Dumitriu ([email protected] > > >>> (mailto: > > >>> > >> [email protected])) wrote: > > >>> > >>> > > >>> > >>>> The same day that you send this vote, this article is > published: > > >>> > >>>> > > >>> > >> > > >>> > > > http://opensource.com/business/14/9/community-best-practices-new-era-open-source > > >>> > >>>> > > >>> > >>>> Relevant quote: > > >>> > >>>> > > >>> > >>>> "[...] the contributor had to learn the specific mechanisms > for > > >>> > >>>> contributing to their chosen project. Thus, if a contributor > > worked > > >>> > >>>> across several projects, they needed to learn several > different > > >>> ways of > > >>> > >>>> doing things. > > >>> > >>>> > > >>> > >>>> Now there’s GitHub, and six million people use it. If your > > project > > >>> is on > > >>> > >>>> GitHub, it means that no one has to learn special magic tricks > > to > > >>> > >>>> contribute to your project, because every project on GitHub > > works in > > >>> > >>>> basically the same way. In the time it used to take a user > just > > to > > >>> > >>>> figure out a project’s contribution mechanisms, a user can now > > fork > > >>> a > > >>> > >>>> repo, make a fix, and submit a pull request. The default > > instinct > > >>> of new > > >>> > >>>> developers is no longer “suggest a change”—the instinct is now > > “fix > > >>> the > > >>> > >>>> problem”. > > >>> > >>>> > > >>> > >>>> > > >>> > >>>> I've been using GitHub issues for almost 3 years now, and I'm > > pretty > > >>> > >>>> happy with those. Sometimes I miss the extra features of Jira, > > but I > > >>> > >>>> also like the simplicity of this simple issues tracker. > > >>> Supplementing > > >>> > >>>> Jean's answer, creating a Jira issue is a lot of work, having > to > > >>> decide > > >>> > >>>> what version is affected, the relevant components, labels, > > >>> environment, > > >>> > >>>> priority... A GitHub issue can be just a title, and it takes > > >>> seconds to > > >>> > >>>> create. > > >>> > >>>> > > >>> > >>>> Most of the arguments in favor of Jira are about aiding the > > XWiki > > >>> > >>>> overlords: how do we measure ALL the activity across all > > projects? > > >>> How > > >>> > >>>> is that relevant for a simple contributor that just wants to > > >>> scratch an > > >>> > >>>> itch? We should make it as easy as possible to contribute. > > >>> > >>>> > > >>> > >>>> > > >>> > >>>> Another argument for GH Issues is locality: there's only one > > place > > >>> for > > >>> > >>>> code, issues, roadmap, and discussions. With GH Wiki, > > documentation > > >>> as > > >>> > >> well. > > >>> > >>>> > > >>> > >>>> > > >>> > >>>> So, I think there are good reasons why someone would prefer > > having > > >>> > >>>> everything on GitHub, we shouldn't enforce what we thing is > > best on > > >>> > >>>> someone else's project. > > >>> > >>>> > > >>> > >>>> On 09/23/2014 09:22 AM, [email protected] wrote: > > >>> > >>>>> Hi everyone, > > >>> > >>>>> > > >>> > >>>>> ATM the rule we have for contrib projects is to use JIRA (see > > >>> > >> > > http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HHostingtools) > > >>> > >>>>> > > >>> > >>>>> I’ve heard that some people have been proposing using other > > >>> trackers. > > >>> > >>>>> > > >>> > >>>>> So I’d like to poll your opinion on the following > alternatives: > > >>> > >>>>> > > >>> > >>>>> Option A: all projects use JIRA > > >>> > >>>>> =============================== > > >>> > >>>>> > > >>> > >>>>> This is the current option in use. > > >>> > >>>>> > > >>> > >>>>> Pros: > > >>> > >>>>> * A single place for people to view and search for issues in > > the > > >>> XWiki > > >>> > >> Ecosystem > > >>> > >>>>> > > >>> > >>>>> Cons: > > >>> > >>>>> * For XWiki admins, creating a new JIRA project takes 5 > minutes > > >>> > >>>>> > > >>> > >>>>> Option B: all projects use GitHub issues > > >>> > >>>>> ======================================== > > >>> > >>>>> > > >>> > >>>>> Pros: > > >>> > >>>>> * Simple to set up for admins (hosted by GitHub) > > >>> > >>>>> * Simple to use (too simple sometimes?) > > >>> > >>>>> > > >>> > >>>>> Cons: > > >>> > >>>>> * No single place to search all issues related to XWiki (both > > JIRA > > >>> + > > >>> > >> GitHub) > > >>> > >>>>> * No single place to report JIRA issues > > >>> > >>>>> * Tied to the SCM choice. When we stop using Git as our SCM > and > > >>> move > > >>> > >> to the next SCM tool we’ll have to import all issues (see > > >>> > >> > > >>> > > > https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-importers-github-plugin/versions > > >>> > >> ) > > >>> > >>>>> * Need to implement feature on extensions.xwiki.org to add a > > link > > >>> to > > >>> > >> the issue tracker for each extension > > >>> > >>>>> > > >>> > >>>>> Option C: let each project decide > > >>> > >>>>> ================================= > > >>> > >>>>> > > >>> > >>>>> Pros: > > >>> > >>>>> * Simple to set up for admins when project decides on GitHub > > >>> > >>>>> > > >>> > >>>>> Cons: > > >>> > >>>>> * No single place to search all issues related to XWiki (both > > JIRA > > >>> + > > >>> > >> GitHub) > > >>> > >>>>> * No single place to report JIRA issues > > >>> > >>>>> * Tied to the SCM choice. When we stop using Git as our SCM > and > > >>> move > > >>> > >> to the next SCM tool we’ll have to import all issues (see > > >>> > >> > > >>> > > > https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-importers-github-plugin/versions > > >>> > >> ) > > >>> > >>>>> * Need to implement feature on extensions.xwiki.org to add a > > link > > >>> to > > >>> > >> the issue tracker for each extension > > >>> > >>>>> > > >>> > >>>>> Option D: XWiki Task Manager > > >>> > >>>>> ============================ > > >>> > >>>>> > > >>> > >>>>> > > >>> > >> > > >>> > > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Application > > >>> > >>>>> > > >>> > >>>>> Pros: > > >>> > >>>>> * Eat our own dog food. > > >>> > >>>>> * Forces us to improve this extension > > >>> > >>>>> > > >>> > >>>>> Cons: > > >>> > >>>>> * Pressure to fix bugs > > >>> > >>>>> * Increases volume of data on xwiki.org and thus impact > > >>> performances > > >>> > >>>>> * Maintenance cost: More work when upgrading xwiki.org > > >>> > >>>>> * No single place to search all issues related to XWiki (both > > JIRA > > >>> + > > >>> > >> GitHub) > > >>> > >>>>> * No single place to report JIRA issues > > >>> > >>>>> * Need to implement feature on extensions.xwiki.org to add a > > link > > >>> to > > >>> > >> the issue tracker for each extension > > >>> > >>>>> > > >>> > >>>>> WDYT? Other options? > > >>> > >>>>> > > >>> > >>>>> Personally and based on all pros/cons I think the best ATM is > > >>> really > > >>> > >> Option A. And if we really want, it’s possible to improve the > > cons by > > >>> doing > > >>> > >> a bit of java coding: > > >>> > >> > > >>> > > > https://developer.atlassian.com/display/JIRADEV/Creating+a+Project+Template > > >>> > >>>>> > > >>> > >>>>> Thanks > > >>> > >>>>> -Vincent > > >>> > >>>>> > > >>> > >>>> > > >>> > >>>> > > >>> > >>>> -- > > >>> > >>>> Sergiu Dumitriu > > >>> > >>>> http://purl.org/net/sergiu > > >>> > >>>> _______________________________________________ > > >>> > >>>> devs mailing list > > >>> > >>>> [email protected] > > >>> > >>>> http://lists.xwiki.org/mailman/listinfo/devs > > >>> > >>> _______________________________________________ > > >>> > >>> devs mailing list > > >>> > >>> [email protected] > > >>> > >>> http://lists.xwiki.org/mailman/listinfo/devs > > >>> > >>> > > >>> > >> > > >>> > >> _______________________________________________ > > >>> > >> devs mailing list > > >>> > >> [email protected] > > >>> > >> http://lists.xwiki.org/mailman/listinfo/devs > > >>> > >> > > >>> > > _______________________________________________ > > >>> > > devs mailing list > > >>> > > [email protected] > > >>> > > http://lists.xwiki.org/mailman/listinfo/devs > > >>> > > > > >>> > > > >>> > > > >>> > -- > > >>> > Caleb James DeLisle > > >>> > XWiki SAS > > >>> > [email protected] > > >>> > _______________________________________________ > > >>> > devs mailing list > > >>> > [email protected] > > >>> > http://lists.xwiki.org/mailman/listinfo/devs > > >>> _______________________________________________ > > >>> devs mailing list > > >>> [email protected] > > >>> http://lists.xwiki.org/mailman/listinfo/devs > > >>> > > >> _______________________________________________ > > >> devs mailing list > > >> [email protected] > > >> http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > -- > > Thomas Mortagne > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
