chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] [PATCH] Add missing "C_" prefix to a snprintf call


From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Add missing "C_" prefix to a snprintf calls in a tcp module
Date: Sun, 19 Oct 2014 17:32:57 +0200
User-agent: Mutt/1.4.2.3i

On Sun, Oct 19, 2014 at 07:24:23PM +0400, Oleg Kolosov wrote:
> On 19 Oct 2014, at 18:17, Peter Bex <address@hidden> wrote:
> > Thanks for the patch, it looks good.  I've pushed it to master and
> > chicken-5.  Please note that this is not the best test for the process,
> > because we normally require double sign-off on patches, but for trivial
> > ones we can push them straight away.
> 
> Do you mean that I should sign-off by myself and ask somebody on IRC to 
> review and sign-off too? I’ve looked on http://wiki.call-cc.org/contribute - 
> it says “send them to the mailing list or fill a ticket”. Perhaps this 
> section should be updated.

No, only core developers ("committers") are allowed to sign off on
patches.  Sorry if that wasn't clear.  Sending it to the mailing list
is perfectly fine.

I was just trying to explain that now only I signed off and pushed,
but normally I would have to sign off, and resend the patch (possibly
modified) to the list, so that a second core developer can sign off
on it and push it.

> > I'd hesitate to apply them, because we wouldn't be able to maintain
> > them.  We'd need msvc support so we can verify things still work if
> > we change things up.  Do you think you could write a Windows Makefile
> > which uses the msvc compiler?
> 
> I do not think so. This task looks too formidable.

That's too bad :(

What in particular is tricky about it?  I'd expect the mingw
Makefile to be reusable with a few changes to C_COMPILER and
some flags.  But that's just my ignorance talking, probably.

> > I'd like to know what the other hackers think about this.
> 
> Well, I’ve tried hard to not break the existing system. It still builds with 
> make just fine (but I’ve not tested on anything besides runtests). I intend 
> to keep it this way as long as possible to ease merging.
> 
> There is another alternative. I maintain our company’s internal fork with 
> CMake support and other experimental features and currently in the process of 
> pushing it to my github repo, the management is fine with that so far.
> 
> In a few weeks we will have point release of our product, and after that, I 
> plan to try to rebase it all on chicken-5. If all goes well - we will have a 
> public repo with direct commit rights to experiment on as we please without 
> spamming the mailing list with the discussions, and you will get some testing 
> of the latest development branch on the real world application. Win - win.

This is pretty cool, but I'd caution against it if you're using a lot of
eggs.  We intend to change a lot of things still, so you'd be creating a
lot of extra effort for yourselves to port and re-port these eggs every
time we make an incompatible change.  The same goes for your product, of
course.

On the other hand, you would have the opportunity to develop in
lock-step with core, which means you'll only need to make small iterative
changes while core is evolving.

Cheers,
Peter
-- 
http://www.more-magic.net



reply via email to

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