+2 Oops... That was a spurious review :)
More seriously, I agree with you. For big ops like bumping the whole X11 stuff and adding ~100 new packages in Tizen:Common, a review for each package is not necessary as multiple maintainers and REs are already working on the topic together.
So bypassing Gerrit when hundreds or reviews are needed gives less noise, for sure. And grouping packages together as one, would certainly help too.
But on the counterpart, things that Gerrit does (communication between developers) wouldn't be done if maintainers push --force on their git trees.
=> so we should get some compromise: when such a big operation is started, the steps should be announced here (dev mailing list), some consensus should arise (say it's a +2 :)) and the progress on the tasks should be regularly updated. This way, most reviews related to the topic could be avoided, but people would still know what's going on.
For the X11 integration in T:Common, Boram Park did communicate here and I felt this sufficient for everybody to know what was going on (and yes, reviews in gerrit were mostly useless even if this follows the official workflow).
BR -- Stéphane Desneux Intel OTC - Vannes/FR gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726 Carsten Haitzler (The Rasterman) wrote:
in the last week i have gotten 280 mails from gerrit about review requests/merges/whatever in every single x library and util. you get multiple mails per package. it's really silly. they are all upgrades together... why not just package them together. simplify things. just have an "x libs" pkg with all x library and relevant util repos pulled in as sub repos. it makes so much more sense. :) i know the upstream has them split. this is something we can't do anything about. i also get one for mobile, one for ivi:panda too. the exact same patch set, review request etc. basically this should really be a single review of a single "upgrade x11 stuff" for example. if we have to review instead 280 submissiongs instead of maybe just 4 (which is about the number of versions of the submission i saw)... that's going to lead to: 1. not bothering to even review/approve. too much noise and going through gerrit 100's of times as opposed to 4 is going to have me prioritise such things at the very end of my todo list, after the "flossing the cat" item. or 2. poor and "quick and dirty" reviews that actually dont review antyhing and just rubber-stamp things. if we are just rubber-stamping, then whu bother with gerrit? just allow commit access and save the work and lag. if there is a mistake someone can revert it from git. so i am thinking we should rationalize our packaging and/or use of gerrit. where it stands now is not in a good state.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
