[Dev] can we please merge xlib/util pkgs?

Stéphane Desneux stephane.desneux at open.eurogiciel.org
Thu Aug 21 00:00:05 GMT 2014


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).

Stéphane Desneux
Intel OTC - Vannes/FR

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.

More information about the Dev mailing list