incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <dbronds...@geek.net>
Subject Re: commit & merge practices for Allura
Date Mon, 10 Dec 2012 20:27:52 GMT
Thanks for remembering about rebasing, that is important to bring up.
 Using merge commits on master for easier reverting might be nice, but it
also can be tricky if you are trying to re-do the merge later.  See
http://git-scm.com/2010/03/02/undoing-merges.html (skip down to "Reverting
the Revert" if you want).  Personally I like the clean timeline rather than
merge commits, and it's not often we need to revert commits that are on
master already.


On Mon, Dec 10, 2012 at 2:43 PM, Cory Johns <johnsca@geek.net> wrote:

> I vote for keeping with the branch-per-story, optionally with
> user-initialed-namespacing, and experimental features ought to be tied to
> tickets anyway (i.e., option 1).
>
> Additionally, I like the idea of "unassigned QA" and encouraging developers
> to pick up QA as they can and feel comfortable.  And we can still assign QA
> if we discuss it with the person beforehand and there is a reason to do so
> (or just to ensure that it gets done in a timely manner).
>
> One thing that isn't mentioned is our rebase workflow.  A lot of people are
> more used to a merge workflow and avoid rebasing as much as possible.  I
> used to be in this camp, but have come to appreciate the relatively
> uncluttered timeline that the rebase workflow gives us.  But we'll need to
> be explicit about our convention here because it is not the most common in
> the community.
>
> I have also started to think that we might change one aspect of our rebase
> workflow.  Currently, we only do fast-forward merges into master.  I'm
> thinking that we might want to flip that around and, while keeping our
> rebase workflow to keep the commits grouped together, requiring that
> branches merged into master be *non*-fast-forward.  This way, if we need to
> revert the merge, there is a single commit that can be reverted, instead of
> having to revert each individual commit.  I'm open to thoughts, discussion,
> or correction here.
>
> On Mon, Dec 10, 2012 at 1:32 AM, Alvaro del Castillo <acs@bitergia.com
> >wrote:
>
> > 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-
> >
> >
>
> --
> ====
> This e- mail message is intended only for the named recipient(s) above. It
> may contain confidential and privileged information. If you are not the
> intended recipient you are hereby notified that any dissemination,
> distribution or copying of this e-mail and any attachment(s) is strictly
> prohibited. If you have received this e-mail in error, please immediately
> notify the sender by replying to this e-mail and delete the message and any
> attachment(s) from your system. Thank you.
>
>


-- 
Dave Brondsema
Principal Software Engineer - sf.net
Geeknet

-- 
====
This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message