[llvm-dev] [RFC] Helping release management

[Renato Golin via llvm-dev]

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