On Tue, Aug 09, 2016 at 05:58PM, Pete Vander Giessen wrote: > Hi All, > > Would it make sense to to make a branch that lived in our fork of the > bigtop project (github.com/juju-solutions/bigtop)? That way, we charmers > all have commit access, and can grant commit access to those working on a > charm. We can then open a sort of mega PR against the Apache bigtop repo, > and you can review and merge that when you're ready.
Having a branch on your own never was prohibited nor it should be :) The way people choose to collaborate on the GH isn't really a concern here, but the way we can efficiently get the changes into the project master is. I don't think a mega PR will help with the issue much, as the review of mega-anything is a mega-PITA. This is the reason most of the projects are trying to make commits narrowly focused and reasonable in size. > The issue that I see is coordinating upstream merges with downstream > additions. Are there points where you want us to freeze the branch while > you prepare to merge it? The coordination is a part of it. Another part is the addition of the charms which lead to discovery of various issues in the Puppet and elsewhere. Sometimes these fixes are intertwined with the charms and that's where the snug is: most of us don't have enough hands-on experience with Juju at this point to make an informed review and/or test the changes (as has been discussed earlier). This results in slowing down of the rate of the acceptance of the changes. Which isn't good for anybody. > Also, are you proposing that the branch contain just the charms themselves > -- the files in in bigtop-packages/src/charms -- or do you want us to > include puppet fixes and changes in the branch? I think that it might make > a lot of sense to keep all the directly charm related stuff in a branch, > but would strongly prefer to keep the puppet related fixes in their own, > per ticket, branches. That mega branch is going to get rebased frequently, > and I'd rather cut down the chances of conflicts and messiness to a minimum. Bigtop source code doesn't live in multiple repositories, so I don't see how we can fragment the code this way. In my practice, you'd have all the code on the branch, but people will be working just on the particular areas of the code as they see fit. Once there's a consensus that the branch is in a good shape it should be merged back to the master, It is normally done in one swift motion. No need to freeze anything as the granularity of the branches could vary - per feature, per fix, per mega-functionality, etc. Hope it makes sense. Cos
