> > I think the natural progression of things is: > > stage 1. coded up, ready to share, not ready to build or test. > (might be being built out of stream, etc.) > early stage of collaboration, code review, etc. > [ I think people currently do this in various > different ways... ] > stage 2. ready to test / build / for a LIMITED set of > architectures (often just one.) > start of testing, don't need all architectures yet. > OR, failed on one architecture, want to just test *that* > architecture. [ We don't currently have a way to > do this, but I bet at least half of our builds could > work this way. ] > stage 3. ready to test / build / for ALL architectures. > about to commit fix to master / general distribution, > known to work on one architecture, but want to actually > do the thorough test on everything. > Stage 1 and 2 could be accomplished by started a build with kraken in IRC or by using the jenkins web UI (I'd recommend kraken though). By default we are currently building for xenial, trusty and centos7 on x86_64 for every push to ceph.git. That's look something like this: !ci build ceph-dev BRANCH=$branch You could also limit the distros: !ci build ceph-dev BRANCH=$branch DISTROS="xenial" It's stage 3 that I think we need the naming convention for. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
