What about one (or more) separate apache-hosted repository for experimental projects? Maybe completely separate, maybe a clone just to host the experimental branches. This would
- keep the main repository cleaner - ease experimentation, since there will be no subconscious fear of committing junk to the main rep - make some good use of git's distributed features Since a git clone holds the whole history of the repository, including all branches, it makes sense to try to keep it somewhat clean. On Mon, Apr 2, 2012 at 11:35 AM, Emond Papegaaij <emond.papega...@topicus.nl> wrote: > After a good discussion with Martijn Dashorst, we agreed that Github (or any > other open repository) probably is a good thing, but not yet. The board needs > to come up with a way to integrate this into the 'Apache way' of development. > Until then, it's probably best to always push your code to the Apache server > first, after which you can also push it to Github (it's open source after > all). This should keep everone happy. So expect a wicket-atmosphere sandbox > branch soon :) > > Best regards, > Emond > > On Monday 02 April 2012 15:11:45 Emond Papegaaij wrote: >> 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
