> Looks we had so much discussed here, Let's try to conclude. Can we've one > call on this and finalize this..?
Technical decisions shouldn't be done on other places than public mailing lists, as described in the "Open Communications" section of [1] and [2]. So we should conclude the discussion in this mailing list. (And with my poor English, I'm not so confident to catch up with your fluent talk ;) > FYI. Even looks bigtop used some where also.. Bigtop is ASF's trademark as you can see in the "Apache Bigtop® software" section of [3]. So it doesn't have the risk of trademark infringement. [1]: https://www.apache.org/theapacheway/index.html#what-makes-the-apache-way-so-hard-to-define [2]: https://www.apache.org/dev/pmc.html#mailing-list-naming-policy [3]: https://www.apache.org/foundation/marks/list/ Kengo Seki <sek...@apache.org> On Sun, Jul 10, 2022 at 4:11 AM Battula, Brahma Reddy <bbatt...@visa.com.invalid> wrote: > > Looks we had so much discussed here, Let's try to conclude. Can we've one > call on this and finalize this..? > > FYI. Even looks bigtop used some where[1] also.. > 1. https://en.wikipedia.org/wiki/Bigtop_(Microsoft_product) > > > On 08/07/22, 8:06 PM, "Kengo Seki" <sek...@apache.org> wrote: > > Thank you for your explanation, Brahma. > CRH (abbreviation of "CHINA REDOOP HYPERLOOP" [1]) is supposed to be a > trademark of Redoop, so they can name the script crh-select without > problem. > But regarding BDP for example, I can easily find products that have > the same name [2][3][4] as you already mentioned, so I'd like to > recommend bigtop-select for avoiding unnecessary trouble. > Or, a single and more general word just like conf-select may be less > troublesome than bdp. How about "stack-select", for example? > > [1]: > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.redoop.com%2F&data=05%7C01%7Cbbattula%40visa.com%7C5710428143074e43882708da60ef4387%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637928877994379337%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GGowKe08K0CoMwQsKMA4%2FIE5w%2FC6ouh0affpiusraaU%3D&reserved=0 > [2]: > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatumstudio.jp%2Fen%2Fbigdataplatform%2F&data=05%7C01%7Cbbattula%40visa.com%7C5710428143074e43882708da60ef4387%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637928877994379337%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tTQPVQs28P2n08b8qvsbRrwfG4xulzxaalu7XF1AFNE%3D&reserved=0 > [3]: > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.talend.com%2Fr%2Fen-US%2F8.0%2Fstudio-getting-started-guide-big-data-platform%2Fintroduction&data=05%7C01%7Cbbattula%40visa.com%7C5710428143074e43882708da60ef4387%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637928877994535472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RN38y2gBsrfxJL%2BA2rR5jh15RL7V%2BP0h8NT00X8YVLs%3D&reserved=0 > [4]: > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.harmony-alliance.eu%2Fbigdata-platform%2Fbig-data-platform&data=05%7C01%7Cbbattula%40visa.com%7C5710428143074e43882708da60ef4387%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637928877994535472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=M6HNTNAi4sWJLBmR%2FVlfumbtvhjUoYR7eYFhg%2FWg0Eo%3D&reserved=0 > > Kengo Seki <sek...@apache.org> > > On Fri, Jul 8, 2022 at 2:51 AM Battula, Brahma Reddy <bbatt...@visa.com> > wrote: > > > > >Do you mean that you're going to name the module (same as > "component" > > >in the Bigtop terminology, I think) bigtop-distro-select, > > >and still the script in question bdp-select? If so, is there any > > >reason that the script must be that name? > > >(No offence, I just want to understand your thoughts and its > > >background, and avoid the conflict or user's confusion with > existing > > >trademarks or products) > > > > Thanks @Kengo Seki for consolidating all the concerns. Name should > represent the stack which includes all the components hence planning to have > like bdp,bds...and this only one file like below[1] which has done redoop. > > > > > > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fredoop%2Fbigtop%2Ftree%2Fe5f9fe81773180159d291f18ec366ac8bfa4d6d2%2Fbigtop-packages%2Fsrc%2Fcommon%2Fambari-mpacks%2Fselector&data=05%7C01%7Cbbattula%40visa.com%7C5710428143074e43882708da60ef4387%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637928877994535472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vP3NafvMeQyhrpflbPHYtG7gpOzPli8%2FiPm1GxshA5g%3D&reserved=0 > > > > > > On 07/07/22, 6:07 AM, "Kengo Seki" <sek...@apache.org> wrote: > > > > The following concern Masatake mentioned before is an important > point, > > so I talked to Brahma for clarifying his intention on the ASF Slack > > yesterday. > > > > > Multiple versions of the same package (deb/rpm) can not be > installed at the same time. > > > IIRC, HDP uses convention in which the product version is part of > package name > > > for addressing this. > > > > > I don't like to bring the awkward package name convention to > Bigtop > > > at least by default. > > > > He's planning to adopt the same mitigation as HDP for now, but he > > doesn't intend to change the default package naming convention of > > Bigtop, > > but just add a new functionality to include an extra part into the > > package name for avoiding conflict, which is disabled by default. > > > > And Brahma, let me confirm about the following reply: > > > > > Sure, we can have module name like bigtop-distro-select. > > > > Do you mean that you're going to name the module (same as > "component" > > in the Bigtop terminology, I think) bigtop-distro-select, > > and still the script in question bdp-select? If so, is there any > > reason that the script must be that name? > > (No offence, I just want to understand your thoughts and its > > background, and avoid the conflict or user's confusion with existing > > trademarks or products) > > > > Kengo Seki <sek...@apache.org> > > > > On Thu, Jul 7, 2022 at 2:08 AM Battula, Brahma Reddy > > <bbatt...@visa.com.invalid> wrote: > > > > > > > The name of stack based no Bigtop should be Bigtop. > > > > If you can not accept the name like bigtop-*, the work > should done outside of Bigtop. > > > > I will cast -1 if someone submit a patch to add a module > with the name spoiling branding. > > > > > > Sure, we can have module name like bigtop-distro-select. > > > Initially we'll do this separate branch. > > > > > > > > > > > > On 06/07/22, 8:55 AM, "Masatake Iwasaki" > <iwasak...@oss.nttdata.co.jp> wrote: > > > > > > > I believe it's for project name. isn't it.? > > > > > > projects and products. > > > > > > > IMO, We need to create folders and refer stacknames so > ambari-select,bigtop-select wn't looks good. > > > > > > The name of stack based no Bigtop should be Bigtop. > > > If you can not accept the name like bigtop-*, the work should > done outside of Bigtop. > > > I will cast -1 if someone submit a patch to add a module with > the name spoiling branding. > > > > > > > > > On 2022/07/06 11:44, Battula, Brahma Reddy wrote: > > > > > > > > I believe it's for project name. isn't it.? > > > > > > > > > > > > On 06/07/22, 7:27 AM, "Masatake Iwasaki" > <iwasak...@oss.nttdata.co.jp> wrote: > > > > > > > > > But As we are not releasing as enterprise should be > fine I think. IMO, We need to create folders and refer stacknames so > ambari-select,bigtop-select wn't looks good. > > > > > > > > Not fine. > > > > We have a trademark policy. > > > > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Ffoundation%2Fmarks%2F&data=05%7C01%7Cbbattula%40visa.com%7C5710428143074e43882708da60ef4387%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637928877994535472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ry1C9%2F3yRgwDAfOxsYUxjAX2nufDkyvgi3pk6YD2y%2F4%3D&reserved=0 > > > > > > > > On 2022/07/06 10:37, Battula, Brahma Reddy wrote: > > > > >> Should we avoid unrecognized brand which may be > trademark of someone? > > > > >> ambari-select or bigtop-select should be enough. > > > > > > > > > > Not sure, where to confirm whether there is already > trademark. When I googled found so many. > > > > > But As we are not releasing as enterprise should be > fine I think. IMO, We need to create folders and refer stacknames so > ambari-select,bigtop-select wn't looks good. > > > > > May be you can refer the initial proposal [2] where > I mentioned some more names. (BDS-BigDataStack,OSS-OpenSourceSelect..) > > > > > > > > > > Finally thanks a bunch for long healthy discussions > on this. Mostly we all same page now. > > > > > > > > > > 1. > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fsearch%3Fq%3Dbdp%26safe%3Dactive%26sxsrf%3DALiCzsaQDcQS0gb8KbAMfjadXuG-jomxRQ%253A1657070844287%26ei%3D_OTEYsuWEYrD4-EPp4uKqAE%26ved%3D0ahUKEwjLhKr4jeP4AhWK4TgGHaeFAhUQ4dUDCA4%26uact%3D5%26oq%3Dbdp%26gs_lcp%3DCgdnd3Mtd2l6EAMyBAgjECcyBAgjECcyCggAELEDEIMBEEMyCwgAEIAEELEDEIMBMgsIABCABBCxAxCDATIRCC4QgAQQsQMQgwEQxwEQ0QMyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEOgcIABBHELADOgYIABAeEBY6CggAEB4QDxAWEAo6CggAEIAEEIcCEBQ6CwguEIAEEMcBEK8BOgcIABCABBAKOhYILhCABBCHAhCxAxCDARDHARDRAxAUSgQIQRgASgQIRhgAUKsHWNgRYLoWaAFwAXgAgAGoAYgBtAeSAQMwLjiYAQCgAQHIAQjAAQE%26sclient%3Dgws-wiz&data=05%7C01%7Cbbattula%40visa.com%7C5710428143074e43882708da60ef4387%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637928877994535472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=P6xNjfFVvSIo9ipokO%2Fshg6dOMojqxoPihFJD3vIOIQ%3D&reserved=0 > > > > > > > > > > 2. > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fm77lhzo0njr2dhoock5twtm0c19j2py8&data=05%7C01%7Cbbattula%40visa.com%7C5710428143074e43882708da60ef4387%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637928877994535472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zxWOo4vFt1YUkN4kFPOfWqcX2Tguus6MNRff5Rh8FH8%3D&reserved=0 > > > > > > > > > > > > > > > On 06/07/22, 4:01 AM, "Masatake Iwasaki" > <iwasak...@oss.nttdata.co.jp> wrote: > > > > > > > > > > > We have still not officially finalized the > new replacement name for > > > > > > hdp-select, it would likely be bdp-select > (bdp: BigData Platform). However, > > > > > > the purpose of bdp-select and conf-select > remains the same. > > > > > > > > > > Should we avoid unrecognized brand which may be > trademark of someone? > > > > > ambari-select or bigtop-select should be enough. > > > > > > > > > > On 2022/06/29 13:52, Viraj Jasani wrote: > > > > > > Hi Ambari/Bigtop dev, > > > > > > > > > > > > As per the new roadmap of Apache Ambari, we > would like to propose moving > > > > > > certain scripts (previously known as > hdp-select and conf-select) to Bigtop > > > > > > so that their rpm installation could be > managed independently. > > > > > > These scripts are a basic necessity in the > Ambari framework for the > > > > > > installation of various Bigdata packages. The > only major changes they would > > > > > > receive is when we onboard new services and > components to Ambari, else they > > > > > > usually do not receive updates. In the past, > we used to get hdp-select rpm > > > > > > downloaded and installed from HDP > repositories. > > > > > > > > > > > > We have still not officially finalized the > new replacement name for > > > > > > hdp-select, it would likely be bdp-select > (bdp: BigData Platform). However, > > > > > > the purpose of bdp-select and conf-select > remains the same. > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@ambari.apache.org > > > For additional commands, e-mail: dev-h...@ambari.apache.org > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@ambari.apache.org > > For additional commands, e-mail: dev-h...@ambari.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ambari.apache.org > For additional commands, e-mail: dev-h...@ambari.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ambari.apache.org For additional commands, e-mail: dev-h...@ambari.apache.org
