incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alvaro del Castillo <...@bitergia.com>
Subject Re: commit & merge practices for Allura
Date Mon, 10 Dec 2012 06:32:29 GMT
Hi guys!

About the process for contributing code to Allura, I find quite
reasonable how you were working in Sourceforge so it is ok for me!

El jue, 06-12-2012 a las 20:38 -0500, Rich Bowen escribió:
> 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.
> 

And about this issue, I am not sure. If we bet for #1 we don't introduce
a new different process in the code contribution process.

Another interesting issue is mentoring. The Allura development process
seems really mature and the sourceforge team have used it for several
months (maybe some year). Newcomers, like myself, will need help
adopting all the best practices you are following. Do you think it is a
good idea to have personal development mentors to guide the newcomers in
the first steps in the project? Or we can use directly the mailing list
and follow a group mentoring model?

Cheers
-- 
|\_____/| Alvaro del Castillo
 [o] [o]  acs@bitergia.com - CTO, Software Engineer
 |  V  |  http://www.bitergia.com
  |   |
-ooo-ooo-
|\_____/| Alvaro del Castillo
 [o] [o]  acs@bitergia.com - CTO, Software Engineer
 |  V  |  http://www.bitergia.com
  |   |
-ooo-ooo-


Mime
View raw message