On Wed, Nov 4, 2015 at 1:25 PM, Ken Dreyer <kdre...@redhat.com> wrote: > On Tue, Nov 3, 2015 at 4:22 AM, Sage Weil <sw...@redhat.com> wrote: >> On Tue, 3 Nov 2015, Nathan Cutler wrote: >>> IMHO the first step should be to get rid of the evil submodule. Arguably >>> the most direct path leading to this goal is to simply package up the >>> downstream civetweb (i.e. 1.6 plus all the downstream patches) for all >>> the supported distros. The resulting package would be Ceph-specific, >>> obviously, so it could be called "civetweb-ceph". >>> >>> Like Ken says, the upstreaming effort can continue in parallel. >> >> I'm not sure I agree. As long as everything is not upstream and we are >> running a fork, what is the value of having it in a separate package? >> That just means all of the effort of managing the package dependency and >> making sure it is in all of the appropriate distros (and similar pain for >> those building manually) without any of the benefits (upstream bug fixes, >> etc.). > > I think there's value in getting the packaging bits ready ahead of > time and letting those "bake in" in Fedora/Ubuntu/Debian/SUSE while we > continue to merge Ceph's civetweb changes to Civetweb upstream. > > Now that Civetweb with RGW is mainstream, I'm looking forward to > eventually using a pre-built civetweb package that can shave time off > our Ceph Gitbuilder/Jenkins runs :)
Oh, I just re-read this, and Nathan's proposing to package up "civetweb-ceph" as a fork... I'm not sure that's worth it (at least, speaking for packaging in Fedora). When I was talking about a "parallel effort", what I meant is that we'd get vanilla civetweb upstream into the distros, and we'd also continue to bundle civetweb in Ceph, until we can reliably use the upstream Civetweb package. - Ken -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
