llvm dev - May 2016 - [RFC] Helping release management

On 17 May 2016 at 21:54, Quentin Colombet <qcolombet at apple.com>
wrote:
> I am fine keeping PR#, I just find it convenient for them to be clickable
in mail.
> Also, I do not see any problem supporting two styles. People have their
preferences and the tools should adapt, not the other way around.
The current policy already allows you to use URLs instead of just the
bug numbers, as long as PR# is on there somewhere.

I certainly won't object to that. :)

> As far as I can tell, what I explicitly called out is already interesting
information that people more or less put.
Indeed. But trying to codify makes people less appealed to use it. Our
approach to policies have been always "codify the least, cover the
most".

> The idea is to have a tool (hook) doing the boring things on top of our
current practices. If this is not the case, then, yes, this is not going to
work.
The tool is orthogonal, and there has been some pretty good ideas on
this thread already that can work without any change to the policy.

> I tend to believe that if that makes people's job easier (or equally
painful) they would use it.
Long time ago I realised that what makes my job easier is rarely what
makes other people's job easier, by being encouraged to use the tools
that other people built. :)

Having the tools is great, encouraging their usage is ok, encoding it
into a vast community's working, not so much.

> This use case actually goes beyond the conveniency I wanted to provide
(i.e., not having to file a PR if this is a simple fix).
> Indeed, if we need more than one commit to fix the problem I was thinking
that we may want to create a PR first anyway.
> Anyhow, if we decide to support that use case, we could choose to leave the
PR open or have different keyword and stuff. Though, it seems to become
complicated.
> Like we discuss with Jim, I want the path of less resistance to do the
right thing and adding a bunch of keywords seem against that.
The current policy is aligned with you adding as much as you think
it's necessary to the commit message. That includes metadata for your
bug-creating script.

Personally, I'd prefer that you have the script running on your local
tree, and changing your commit messages *before* commit. Once the
script is stable and more people are using it, it could even migrate
to an official SVN hook.

But I still strongly advise against encoding that on the policy.

> Why is this different from the current process of filing a PR or fixing a
bug?
Because when filling a bug manually we actually have to think about
those things. I don't think there's value in creating dozens of bugs
under  "newbugs" that only you see. The additional metadata can make a
back-port bug-scraping script much more efficient.

> We could use the default component or take advantage of the TAG in the
title line.
People use different tags, sometimes not at all. Also, Bugzilla's
selection of components doesn't really reflect current distribution,
but that's a separate issue. :)

>> Which fix version?
>
> I did not get that.
If we want to back-port stuff, we should say it somewhere (preferably
metadata, not free text) where the fix should apply to.

> The commit hook is about documenting that a commit is a fix and the commit
message is about answering all the interesting questions. But I do not plan to
enforce any rules on them. People will need to use their own judgment to know
what is best for the project.
> If that means reminding contributors on their commit message what is
helpful to release managers when fixing a bug, I do not see the harm.
I foresee confusion. An SVN hook can create bugs in the wrong place,
with the wrong content and be actually more trouble than it's worth.

If this is an optional feature, it should not be an SVN hook that will
run on *every* commit.

The commit message policy are things that we really encourage everyone
to do every time, where relevant. If we include optional directives,
people will take it even less serious than they do now. :(


> Yes, those are required answers, but I disagree that marking the bug is
useless.
I just meant "creating an empty bug, without any info or metadata" is
useless. Or, as useful as saying "fixes bug" on the commit message,
but noisier.

> Well, if I need to change my workflow (e.g., using a different tool than
git for the commit) for llvm compared to the other project I work on, that path
is already dead for me. If we do not achieve transparency, we shouldn’t work
into it.
Well, it's hard to get everyone working in the same way on different
projects. I surely don't want to force the kernel's way of working
into LLVM just because I may work on both. And if I have to use two
sets of tools for both of them, than that's a cost I alone should be
prepared to pay for.

> Sorry for nitpicking your comment, but this is *not* a policy, this is a
recommendation. We will not revert commit or whatever because of that. I am
trying to instil what information is required by release managers to help them
do their job. Contributors already know that information and most likely already
put it in the commit message.
I replied to this above: it *is* a policy, not a hard rule, not a
guideline. We seriously recommend those practices, and sometimes frown
upon if you don't follow it, but we won't slap your hand or revert
your commit.

As it stands, that policy is a the right strength level. I don't want
it being more strict, not less. From the discussions on the policies
(including the commit message), most people in the community don't
want that either.

>> People out of the system will never care. People in the system that
>> get things slightly wrong will be very annoyed.
>
> Why?
I said above: people trying to do one thing and the script
interpreting as another will create more extra work for those that
wanted none.

The way you describe your tool seems like a very personal way of
working. I imagine you find it very helpful (we have our own set of
scripts at Linaro), but making a personal style into the policy & an
SVN hook is pushing a bit too far, IMHO.

cheers,
--renato

Hi Renato,
> 
> 
>>> People out of the system will never care. People in the system that
>>> get things slightly wrong will be very annoyed.
>> 
>> Why?
> 
> I said above: people trying to do one thing and the script
> interpreting as another will create more extra work for those that
> wanted none.
> 
> The way you describe your tool seems like a very personal way of
> working. I imagine you find it very helpful (we have our own set of
> scripts at Linaro), but making a personal style into the policy & an
> SVN hook is pushing a bit too far, IMHO.
Indeed, if this is how it is perceived, I won’t push it forward. I was trying to
provide a mechanism for Jim’s proposal of filing a PR for every fixes that was
not too heavy on the user.

Anyhow, I have to read the thread again to see how the hooks ideas were pushed
and see what is actually achievable.

Just to make sure I got essence of what you said, the patch I suggested for the
commit message policy is not good to you, right?

Cheers,
-Quentin 
> 
> cheers,
> --renato

On 18 May 2016 at 17:32, Quentin Colombet <qcolombet at apple.com>
wrote:
> Just to make sure I got essence of what you said, the patch I suggested for
the commit message policy is not good to you, right?
Yeah. I don't speak for the community, of course, but I personally
don't think we should encode more than we have, since you're already
free to add what you think is necessary to your commit messages.

Having said that, Linaro is experimenting with command line tools to
automatically create Jira bugs, and I'll suggest a mode where you
provide a branch and the tool creates one bug and add the messages of
all commits beyond master as comments. The rest of the meta-data,
however, has to come from command line options or configuration files,
as we don't want to leak our own patterns to all the FOSS projects we
contribute to. :)

cheers,
--renato