From my experience some projects recently switched to Gitlab like GNOME and freedesktop. My question is, whether this might be also a good step for KDE. This issue can therefore be used to discuss this topic. Some arguments: Pro: - More intuitive to use - Having issues and code on the same place Con: - Might be missing some features - Requires some work (setup, migration)
This is something we're going to determine as part of the current Gitlab evaluation. No need to track it here. :)
Thanks for letting me know, nice to hear this is already in consideration :) Nonetheless, I think it should be tracked somewhere (preferably on KDE side), as the result of said evaluation is not clear. After searching I found https://gitlab.com/gitlab-org/gitlab-ce/issues/53206 which is the corresponding issue on GitLab tracking some of the process.
At this time the evaluation work is being done with a small number of test projects (those listed at https://invent.kde.org/kde/) and the feedback collected from them is being held privately. We're doing this to allow us to solve KDE workflow specific issues with Gitlab without having those not involved in actually working with it so far (in our implementation) from bringing things up. As time goes on we may bring other projects on board to help with testing and evaluating it, and prior to any switch there will be a full public discussion.
I like the process of evaluation. For now I change this to "WAITINGFORINFO", as it currently depends on the evaluation and discussion afterwards outcome.
Please don't change the resolution. waitingforinfo has a different purpose.
Same applies to Resolved - not a bug (at least imho). I thought waitingforinfo was more accurate than this (although not fitting good). This is not resolved imho.
"RESOLVED NOT A BUG" is another way of saying, "This isn't something that's appropriate to have in the bug tracker." It's simply not the right place to discuss whether or not we're going to move to replace Bugzilla with Gitlab issues. The discussion is going to happen later, after the evaluation, and in another venue.
(In reply to Nate Graham from comment #7) > "RESOLVED NOT A BUG" is another way of saying, "This isn't something that's > appropriate to have in the bug tracker." > > It's simply not the right place to discuss whether or not we're going to > move to replace Bugzilla with Gitlab issues. The discussion is going to > happen later, after the evaluation, and in another venue. I partly agree. I support this should not be used for discussions now as they are rather pointless knowing that there are current investigations going on. After you told me so, I wanted to keep that open just as a "feature request" issue rather than a discussion issue. Is it in that case better to open an issue with the description just saying "I'd like to see KDE switch to GitLab"? Or can we treat this issue like one with said description (which can't be changed on Bugzilla :D)?
Having it open as a feature request wouldn't be correct either i'm afraid. Changes in community tooling is far outside of scope for Bugzilla - things like this if not initiated directly by groups within KDE trying out new software, tend to be started through discussion on the relevant mailing lists.
I remember being where you are right now, Claudius. You want to have an impact on big things, but none of the channels of communication available to you as a user seem adequate for this. The solution is to step up and become a contributor! Join the mailing lists, get on IRC, start triaging existing bugs, submit some patches, etc. If you want your voice to have the kind of impact it seems you're looking for, you gotta start contributing first. Trust me, it works. ;) https://community.kde.org/Get_Involved
(In reply to Ben Cooksley from comment #9) > Having it open as a feature request wouldn't be correct either i'm afraid. > > Changes in community tooling is far outside of scope for Bugzilla - things > like this if not initiated directly by groups within KDE trying out new > software, tend to be started through discussion on the relevant mailing > lists. Sorry for my extremely late reply, I was busy in between and forgot about this issue later. I (personally) don't like having different places to discuss things, since it is leading to different workflows for different things and also not having a single point of truth. This especially involves discussing some things on mailing lists. I don't really like them, they tend to only really work for people regularly following (subscribing to) them, while the history is pretty painfully to follow. So I personally would prefer to discuss this in an issue. Apart from that, I really think this can be discussed on Bugzilla. That is at least what I thought this Product category was thought for - for meta issues about Bugzilla.
(In reply to Nate Graham from comment #10) > I remember being where you are right now, Claudius. You want to have an > impact on big things, but none of the channels of communication available to > you as a user seem adequate for this. The solution is to step up and become > a contributor! Join the mailing lists, get on IRC, start triaging existing > bugs, submit some patches, etc. If you want your voice to have the kind of > impact it seems you're looking for, you gotta start contributing first. > Trust me, it works. ;) > > https://community.kde.org/Get_Involved Also sorry to you Nate that it took me so long for a reply. I had this in mind several times, but never got to it. Basically I want to improve KDE. I'd like to contribute (in my scope), I already opened issues, what I also consider a contribution. However, the current workflow is not really what I am used to. I don't really like mailing lists (as written above) and Bugzilla. They don't seem very efficient or easy to use to me. I really appreciate that you continued moving more stuff to GitLab. I hope the issue tracker will follow (and be merged with the current Phabricator replacement, so issues are not divided between developer and user scope). Then I might do some issue triaging which I currently find unattractive due to the usage of the rather unintuitive Bugzilla. > If you want your voice to have the kind of > impact it seems you're looking for, you gotta start contributing first. I hope also good arguments alone can have an impact :D
I hear you, Claudius. I don't like mailing lists either, and I agree that Bugzilla is clunky and antiquated. I'm very much in favor of migrating everything to GitLab issues. However our sysadmins are already at 100% capacity with migrating to the GitLab CI, and then after that, migrating Phabricator Tasks to GitLab. Only after those are done can we begin the move from Bugzilla to GitLab Issues. The best way to make that happen faster would be to volunteer to help the sysadmin team with the technical work required, if you have any kind of sysadmin or devops background.
It's more than that, we can't get rid of bugzilla until we completely re-do the crash reporting system.
(In reply to Nate Graham from comment #13) > I hear you, Claudius. I don't like mailing lists either, and I agree that > Bugzilla is clunky and antiquated. I'm very much in favor of migrating > everything to GitLab issues. However our sysadmins are already at 100% > capacity with migrating to the GitLab CI, and then after that, migrating > Phabricator Tasks to GitLab. Only after those are done can we begin the move > from Bugzilla to GitLab Issues. > > The best way to make that happen faster would be to volunteer to help the > sysadmin team with the technical work required, if you have any kind of > sysadmin or devops background. Alright, thanks for the input about what is currently the "bottleneck". I have no background in sysadmin or devops, but might be able to help with some stuff. Regarding migrating Phabricator tasks the problem is probably that it is not really supported out of the box by GitLab (https://docs.gitlab.com/ee/user/project/import/phabricator.html), correct? I read on https://gitlab.com/gitlab-org/gitlab-foss/-/issues/26850 that it should be possible with a script GNOME created, but am not really up to speed with the current state of the migration. At least it seems to be pretty much possible to achieve with existing tools. Also, I thought about maybe asking GitLab for help with some of the migration stuff. At least there is an issue for migration there: https://gitlab.com/gitlab-org/gitlab/-/issues/24900
(In reply to Nicolás Alvarez from comment #14) > It's more than that, we can't get rid of bugzilla until we completely re-do > the crash reporting system. I did not find much about it on the internet, are you referring to Dr. Konqi? From what it looks to me that would need adjustments, yes, but probably not a complete re-do.