[llvm-dev] [RFC] Helping release management

Hans Wennborg via llvm-dev llvm-dev at lists.llvm.org
Mon May 2 16:33:54 PDT 2016


On Mon, May 2, 2016 at 4:03 PM, Quentin Colombet <qcolombet at apple.com> wrote:
>>> 1. Use [Fix] for commit related to bug fixes.
>>
>> I think we're mostly pretty good at referencing PR's in commit
>> messages already. That's also easy to grep for, so maybe that's good
>> enough?
>
> When a PR is available, that is certainly good enough.
> I do not want to make filling a PR mandatory for each bug we fix though. Having a PR is great, but I can see why we may not want to create one each time we fix something.

At least for me, if I run into a problem that takes some work to
reduce, debug, etc., I find filing a PR worth it, if nothing else to
keep track of the work for my own sake.

For bugs which one just stumbles across in the code and which can be
fixed with a quick patch, I agree that filing a bug doesn't make
sense.

I suspect the kind of fixes that are important for a release branch
are mostly of the former kind, though.

>>> 2. Add a description of the problem in the commit message to help answer the following questions:
>>> - What is fixed?
>>> - Which targets are impacted?
>>> - What is required to trigger the bug? (I.e., how often the end users may encounter it.)
>>> - When was the bug introduced?
>>
>> This sounds like the kind of information that should be in a great
>> commit message anyways.
>>
>> But I'm also thinking that maybe we could be better at using our bug
>> tracker? Whether a bug is a feature request, something that was always
>> broken, or a regression (and from what version), sounds like a perfect
>> fit for a bug tracker. Someone doing a release could then query the
>> Bugzilla to see e.g. what regression bugs were fixed in a certain time
>> span.
>
> Sounds great to me.
>
> Would that kind of workflow ease your job for tracking what should be pulled into the release branch after you’ve branched?
> What would be the best workflow for such task for you?

My ideal workflow for discovering commits suitable for merging is when
folks cc me on the commit message, because then I don't have to do any
work :-)

But besides that, I do rely on the bug tracker quite a lot. It's hard
to keep up with the commits list, but keeping up with filed and fixed
bugs is doable, and a good source of information. It's usually easy to
tell from a PR whether it's serious or not, and most people are good
about indicating what version they used, if it started failing
recently, what target they're using, etc.

Cheers,
Hans


More information about the llvm-dev mailing list