Thu, 8/18 @6pm (Cloudera's PA office)

• Participants:
  • Andre Arcilla
  • Andrew Bayer
  • Bruno Mahe
  • Peter Linnell
  • Roman Shaposhnik
  • Andrei Savu
  • Eli Collins
  • Alan Gates
• Minutes
  • Review-commit window
    • At this point it feels like Bigtop should be moving faster unless we run into problems,
      Alan suggested Pig's approach with 24 hours window and immediate commits after +1 unless
      changes are expected to be controversial.
  • Wrapping up for 0.1 release
    • We have code grant to clear all the licensing issues and it seems that we are not constrained
      by any known issues. Should be moving to produce an RC this week. It was noted that getting
      NOTICES right is extremely important. We might need to start a how-to-release wiki page modeled
      after Hadoop. One last bit of nice-to-have is documentation, especially for new users.
  • Nightly builds and artifacts
    • It would be useful to have nightly builds, nightly artifacts published to the repos and also
      testpatch-like ability. Currently we're constrained by the lack of necessary infrastructure
      @apache.org (we need at least one LTS Ubuntu VM and one CentOS VM, but in general there was
      no clear understanding of what platforms folks really care about). We need to explore some
      alternatives to apache's infra. Everybody in the room was fine to use infra @osuosl.org or
      even hosting it on EC2 go get us going, since donations of hardware to Apache foundation
      are not easy to accomplish. We need to clearly mark artifacts as "bigtop" and "incubating"
      since we essentially will be re-packaging releases of external Apache projects. It is also
      important to stick with released versions of these projects for now and not pursue trunks.
      There might be a need to rubber stamp infra decision with Apache legal if we end up going
      the way of suosl.org.
  • Stack validation
    • We have to establish a clear barrier of entry for new stuff that gets added to Bigtop.
      For now we have enough of existing package tests (albeit very basic ones) to validate
      that new packages can be installed/removed, etc. System tests are the biggest part of
      the value add, but there seems to be no interest at the level of individual projects as
      far as contribution of these tests is concerned. Perhaps we can leverage some of the
      existing testbases to be executed in the Bigtop context. That said, the bottom line seems
      to be – if we're serious about system testing members of Bigtop would have to contribute
      the bulk of work.
  • What to do for project bundling their own packaging code
    • Bigtop does NOT care about existing packaging infrastructure co-bundled with the project.
      There were no desire expressed about getting involved in on-going work on packaging
      infrastructure at the level of individual projects (e.g. Hadoop). "We will be building
      it and they will come". One question that wasn't clearly answered was – whether we
      should strive for packaging that integrates well with an OS or that caters more towards
      tar-ball like Java packaging. It was said that developers find packaging useful for
      quickly installing dependencies of the projects they are working on (e.g. HCatalog grabbing
      Hadoop RPMs).
  • Support for non-standard environments and components
    • Evaluate them one-by-one and establish a clear entrance criteria.