Paul,
On 6/27/2016 8:22 AM, Paul Jakma wrote: > [any 'you' in the below may be general case than you specifically] Thanks -- glad to see you're not singling me out ;-) It would be good to hear from others too (BTW there were a slew of folks who fully participated in the last call -- and I wasn't one as I could only stay for ~20 minutes) --I don't think I'm the only one that cares about this -- if I am, I'll shut up and leave the list in peace. But perhaps it's because I have less "skin in the game" as I'm not, and don't expect to be, a candidate for Maintainer. > On Mon, 27 Jun 2016, Lou Berger wrote: > >>> In terms of specific development processes, things have evolved and >>> should continue to evolve. >> Why is this recent discussion anything than an evolution of the >> process? > If it's meant to be evolution, show me the evolutionary path? Give me a > "diff" from the current processes to what is being proposed? Again, if there was a document to diff against, we could do this -- but there isn't one! To (hopefully help) I've added the text from https://lists.quagga.net/pipermail/quagga-dev/2016-February/014883.html to the strawman process and maintainers doc to help move this along. > Just the fact one must have a Google account to participate in this > suggests this is far from an evolution. This is incorrect - all one needs is a browser. To demonstrate, I made the above changes without using any google account. > >> I accept that there may not be as much understand and context of >> quagga's history as think there should be. But if those that have the >> history or are not participating in the discussion , that history will >> be missed. While this isn't preferred, we can't compel people to >> participate. > That's a 2-way street. > >> And it has seemed to have left you somewhat abandoned by the other >> "maintainers". > Look, it really gives me _no_ joy to make other people unhappy. > Honestly. I _want_ you to be happy, and if you want a project where: > > - Decisions are made by Google Hangouts at a time that suits US TZ The last text I saw said that decisions are reviewed/confirmed on list. > - Contributors can game (consciously or not) things by simply ignoring > comments for nearly 2 years, then rally others to vote in their > changes en bloc with talk about how the development process is broken, > _failing to mention_ how they helped break it. I agree this is wrong. > - Any old crap goes into master, just if whatever random 'Acks' > (completely immune to gaming is that!), and anyone who might have > views just happens to have taken even a brief holiday (cause, > holidays, who needs those). I'm not sure how to deal with this -- if a patch is updated and resubmitted it's discussed by those participating. Personally I like a model of 5+ maintainers and one maintainer ack is required for inclusion in mainline. (Note I say mainline, which may or may not differ from master.) > [the goal of reducing rebases is a good one, and fast cycles and > auto-collated proposed trees would help with that, but some of what > I've read so far is just "I want magic ponies!" in that regard] > > Then _please_ go set up that project. I'm _*begging*_ you. _How clear do > I have to be?_ > > Really, we'll _all_ be happier. > > Me, I'm going to: > > - Keep going through the last of the backlog, and sort it out. > > - Get the obvious stuff in ASAP, get nits pushed back ASAP to the > contributors so they can fix them, and derail stuff that needs wider > discussion (and sorry that just happens in distributed, decentralised > development sometimes - people just /happen/ to pull in different > directions, and it needs resolving; and the outcome can mean > significant reworking or even lost work; it happens, it happens to > me]. > > - Listen to people's comments on patches, including my own. I manage to > listen to other people's opinions on my patches - I might not like the > comments or agree with them. I don't see why this is a problem in a > well functioning community. > > - Find people willing to help constructively, who are willing to work to > consensus > > [that can mean going with majority opinion usually, but still > respecting people when there's something they really don't get on with > - e.g. like trying to push binding majority votes through, in order to > try get around comments on a series of their patches]. > > I'm more than willing to share Quagga with others. The people involved - > including in maintainer/governance/roles has generally increased while > I've been active. I think fixing the (lack of) maintainers issue ASAP would benefit us all. > All I ask is that we share on a mutually agreeable basis. > > If that seems unreasonable to anyone: > > The door is -------------> that way. As the domain owner and sole active maintainer you *can* kick the rest of us out! > I'll be sad, I'll wish them well, I'll hope to still be able to > collaborate with any such person in the future to some degree. However, > if we can't agree on that fundamental parameter then THIS IS NOT THE > PROJECT FOR SUCH PEOPLE, and it is _better for all of us_ if we go to > separate projects where we won't have to butt heads as much. I genuinely appreciate you engaging in this (IMO painful and unwanted) discussion. I really do believe that *everyone* is interested in the same thing: an inclusive, successful and vibrant quagga. Lou > regards, _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
