+1, looks very good :) On Mon, May 5, 2014 at 5:56 PM, Guillaume "Louis-Marie" Delhumeau < gdelhumeau(a)xwiki.com&gt; wrote: -- Denis Gervalle SOFTEC sa - CEO

On May 7, 2014 9:44 AM, &quot;vincent(a)massol.net&quot; &lt;vincent(a)massol.net&gt; wrote: mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote: XWiki Dev Team so it’s the XWiki Dev Team who will release its extensions. more committers. The idea is to get the contributors of those extensions as committers for those extensions and thus be the RM for those extensions. had any code committed for it. What’s important is to be able to get it in the hands of users when there are important bug fixes or new features. It seems logical to me that those who commit these bugs/features release them. wanted to always release them all. But this is not the case. They’ll be released when those working on them want to release them or under user pressure. notes. I think we should start defining roadmaps per extension on e.x.o (we already support RN on e.x.o using either the jira macro or manually). need a person resonsible for it, who’ll be in charge of defining the roadmaps, release notes and do the releases (he/she can delegate but he/she will still be responsible until that responsibility is handed to someone else. I believe this will be one criteria for accepting an extension in xwiki-extensions. If we make sure that each repo/extension on xwiki-extensions has an owner then I'm fine the proposal. > Future > ====== > When we have the notion of Flavors, I believe it will simplify things to organize releases per flavor (XE can be considered a flavor ATM BTW). When this time comes we could decide to have a RM per flavor with a Roadmap/Release notes per flavor. I have no idea how many flavors we would have but I can think of 3: > - xwiki.org flavor (FAQ app, JIRA macro, IRCBot app, etc) > - knowledge base flavor (…) > - collaborative apps flavor (calendar, meeting manager, file manager, etc) > > As for moving extensions out of xwiki-contrib to xwiki-extensions, > > it's not simple. First, it's not very clear which contrib extensions > > will be chosen. You said "some maintained apps" but the link you gave > > is more about the functionality they provide and whether they fit in > > our view of the collaborative app suite. Then in order to move an > > extension you need to ask the contributors, otherwise you'll have to > > fork the repo and create a new extension id. > They’ll be chosen on a case by case basis with a VOTE for each. The person proposing it will put forward a maintainer for the extensions (who will be responsible of Roadmap/Releases Notes and performing releases). > Note that IMO there are some conditions that we could define as base conditions: http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… (this means the functional test fwk is in place and ready to receive more tests) http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle and generally speaking obey the practices defined on http://dev.xwiki.org > > Then what happens if an > > extension from xwiki-extensions stops being maintained, do we move it > > back to xwiki-contrib? > Yes, same as what happens currently in the xwiki organization. > > I'm not fully convinced by your proposal. > The real goal of this proposal is to start having nice applications that can be a showcase of XWiki. Till now we have the engine and some extensions but none of them are developed as strongly as platform and they fall short. This is an effort to make a usable XWiki *product* vs just an XWiki *platform*. > Again, we should take in only extensions that we can maintain, i.e. for which we have a volunteer to maintain them. > TBH I don’t know if this will succeed or not but I feel it’s worth trying :) No, I'm just woried that this proposal will lead to more (paper)work, but I guess this is needed if we want extensions of good quality. Then, I also have mixed feelings about the fact that we'll have extensions in two places and those from xwiki-contrib will become second-class citizens. Thanks, Marius > Thanks > -Vincent > > Thanks, > > Marius > > > On Mon, May 5, 2014 at 5:43 PM, vincent(a)massol.net wrote: > > > Hi devs, > > > > > Right now we have 2 organizations related to the XWiki project on Github: xwiki and xwiki-contribs. > > > > > The separation is currently the following: > > > * XWiki Committers maintain the code in the “xwiki” organization > > > * non XWiki Committers (aka contributors) maintain the code in the “xwiki-contrib” organization in the way they want (some extensions there are not maintained, others are maintained) > > > > > After brainstorming with Thomas Mortagne we’d like to propose the following changes: > > > > > Need > > > ===== > > > > > * Be able to extract some maintained apps from xwiki-contrib to separate them from less maintained extensions. For example the top apps listed here: http://design.xwiki.org/xwiki/bin/view/Proposal/CollaborativeApplications xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features). > > > > > Proposal > > > ======= > > > > > * Introduce a new xwiki-extensions organization in GitHub which would be maintained by the XWiki Dev Team (aka XWiki Committers) > > > > > * For now, move out of xwiki/xwiki-platform all modules that are not bundled by default in XE. This rule will be reviewed and modified when we introduce the flavors concept in the future. The idea is that xwiki-platform will contain “core extensions” only and as we progress towards extensions, the number of core extensions will get smaller and smaller till possibly only the EM and what it requires. Everything else would be located in the xwiki-extensions organization > > > > > * Have one repository per extensions in the xwiki-extensions github organization so that each extension can be released independently of each other > > > > > * In order to make it simple to release, the idea would be to have Roadmaps and aggregated Release Notes per Flavor (this is what we’re doing now with the “XE” flavor BTW). > > > > > * We will be able to vote in committers for specific repos located in the xwiki-extensions organization without having them voted for the xwiki organization (although, over time, they would be able to become xwiki committers for the xwiki orgnization should they wish and if they’re voted in) > > > > > * Extensions from xwiki-extensions published on e.x.o would have “XWiki Development Team” as author, which means they will be officially supported by the xwiki committers. > > > > > > > WDYT? > > > > > Thanks > > > -Vincent & Thomas > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

IMO we are not going to do complete roadmap/RN, anounce etc by hand like we do for https://github.com/xwiki/ for each of https://github.com/xwiki/-extension/ repositories. For me the only required minimum to release those extensions is "mvn release:prepare && mvn release:perform" as soon as there is something interesting to share in it. Then it's about adding automated links to jira that already take care of release notes in http://extensions.xwiki.org which is what we pretty much do for many contrib extensions already just not automated (and at some point probably have a XWiki Taks Manager project associated to each of theses extensions with a jira-like release note in http://extensions.xwiki.org). If the extension owner want to do announcement and stuff he can but it's really not require in my mind. Once we start working on flavors that depends on those extensions there will be complete roadmap/RN and stuff but at flavor level like we do now with the XE flavor. On Wed, May 7, 2014 at 9:35 AM, vincent(a)massol.net &lt;vincent(a)massol.net&gt; wrote: -- Thomas Mortagne

  On 7 May 2014 at 15:35:47, Jeremie BOUSQUET (jeremie.bousquet@gmail.com(mailto:jeremie.bousquet@gmail.com)) wrote: [snip] The goal is not to “move" all extensions from contrib to xwiki-extensions, only those that the XWiki Development Team is interested in maintaining. If it happens that this extension was developed and is still actively developed by contributors then the VOTE will include voting them as XWiki Committers for their extension. Of course the move will happen only if those contributors want it ;) Once they are voted as committers, they would participate and have voting rights and vetos on their extensions. I don’t see this as any different from any existing module in the xwiki organization. We have discussions and come to agreement. Does that sound ok? Thanks -Vincent