On gio, 2014-08-21 at 18:01 +0900, Carsten Haitzler wrote: > On Thu, 21 Aug 2014 02:00:05 +0200 Stéphane Desneux > <[email protected]> said: > > > +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. > > that was why i thought that maybe merging where commonly N packages are all > upgraded/dealth with as a group, into a single gerrit repo, so we still get > notifications but just a few of them instead of 100's. we sitll have > visibility > and ability to even approve/deny (if its just an upgrade i'd likely just > approve > anyway), and we have lower noise.
Hi Carsten, The crumbling of the X repos is really painful I agree with that. I'm not sure that regrouping it would be the solution because gerrit creates a review for any commit. Thus having it in one or several project is creating almost the same count of mails. The solution of Stéphane is better. Best regards José > > > 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). > > yeah. it was really just unneeded noise that is a result of our use of > gerrit in the way we do. :) > > > 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 > > > > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
