[DISCUSS] Splitting the repos - ambari-metrics and ambari-logsearch
Hi devs, We had a brief discussion about the release management of Ambari w.r.t to the new work that is on-going with Mpacks and multi-services, amongst the developers working on the respective pieces. The main point of discussion was that although Metrics and LogSearch are sub-projects of Ambari, the release cadence of these sub-projects and Ambari core does not have to be tied together. Having an Infra Mpack will allow changes to these two modules to be published independently. The general consensus was to have separate repos for Ambari Metrics, Ambari Log Search and Ambari Infra which would mean we can build and version these modules separately and simplify the release process. I wanted to start a discuss/vote thread for this. I will follow this up with an Infra ticket to fork off the git repos for Ambari Metrics, Ambari LogSearch and Ambari Infra separate from the core codebase once we reach consensus. Note: These sub-projects do not have any compile-time or run-time dependencies on Ambari except logical dependency on Ambari stack advisor feature to configure the services correctly based on cluster resources. With the MPack effort this behavior will be delegated to individual stack services and the corresponding code will be housed in the service repos anyways. Ambari depends on Ambari Metrics at compile time on the ambari-metrics-common module which is already published to maven central and we would continue to do so if anything changes in the common library. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Here is my +1 to start. Best Regards, Sid
Re: Necessary to attach patch to Jira?
Hi Jason, There is no need to attach the patch to JIRA. The link to github PR should automatically be added to the JIRA if PR title contains the JIRA id in the format specified in docs - https://cwiki.apache.org/confluence/display/AMBARI/How+to+Contribute Thanks, Vivek Ratnavel On Thu, Jan 25, 2018 at 12:52 PM, Jason Golieb wrote: > Now that we are using pull requests, is it necessary to attach a patch to > a Jira if the Jira is linked to the PR? >
Necessary to attach patch to Jira?
Now that we are using pull requests, is it necessary to attach a patch to a Jira if the Jira is linked to the PR?
Re: Removal of old/defunct branches
Thank you to all of the responses for removal of the branches. I will proceed with them today. In addition to the below branches which seem old and abandoned, I also propose removing feature branches which have not seen a commit in more than a year (some in more than 2 years) ambari-websocket ambari-yarnapps audit_logging branch-embedded-views branch-rbac-sso branch-yarnapps-dev side-navigation-feature-branch Please let me know if there are any objections to removing the above branches as well. > On Jan 24, 2018, at 1:59 PM, Jonathan Hurley wrote: > > Hi committers and contributors, > > Ambari seems to have a bunch of branches that are dead and don't seem to > serve any useful purposes. These include: > > origin/AMBARI-12885 > origin/trunk > remote/branch-2.4 > remote/branch-2.5 > trunkj > trunkpwd > > They all seem to be either wrong (including the name of the origin or remote > in them) or misspellings. > > I am sure some of the other branches we have are dead too (like > feature-improved-rack-awareness-handling), but I thought we'd start with the > obvious ones. I'd like to see if the community is OK removing the above > mentioned branches. >
