I know I'm not an Apache committer or even a regular on these discussions. But it seems to me this whole conversation is a little weird. It seems your trying to make "culture" into policy, or more directly policy that is potentially counter to the current development culture. If the community is developing experimental code elsewhere and then contributing it back, shouldn't that be a "Good Thing" (tm) and encouraged, it seems to me that restricting to Apache Servers would stifle creativity & hamper development, which are both anathema to Open Source in general. Instead of forcing a "private experimental" server, why not just come up with a procedure to easily incorporate finished modules into Wicket.
Also Maybe I'm missing the point, but what's Wrong with starting code in github and/or WicketStuff? Isn't that part of the point of their existence? Is it a loss of history issue once the code is "imported" into Wicket Proper? Trying to better understand the discussion, Tom Burton -----Original Message----- From: Emond Papegaaij [mailto:emond.papega...@topicus.nl] Sent: Monday, April 02, 2012 10:25 AM To: dev@wicket.apache.org Subject: Re: More experimental code happening at Apache Martijn and I want to release experimental things in different modules. For that, they need to be stable enough to release, and it needs to be certain that they will be continue to be supported for some time to come, but the code does not need to be finished. For example, the code I'm currently working on integrating Atmosphere with Wicket will meet these conditions. I do understand Martijn's concerns regarding IP-clearance, but I do think the current vission of some members of the board is a little short minded. I read (most of) a discussion about what should be done when an Apache developer develops code at Github and wants to move it to Apache. Although they did not seem to agree entirely, the concenses was that 'large' pieces of code needed to be cleared before moving it to Apache. IMHO, this severely limits the freedom of Apache developers. This also means, your wicket-cdi project will need to be cleared before moving it to the main Wicket repo, even though you and I are the only persons that have committed on the project. Best regards, Emond On Monday 02 April 2012 10:03:04 Igor Vaynberg wrote: > from a couple of replies to this thread i am a little confused. are we > talking about keeping experimental things in different modules on > master or different branches? > > obviously the big problem is that not everyone has access to the > apache git repo, so projects will still pop up on github, etc, if they > require collaboration from non-committers. > > if, this is directed at committers, there are a couple of issues that > need to be discussed. > > 1) sometimes its not possible to release the code, ie wicket-cdi which > lacks necessary maven dependencies in central. what do we do in those > cases? > > 2) sometimes a project is just an idea to play with. once we release > it as a 0.1 module we have to at least somewhat maintain it. and what > if the idea doesnt pan out, is it ok to just drop the module? what > happens with the dropped code if someone outside wicket wants to work > on it, does it move back to github? > > -igor > > On Mon, Apr 2, 2012 at 5:49 AM, Martijn Dashorst > > <martijn.dasho...@gmail.com> wrote: > > The trend seems to be to do experimental things at wicketstuff or > > personal github accounts with the intention of bringing that back to > > Wicket at a later time. IMO this is the wrong way. The Apache Way > > should be (IMO): also do experimental stuff at Apache, within the > > purview of the PMC. > > > > When things are not mature enough for a 1.0 release, we can either > > mark it @Experimental or @Beta, or deliver the code in a side > > project with a version number of < 1.0 until the code is mature > > enough to be included in Wicket proper. In the mean time, the > > experimental projects will be released with the wicket proper > > releases, but with a release version < 1.0, marking them as unfinished. > > > > So for example, a Wicket Push/Comet/Atmosphere project would reside in: > > > > wicket/ > > core/ > > extensions/ > > .../ > > push/ > > > > With a pom that specifies the version as 0.1-SNAPSHOT. When released > > it will released as 0.1, and the next version will become > > 0.2-SNAPSHOT. Iterate ad nauseam, and when the code base is mature > > enough, reversion to be on par with the proper Wicket release > > version (e.g. 6.1). > > > > The benefits of this are: > > - no need to go project hopping, there is one central place where > > we can find Wicket code, proper and experimental > > - better visibility of the project within Wicket and the wicket > > community > > - easier to attract new core developers to Wicket > > - no need for software grants and 'white washing' of code through > > the http://incubator.apache.org/ip-clearance/index.html > > - clearly defined trajectory for code bases developed by Wicket > > committers to go into core > > - no need to explain to the board why we have zero commits at > > apache's git and everything happening outside the purview of the PMC > > at external servers > > > > Martijn
