RE: proposed changes for winbuild makefile
Date: Tue, 31 Jan 2017 10:24:43 -0000
Thanks for taking the time to respond.
TLDR; Some people are listening, tell me what to do next.
> . I wouldn't expect to hear anything from 99% of them
> unless it stops working, because that's usually the way it goes
I deleted my response to that - it didn't say anything you won't already know. It’s the leitmotif of every successful Open Source project I have contributed to. You are just more laid back than I am....
> If you
> have a PR you want to submit that will improve winbuild then that's
> great, but I doubt anyone can (or should) give you a guarantee that your
> work will get in without any friction.
I have no problems with that.
> We are all reviewed by our peers
> and we adjust. Changes may be and often are requested. Or maybe an idea
> is a bad or implementation is bad or it just shouldn't be added.
I have no problems with that. Once you can get something past the OpenAFS gatekeepers (where no change can be more than about 20 lines difference and each once has to compile as pass tests) you can get anything committed.
But I'm struggling to work out the protocol for this project. For instance:
> Concerning the patch I did not review it however what was ultimately
> proposed in 1201  I think seems to make a lot of sense.
Whilst I agree that it seems to make sense, I'm not sure if I'm embarrassed or saddened that this PR wasn't on my horizon after several weeks of discussion. Should I have been communicating there? I am very new to this project and I may have missed on protocol - advice would be welcomed: despite my cynicism I am willing to contribute to help the common good.
> We need support for OpenSSL 1.1.0 libraries, and so I think the ability
> to override the variables on the command line seems like a good idea.
I believe so, but it comes at the cost of downstream support. Once you "document" something it has to work forever - that’s why I like these changes, I can move our build over to a supported mechanism.
> Changing the static library to roll up all the dependencies in one big
> library I think is a bad idea.
It makes me itch and I would build both dll and lib from the same objs; but I'm not a usermode library specialist = the DLLs I usually author are kernel-mode drivers. In this case I'd follow the reviewers as to what to do (and in doing so I must mention that I understand that I forgo my right to whine after the event).
So, what's needed? Do we (Kees and I) need to deconstruct the patch? Shall I start from scratch and do what I need and work with Kees to make it do what it should?
Received on 2017-01-31