Re: [xwiki-devs] [Contrib] Reporting extensions issues

Hi, I also have a question about the release policy. Since xwiki-contrib is outside our Roadmap, it happens more frequently to have the application's version a bit behind with the fixed issues. Who's responsibility is to make sure we find on e.x.o the latest application version?

Of course the developer's, but what do we do when we find applications that have issues fixed, but not released for a long time? Do we create a task issue on the issue tracker in order to remind the developer to make the release?

Can a xwiki-contrib administrator release the application instead of the developer?

Should we have like a time rule: if there are issues fixed older than 1 month the application should have a new version released (depending on the quality of the issues, the release can be a major, minor or a bugfix release)?

Thanks, Caty On Tue, Jan 21, 2014 at 5:03 PM, Ecaterina Moraru (Valica) < valicac(a)gmail.com&gt; wrote: > Hi, > > This is just an idea: > In the context of finding easier ways for our users to report issue for > our e.x.o applications, me and Vincent played a bit with JIRA's Issue > Collectors functionality. > You can read more and see some screenshots at > http://jira.xwiki.org/browse/XINFRA-132 > If we consider this to be interesting, this functionality would be > available to applications hosted on xwiki-contrib that have a > jira.xwiki.org project attached to them. > > Thanks, > Caty > > > On Tue, Jan 21, 2014 at 3:12 PM, vincent(a)massol.net wrote: > >> Hi Caty, >> >> On 17 Jan 2014 at 11:21:49, Ecaterina Moraru (Valica) (valicac(a)gmail.com >> (mailto:valicac@gmail.com)) wrote: >> >> > Hi, >> > >> > This mail should be seen as feedback for improving our e.x.o ( >> > extensions.xwiki.org) and our contributions process, while answering >> some >> > of my questions :) >> > >> > Right now I am playing and testing some XWiki extensions from e.x.o. >> > The problem that I have is that I don't know where is the best place to >> > report bugs and issues. >> > >> > 1. First of all I think we should add a 'Issue Tracker' field in the >> > repository application, where the developer should state where the >> issues >> > should be reported (what is the preferred way of reporting and even if >> the >> > developer is available for further iterations of the extension). >> >> +1 to that, see http://jira.xwiki.org/browse/XWIKI-9682 >> >> > 2. What issue tracker we should use and how? >> > Right now there are several ways the users can give feedback for a >> certain >> > extension: >> > >> > A. Direct e-mails to the developers: >> > I've received couple of times e-mails with questions about the >> extensions >> > I've developed. This approach is not recommended since we are doing open >> > development and other users might have the same question. Usually I >> suggest >> > to use the mailinglist ( >> > http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists ) if there >> are >> > additional questions, but an issue tracker could also solve the problem. >> >> I ask them to use the mailing list for questions and to report issues in >> JIRA (I always make sure to create the required JIRA project if it doesn't >> already exist but usually there's always one for my extensions). >> >> > B. Community mailinglist: >> > We receive many questions about the extensions on the mailinglists. The >> > problem is that the answers are very hard to track and share among other >> > users (you need to know that the question has been asked before and than >> > that an answer has been provided). An issue tracker would improve the >> > process. >> > >> > C. Comments on the extension page: >> > There are several extensions that have comments on their extension page. >> > While this approach is the most accessible, it is hard to know what is >> the >> > status of a comment and the responsible person for it (was it fixed >> > already? in what version? is the comment still valid?). >> > >> > D. GitHub issue tracker: >> > While some extensions contain just snippet code or local XARs, other >> have a >> > repository attached to it. I know some extensions that track their >> issues >> > on github. The advantages of this approach is that you keep total >> control >> > of your extension and also you don't need approvals from xwiki >> community to >> > have your repository created or help with the management of it (rights, >> > etc.). You handle your own development while using e.x.o as a publishing >> > platform. The above statements are in case you have a personal >> repository. >> > The alternative is to have a repository on xwiki-contrib ( >> > https://github.com/xwiki-contrib ), but these repository could also >> have >> > the github issue tracker activated. >> > >> > E. jira.xwiki.org project: >> > On jira.xwiki.org there is a whole section of Contributed Projects ( >> > http://jira.xwiki.org/secure/BrowseProjects.jspa#all ). There is also a >> > generic XWiki Contrib project ( http://jira.xwiki.org/browse/XCONTRIB) " to >> > be used by all projects till they achieve a first release or till they >> > grow to a size significant enough to warrant a dedicated JIRA project" >> > (quote taken from http://contrib.xwiki.org/ ) >> > >> > F. IRC: >> > Even harder than mailinglist to reference. >> > >> > G. other? >> > >> > I've written all the ways in order to agree on the recommended way >> (which I >> > guess is E.) while I don't think there is a way to force the others from >> > happening. >> >> Our current strategy is to have a JIRA project for all active contrib >> projects. Thomas and I have created a lot of JIRA projects for projects we >> knew were active. Missing project need to be created. >> >> I agree that one difficulty is that the contributor doesn't have the >> right to create his own jira project. What we could do is: >> - whenever someone ask for a repo on contrib, create a jira project by >> default for him/her >> - if possible automate it (I've researched a bit JIRA and even though >> they have a notion of template projects it seems quite hard to use and >> require some java coding, maybe someone need to research it a bit more). >> >> From the outset I'd think that using the same issue tracker for all is >> best but I agree that using the GitHub issue tracker is tempting for >> contrib extensions. If we were to do this we would need to decide how to >> handle existing jira projects for contrib projects. >> >> > 3. Related extensions vs. Branched extensions vs. Forked extensions >> > My problem is like this: Lets say I want to test the Forum Application. >> > Currently there are 3 versions of the Forum application (read more at >> > http://design.xwiki.org/xwiki/bin/view/Proposal/ForumApplication ). >> > - First of all it was hard to know that we have 3 versions for the >> 'same' >> > functionality. A feature like "Related extensions" would have been >> great to >> > have on e.x.o. >> >> I do a lot of gardening on this but I'd like help since this is my job to >> do. Everyone should help here. So what I do is add some info box ({{info}} >> macro) when I see an extension that's made obsolete by another newer >> extension. At least I try to explain about the reasons to choose one over >> another. Everyone who introduces a new extension should always add such a >> box. >> >> > - Then it was difficult to find out where is the place to report issues >> for >> > each of these applications (see the whole point of this mail). Currently >> > there are 2 JIRA projects created for Forum (XAFORUM and XBB) but there >> is >> > no place to report for SimpleForumApp. >> >> This should be fixed by http://jira.xwiki.org/browse/XWIKI-9682 >> >> > - It was hard to know what version still work and if there is still >> active >> > development on it (especially if you have just an attached XAR and not a >> > repository). >> >> Same answer as above with the info box. >> >> > - It is hard to know if the apps are completely different or if they are >> > just forks of the same base code. Do they share the same functionality, >> do >> > they want to be improved versions or are just completely different >> things? >> > These questions are important because they give you an answer if the >> > entries should have separate JIRA projects or we could solve the >> problem by >> > creating just a COMPONENT in the same JIRA project. >> >> Same answer as above with the info box. >> >> > - Whose responsibility is it to create the issue tracker, to link to the >> > related applications, etc? (the developer? the contrib managers? other >> > members of the community?) >> >> I'd say the person who creates the project on behalf of the contributor >> who asks for a repo on xwiki-contrib. >> >> > The same questions apply for Calendar Application ( >> > http://design.xwiki.org/xwiki/bin/view/Proposal/CalendarApplication ). >> I >> > have 3 variants with other related extensions. The only extension that >> has >> > a JIRA project associated with it is the older extension. >> > So, as an user of the extension, where do I report issues? >> > - Do I need to ask for the creation of a separate project? >> > - Do I ask for the creation of a separate component in the existing >> project? >> > - Do I report in the generic xcontrib project? >> > - Do I need the permission of the developer to have the project created? >> >> You need to talk to the creators of the various "versions" to understand >> if: >> - the newer "version" has been rewritten from scratch, in which case it >> should be a completely separate project with a different JIRA project and >> different repo and different exo page. This means users can still install >> both "versions". >> - the newer "version" is an improvement (even if a big one) and in this >> case it should have it's major version upgraded (from 1.x to 2.0 for >> example). In this case it's the same github repo, same JIRA project, same >> exo page. And users don't install the old version anymore, the EM will >> suggest the new version. >> >> > - Should we enforce the creation of projects for the new extensions? >> >> I don't know what you mean by "enforce" but at least we should make it >> clear on contrib.xwiki.org that whoever creates the new project should >> also create the JIRA project (if we decide to continue with JIRA projects. >> If we go the github tracker way then the creator should enable the github >> issue tracker). It would be nice if we had a one click button to create a >> new jira project from a template, right now it takes 5 minutes to create a >> new one with the risk of making some mistakes. >> >> > - How we decide if an extension is big enough or important enough to >> have >> > its own project? >> >> We changed our informal rule not long ago on this and decided to create >> jira projects all the time even for new extensions. The doc on >> contrib.xwiki.org needs to be updated. >> >> > - Who should monitor these growth? (since we actually don't know if the >> > extensions are used or downloaded?) >> >> I'd everyone from the xwiki dev team should pay attention and help fix >> problems. >> >> Thanks >> -Vincent >> >> > Let me know what you think. >> > Thanks, >> > Caty