On Fri, 2010-02-26 at 07:21 -0500, Kamil Paral wrote:
----- "James Laska" jlaska@redhat.com wrote:
On Tue, 2010-02-23 at 12:27 -0500, Will Woods wrote:
Hi folks,
So I've been thinking about how we should be managing the autoqa sources, and patch review, and things like that. Here's some
guidelines
that I've come up with. Probably this will go in a wiki page on the autoqa trac instance, but I wanted to send it here for review
first.
The short version is this:
- we use git, and the 'master' branch is the production code (for
now)
- send git-formatted patches to the autoqa-devel list
- if changes are too big for patches, ask for a personal branch
- wwoods is responsible for applying patches / merging changes, but
he'll also get jlaska & kparal to help
I'd defer to you and Kamil first. But I'm happy to merge changes whenever desired.
The longer version:
- autoqa is hosted in git, and the autoqa-devel mailing list is the
best
place to discuss new ideas for autoqa tests, features, and such.
Definitely. Keep the thread coming! :)
To discuss, certainly. I'm just a little worried about patch management. It is really easy to forget about a waiting patch in the mailing list. Unless we have a Review Board [1], maybe we can create tickets for patches in our Trac, just not to forget about them?
[1] https://fedorahosted.org/fedora-infrastructure/ticket/1196
Very cool, no objections here once that option is available.
For tickets, I was a bit leery at first to the idea (oh no, more process!). But thinking further, pretty much anything we do in autoqa is in response to something, whether it's a bug fix or a new feature. I think it's safe to record all of those as tickets (which makes the spec file easier to parse for me).
Whatever we choose, hopefully it's light weight so it's sustainable, but like you note ... helps us avoid losing patches out for review on the list.
Any other opinions?
- The autoqa git repo has a 'master' branch - this should be
considered
the production code, at least for now. We encourage developers to
clone
the repo and create their own private branches.
With guidance from Will, I updated the AutoQA_PatchProcess page to provide some guidance on creating a named branch to work on changes.
https://fedoraproject.org/wiki/AutoQA_PatchProcess#Named_Branch
I think there should not be "git push --all" in the examples, just the name of the new branch. Recently I was quite surprised when I noticed some branches available that I deleted from our git repo a long time ago. This may be the explanation :)
Thanks. I need to walk through these steps myself. I'll update the wiki once completed.
- If you have a bugfix or a proposed patch, please send it to the
list
for review or discussion. It's best if you use 'git format-patch'
and
'git send-email' to format and send your patch(es). Anyone on the
list
should feel free to comment on incoming patches.
Same here. I reordered some wiki content regarding patch submission. Thoughts/concerns welcome - https://fedoraproject.org/wiki/AutoQA_PatchProcess#Patch_submission
- If you have some changes that are more complex than a simple patch
or
patch set, feel free to ask for commit access to the repo so you
can
have your own branch in the public repo.
<snip>
Leaving remaining questions for wwoods.
Thanks, James