[Kde-pim] Problems with infrastructure

Milian Wolff mail at milianw.de
Mon Dec 15 09:48:16 GMT 2014


On Saturday 13 December 2014 18:13:41 Albert Astals Cid wrote:
> El Dissabte, 13 de desembre de 2014, a les 13:46:24, Jan Kundrát va 
escriure:
> > On Friday, 12 December 2014 22:44:39 CEST, Albert Astals Cid wrote:
> > >> That's very different from saying "whole KDE should just
> > >> switch to Gerrit", and I'm not proposing that. Some people have made
> > >> themselves clear that no change is going to happen, and I can live with
> > >> that.
> > > 
> > > Where was that discussed? Which people is that?
> > 
> > (Removing PIM from the list, because I don't see this as a PIM matter.)
> > 
> > That was the impression which I got from the #kde-devel IRC channel and
> > the
> > kde-core-devel ML right after that frameworks BoF during Akademy. When
> > re-reading the threads and the IRC logs today, I no longer have the
> > impression that there was a clear, absolute and strict "no", but there was
> > nonetheless IMHO quite a strong resistance to using something "as horrific
> > as Gerrit". That might explain why I think that there will be a subset of
> > people who won't be fine with any change, and because I respect their
> > opinion, I don't want to force such a change upon them.
> 
> As i said there is value in uniformity of the tooling, I like to think we're
> all reasonable people and understand that if the majority thinks it's a
> better tool, it makes sense to move to that tool. That's what happened with
> git.
> 
> And if after evaluating it, it doesn't make sense, we don't. That's what
> happened with gitlab.
> 
> Now to me it seems that you're basically saying "you" do what you want, i'll
> keep using "my" stuff. Which i find sad since it's creating artificial
> barriers between "you" and "my" :/
> 
> It also puts the discussion about a possible switch to gerrit in a weird
> situaion since we either all switch and have uniformity or we don't and then
> we end up with reviewborad+gerrit :/

Personally, I don't see why its a bad thing to have two options, if both 
fulfill a different users needs. Reviewboard is apparently liked by some, and 
its certainly simple to send trivial patches with it. Gerrit otoh is much 
better for people who work a lot on projects, as you can get much more 
productive with it. You just use git, and the rest is handled by the web ui.

> > So, basically, from my point of view -- the tools are here, the CI is
> > done.i
> > That CI bits in particular make the workflow much more appealing to me.
> > Now
> > it's up to the KDE developers to come to a decision whether they want that
> > or not.
> 
> Maybe you could start a thread explaining why gerrit is better than
> reviewboard nd why should we switch to it?

I can just say that I like using it in the setup they have for Qt. Much more 
productive to work on patch sets and then pushing them to an alias remote. 
Then I can fix them up and/or rebase and push again to update everything. With 
reviewboard, I'd need to manually push each individual patch, and updating 
them is again as much work.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de




More information about the kde-core-devel mailing list