https://pantsbuild.org/ logo
Join Slack
Powered by
<@U01PZK60W2F> has a polly for you!
# development
s
@curved-television-6568 has a polly for you!
b
I'm pretty anti-PR-title. It take sup valuable space, and I think the commit log and changelog have two different audiences.
I'm for 1, and I'll say I hope we can use very short tags/labels so multiple backends wouldn't eat too much space. E.g. "JS" or "Py"
c
I hope that the common case is just one backend, and in case of many backends, we shouldn’t list all verbatim. The idea is that this should help cut through the noise, not add to it.
perhaps 
[3 backends] This changes some stuff for java based languages.
so we rely on the context provided by the text to reveal applicability then…
b
I was annoying and added another option: the import path a user uses to load a backend. If we’re synthesising it (not including it in every PR title), it seems like we should connect it back to how users interact with it.
c
I like that. Are you also saying you prefer option (2) over (1)?
(as from the style, not content, perspective, your suggestion is the same as 2)
b
Hmm. If we’re spelling out a full backend path as a back tick-quoted code block, yeah… but only very very weak preference
c
Ah, true, I agree if it’s a codeblock path, then 
:
feels more appropriate.
if we spell out backends.. we hardly need the labels, just look at changed paths (with some clever logic to locate the appropriate 
register.py
file to infer the backend)
will that become clearer, or are we better off using sub-headings and grouping changes per backend instead then?
that would also solve the issue with a change touching multiple backends, just include the change under each backend (i.e. multiple times)
b
Yeah, grouping changes per backend might be a good way to do! Can still use the category labels, but I imagine a user will generally want to first skim by backends that are relevant to them, and then look at the new-features/bug-fixes/documentation-improvements that apply to those backends, rather than looking at all new-features and skimming for which are relevant to them (and then the same for all bug-fixes).
c
Aha.. yea, I was imagining grouping per backend under each category, but of course, it may make more sense from a user perspective to have the categories under each backend..
Open in Slack
PreviousNext
Powered by