You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Dave Brondsema <da...@brondsema.net> on 2012/12/06 17:33:21 UTC
commit & merge practices for Allura
So now that we have several new committers on Allura, I think its time to talk
about how we want to handle reviewing & merging code into Allura. I'll give an
overview of how we at SourceForge have been doing it so far, but I think it will
need some modifications.
1. create a ticket for the issue
2. assign the ticket to yourself
3. create a branch (we name them with our initials and ticket number, like db/1234)
4. commit & revise as much as needed on that branch, until ready
5. change the ticket status to "code-review" and put enter another developer
into the QA field
6. the "QA" developer reviews the changes in the branch, to make sure the code
is good, functionality is correct, no performance or security concerns, tests
are present, etc
7. the reviewing developer merges the branch to master and closes the ticket
This works well for us, so personally I'd be interested in continuing a process
similar to this. However, I think #5 at least needs more thought. Since
SourceForge has several full-time developers working on Allura (and other
internal things too), we work on a lot of tickets, and regularly check our QA
queue to review each others' tickets. How do we get the rest of the Allura
committers involved? Assigning tickets to people puts a responsibility on them
to do that review, which isn't appropriate at Apache. Maybe we could just
change tickets to "code-review" status and not assign a reviewer. Then there
would be a pool of tickets and anyone can take any ticket from that pool to
review it. SF employees would probably take a lot of them, but that's ok, at
least it wouldn't be exclusive to us then.
What do others think about this process? Changes to it? Something completely
different?
I think it'd be good to get a broad perspective here, opinions from SourceForge
devs, our newer committers, mentors, and anyone else is encouraged
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: commit & merge practices for Allura
Posted by Wayne Witzel III <ww...@gmail.com>.
42cc_ is used by 42 Coffee Cups which is a company who contributes to Allura.
As for how and when a prefix is used, I don't think there is any specific rule, it tends to either be the persons initials, sf-username, or company abbreviation.
--
Wayne Witzel III
http://pieceofpy.com
wwitzel3@gmail.com
On Monday, December 10, 2012 at 3:13 PM, Peter Hartmann wrote:
> One more thing about branch-per-ticket scheme. Branches in Allura repo
> have fairly non-descriptive prefixes, like "cj/" or "tv/". I figure out
> that this have something to do with either author or QA person (Cory
> Johns and Tim Van Steenburgh respectively?), but i'm puzzled about
> "42cc_" thing. How and when it is appropriate to use certain prefix?
>
> I'm asking here and not on irc cause the answer may prove useful to
> other people, too.
>
> - Peter
Re: commit & merge practices for Allura
Posted by Peter Hartmann <ma...@gmail.com>.
One more thing about branch-per-ticket scheme. Branches in Allura repo
have fairly non-descriptive prefixes, like "cj/" or "tv/". I figure out
that this have something to do with either author or QA person (Cory
Johns and Tim Van Steenburgh respectively?), but i'm puzzled about
"42cc_" thing. How and when it is appropriate to use certain prefix?
I'm asking here and not on irc cause the answer may prove useful to
other people, too.
- Peter
Re: commit & merge practices for Allura
Posted by Cory Johns <jo...@geek.net>.
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 <db...@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 "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 <jo...@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.
>
>
--
====
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.
Re: commit & merge practices for Allura
Posted by Dave Brondsema <db...@geek.net>.
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 <jo...@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.
Re: commit & merge practices for Allura
Posted by Cory Johns <jo...@geek.net>.
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 <ac...@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.
Re: commit & merge practices for Allura
Posted by Alvaro del Castillo <ac...@bitergia.com>.
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-
Re: commit & merge practices for Allura
Posted by Rich Bowen <rb...@rcbowen.com>.
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
rbowen@rcbowen.com
Shosholoza
Re: commit & merge practices for Allura
Posted by Peter Hartmann <ma...@gmail.com>.
W dniu 06.12.2012 17:33, Dave Brondsema pisze:
> So now that we have several new committers on Allura, I think its time to talk
> about how we want to handle reviewing & merging code into Allura. I'll give an
> overview of how we at SourceForge have been doing it so far, but I think it will
> need some modifications.
>
> 1. create a ticket for the issue
> 2. assign the ticket to yourself
> 3. create a branch (we name them with our initials and ticket number, like db/1234)
> 4. commit & revise as much as needed on that branch, until ready
> 5. change the ticket status to "code-review" and put enter another developer
> into the QA field
> 6. the "QA" developer reviews the changes in the branch, to make sure the code
> is good, functionality is correct, no performance or security concerns, tests
> are present, etc
> 7. the reviewing developer merges the branch to master and closes the ticket
>
> This works well for us, so personally I'd be interested in continuing a process
> similar to this. However, I think #5 at least needs more thought. Since
> SourceForge has several full-time developers working on Allura (and other
> internal things too), we work on a lot of tickets, and regularly check our QA
> queue to review each others' tickets. How do we get the rest of the Allura
> committers involved? Assigning tickets to people puts a responsibility on them
> to do that review, which isn't appropriate at Apache. Maybe we could just
> change tickets to "code-review" status and not assign a reviewer. Then there
> would be a pool of tickets and anyone can take any ticket from that pool to
> review it. SF employees would probably take a lot of them, but that's ok, at
> least it wouldn't be exclusive to us then.
To me, the way it's working now with proposed changes to QA seems fairly
sane. It does the job of keeping commits separated and not put into, how
should I call it, "endorsed" repository branches too early. One downside
I can think of is that it makes repository somewhat cluttered, but it's
purely esthetic issue.Frankly, I was going to discuss these matters on
irc tomorrow, regarding removal of ForgeHg from Allura's repo. I've
taken the liberty to merge changes from #5037 to ForgeHg repository already.
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.
- P.H.