[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Koko in KDEReview
From: Ben Cooksley <bcooksley () kde ! org>
Date: 2021-05-04 19:23:22
Message-ID: CA+XidOHwQDUamxfnEh9y_D4LP=LUWW=fXSgSJPsDBt+_GYEFSA () mail ! gmail ! com
[Download RAW message or body]
On Wed, 5 May 2021, 1:28 am Nate Graham, <nate@kde.org> wrote:
> 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.
>
Side note here: It is actually possible to disable issues on Gitlab
projects.
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.
> 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
>
Cheers,
Ben
>
[Attachment #3 (text/html)]
<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>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic