[Kde-pim] Problems with infrastructure
Albert Astals Cid
aacid at kde.org
Mon Dec 15 19:35:27 GMT 2014
El Dilluns, 15 de desembre de 2014, a les 10:48:16, Milian Wolff va escriure:
> 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.
I've already written it in lots of places but i'll try to do it again:
* Makes it harder for newcomers (and developers in general) since they have
to find out which of the two patch review systems to use for repository
* People need to llearn two tools instead of one to contribute patches to
"KDE projects"
* Increases our maintaince effort (there's two web systems that can break
instead of one)
And i could find more, but i sincerely think these three are "bad enough".
Cheers,
Albert
> > > 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
More information about the kde-core-devel
mailing list