On Thu, 2014-01-30 at 17:02 +0100, Philippe Coval wrote: > ### WAITING TO BE REVIEWED ### > > Over 250 changes are not reviewed at all (note some have Verified+1 status) > > https://review.tizen.org/gerrit/#/q/label:Code-Review%253D%252B1+AND+NOT+label:Code-Review%253D-1+AND+NOT+label:Code-Review%253D-2+status:open,n,z > > This means everyone should take a little time to help shrinking this > list, or abandon irrelevant changes > > Or maybe we could have more assigned reviewers per package,
I would argue the opposite: we have too many reviewers per package. Take https://review.tizen.org/gerrit/#/c/15885/ as an example. libXv has over 80 reviewers. How many of those are really active and paying attention to the review request? I bet most of them send Gerrit emails directly to /dev/null. This has come up before. See the "can I get less review requests from gerrit" mail thread [1]. > ### NEED TO SUBMIT TO BUILD AND PUBLISH IN REPOS ### > > This topic is also important, because if the change was merged through > gerrit, > it does not mean it is actually published ... > and requiere some deep investigation to know why it wasnt released > or if it was even submitted (by maintainer)... Same here. Each package is supposed to have exactly one maintainer who is responsible for doing this step in a timely manner. Too many packages don't have that, or have a maintainer who is "missing in action" (left the project without handing over his responsibilities to someone else or is not paying sufficient attention for a prolonged period of time). I think it is time to establish a procedure for identifying such absent developers. Thiago, you helped define the Tizen Governance and how contributors can obtain some of the roles [2]. Can you also do the next step and define how inactive developers can be identified and what should be done in such cases? It might be as simple as pinging people at certain intervals to see whether and how they respond; some might have simply forgotten that certain roles are still assigned to them. More drastic measures might be needed when developers are not doing their job, but refuse to step down or no replacement can be found. [1] https://lists.tizen.org/pipermail/dev/2013-December/001164.html [2] http://events.linuxfoundation.org/sites/events/files/slides/Tizen%20Development%20and%20Governance%20Model%20TDS%2020131111.pdf -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
