Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On donderdag 4 juli 2019 10:07:40 CEST Clemens Toennies wrote:

> I agree that switching to gitlab and not planning to use it as suite of 
> integrated features is imo pointless.
> As Albert mentioned, reducing the need for users and devs to look at and 
> maintain multiple interfaces/tools in various places should be one of 
> the main reason for deciding to go with gitlab in the first place.
> This also goes in line with our goal of attracting fresh new blood (as 
> explained by Emmanuel under point 2. above), be it users who like to 
> participate and can eventually be motivated to try and fix a bug 
> themselves easily after successfully reporting it, or new developers who 
> simply are already familiar with modern interfaces that github or gitlab 
> provide.

As pointed out in other threads in this mail, gitlab actually isn't sufficiently like a github clone. The shared workflow is the clone, then merge request part. The code review, issue handling and so on is very different, so anyone familiar with github will flounder anyway.

> As for a practical move to gitlab, I could see the following work:
> Older projects could be allowed to keep using bugzilla for another 6-12 
> months before adding new bugs there would be disabed (Bugzilla can be 
> kept as legacy read only). If a project wants to switch from bugzilla to 
> gitlab issues right away, it should be allowed to do so and bugzilla 
> disabled then for that project. At the same time every new project 
> should be using gitlab issues default and not even be added to bugzilla 
> retroactively.
>
> That would result in people looking at a project on gitlab first for 
> whatever reason they are interested in including bugs, and only in case 
> that project has no bugs there, check bugzilla. The chances of that 
> workflow happening in this order will be the majority of cases anyway if 
> the plan is to advertise/promote invent.kde.org <http://invent.kde.org> 
> to users and developers alike as "the new place to go" for projects 
> within KDE.

Keeping the tool users use to report issues and the tool developers use to plan and execute their work is a feature, not a problem. I don't want my users to go around poking in gitlab. 

> Contrasting that with disabling or limiting gitlab issues and continuing 
> bugzilla will very likely be perceived as odd/weird/disappointing by the 
> majority of people that are going to check out invent.kde.org 
> <http://invent.kde.org> and is imo backwards.

On the other hand, we also need to use tools that make our work possible. Me being able to do my work, my developers being able to do their work is also important. These tools are not for marketing, they are for making the development process go better. And not just for newcomers, but also for the people actually shouldering the load of triaging ~150 reports a month.

> Plus it adds complexity whereas using gitlab issues could reduce need 
> for maintance, servers, backups, syncing, etc.
> 
> Overall, I think KDE in general should be more active and confident in 
> taking steps to consolidate and modernize its software offerings and 
> technical landscape, especially if adoption of key future infrastructure 
> solutions seems to be happening already in many comparable places (e.g. 
> discourse, as used by mozilla, nextcloud, and all over the place, or 
> gitlab being in use by gnome, debian, purism, manjaro), etc.
> 

I disagree. I'm fine with modernizing bugzilla to bugzilla 6. But gitlab's issues feature is not powerful enough to handle the amound of bug reports I have to handle. In other words, I cannot do my work with gitlab's issues feature. It might look more modern, but it just doesn't have the power. 

I also think that we should evaluate what those new systems bring us. Has webchat.kde.org brought in more new people in comparede to last year? What are the positives, what are the negatives now we've used it since February? Have the projects that have already moved to Krita seen an increase in first patches by newcomers compared to a similar time period last year? We should really get those statistics so we know that what we're doing is working.


-- 
https://www.krita.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20190704/74677cdb/attachment.sig>