On Dec 6, 2012, at 8:23 PM, Peter Hartmann wrote: > I'd also like to take this opportunity to tackle related issue. As Allura > will get more and more developers (hopefully!) at least some of them will be > eager to do a highly invasive kind of work. Developing experimental features > is cool and fun and once we'll get a release sorted out, I for one would > certainly like to do so. However, this kind of code may not fit too well > within Allura development goals and planned featureset, it may be untested, > or simply too buggy to merge it with master. > > So how do we handle this kind of work? I see three possibilities here: > 1) each experimental feature gets it's own branch, much like it is now with > bugtracker tickets, > 2) each developer gets his own "playground" branch where he puts whatever he > likes and commits changes as he pleases, > 3) don't do it here; make a fork on github (easy cause our git is mirrored > there) or whenever you like, but Allura doesn't want to have anything to do > with it. > > I think #2 would be best, cause after all there may - and probably will - be > features among this experimental code that would make great addition to > Allura and we'll like to have them merged in. #3, however, seems most similar > to how it has been before Allura's move to Apache, i.e. individual > repositories for every interested person.
My preference, for two reasons, would be either #1 or #2. 1) Our goal here is to make Allura into a full-featured forge, and, as such, we want to be "eating our own dogfood", as the saying goes. 2) The only reason to develop code outside of the ASF infrastructure is if it's not Apache licensed. In which case, we can't have it in Allura anyways. By developing it with ASF's git to begin with, there's no further process to accept it back into our repo, since it's already here. So, yeah, I'd prefer option #2 above, same as you. -- Rich Bowen [email protected] Shosholoza
