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 >
