----- "James Laska" <jlaska(a)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
> * 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 :)
> * 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.
Git is decentralized, so why grant people commit access to our repo?
I would just instruct them to push their branch to their own location
(like on
fedorapeople.org). Simple http server is enough. And then
they just send us the link to their branch.
(This will make it easier
to
> cherrypick changes and/or merge large patch sets without
overwhelming
> the list.)
>
> * It's helpful if people who have personal branches put their
> username/IRC nick in the branch name, so everyone knows who owns
which
> branch.
In hindsight, having my local changes in a branch would have made
merging a bit easier.
> * wwoods is the maintainer/patch monkey for the 'master' branch, but
he
> sometimes delegates authority to jlaska and kparal to do updates to
> master. (Especially when he's off in the clouds and there's bugs
that
> need fixin'.)
So unless you say otherwise, all the patches goes through you (even
patches from our team), is that right?
>
>
> Does this clear up the current development process any?
This does for me. I don't have tons of development project
experience,
but what I appreciate here is trying to be specific about who is
responsible for what. So if this helps identify who is doing what,
when ... great!
Thanks,
James
_______________________________________________
autoqa-devel mailing list
autoqa-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/autoqa-devel