Koko in KDEReview

[Nate Graham]

On 5/4/21 1:16 AM, Harald Sitter wrote:
> Every time the bugz vs gitlab schism comes up I eventually tune out with
> the distinct feeling that there is strong opposition to moving. What I,
> what we all, do not want is to end up with two systems that require us
> to maintain two client libraries with double the bugs for the next 10
> years, and everyone gets to roll a dice which platform a given product
> tracks bugs on. So what we need is community agreement which BTS to use
> long term and then we can drive the technical changes to make that happen.
> 
> Short to mid term bugz is the reality we have to live with.

There is policy, and there is reality. Policy is not self-enforcing, and 
if it attempts to prescribe a reality too different from the actual one, 
it breaks and looks somewhat silly.

Since we have no way of actually *disabling* the Issues feature in our 
GitLab instance, certain projects are inevitably going to start using it 
despite all the policy we can come up with. Why? Because it's generally 
better for most of the things that most of us care about (it does not 
have to better for literally everything to still be a net win) . I don't 
see anyone really trying to argue otherwise.

Therefore, I think we need to re-focus the conversation towards "how do 
we migrate to GitLab issues in a coordinated and supported manner." This 
was supposed to be a big advantage of GitLab, yet we're not embracing it 
it despite clear demand from within the community.

Another thing: If we had a clear migration plan and roadmap, it would be 
an easier sell to tell new projects whose owners are accustomed to a 
better bug management UX, "You have to use Bugzilla for now, but we'll 
be able to use GitLab issues in X months."

Nate