Mailing-List: contact allura-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: allura-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of cjohns@geek.net designates
 74.125.149.201 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ65OfjwPWwR7OJ8ktn+5ONRYObFndbHp9uGO_QK3w-kfMejqQ@mail.gmail.com>
References: <50C0C8D1.3080801@brondsema.net>
	<50C144FD.4050905@gmail.com>
	<ADEA2D31-735A-4FF1-B6DC-389AD3A69AC4@rcbowen.com>
	<1355121149.14536.30.camel@lenovix>
	<CADiukUfE0rLJvUYSwAwRmBWceCY5Eat61=Zff2iQ80WhW_vXMA@mail.gmail.com>
	<CAJ65OfjwPWwR7OJ8ktn+5ONRYObFndbHp9uGO_QK3w-kfMejqQ@mail.gmail.com>
Date: Mon, 10 Dec 2012 15:39:01 -0500
Message-ID: 
 <CADiukUfO48Amm4X+va8cNdCaN23qgn10buhfijOkGd_tAD1zvg@mail.gmail.com>
Subject: Re: commit & merge practices for Allura
From: Cory Johns <johnsca@geek.net>
To: allura-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=e0cb4efe2ed036cec804d0858e61

--e0cb4efe2ed036cec804d0858e61
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I know that we don't often revert stories from master currently, but when /
if we do end up needing to, I don't want to be the one reverting a bunch of
commits by hand.  :-)  The penultimate line in your linked post even
suggests using --no-ff for this exact case (though it is mentioned in
reference to a merge-heavy workflow, which we clearly don't have).
 Probably it's not worth switching to until it becomes an issue, but I
wanted to bring it up.

We do still need to be sure to make clear what workflow we want to try to
stick to so that people aren't just guessing or using their own preferred
workflow.


On Mon, Dec 10, 2012 at 3:27 PM, Dave Brondsema <dbrondsema@geek.net> wrote=
:

> 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 "Revertin=
g
> the Revert" if you want).  Personally I like the clean timeline rather th=
an
> 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 assig=
n
> 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 nee=
d
> to
> > revert the merge, there is a single commit that can be reverted, instea=
d
> 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=F3:
> > > > On Dec 6, 2012, at 8:23 PM, Peter Hartmann wrote:
> > > >
> > > > > I'd also like to take this opportunity to tackle related issue. A=
s
> > > Allura will get more and more developers (hopefully!) at least some o=
f
> > 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 f=
or
> > 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 b=
e
> > > 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 i=
s
> > 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 probabl=
y
> > > 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 infrastructur=
e
> is
> > > if it's not Apache licensed. In which case, we can't have it in Allur=
a
> > > 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 proces=
s
> > > 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 li=
st
> > > 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-
> > >
> > >
> >
> > --
> > =3D=3D=3D=3D
> > 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 strictl=
y
> > prohibited. If you have received this e-mail in error, please immediate=
ly
> > 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
>
> --
> =3D=3D=3D=3D
> This e- mail message is intended only for the named recipient(s) above. I=
t
> 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 a=
ny
> attachment(s) from your system. Thank you.
>
>

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


--e0cb4efe2ed036cec804d0858e61--