findutils-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Findutils-patches] [PATCH 1/2] Explain that before reporting a prob


From: James Youngman
Subject: Re: [Findutils-patches] [PATCH 1/2] Explain that before reporting a problem, you should try the current
Date: Sat, 23 Jun 2007 15:33:16 +0100

(Copying bug-findutils)

On 6/23/07, Eric Blake <address@hidden> wrote:
Say, do you have your git repository published somewhere?  Is it worth
getting it added to git.sv.gnu.org/gitweb?

Yes and no.   There is a public repo, but it's downstream of CVS.

Our updated workflow for reviewing patches is not exactly stable or
simple just now.  Here's the situation up to last week:


1. No review process
2. To accomodate a Summer of Code student, I created a public GIT
repository.  He commits into a branch in that, I sync CVS into
"master" in that repository.  I merge master into his branch.   This
repository is http://repo.or.cz/w/findutils.git.
3. I run "git cvsimport" locally to sync it roughly weekly to a local
scratch GIT repository, and push changes to the public repository.
4. The main reson to do this is to avoid an eventual "huge merge" when
the SOC project completes.


Here's the current situation, as of roughly right now.

1. Review process exists but is embryonic.
2. as above
3. as above
4. as above
5. There is also a third git repository which is also local here, in
which I make changes on a private branch.  I then format the commits
and mail them to address@hidden for review.  I have a
script for doing this, so far it seems cumbersome but painless.
6. Patches to the findutils-patches mailing list are delivered
indirectly to individual files in a location convenient to me.
7. When positive review comments come in I can apply these patches to
the CVS repository.
8. I can then sync CVS changes into the master branch of my GIT
repository (see item 5 here).   I can periodically rebase my private
branch against the master.

This is all unproven and not well bedded in.  Items 7 and 8 haven't
happened yet, having three GIT repositories seems a bit cumbersome,
not enough is automated, and I am still so new with git that I fear it
is only a matter of time before I have a nasty accident :(

Currenly a change will go like this:

Brain -> Editor -> disk -> commit to my private branch in a local git
repo -> mail to findutils-patches -> delivery to list members ->
procmail saves it on a local disk here.

Pause for others to respond.  Positive review causes me to apply the
patch to the public CVS repository.

public CVS -> cvsimport to my local scratch repo -> push to git.or.cz:master
Then I merge push to git.or.cz:master into push to git.or.cz:polzer.

There are a number of things I don't like about this, but the main one
is that I think it's all too manual and uses too many separate stages
and repositories.   Secondly I have no way to adequately track the
review status of patches.

I'm not ready, yet, for using GIT as the authoritative upstream
source.   At the moment I am essentially using git for managing
patches.   My principal reason is that I'm insifficiently familiar
with it.  More generally though, I am positively inclined about the
idea of using git.sv.gnu.org.

Suggestions for better automation and process streamlining will be welcome :)
James.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]