chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] [PATCH] bug in type-validation for "deprecated" de


From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] bug in type-validation for "deprecated" declaration
Date: Sat, 8 Sep 2012 22:59:31 +0200
User-agent: Mutt/1.4.2.3i

On Sat, Sep 08, 2012 at 10:50:24PM +0200, Felix wrote:
> > Since I approved the basic idea and implementation of your patch, and you
> > approved my additional changes (which I obviously also approve of), we
> > have two developers in agreement over a patch.  I think this means you
> > can sign off on it (since my patch is last).  It's a bit odd given the
> > git attribution of "signed off by" and "authored by", so maybe we should
> > come up with a sane way to mark changes like this.  Should I sign off
> > your changes and include my patch, which you then sign off on as well
> > (thereby ending with two or more "signed-off-by" lines)?  Or maybe I
> > should sign off on your patch as-is, even though it's broken and then
> > create a new patch, sending it as two changesets back to the list?
> 
> I don't know. Too many words for too little an issue.

This one doesn't matter as much, but I was also considering the future.
We've had similar situations before, where two people were working on a
patch and then having to wait for a third to push it.  This seems like
unnecessary overhead; if one core dev agrees a patch of another core dev
is okay, the patch can be pushed, so why can't this be done when the
patch is a collaborative effort of two devs?

When the two devs agree about the final product, it's pretty much the
same situation.  If the patch is complicated, a third dev's opinion
might be useful, but in cases like this one that's indeed just overkill.

> I'll push it now.

No need, I already pushed it, with Mario's fixes of my fixes.

> > Also, can we really tag a new RC?  Shouldn't the Linux/MacPPC issue
> > (#916) be fixed first?  Otherwise we'd need *another* RC.
> 
> I can not reproduce this, and only can test on a PPC64 (gcc compile
> farm). This bug looks a bit obscure.

I can't either on NetBSD/macppc, but AFAIK Mario can reproduce it
reliably.  If Mario needs help in debugging it, perhaps he can arrange
for this box to be available at certain hours, for us to test on?

Finally, we have John Cowan's point about Cygwin, which is pretty bad
and a probable release-blocker.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth



reply via email to

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