(Continuing discussion on list instead of in arbitrary Jira) My original concern was that pushing your feature branches to asf git adds much noise to mailing lists and should be used sparingly for issues where we expect co-authoring.
> What we need is avoid notifications for commits to all the JIRA branches +1 if you can pull that off, that would help. But if we start pushing hundreds of jira branches it clutters things up, so we should remember to delete those branches after merge. > Using a feature branch is good for collaboration. Every committer > automatically had access to your branch That should also be possible on github PRs now (there’s a checkbox), but have not tried it yet. Jan Høydahl > 3. aug. 2019 kl. 01:13 skrev Noble Paul (JIRA) <[email protected]>: > > > [ > https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899269#comment-16899269 > ] > > Noble Paul commented on SOLR-13677: > ----------------------------------- > > What we need is avoid notifications for commits to all the JIRA branches . > Using a feature branch is good for collaboration. Every committer > automatically had access to your branch > >> All Metrics Gauges should be unregistered by the objects that registered them >> ----------------------------------------------------------------------------- >> >> Key: SOLR-13677 >> URL: https://issues.apache.org/jira/browse/SOLR-13677 >> Project: Solr >> Issue Type: Improvement >> Security Level: Public(Default Security Level. Issues are Public) >> Components: metrics >> Reporter: Noble Paul >> Priority: Major >> Time Spent: 10m >> Remaining Estimate: 0h >> >> The life cycle of Metrics producers are managed by the core (mostly). So, if >> the lifecycle of the object is different from that of the core itself, these >> objects will never be unregistered from the metrics registry. This will lead >> to memory leaks > > > > -- > This message was sent by Atlassian JIRA > (v7.6.14#76016)
