Nick is right that the ASF does not provide support in an explicit way (i.e. there are no pathways to get *prioritized* support via SLAs, etc.), but it is expected that apache projects provide support via mailing lists and answered by volunteers. Specifically, this is the crux of the "community over code" credo. That philosophical point aside, I think what Justin may be intending is "support" in the sense of how much do we fold Ubuntu into our testing cycle. It could be said that we tacitly "support" configurations which we test, beyond that caveat emptor. Which is to say that questions on the mailing lists for Metron on Centos will likely be answered whereas Metron on OpenBSD might be met with more skepticism or not answered.
I would argue that we start with Nick's very generous contribution without forcing developers to test their code against it. Eventually, when we have a full-dev that spins up ubuntu, I'd argue that we could consider folding it into our testing plans for an RC. Regarding whether it fits in a feature branch, I think that as long as each PR stands alone in providing value, we can avoid a feature branch. It might be worthwhile constructing a JIRA in apache to capture the follow-on tasks required to bring Ubuntu into a status where it's more prominent in our testing cycle. On Fri, Dec 15, 2017 at 10:45 AM, Nick Allen <n...@nickallen.org> wrote: > > The end goal is Ubuntu Ambari + Deb and full-dev-ubuntu right? > > That list sounds good to me. > > (Plus, some way of dealing with Justin's point about support.) > > > > On Fri, Dec 15, 2017 at 10:11 AM Otto Fowler <ottobackwa...@gmail.com> > wrote: > > > I’m ok if it is not. Suggesting because it is a series of prs. > > > > The end goal is Ubuntu Ambari + Deb and full-dev-ubuntu right? > > > > On December 15, 2017 at 10:03:23, Nick Allen (n...@nickallen.org) wrote: > > > > > This seems like a feature branch candidate. > > > > Personally, I don't see the need for a feature branch on this one. It > > won't involve big, architectural changes. The touch points are > > constrained. Everything that we currently have will continue to work as > it > > always had after each PR. If you feel strongly the other way, please > > provide your reasoning to help me understand. > > > > > > > > > > On Thu, Dec 14, 2017 at 6:28 PM, Otto Fowler <ottobackwa...@gmail.com> > > wrote: > > > >> This sounds awesome. The hortonworks article is getting older ever day. > >> This seems like a feature branch candidate. > >> > >> On December 14, 2017 at 18:22:33, Nick Allen (n...@nickallen.org) > wrote: > >> > >> I've done some work to get the MPack working on Ubuntu. I'd like to get > >> that work packaged up and contributed back to Apache. I think it would > be > >> genuinly useful to the community. > >> > >> Here is how I was thinking about tackling that through a series of PRs. > >> > >> 1. Create the DEBs necessary for installing on Ubuntu. See PR #868. > >> > >> 2. Submit 3 or 4 separate PRs that enhance the existing MPack so that it > >> works on both CentOS and Ubuntu. I honestly am not sure how many will > fall > >> out of the work that I've done, but I will try to chop it up logically > so > >> that it is easy to review. > >> > >> 3. Create a "Full Dev" equivalent for Ubuntu so that we can see the > >> end-to-end install work for Ubuntu in an automated fashion. > >> > >> > >> ** I do not expect developers to test their PRs on both CentOS and > Ubuntu. > >> I think the existing CentOS "Full Dev" should remain as the gold > standard > >> that we test PRs against. No changes there. > >> > >> Let me know if you have feedback or thoughts on this. > >> > >> Chao > >> > >> > > >
