+1 this idea On Fri, Oct 14, 2016 at 12:03 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > That seems okay for now. I think this might have gotten lost in the > earlier thread, though: > > Why don't we take this opportunity to create a ceph-ci.git and lock down > ceph.git? > > - ceph.git would contain only official branches (master, jewel, etc.) > - ceph-ci.git would have all the branches that need to get build for > ci purposes. > - ci would build everything in ceph.git and ceph-ci.git that doesn't have > a / in it > - if you don't want a branch built, don't push it to either one; push it > to your private clone (which is what you should be doing anyway!) > - restrict access to ceph.git to core developers (and trusted robots) > - grant access to ceph-ci to a broader set of developers (and robots) Except for this. Until/unless we find something requiring ceph.git access, we should lock down push access and only let code go in via Github PRs. Give ceph-ci access to everybody who's allowed in to sepia. Why open any gates preemptively if we don't need to? :) -Greg > > Right now, I think this requires that > > 1) shaman and/or jenkins build branches in both ceph.git and ceph-ci.git > > and then at our leisure, > > 2) we delete or move all non-official branches over to ceph-gi.git > (prefixing historical branches with old/ or similar), and > 3) we restrict ceph.git access. > > ? > sage > -- > 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 -- 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
