automake-patches
[Top][All Lists]
Advanced

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

Re: where to base patch series off of (was: [PATCH 0/6] Lex, Yacc and ex


From: Stefano Lattarini
Subject: Re: where to base patch series off of (was: [PATCH 0/6] Lex, Yacc and explicit declarations of dependencies.)
Date: Tue, 6 Jul 2010 23:57:13 +0200
User-agent: KMail/1.12.1 (Linux/2.6.30-2-686; KDE/4.3.4; i686; ; )

At Tuesday 06 July 2010, Ralf Wildenhues wrote:
> > I just thought that the feature could be a reasonable candidate
> > for a new branch, which BTW would have given me a first
> > opportunity to mess around with remote branching and pushing
> > without touching/endangering the master/maint branches.
> Indeed.
Does this mean "OK, you can create and push the branch, I'll review 
that instead of your git-formatted patches"?
 
> > > it shouldn't be necessary to post updated patches nor push a
> > > branch; I have your patches in an old branch sitting here.
> >
> > Agreed.  But I think it would be a good idea anyway to edit the
> > ChangeLog of the [PATCH 2/6] to cite also Solaris 10
> > /usr/xpg4/bin/make rather than only Heirloom make.
> 
> Sure.  I didn't mean that I would push the old branch; just that
> for reviewing I won't necessarily need an update.
The update wasn't meant to ease the review, just to avoid any merge 
conflict (which would have been spurious anyway), and to improve the 
ChangeLog entry w.r.t. the make implementations affected.

> > Yes, it's definitely possibile.  But why maint?  I'm not so sure
> > the change should to be considered as maintainance/bugfixing
> > only...
> 
> Oh, I didn't mean that the patch series should be committed to the
> maint branch.  Rather, that it should be committed to a new branch
> which itself is based off of the maint branch, rather than based
> off of master.  This doesn't mean that the patch series should be
> merged into maint at some point into the future, but that it
> *could* be done; IOW, I would like to be able to postpone the
> decision about where to merge the branch to.  A more likely
> scenario, namely that it is merged into master only but not maint
> nor branch-1.11, is still possible, and rarely more work.
Oh.  This makes sense, and sounds like a good idea too.

Regards,
   Stefano



reply via email to

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