On Wed, Mar 16, 2016 at 2:50 PM, Jie Yu <[email protected]> wrote: >> >> Why not check your backlog for your answer? Or do you need me to write >> a script to scan all the pending review requests for you? > > > OK, i just looked at your pending patches: > https://reviews.apache.org/users/wangcong/?show-closed=0 > > The associated tickets: > https://issues.apache.org/jira/browse/MESOS-4740 > https://issues.apache.org/jira/browse/MESOS-2769 > https://issues.apache.org/jira/browse/MESOS-2799 > > (Some of the rb request does not have associated tickets)
Even your rb doesn't have one: https://reviews.apache.org/r/44922/ Not to mention those commits don't even have a RB at all... https://github.com/apache/mesos/commit/19dd467500ea31371dbebe73a4acfa0346aa9e40 https://github.com/apache/mesos/commit/8c83b843dfcd08f82a394c29939f3c5940a78027 https://github.com/apache/mesos/commit/2de2e5791a6c119e26e9e0bc35bdea4b2e54bbec What's your point here? > > I don't see a shepherd for MESOS-4740. Looks like Vinod is the shepherd for > MESOS-2769. MESOS-2799 does not have shepherd as well, but I think that > should be me. Are you still interested in shipping those patches? Whether to ship my patches or not is a trivial problem to fix, the bigger problem, which you keep ignoring, is why this rule (shepherd, ping etc.) can't be improved? > > I think you made a valid point that there is some problem regarding: > 1) Do we want to work on all created tickets (i.e., how do we decide if we > want to accept a ticket or not), and who decide that? Why always need a ticket? Some big feature does need one to track the subtickets, I definitely agree, but for things like a typo fix apparently not. It doesn't worth the time at all to create a ticket when you just want to fix some indention like the one you did: https://github.com/apache/mesos/commit/19dd467500ea31371dbebe73a4acfa0346aa9e40 (although I think this worth a RB). > 2) Once we accept the ticket, how can we prioritize those tickets? Should > PMC members groom the accepted tickets regularly? Why prioritize tickets rather than just reviews? Code is on review board not in tickets, you should be able to evaluate the code to decide if it is ready to merge or not. Linux kernel never uses tickets to track features, once all reviews are addresses it would be merged. > 3) If no committer is volunteer for the accepted ticket, what's the > procedure in that case, should we pick one? > 4) What's the procedure of finding another shepherd if the original > shepherd does not have time for that anymore. Promote new committers, seriously. You have 20+ committers, if all of you are working, you should be able to handle all the reviews. The problem is apparently some of you are not working, so why not promote new ones to replace non-working ones?
