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.
