[Dev] can we please merge xlib/util pkgs?
jose.bollo at open.eurogiciel.org
Thu Aug 21 09:09:43 GMT 2014
On gio, 2014-08-21 at 18:01 +0900, Carsten Haitzler wrote:
> On Thu, 21 Aug 2014 02:00:05 +0200 Stéphane Desneux
> <stephane.desneux at open.eurogiciel.org> 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.
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.
> > 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
> > Dev at lists.tizen.org
> > https://lists.tizen.org/listinfo/dev
More information about the Dev