Message ID | cover.1695330852.git.steadmon@google.com (mailing list archive) |
---|---|
Headers | show |
Series | config-parse: create config parsing library | expand |
Josh Steadmon <steadmon@google.com> writes: > Config parsing no longer uses global state as of gc/config-context, so the > natural next step for libification is to turn that into its own library. > This series starts that process by moving config parsing into > config-parse.[c|h] so that other programs can include this functionality > without pulling in all of config.[c|h]. This has been in list archive collecting dust. It is unfortunate that not many people appear to be interested in reviewing others' patches? > Open questions: > - How do folks feel about the do_event() refactor in patches 2 & 3? I gave a quick re-read and found that the code after patch 2 made it easier to see how config.c::do_event() does its thing (even though the patch text of that exact step was somehow a bit hard to follow). However, the helper added by patch 3, do_event_and_flush(), that duplicates exactly what do_event() does, is hard to reason about, at least for me. It returns early without setting .previous_type to EOF and the value returned from the helper signals if that is the case (the two early return points both return what flush_event() gave us), but the only caller of the helper does not even inspect the return value, unlike all the callers of do_event(), which also looks a bit fishy. Thanks.
On Tue, Oct 17, 2023 at 10:13:49AM -0700, Junio C Hamano wrote: > Josh Steadmon <steadmon@google.com> writes: > > > Open questions: > > - How do folks feel about the do_event() refactor in patches 2 & 3? > > I gave a quick re-read and found that the code after patch 2 made it > easier to see how config.c::do_event() does its thing (even though > the patch text of that exact step was somehow a bit hard to follow). > > However, the helper added by patch 3, do_event_and_flush(), that > duplicates exactly what do_event() does, is hard to reason about, at > least for me. It returns early without setting .previous_type to > EOF and the value returned from the helper signals if that is the > case (the two early return points both return what flush_event() > gave us), but the only caller of the helper does not even inspect > the return value, unlike all the callers of do_event(), which also > looks a bit fishy. I had similar thoughts while reviewing. But I am not sure that I agree that this series is moving us in the right direction necessarily. Or at least I am not convinced that shipping the intermediate state is worth doing before we have callers that could drop '#include "config.h"' for just the parser. This feels like churn that does not yield a tangible pay-off, at least in the sense that the refactoring and code movement delivers us something that we can substantively use today. I dunno. Thanks, Taylor
Taylor Blau <me@ttaylorr.com> writes: > This feels like churn that does not yield a tangible pay-off, at least > in the sense that the refactoring and code movement delivers us > something that we can substantively use today. > > I dunno. That matches something I felt but was too polite to say aloud ;-)
Taylor Blau <me@ttaylorr.com> writes: > But I am not sure that I agree that this series is moving us in the > right direction necessarily. Or at least I am not convinced that > shipping the intermediate state is worth doing before we have callers > that could drop '#include "config.h"' for just the parser. > > This feels like churn that does not yield a tangible pay-off, at least > in the sense that the refactoring and code movement delivers us > something that we can substantively use today. > > I dunno. > > Thanks, > Taylor Thanks for calling this out. We do want our changes to be good for both the libification and the non-libification cases as much as possible. As it is, I do agree that since we won't have callers that can use the new parser header (I think the likeliest cause of having such a caller is if we have a "interpret-config" command, like "interpret-trailers"), we probably shouldn't merge this (at least, the last 2 patches). I think patches 1-3 are still usable (they make some internals of config parsing less confusing) but I'm also OK if we hold off on them until we find a compelling use case that motivates refactoring on the config parser.
On 2023.10.24 15:50, Jonathan Tan wrote: > Taylor Blau <me@ttaylorr.com> writes: > > But I am not sure that I agree that this series is moving us in the > > right direction necessarily. Or at least I am not convinced that > > shipping the intermediate state is worth doing before we have callers > > that could drop '#include "config.h"' for just the parser. > > > > This feels like churn that does not yield a tangible pay-off, at least > > in the sense that the refactoring and code movement delivers us > > something that we can substantively use today. > > > > I dunno. > > > > Thanks, > > Taylor > > Thanks for calling this out. We do want our changes to be good for both > the libification and the non-libification cases as much as possible. As > it is, I do agree that since we won't have callers that can use the new > parser header (I think the likeliest cause of having such a caller is > if we have a "interpret-config" command, like "interpret-trailers"), we > probably shouldn't merge this (at least, the last 2 patches). > > I think patches 1-3 are still usable (they make some internals of config > parsing less confusing) but I'm also OK if we hold off on them until > we find a compelling use case that motivates refactoring on the config > parser. Thanks everyone for the revived discussion here. I think I agree, this series is not going in the right direction. Additionally, our internal use case for this change has evaporated, so let's just drop the series. We can pick it up again later if interest returns.
Josh Steadmon <steadmon@google.com> writes: > Thanks everyone for the revived discussion here. I think I agree, this > series is not going in the right direction. Additionally, our internal > use case for this change has evaporated, so let's just drop the series. > We can pick it up again later if interest returns. OK. Let's scrap it for now. The "internal use case" behind a proposed feature changing so quickly is a bit worrying. What is good for this project should ideally be good for everybody, not only for satisfying a particular $CORP needs of the day. But I think the idea of giving enhanced visibility into stakeholder companies directions and priorities Emily (I think?) floated during the contributors' summit may help reduce such a risk, hopefully. Thanks.