Hi Attila, On Fri, Oct 21, 2016 at 7:51 PM, Attila Simon <s...@cloudera.com> wrote:
> I have no strong opinion on whether we should have a jira or not (thus > the proposal of FLUME-PR70). I just "I found this habit very useful". > It seems kind of obtrusive to me to require committers to use this kind of pattern for a PR, to be honest, when the "Closes #70" thing is already there. Something that Gerrit does is it automatically adds something equivalent to: Reviewed-on: https://github.com/apache/flume/pull/70 to the bottom of the commit message. Maybe it would be useful to have people include this when committing PRs? However, it's particular enough that we should probably write a shell script to automate it so committers don't have to remember (or adapt one of the scripts used by the Spark project, maybe). Would that help with the problem you are facing? > I have tooling which depends on the commit titles are unique with high > probability. Most likely these tools can be upgraded with some extra > effort. > I think we should try to make it as easy as possible for downstream distributors to consume Flume. Still, I wonder if that tool you're using just sucks. Let me know how I can help you deal with the downstream stuff as I wonder if there aren't better ways of solving this problem. Maybe having jira for each change is an overkill for small changes. > What do you think what can be considered as a small change? eg the > ones for which the "how to contribute" guide doesn't require review > board? > In the past we have used JIRA to track patch submission, comments, and code reviews. GitHub Pull Requests encompass all of those things, so I don't see any reason to also use JIRA when submitting a PR, except when the PR fixes an issue or implements a feature that has a JIRA filed against it. I just don't see value to the project in requiring someone submitting a PR to additionally file a JIRA. I think JIRA is mostly useful as a way to track outstanding bugs and future work. I know that different people have different views on this issue and I don't want to impose my preferences on everyone working on Flume. I'd like to get your thoughts on the above and I'd also like to hear from others on the topic. I hope that we can standardize on a process that works well for everyone. Mike
