Hello, Alex On Mon, May 16, 2016 at 10:17 AM, Alex Rukletsov <[email protected]> wrote: > Cong, > > it's strange that you project your frustrations—which are understandable > and may have good reasons—on the project as a whole. There are reasons why > things are done in the way they are done; our primary goal is quality, we'd > rather have a few well implemented features rather than a bunch of > half-finished efforts that are hard to maintain. This means sometimes we > can't distract and invest time into some great but not yet prioritized > features.
Sure, no one asks you to accept everything proposed, you always have the right to decline code you don't like, and this is clearly not what I am complaining. What I keep complaining is how fast you response to a review (no matter accept or decline), no one will be happy when his/her patch got no response after several months. And this is still happening in your community right now: https://reviews.apache.org/r/45605/ https://reviews.apache.org/r/45606/ https://reviews.apache.org/r/45607/ https://reviews.apache.org/r/41302/ https://reviews.apache.org/r/41305/ https://reviews.apache.org/r/41306/ https://reviews.apache.org/r/41308/ (I can show you more as long as you need.) I am sure you will say I need to ping someone, clearly this doesn't work. > > You brought up some reasonable suggestions in other threads. As every group > of people with more that 1 person, Mesos community has some inertia. > Features, ideas, and processes should settle down and cook for a while > (except if it is a critical bug). It would be great if we can work together > improving developer experience, despite frustrations, inertia, and personal > opinions. I am glad to help, but people don't need my help. What progress do you make so far? Is there any new committer joining? Is there any non-working committers kicked out? Does any of you committers work more efficiently that before? > > But everyone can easily help us to deal with the known issues. Reviewing > patches of other contributors, paying attention to style and typos, do > better testing. All these things can be done right now, without discussion > and involving committers and will directly help them (committers) to feel > more comfortable about the feature and land patches. For example, you could > have reviewed r/47281/ and help José, right? Come on, even if I helped to review, so what? It is still there waiting for committers. Most of the times, committers are the bottleneck, not reviewers. On the other hand, what can I get if I help to review a patch? Will my name be shown in the git log? No. Will I get any real credit? No. So, why should I help to review? ;-P > > It would also help if we separate technical discussions from operational > issues. This way it's easier to search history. > This is all about your development process, not operations. > Though k8s is a great project, I don't think that hopping from project to > project is a rewarding experience. Like in a relationship, sometimes one > should invest time and effort to make things work. And be patient and > forgiving : ). > Sounds like you give yourself a reason to let people to wait for 6 months for their code to commit... Oh, well, I have been there: https://reviews.apache.org/r/38117/
