While I do agree with you that we could put experimental code in modules in Wicket, I do not agree with you that all development should take place on Apache Git servers. We no longer live in a centralized world. With Git, development is a decentralized process, taking place on many locations by many people at the same time.
I do understand the need for ip-clearance, but moving all development to a central server defeats the purpose of using Git on most points. Git allows open development, where everybody can contribute. Not so long ago, the board asked if Git changed our community dynamics. I think that's exactly what is happening right now. Git is changing our community for the better, and forcing all development back to the central servers will kill that process. Mainline Wicket develoment will still take place on the central Apache repository, because that's where our code lives. Code will have to be integrated into our main repository before it can become part of a release. If code from non-committers needs to be flaged, you can always aks the person to export the commits to mbox with format-patch and attach them to a ticket (the good-old email workflow). But IMHO the PMC should come up with a way to flag git commits without the need to attach them to a ticket. Best regards, Emond On Monday 02 April 2012 14:49:49 Martijn Dashorst 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
