It's great to hear you want to work with is on this. Apache projects work on a meritocratic basis. If someone contributes to get commit rights.
Before someone gets commit rights they need to submit patches for review. This is done through the issue tracker. Once the number of patches or even a single significant patch is accepted by the project contributors may be invited to become committers. This process is called review then commit (RTC). Since this review process can be time-consuming we tried to make people committers earlier rather than later. Once they are committers they can make changes directly in the version control system. Such changes are sent to the commit mailing list where other committers will review them. This process is called commit then review (CTR). Committers need to submit an Individual Contributer a License Agreement (ICLA). With significant contributions that involve many developers we need to have a software grant and make all developers committers upon initial contribution. I doubt that this contribution will require this. However, your mail implies that there are multiple developers involved with this contribution. I suspect the best way to proceed is to start out extracting your code into the stand-alone project we've discussed. It would be best to do that in stages contributing patches directly to Wookie as you go. This will enable us to evaluate individual contributors patches and recognise individual merit as appropriate. It will make things a little slower to start with as you will need someone here to submit your patches to version control. However, since nobody here is likely to work on it in the short term this shouldn't pose much of a problem. The advantage is that we would be able to give commit rights in recognition of the work being done during the porting. Alternatively, you could do this work in somewhere like Apache-extras (an area within Google code). This would allow you to give write access to your full developer team early and would enable the Eookie team to review each contributors activity there. However, merit in an Apache project cannot be earned through contributions to a non-Apache project. This means that it would be slower for your team to get commit access here. What is less than ideal is for you to submit a large amount of completed code with a request to make a number of, to us unknown, people as committers. Which is the best approach for you depends on your team. Trying to work here through patches will slow your initial work but ultimately get you commit access here more quickly, which will enable you to create a tighter integration with Wookie without having to depend on existing committers. Ross On 6 July 2012 09:30, Olexiy Chudnovskyy <[email protected]> wrote: > Hi Scott, > > this would be great to open a dedicated sub-project under the Wookie's hood. > What do we need to take care of? What are the policies for development/code > submission and version control? Next week I'll have a meeting with my > colleagues, where we will elaborate the first backlog. Should we publish it > somewhere? > > Best Regards, > Olexiy > --- > Chemnitz University of Technology > Department of Computer Science > Distributed and Self-organizing Systems Group > Straße der Nationen 62 > D-09107 Chemnitz > Germany > E-Mail: [email protected] > WWW: http://vsr.informatik.tu-chemnitz.de/people/chudnovskyy > Phone: +49 371 531 39146 > >> -----Original Message----- >> From: Scott Wilson [mailto:[email protected]] >> Sent: Thursday, July 05, 2012 2:56 PM >> To: [email protected] >> Subject: Re: Extending widgets towards Inter-Widget-Communication >> >> >> On 5 Jul 2012, at 13:20, Ross Gardler wrote: >> >> > On 5 July 2012 13:07, Olexiy Chudnovskyy >> > <[email protected]> wrote: >> >> Hi Scott & Ross, >> >> >> >> here is the source code of our prototype and a tutorial to get it > running: >> >> >> >> http://vsr.informatik.tu-chemnitz.de/demo/iwc-extension/apache- >> wookie-iwc-0. >> >> 10.0-incubating-standalone.zip >> >> http://vsr.informatik.tu-chemnitz.de/demo/iwc-extension/tutorial.pdf >> > >> > Thanks. I'll take a look ASAP, but since I'm about to hit the road for >> > a couple of weeks it won't be soon. >> > >> >> I like Scott's idea on "IWC Enchancer" add-on, which is completely >> >> decoupled from a concrete widget container instance. This is >> >> definitely a cleaner solution. >> >> Another scenario is, however, extension of an already deployed >> >> widget. Or do you think this situation is rather unusual? >> > >> > There are at least three ways of thinking about this scenario: >> > >> > - have a standalone enhancer that understands the Wookie API - request >> > the .wgt file, enhance, re-submit it >> > >> > - embed the enhancer within Wookie for tight integration >> > >> > These two approaches are not necessarily mutually exclusive. If the >> > enhancer is capable of working stand-alone then it can also be >> > included in a Wookie distribution and installed without user >> > intervention, along with a suitable interface for accessing it. >> > However, bear in mind that the admin UI in Wookie has been removed. >> > The current goal of Wookie is to ensure the API is fully functional so >> > that third parties can build admin UIs specific to their needs. We >> > have discussed the idea of providing a set of admin widgets but nobody >> > currently has that high enough on their task list. >> > >> > Furthermore, by decoupling the enhancer from Wookie you are opening >> up >> > the potential for the enhancer to be extended to work with other >> > gadget/widget specs if that becomes an strong enough itch for someone. >> > >> > This would suggest to me that the standalone system accessing Wookie >> > through the API would be the best approach. If the interface can >> > become a widget then all the better (note Scott did some >> > experimentation with admin widgets). >> > >> > However, by suggesting this path I am not intending to imply we don't >> > want it here in the Wookie project. I'd be +1 to making it a >> > subproject here. If it ever grows up to work with other kinds of >> > gadgets then it could become a TLP in its own right, but while it >> > focusses on Wookie APIs and widgets it makes sense for it to be a >> > sub-project. >> >> +1 I think the enhancer would make a good subproject, I like the idea of >> potentially supporting other widget types, plus it would be good to have >> different options for which IWC solution to enhance the widget with >> (OpenAjax, Role/XMPP, PostMessage etc). >> >> Currently we have some sub-projects in the Wookie trunk, and these are >> built and deployed in the standard distribution - would this work for the >> enhancer too, or should we create a directory at the top level, e.g. >> /incubator/wookie/enhancer/trunk ? >> >> S >> >> > >> > Ross >> > > -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
