hm, just for as an outstanding I'd like to comment on this :-) (again just my 2 cents)
I clearly understand both Charles and Lukaszs point of view here. For one I do see that a sandbox is clearly something in the Prototype phase where lot's of improvements/re-factoring do take place and so it's probably also the point where changes do get in conflict with each other. Still I would like to see that also in a prototype we can manage those conflicts to a minimum. How can we achieve that? First of all, TALK, if we work on such a thing we need communication, I see all of the people being in the irc and chatting, way to go. If there is a "major" re-factoring maybe just give a quick hint beforehand, either IRC or a mail. For me it's important that all of the guys involved get somehow informed. (all other just sitting there and watching would also like to be but well :-) ) I know you guys do a tremendous job getting this thing done. And I appreciate it. But something I really don't want to see here is that the work you have achieved will be splitted again to several git-hub forks. I don't think this will work, and it's against any "team"-spirit we have at the Karaf-Team. So since I'm not directly involved but just the guy sitting at the sideline watching, I would like to see something like Lukasz already mentioned: 1) Talk to each other, either via IRC or by mail 2) do write some meaningful commit messages 3) bigger re-factoring - just give a quick hint by mail that something is coming at us :-) secondly I have to agree with Lukasz that a "bureaucracy" doesn't help but I also didn't see any questions for it in the previous mails. just my 2 cents here ;) regards, Achim 2011/8/22 Łukasz Dywicki <[email protected]>: > Guys, > I going to argue with every of you. What is purpose of sandbox if we have to > vote everything isn't it is for open work? Just like apache commons declares > "sandbox is svn repo to function as open workspace for sharing and > collaboration". There is nothing with standard projects regulations. Honestly > If I would like take all Apache Software Foundation bureaucracy I would > donate our work to incubator or directly as a Karaf subproject. > Do you want vote every code move from one module to another? Guys, with this > we'll simply stuck with discussions. I told Charles once and will repeat you > same words - for me webconsole is prototype (that's why it is in sandbox) and > if someone don't want code refactors then he should wait untill core of this > project will be stable. Charles donated features subpage with state change > operations and languages switcher. I donated navigation, branding and > dashboard widgets while Andreas was working mainly on pax-wicket > improvements. Most of current look and feel comes from me and I simply will > not ask anybody for agreement to (re)move code which should not be in core. I > will notify you next time about changes I did or describe it in commit > messages clearly. > If you can't follow some of my work I will simply start maintain my github > fork instead of putting code to sandbox. Just like Ioannis did with Cellar. > This will solve most of problems between my and Charles. Sorry to say this > (it sound selfishly) It's up to you how you going to work on this prototype > because I won't change too much. > > Best regards, > Lukasz > > >> Thx to remind/refresh people about the Apache Team Spirit ;-) >> >> >> On Fri, Aug 19, 2011 at 10:56 AM, Jean-Baptiste Onofré <[email protected]> >> wrote: >>> Hi Charles, >>> >>> even if Karaf WebConsole is on sandbox for now, we should apply the same way >>> as we use for Karaf, and more generally in all Apache project. >>> >>> I mean that: >>> - any refactoring should require a kind of approval or at least discussion >>> with the people involved on the project. Just a quick e-mail [WebConsole] on >>> the dev mailing list could avoid a lot of wasted time >>> - before commiting, the dev should be sure that the build works and there is >>> no regression. >>> >>> Karaf WebConsole is an Apache project: it doesn't belong to one person, it's >>> a community effort. So, we should work in a community compliant manner. >>> >>> Just a quick reminder for all of us ;) >>> >>> Regards >>> JB >>> >>> On 08/19/2011 10:42 AM, Charles Moulliard wrote: >>>> >>>> Hi, >>>> >>>> with last commit on , the features list page does not work anymore >>>> >>>> WicketMessage: Unable to find component with id 'link' in >>>> [MarkupContainer [Component id = cell]]. This means that you declared >>>> wicket:id=link in your markup, but that you either did not add the >>>> component to your page at all, or that the hierarchy does not match. >>>> [markup = >>>> bundle://93.0:1/org/apache/karaf/webconsole/karaf/internal/feature/FeaturesActionsPanel.html >>>> <wicket:panel xmlns:wicket="http://wicket.apache.org";> >>>> <a href="#" wicket:id="link"> >>>> <img wicket:id="actionButton" alt="feature install button"/> >>>> </a> >>>> </wicket:panel>, index = 2, current = '<a href="#" wicket:id="link">' >>>> (line 2, column 5)] >>>> >>>> >>>> When people commit code, it is required that they check the >>>> functionalities if they works, otherwise don't commit !!! >>>> By the way the FeaturesActionsPanel page has disappeared and the >>>> images cannot be displayed as getImage is not longer called. >>>> >>>> Regards, >>>> >>>> Charles Moulliard >>>> >>>> Apache Committer >>>> >>>> Blog : http://cmoulliard.blogspot.com >>>> Twitter : http://twitter.com/cmoulliard >>>> Linkedin : http://www.linkedin.com/in/charlesmoulliard >>>> Skype: cmoulliard >>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> > > -- -- *Achim Nierbeck* Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/>
