automake-patches
[Top][All Lists]
Advanced

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

Re: pushing patches (was: [PATCH] Extend tests/README (trailing `:' in t


From: Stefano Lattarini
Subject: Re: pushing patches (was: [PATCH] Extend tests/README (trailing `:' in test scripts))
Date: Sun, 4 Jul 2010 23:24:19 +0200
User-agent: KMail/1.12.1 (FreeBSD/8.0-RELEASE; KDE/4.3.1; i386; ; )

Hello Ralf, and sorry for taking so long to answer this.

In my defense, I can say that gmail put this message in Spam :-(, and
I haven't seen it until today (yeah, stupid me trusting gmail filter 
so blindly).  BTW, gmail marked as spam also the message "the branch
a patch is for (was: [PATCH] Testsuite: ensure verbose printing of 
captured stderr.)", where you were referring to this one.  Murphy hit
really hard here.

I'm really really sorry about this.

Now back to business...

At Saturday 12 June 2010, Ralf Wildenhues wrote:
> Hi Stefano,
> 
> * Stefano Lattarini wrote on Fri, Jun 11, 2010 at 12:42:24PM CEST:
> > OK to apply this patch to tests/README? [...]
> 
> Speaking of "OK to apply", would you prefer pushing approved
> patches yourself?  If yes, please apply as project member on
> <http://savannah.gnu.org/project/memberlist.php?group=automake>
Done.
> so I can set the write bit for you.
Mmh..  I must admit that I'm a bit wary about the possibility of 
having a full committer status, because that also entails the 
possibility of messing up the *official* Automake repository with some 
simple botched git command.
There is maybe some way to restrict committer status to e.g. certain 
branches?  That would be great.
In case that's not possible, there is maybe some git black magic to be 
put in (say) the local .git/config or ~/.gitconfig, so that pushing is 
allowed only against some (explicitly listed) remote branches?

> I have been waiting with this step for quite a while, mainly
>  because I wanted to gain some experience working with multiple,
>  long-lived branches and getting a more-or-less coherent git
>  workflow.  The single-push integratory scheme of the last year or
>  so works quite well for me, so I don't mind continuing that, since
>  I pretty much apply all patches I review to my tree anyway.  The
>  bottle-neck is the reviewing, not the slurping of patches, thanks
>  to git.
> 
> If you prefer pushing, then I would push the pointer of my maint
> branch to the public repo as well, plus any other topic branches
> that are longer-lived.
Yes, I'd like that.  This way a contributor can merge those branches 
in his own remote ones, thus making the future merge of these personal 
branches into the main ones easier.
> This change will require to weed out old
>  topic branches every now and then, and in fact I think the
>  following branches are ready to go:
>   ad-parallel-tests
>   dr-cscope
Not sure about this last one, as there still are some pending patches 
of mine regarding the cscope functionality.

> 
> This one we could revive, with some reasonable policy:
>   next
> 
> The vala and silent-rules support probably can see some more
> improvements at some point:
>   je-silent
>   mh-vala-support
> 
> The following are leftovers from the conversion from CVS, I'm
>  reluctant to just remove them:
Why? No criticism here, just curious...
>   master-UNNAMED-BRANCH
>   master-UNNAMED-BRANCH-UNNAMED-BRANCH
>   user-dep-gen-branch
>   user-dep-gen-merge-branch
> 

Thanks, and again, please accept my apologies.

Regards,
  Stefano



reply via email to

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