Changes to our Git infrastructure

Jan Kundr√°t jkt at kde.org
Mon Jan 5 17:39:37 GMT 2015


On Monday, 5 January 2015 18:01:12 CEST, Jeff Mitchell wrote:
> The problem here is that you believe -- incorrectly -- that a 
> single workflow cannot include more than one tool. The reason I 
> can definitively say that you are incorrect is because your own 
> preferred workflow involves more than one tool, regardless of 
> how they interact. And if yours does, you can't complain about 
> other workflows that do.

I was complaining about an IMHO artificial split where drive-by people 
submit changes in a different way than core developers. I stated that this 
introduces some needless difference to the way devs and contributors work, 
and that we should check whether there are tools that remove this 
difference. I know that e.g. Gerrit removes that difference, so I am not 
thrilled by the idea of using something without that feature.

> It does if my point was (and it was) that a workflow consisting 
> of producing a commit in Git and having the review take place 
> via a web UI is a very broadly accepted paradigm in software 
> development, and one that is often considered to be friendly to 
> newcomers.

You're right, and I apologise for not understanding you correctly, we're in 
violent agreement after all.

>> and I believe you were saying that it's fine for a CR tool to 
>> work on patches and not git trees.
>
> Correct. Although I recognize the merits of such an approach, I 
> do not believe that the only acceptable way for a code review 
> tool to work is on git trees instead of via patches. And I do 
> not believe that this one feature is enough to outright dismiss 
> all other options.

That's another thing where I should have probably worded my responses 
better. The requirements I listed were things which I found valuable for my 
work. I did not mean to say that it's the only possible way of doing 
reviews, or that I found everybody who disagrees with me to be a moron. 
It's just that these features are important for me, so I would like to see 
them and I wanted to make sure they are listed as a requirement in a list 
of points gathered by the community.

Maybe this misunderstanding is caused by sysadmins likely perceiving the 
requrements as hard ones which MUST be provided by any solution, while my 
impression is that we were asked to say what is important for us, and the 
evaluation is to be performed by us all together, not just the sysadmins.

> Given your earlier statements I imagine, but this is only 
> supposition, that one of the reasons you desire such an approach 
> is so that you can have all review actions be performed via SSH 
> commands without requiring either a web UI or external tool. 
> While this is certainly nice to have, I don't believe that it is 
> very usable for newcomers.

I agree that *that* would suck :).

> Given the earlier 
> distinction you made between contributors and developers, it 
> also requires those that want to contribute patches to have full 
> KDE developer accounts with commit/push access in order to push 
> those diffs up for code review...something not required from a 
> web interface requiring only an Identity account.

There is no need for full KDE developer account to upload changes for 
review with Gerrit. All that is needed is a regular Identity account.

Behind the scenes, it works by Gerrit being a special git server which 
intercepts pushes and stores each of these changes in a separate ref. I'll 
be happy to go into more detail in another thread, off-list or on IRC.

Cheers,
Jan

-- 
Trojit√°, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/




More information about the kde-core-devel mailing list