[kde-community] Future Git Plans

[Jeff Mitchell]

On 18 Feb 2014, at 11:22, Martin Klapetek wrote:
>> Generally speaking, Gerrit needs to "own" repositories. Would this 
>> require
>> some sort of thing like RB hosting the Git repos?
>
>
> Sort of, it would need its own clone of the repos, which is moreless 
> the
> case right now anyway right? But I imagine it brings all sorts of
> synchronization issues with it...

That's what I would worry about.

My idea w.r.t. RB and Bugzilla -- and this is not discussed fully, so 
please just treat this as "my opinion" and not "the sysadmins' opinion" 
-- is that those have mostly the same pros and cons with respect to 
integrated GitLab functionality:

Pros:
- Can easily move items between components
- Powerful and flexible

Cons:
- Much more confusing for users/casual developers (different site, 
workflow, etc)

So my thinking is that things like KDE Frameworks, where moving bugs 
between components is common, might benefit from staying on Bugzilla and 
ReviewBoard; however, casual projects (especially more self-contained 
ones like extragear) are more likely to benefit from (at their option) 
migrating to the integrated issue tracking. That way users and casual 
developers can sign up and have one place to submit patches, report 
issues, and so on, which makes it easier to do and more likely to be 
done. There are many reasons GitHub has gotten so huge, but integration 
is surely a very major one.

Again, just my thinking. In the end, at least with Bugzilla, I think it 
ought to be available for use but up to a group consensus for 
developers. GitLab is the more GitHub-style issues where you're 
encouraged to tag/search but it can make it hard to get very specific 
queries like you can with Bugzilla, which can be very helpful for 
triagers of big projects. So I can see a lot of projects wanting to stay 
on Bugzilla, and a lot of small projects wanting things integrated, and 
I think both should be supported.

For ReviewBoard, I'd say that there is more of a chance of the sysadmins 
deciding to nix it depending on duplicate functionality -- at least as 
it currently stands -- but RB 2.0 does seem like major improvements, and 
could be worth keeping as well. I wouldn't worry about this happening 
any time soon though, and certainly not before checking out RB 2.0. But 
if RB were to stay, it'd be in addition to GitLab, because if GitLab has 
built-in merge requests, there's little reason to turn them off.

BTW -- this is also my thinking for GitLab wiki capability. It's nowhere 
near as capable as MediaWiki, but for some projects that just want a 
small amount of pages (say, an FAQ page and a news page, or something) 
it may be far nicer to have it integrated than to have those buried in 
TechBase. Certainly it's appropriate for project-specific documentation 
only, though -- UserBase/TechBase/etc are wonderful for what they are, 
and for the higher-level and non-project-specific information that they 
have.

--Jeff