Github user harshach commented on the issue:
https://github.com/apache/storm/pull/1468
@knusbaum maintaining the script shouldn't push us from adopting a better
approach. It's another piece of code that we need to maintain just like entire
repo that we are maintaining right now.
Github user ptgoetz commented on the issue:
https://github.com/apache/storm/pull/1468
I'm okay with automating the merge process, just not the way it is
implemented here. Perhaps we shouldmove the discussion to the dev list.
---
If your project is set up for it, you can reply to
Github user ptgoetz commented on the issue:
https://github.com/apache/storm/pull/1468
I'll also point out that the "if other Apache projects do it, it is oaky"
stance is particularly dangerous. PMC members must understand ASF policy and
not rely on what other projects do. If what
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1468
I'm totally +1 to this approach, even though I think script should be
modified to Storm's project style.
Like I said to dev@ mailing list, I have been doing reviewing and merging
Github user ptgoetz commented on the issue:
https://github.com/apache/storm/pull/1468
I'll second @knusbaum's -1. Based on points I made earlier. This has the
potntial to automatically destroy code provenance, especially if more than one
contributor is involved in a pull request.
Github user knusbaum commented on the issue:
https://github.com/apache/storm/pull/1468
-1
I am generally opposed to this. Most PRs only have a small number of
commits and aren't a problem. For PRs with a large number of commits, it's
simple enough to ask the contributor to squash
Github user harshach commented on the issue:
https://github.com/apache/storm/pull/1468
@HeartSaVioR Thanks for documenting the script.
"Branch policy is not compatible with projects which uses this script. They
have branches per version but we just maintain version lines (major,
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1468
We may have to modify lots of part of script since...
- We don't have develop branch so all about develop branch should be
modified. Spark merge script also doesn't have handling with
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1468
Here's my understanding regarding this script.
> main()
* get latest branch (highest version) from github mirror
* it assumes that prefix of release branch is `release
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1468
I'll take a deep look and describe what this script actually does.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1468
I'd really like to go forward with automated tools for developers /
committers. What I've stated from dev@ mailing list, many projects already use
specific tools for merging, and the merge
Github user harshach commented on the issue:
https://github.com/apache/storm/pull/1468
@ptgoetz makes sense. We can make explicit case for not merging this PR if
the origin PR has commits from multiple authors and also can be integrated into
the tool to not to proceed if thats the
Github user ptgoetz commented on the issue:
https://github.com/apache/storm/pull/1468
@harshach The source of the file is referenced here:
https://github.com/apache/storm/pull/1468/files#diff-da45fe3972445a9f82ef768808dd8853R20
I'd like to get clearance that what this
Github user ptgoetz commented on the issue:
https://github.com/apache/storm/pull/1468
> We won't be able capture this in JIRA either. I am not sure how much of
this is important to have all the commits from each contributor for a single
JIRA which in itself is rare unless its a big
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1468
@harshach
I skimmed a bit, and guess determining fix version will not work since
branch names we use are different from Spark and Kafka and so on. We can still
input them by hand so there's
Github user harshach commented on the issue:
https://github.com/apache/storm/pull/1468
@HeartSaVioR already ran a simple tests. I like it because it allows us to
tag the reviewers and additional committers in the tag message and can be
picked onto other branches as well. It does work
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1468
@harshach Yeah, I don't know what things Kafka improve from Spark script so
I wanted to see the benefit if you know about it. As I commented earlier, just
adopting script doesn't work since we
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1468
Actually I was the one which claims separated credits from other project.
(https://github.com/OpenTSDB/asynchbase/pull/122)
But there was a strong reason to do so, and I think it's not
Github user harshach commented on the issue:
https://github.com/apache/storm/pull/1468
@HeartSaVioR Not aware of spark script. I am ok with using either one or
make this one work as we needed.
---
If your project is set up for it, you can reply to this email and have your
reply
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1468
1. What's the difference between Spark script vs Kafka script?
Spark script is origin of Kafka and Zeppelin, so unless there're specific
improvements, I think picking Spark script is more
Github user harshach commented on the issue:
https://github.com/apache/storm/pull/1468
"That means it removes authorship information. If we tag a squashed commit
as coming from multiple authors, we still wouldn't be able to differentiate
what code was contributed by the individual
Github user ptgoetz commented on the issue:
https://github.com/apache/storm/pull/1468
> It will ask for primary authors and the user who is merging this can
input more than one author at the time of merge.
That means it removes authorship information. If we tag a squashed
Github user ptgoetz commented on the issue:
https://github.com/apache/storm/pull/1468
I'm a little on the fence in terms of squashing the commits of others vs.
asking the contributor to do so. There are a lot of situations where spreading
out a big patch over multiple commits makes
Github user harshach commented on the issue:
https://github.com/apache/storm/pull/1468
commits can be preserved in contributors branch as they seem fit but it
doesn't help having them in the main repo. As a contributor they know what
those commits means but everyone else will doesn't
24 matches
Mail list logo
