hi,
sajolida (2020-03-24):
> intrigeri:
>>> D. sajolida uses it when writing release notes but it's insufficient
>>> and he could probably do as good with Redmine only, with some
>>> caveats (might be a bit slower, might need more clarification from
>>> release managers)
>>
>> I understand you currently need both the changelog and Redmine because
>> your need is a mix of "why" and "how": in many cases the high-level
>> overview is enough, but in many cases you need to dive deeper to
>> understand how it impacts users.
>>
>> I believe the design proposed above would solve most of the "might
>> need more clarification from release managers" problem: you would have
>> the high-level info handy, with the possibility to directly access the
>> details that are missing in Redmine.
>>
>> What do you think?
>
> If I understand correctly, your proposal would give me the same
> information than the current changelog plus easier access to commits.
By and large, yes.
One thing that would change is that you would get raw data from Git +
GitLab issues/MRs, without the rephrasing step currently done by the
RM. I don't know how much this rephrasing work currently impacts your
work: I guess it depends primarily on the target audience the RM has
in mind, and on their tech writing skills.
Personally I'd rather see us put this "express clearly what we're
doing and why" effort into issue/MR titles and commit messages than on
the RM-at-release-time's shoulders.
> It seems to me that it will not make my work harder but will actually
> relax the timing between RM and me by allowing me to fetch this
> information earlier during the release process.
I think so too.
> Did I understand correctly?
I think so.
>> If this idea seems like a good starting point, we could do a MVP (e.g.
>> pasting the output as-is to debian/changelog, no HTML output, no
>> links), try it out for a couple releases, and iterate from there.
>>
>> For completeness, there's another idea floating around: build the
>> changelog from changes files provided by the merged branches (#8689).
>> The crux of this idea is to do the writing work at MR time, instead of
>> at release time, which I think is a good move in principle. The way
>> I see it, if MR titles are not sufficient and we want to write more,
>> GitLab offers us a better way to do that, than snippets included in
>> Git branches: we can do the writing in the MR summary (possibly in
>> a dedicated section with a standard name), and the aforementioned
>> program could include this information in the output, if desired.
>
> I think that we should try your first proposal, which has the benefit of
> not adding more tiny steps and "bureaucracy" while writing a branch.
Fully agreed. This other idea can be part of another iteration,
should we identify the need for it.
