On 23 Sep 2014 at 16:43:23, Jean SIMARD
([email protected](mailto:[email protected])) wrote:
> Oups sorry, indeed, it's not a vote.
>
> I think we don't need the heavy solution of JIRA (at least, as a mandatory
> tool
> for bug tracking) for xwiki-contrib. Each time I want to do a pull request on
> xwiki-contrib, I need to begin to create a Jira, to obtain a Jira ID
> (IDEA-2314
> for example) then I will be able to use it in my commit message. I often began
> to work on the code long before creating a Jira which, as you can see, is not
> very easy in the workflow (being blocked at the commit level because of the
> need
> of an ID?). And then, I create my pull request on Github and then come back to
> Jira to give the link of this pull request. Maybe this heaviness is needed in
> xwiki repository (even not sure of that) but for applications/contributions,
> it's a probably too much in my opinion.
Some comments:
* How is this different with GitHub issues? You still need to create the issue
to get the id for your commits, no?
* So you feel that when people go to http://jira.xwiki.org and try to log a new
issue and they won’t find the project it won’t be an issue?
* Same question for when they search for an existing issue.
* It doesn’t seem to be an issue when we code in
xwiki-commons/rendering/platform/xe
> For having work on Task Manager Application, I think option D is not enough
> mature even if it's an interesting solution
Sure it’s not. That’s why it was an option to improve it.
> (by the way, if option C is chosen,
> Task Manager will become a possibility).
Actually option C is badly named, my bad. It’s “Let the project decide among a
list of tools the xwiki.org committers support”.
And supporting the Task Manager is not a given (see my list of cons below) ;)
Thanks
-Vincent
> Hope this helps.
>
> On Tue, Sep 23, 2014 at 04:29:28PM +0200, [email protected] wrote:
> >
> >
> >
> >
> >
> > On 23 Sep 2014 at 16:07:09, Jean SIMARD
> > ([email protected](mailto:[email protected])) wrote:
> >
> > > +1 for C.
> >
> > Jean could you please motivate your answer… This is not a vote but a
> > brainstorming! :)
> >
> > For example explain why the cons listed are not cons for you (or not
> > important), or why the pros are more important than the cons.
> >
> > Thanks
> > -Vincent
> >
> > > On Tue, Sep 23, 2014 at 03:22:14PM +0200, [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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
