On Tue, Feb 25, 2020 at 03:29:08PM -0800, Junio C Hamano wrote: > Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > > > Hm. I guess I got the opposite impression from you way back in v1. I do > > wish it had been communicated a little more clearly; it's frustrating to > > perceive a reversal after seven months of review. But that's probably on > > my own reading comprehension :) > > Well, seven months is a long time for anybody to learn from repeated > reading and gained experience to form an opinion and get affected by > others' opinions. In any case, this is one of the reasons why I try > to discourage people to have too many topics in flight before moving > on to a new and different topic---the risk of ending up with fliping > and flopping is just too high when you give people chance to forget. > Rather, I'd prefer to see something simple to land first and then > later refined. I think it's exactly what happened with this topic. It's easy to say "don't have too many things out at once" in theory - but becomes less easy when you combine it with things like quarterly planning at dayjob, etc. In fact I have been trying to revive and push through old topics I had in flight because I had this same realization - my six topics were only each updated every month or so, meaning everyone (including me) forgot what was going on from revision to revision. I wonder whether it makes sense to try and finalize the bare minimums of this feature, and then move the rest of the work to their own topics. I see a couple benefits: - Users can start trying out 'git bugreport' when they write us mails much sooner. Even the template alone would increase the quality of a number of the reports I see come into this list. - It may help insulate this topic from 'feature creep,' which in my opinion has plagued it from the start. While the entire topic of 15 patches is in flux, it's hard for someone else to write their own patch adding, say, midex/commit-graph support, and so I feel obligated to write it myself - which of course increases the amount of time the topic lives on in review. - Of course smaller topics are easier to review, and a commit-graph expert is much more likely to click on the subject "[PATCH] bugreport: gather commit-graph diagnostics" than they are to click on the subject "[PATCH] add bugreport utility". That is, I'm guessing there will be more reviews on the semantics of the patch (is it the right diagnostic info? is it useful?) than there have been so far. The downside is mailing list churn, and the possibility that with a minimum 'git-bugreport' checked in I find something better to do. I'm not too worried about the former; after all, that's what this list is for, right? As for the latter, after 7 months of flip and flop I don't think the risk is greater than it is now anyways ;) I think it makes sense to send the following topics: /* To me, this sounds like minimum viable bugreport. "What went wrong, * and how do I build the same binary as you so I can reproduce it?" add git-bugreport tool: - bugreport: add tool to generate debugging info - bugreport: gather git version and build info - bugreport: add uname info - bugreport: add compiler info bugreport: add git-remote-https version bugreport: include shell info - help: add shell-path to --build-options - bugreport: include user interactive shell bugreport: include config info - help: move list_config_help to builtin/help - bugreport: generate config safelist based on docs - bugreport: add config values from safelist bugreport: collect list of populated hooks bugreport: include object store info - bugreport: count loose objects - bugreport: add packed object summary - bugreport: list contents of $OBJDIR/info I'd like to send that first topic as vN+1 of this one, and I can hold the rest of the branches locally until we get it ironed out; once that topic makes it through to 'next' then I can send the rest again. What do you think? > On this particular issue, I actually do not have a preference. As > long as the topic has a coherent position/stance, any one of > > (a) we do as much i18n as possible to help end-users, or > > (b) we stay away from i18n to ensure the reports are machine > readable, or > > (c) somewhere in between with a clear criterion where you are > drawing the line (e.g. "the introductory text is what we want > the end-user to read, so it is i18ned, but the report about > their environment are primarily for our use and we avoid > localizing so that we can process mechanically"), > > is fine. The important point is that we choose what we do with a > solid guiding principle behind the decision. > > In practice, every string in bugreport.c you have control over the > use (or non-use) of _() around it, but codepaths that you call from > existing parts of the system are likely to have their messages > localized if they are meant for Porcelain use. So from that point > of view, (a) would be easier to arrange than (b), I suspect. Hm. Sounds convincing enough to me. - Emily
