[llvm-dev] [RFC] Helping release management

[Renato Golin via llvm-dev]

I'm with Hans that we should use bugzilla/phab better. It's far easier to
update bugs than format commit messages to conform to free text parseable
content.

I don't think we should restrict the commit message more than it is, nor
that we should reprimand / block / revert patches because of downstream
release processes. I also don't think we should change everyone's process
to fit to everyone's else's process. That doesn't scale.

I personally want to see all downstream releases participating on the
upstream release process, and all their release managers actively engaged
in the public process. Anything else will mean additional cost to us all,
and go against the open source nature of the project.

My tuppence.
Renato
On 3 May 2016 12:34 a.m., "Hans Wennborg via llvm-dev" <
llvm-dev at lists.llvm.org> wrote:

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
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160503/c4f7659a/attachment.html>