Hi Caty, On 10 Feb 2014 at 15:41:30, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:
> 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? Whoever has an itch to scratch… :) Either the initial author or anyone interested in getting a new release. > 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? I don’t think so. Creating a JIRA for this is not very useful and we don’t do this on the “core" projects. > Can a xwiki-contrib administrator release the application instead of the > developer? Why an administrator? Any dev in xwiki-contrib is free to work on any project and perform a release if he wants/needs it. If he doesn’t know the state of the project, it’s best to ask on the list beforehand obviously. > 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)? I don’t think it’s the core dev team’s role to manage xwiki-contrib. The point of xwiki-contrib is that it’s not managed/supported by the core dev team ;) What we need to do though is improve the communication between extension users and extension developers: * Add link to the project’s JIRA from e.x.o (already discussed, someone need to code it) * Add link to the project’s mailing list/forum from e.x.o. ATM we have a single mailing list so it would link to the users @ xwiki.org list. Thanks -Vincent > Thanks, > Caty > > > > On Tue, Jan 21, 2014 at 5:03 PM, Ecaterina Moraru (Valica) < > [email protected]> 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, [email protected] wrote: > > > >> Hi Caty, > >> > >> On 17 Jan 2014 at 11:21:49, Ecaterina Moraru (Valica) ([email protected] > >> (mailto:[email protected])) 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
