If that is true, what would happen in the case where we want to make a new major release available? Suppose we have project in 1.x and now as a upstream we release 2.0. Would such a change still be covered by this? How would somebody trying to rebuild all packages handle these changes? If we submit a package update, the bigtop source release will only have the spec files/debian directory from the time that a bigtop release was made. Does that still work with the apache rules?
- André On Mon, May 11, 2015 at 3:52 PM, jay vyas <[email protected]> wrote: > i think -- that -- since bigtop RPM/DEB packages ARE NOT bound by the ASF > guidelines, they are just binary convenience artifacts.... we probably dont > have much to worry about :) > > when this happens id suggest : create a jira, folks will gladly help you > to get your latest binaries published so that people can use the latest > cascading bits from bigtop yum repos . > > just my thoughts, i assume this is correct though. > > > On Mon, May 11, 2015 at 7:19 AM, Andre Kelpe <[email protected]> > wrote: > > > Hi, > > > > the last couple of days I have been investigating the Cascading > integration > > for Bigtop. I have navigated the project and created RPM files for two of > > our projects. Since we are outside of the ASF, things tend to be a bit > > different, but I got it to work. I am currently doing the same for the > > debian packages, which should not take too much time. > > > > Now to my actual questions: Bigtop supports a number of distributions and > > has CI infrastructure to build the packages. I am wondering how we as the > > Cascading community can work with that infrastructure for better > > integration, or if we have to replicate all of it. Let me know, what > could > > work best. I'd love to test and build all packages in an easy way, but > > going through JIRA with a commiter reviewing and committing it looks > like a > > pretty heavy process. OTOH if I replicate the infrastructure I will end > up > > having to catch up with all infrastructure changes all the time. > > > > I am unsure what your way of maintaining things is, once a Bigtop release > > is made. I guess you are not targeting a rolling release, but rather a > > stable release to be used for a longer time. How do bugfix releases for > > packages go in? Suppose we have a Cascading tool version x.y in Bigtop > a.b. > > and we make a critical bugfix release x.z, which we want to distribute to > > Bigtop users as well. Would that then require a complete Bigtop release > > with voting and all that or do you envision a faster track like linux > > distros, which update packages for a given release. > > > > Thanks for your answers! > > > > - André > > > > -- > > André Kelpe > > [email protected] > > http://concurrentinc.com > > > > > > -- > jay vyas > -- André Kelpe [email protected] http://concurrentinc.com
