Harsha, Yes, my bad. Main intention was the notice that we're getting lost with several ideas. Discussion would be better to take place on origin threads.
Btw, I think squashing commits and maintaining CHANGELOG are strongly related on so they can be discussed together. I'll leave this to origin thread, too. I'll move opinions which Abhishek and Aaron gave to origin threads, too. Thanks, Jungtaek Lim (HeartSaVioR) 2016년 5월 14일 (토) 오후 12:58, Harsha <[email protected]>님이 작성: > Jungtaek, > If we didn't get any conclusion. Lets continue discussion on > the same thread. You can just reply to that. > Lets not merge all discussions into major thread where we can't even > track which subject we are discussing. > > Thanks, > Harsha > > On Fri, May 13, 2016, at 08:56 PM, Harsha wrote: > > 3* - I also get one extra email from [email protected] if I am > > participating in a pull request from [email protected]. It will > > be > > great to avoid that as well. By the way, removing notifications from > > Github > > means that PRs with no JIRA id might go unnoticed for long time. > > > > -1. notifications important for everyone else. if you are getting > > spammed by this create a mail rule. > > > > -Harsha > > > > On Fri, May 13, 2016, at 07:47 AM, Aaron.Dossett wrote: > > > I like the idea of squashing to a single commit and tagging that commit > > > and PR with the JIRA ID. Agree that limiting duplicate emails would be > > > good. > > > > > > On 5/13/16, 6:17 AM, "Abhishek Agarwal" <[email protected]> wrote: > > > > > > >1* - Squashing commits is more of a guideline. Committers, > specifically, > > > >should ensure that the patches are squashed or volunteer to do that as > > > >merging otherwise :) These guidelines along with 'how to git squash' > can > > > >be > > > >added to > http://storm.apache.org/contribute/Contributing-to-Storm.html. > > > > > > > >The above page says that for minor changes, there is no need to > create a > > > >JIRA. The definition of what is minor, is of course vague. In my > > > >experience, there were very few changes which were made without a > > > >corresponding JIRA so JIRA creation might as well be made mandatory. > If > > > >each commit is tagged with a JIRA id, it becomes easier to track that > > > >change. I have also seen cases where there were multiple commits under > > > >single JIRA but none of them were tagged with JIRA id. > > > > > > > >3* - I also get one extra email from [email protected] if I am > > > >participating in a pull request from [email protected]. It > will be > > > >great to avoid that as well. By the way, removing notifications from > > > >Github > > > >means that PRs with no JIRA id might go unnoticed for long time. > > > > > > > > > > > >On Fri, May 13, 2016 at 3:43 PM, Jungtaek Lim <[email protected]> > wrote: > > > > > > > >> Hi devs, > > > >> > > > >> I just feel we are following a bit hard way to maintain project. > Some > > > >>of us > > > >> (including me) pointed out earlier by initiating discussion thread, > but > > > >>it > > > >> was forgotten. I found some major items which are worth to discuss. > > > >> > > > >> - [DISCUSSION] Squashing commits before merging in > > > >> < > > > >> > > > >> > https://mail-archives.apache.org/mod_mbox/storm-dev/201505.mbox/%3CetPan. > > > >>[email protected]%3E > > > >> > > > > >> - [DISCUSSION] More convenient way to maintain committer / > contributor > > > >>list > > > >> and changelogs > > > >> < > > > >> > > > >> > https://mail-archives.apache.org/mod_mbox/storm-dev/201512.mbox/%3CCAF510 > > > >>[email protected]%3E > > > >> > > > > >> - does anyone else hate the verbose logging of all PR comments in > the > > > >>Storm > > > >> JIRAs? > > > >> < > > > >> > > > >> > https://mail-archives.apache.org/mod_mbox/storm-dev/201509.mbox/%3CCAO5KY > > > >>[email protected]%3E > > > >> > > > > >> > > > >> I hope that we can come up with final result. > > > >> > > > >> Let me give my opinion about those three items. > > > >> > > > >> *1. Squashing commits before merging in* > > > >> > > > >> I believe learning from other projects is the best way to evaluate > our > > > >> process and change if others are better. > > > >> > > > >> Let's take a look at commits page on some projects - > > > >> Hadoop <https://github.com/apache/hadoop/commits/trunk>, HBase > > > >> <https://github.com/apache/hbase/commits/master>, Kafka > > > >> <https://github.com/apache/kafka/commits/trunk>, Spark > > > >> <https://github.com/apache/spark/commits/master>, Flink > > > >> <https://github.com/apache/flink/commits/master>, Calcite > > > >> <https://github.com/apache/calcite/commits/master>, Zeppelin > (incubator) > > > >> <https://github.com/apache/incubator-zeppelin/commits/master>. > > > >> > > > >> You may notice that most of commit logs are started to JIRA ID > (which is > > > >> what some of us are done implicitly), and there's one commit per one > > > >>issue, > > > >> which may be squashed. (there seems to be some exceptions but seems > > > >>minor) > > > >> Moreover, recently Github includes this feature to UI and many > projects > > > >>are > > > >> using it. > > > >> > > > >> I'm in favor of squashing commits, but some contributors could have > hard > > > >> time to squash by themselves so I think it would be better to > squash in > > > >> merging step. (committers are in responsible to squash, which > should be > > > >> easier with script tool) > > > >> > > > >> *2. More convenient way to maintain committer / contributor list and > > > >> changelogs* > > > >> > > > >> For maintaining committer, I don't know how to automatically collect > > > >> committers / PMCs, but I think managing it from somewhere by hand is > > > >> completely no problem unless we invite tens of persons in 1 day. ;) > > > >> I just want to let this handled from wiki or some other place other > than > > > >> code repo so that committers/PMCs could modify it easier. > > > >> > > > >> For maintaining contributor, we can extract code contributors from > > > >> one-liner command. > > > >> > > > >> git log --pretty=format:'%an' | sort -u > > > >> (borrowed from OpenTSDB/AsyncBase > > > >> <https://github.com/OpenTSDB/asynchbase/blob/master/THANKS>) > > > >> > > > >> We may even extract this from JIRA issue. (though I don't know how > to do > > > >> it) > > > >> I even think mentioning contributors for each release news is more > > > >> honorable compared to just listing up with README forever. There's > also > > > >> contributors tab so we could even get rid of it. > > > >> > > > >> For changelog, projects what I was referred are not having > CHANGELOG in > > > >> their repository. It's really hard to let CHANGELOGs in all > branches in > > > >> sync while we often port back. > > > >> Please no more maintaining this by hand. 'Commits' page could be our > > > >> CHANGELOG when we arrange commit logs better. 'Who merged that PR > 'also > > > >>be > > > >> represented when we squash commits in merging process. > > > >> > > > >> *3. verbose logging : github PR activity goes to JIRA comment and > > > >>trigger > > > >> new mail* > > > >> > > > >> I'm clicking two mails for one new comment from github, which is > really > > > >>bad > > > >> for me. I strongly agree with Erik, and linking github PR with JIRA > is > > > >> enough for me. > > > >> > > > >> Sorry and thanks for reading really long mail. Please let me know > if you > > > >> think it would be better to discuss them separated (each mail > thread) so > > > >> that I can post them. > > > >> > > > >> Thanks, > > > >> Jungtaek Lim (HeartSaVioR) > > > >> > > > > > > > > > > > > > > > >-- > > > >Regards, > > > >Abhishek Agarwal > > > >
