On May 7, 2012 11:57 AM, "Owen O'Malley" <omal...@apache.org> wrote: > > On Sat, May 5, 2012 at 2:13 AM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > > > Now (again IIUC) the interesting bit is whether it's better for BigTop > > to be repackaging and -distributing upstream components by itself, or > > if it would in fact be better for BigTop to simply provide something > > like "bigtop-x.y.rpm" and "bigtop-x.y.deb" packages that just declare > > dependencies to specific, integration-tested versions of upstream > > packages. > > It would be much better for Bigtop to work with the Apache dev > communities that already exist for each of the projects rather than > releasing incompatible artifacts.
As long as Bigtop is using published releases (rather than trunk, say), then it is not "incompatible". Downstream packagers are going to do all kinds of things with Apache packages. Just something to deal with. "Better" to work with, but not required. Hadoop can also pull, just like any other project finding good ideas in the wild and incorporating them back into their project. The IPMC and the mentors should be guiding Bigtop in the social aspect: respect other people and other projects. There aren't technical rules that are being skipped, that I'm aware of, but maybe some social patterns that could be improved. Side note: Apache Subversion is actually discussing *removing* our .rpm and .deb package specs. Downstream users all have different ones anyway, custom to their distro. Nobody really uses ours, so they are growing stale. Of course, Subversion is at a very mature point, relatively, and every distro carries it. We no longer need to "seed" these specs. But the point I'm trying to make is that distros are all going to have their own version. Upstream needs to accept that, and work accordingly. (if/when downstream starts applying (lots of) source patches, then problems arise... dunno if that is an issue here) > It creates a lot of confusion that > the Bigtop Hadoop rpms are labelled as "hadoop-*.rpm" and yet are > significantly different from the Hadoop rpms that are produced by the > Hadoop project. Even more troubling is that the Bigtop distro is > starting to change the interaction with the user to the projects. If the users prefer Bigtop RPMs, then maybe Hadoop has something to learn. But this isn't truly a problem. > > To do this, BigTop would need to work with the upstream projects to > > help them produce the appropriate deployment packages as a part of > > their normal release processes. And BigTop could also team up with > > Infrastructure to maintain the kind of repository structure and > > download service expected by deployment tools like yum and apt, a bit > > like what Maven projects have in https://repository.apache.org/. Concur. /dist is kind of a weird place for the supporting artifacts, as that feeds into the mirror system. We don't want to be a central single-source repository either, for bandwidth purposes. ... something for Bigtop to work on with Infra. Cheers, -g
