On 07/09/2015 12:15 AM, Etienne wrote: > Hello, > > I don't really know what you mean by "push to master" but I strongly > advise about it. > > Actually nobody should push to master :) Master should be stable and tagged. > > Yet, it's compatible with "everybody pushing", as long as they do that > in a separate branch. The best way to go would be to review code before > any merge, but it takes time. Without a solid team of reviewer, the > validation process can really be frustrating and carry away volunteers. > > the best way to go : > 1) Peter push on branch, make a pull request > 2) Validation team (at least 2 people) says go > 3) Merge to master + tagging (except for minor bug fixes) > > The only question is : can we organise ourselves to do so ? With our > daily works and lives... maybe not. "Not-so-perfect-but-working" is > better than "perfect-but-can't-do". > > Cheers > > Tumulte > > P.S. : hello folks, I'm tumulte. Python, PHP front-end programmer. > Skilled enough in Python, PHP, JS. Sucks at software architecture. > Pretty aware of solid QA process. Killer good at CSS/HTML5. Not too bad > with design and UX. >
Thanks, Tumulte. We could certainly use CSS / HTML5 help; consider discussing on the design list how to work with Robert (mray) to actually translate his designs (and finalize them) into working HTML… Anyway, the "push to master" here means *after* people have done work on branches and made merge requests, and review has happened, *who* has the ability to merge into master. That's what Bryan's talking about. Nobody should do work directly to master, i.e. rarely should anyone make commits directly to master, but who has the ability to *push* commits (once made on branches and reviewed in merge request) to the master? Seems you agree with Bryan about having a larger team that could do this. Cheers, Aaron > > On 09/07/15 05:45, Bryan Richter wrote: >> On Wed, Jul 08, 2015 at 08:32:53PM -0600, Peter Harpending wrote: >>> On Wed, Jul 08, 2015 at 05:41:46PM -0700, Bryan Richter wrote: >>>> I think it's important to spread the responsibility for updating >>>> the master branch. Right now only two of us can do so: wolftune >>>> and myself. This can be considered one extreme of the >>>> right-to-push spectrum, and it's one that is used by a lot of >>>> projects. The other extreme is to give write access to everyone >>>> who submits a merge request, which is actually used (and >>>> recommended) by some teams. >>> I don't really see anything wrong with the BDFL approach to things. >>> Could you maybe elaborate on what the potential problems are? >> Honestly, it's fine right now. Every large project, however, has at >> least a few people who spend 100% of their time merging other people's >> code. We can take our time, but I'd like to deal with it >> proactively. >> >>> It seems to me like the second approach (allowing push access to a >>> lot of people) would lead to endless politics and people stepping on >>> each others' toes. >> Could be. It depends. It's an interesting problem. I am somewhat >> inspired by following along with stack's development, which followed >> the "just give everyone push permission" model. That model made it a >> lot easier to pass responsibility on a particular issue to the people >> who were actively engaged with it. There was still oversight, of >> course, but there was also a lot of empowerment and parallelism. >> >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> https://lists.snowdrift.coop/mailman/listinfo/discuss > > > > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.snowdrift.coop/mailman/listinfo/discuss > -- Aaron Wolf co-founder, Snowdrift.coop music teacher, wolftune.com -- Aaron Wolf Snowdrift.coop <https://snowdrift.coop> _______________________________________________ Discuss mailing list [email protected] https://lists.snowdrift.coop/mailman/listinfo/discuss
