<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 5 May 2021, 1:28 am Nate Graham, <<a href="mailto:nate@kde.org">nate@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5/4/21 1:16 AM, Harald Sitter wrote:<br>
> Every time the bugz vs gitlab schism comes up I eventually tune out with<br>
> the distinct feeling that there is strong opposition to moving. What I,<br>
> what we all, do not want is to end up with two systems that require us<br>
> to maintain two client libraries with double the bugs for the next 10<br>
> years, and everyone gets to roll a dice which platform a given product<br>
> tracks bugs on. So what we need is community agreement which BTS to use<br>
> long term and then we can drive the technical changes to make that happen.<br>
> <br>
> Short to mid term bugz is the reality we have to live with.<br>
<br>
There is policy, and there is reality. Policy is not self-enforcing, and <br>
if it attempts to prescribe a reality too different from the actual one, <br>
it breaks and looks somewhat silly.<br>
<br>
Since we have no way of actually *disabling* the Issues feature in our <br>
GitLab instance, certain projects are inevitably going to start using it <br>
despite all the policy we can come up with. Why? Because it's generally <br>
better for most of the things that most of us care about (it does not <br>
have to better for literally everything to still be a net win) . I don't <br>
see anyone really trying to argue otherwise.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Side note here: It is actually possible to disable issues on Gitlab projects. </div><div dir="auto"><br></div><div dir="auto">Given that developers generally need a way to collaborate amongst themselves (as Phabricator tasks are used for) we leave the feature enabled however and generally don't allow for it to be disabled. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Therefore, I think we need to re-focus the conversation towards "how do <br>
we migrate to GitLab issues in a coordinated and supported manner." This <br>
was supposed to be a big advantage of GitLab, yet we're not embracing it <br>
it despite clear demand from within the community.<br>
<br>
Another thing: If we had a clear migration plan and roadmap, it would be <br>
an easier sell to tell new projects whose owners are accustomed to a <br>
better bug management UX, "You have to use Bugzilla for now, but we'll <br>
be able to use GitLab issues in X months."<br>
<br>
Nate<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Cheers, </div><div dir="auto">Ben</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>