Well, in fact there was a discussion as reminded @TPG (but it was in stalled status). So some people may have thought it was abandoned and other it was accepted.
The process which can be used is to have a generic repositories for all issues (it may also be easier to manage if we want a bot reporting new issues to our forum and/or channels/rooms discussions). In case it’s needed, some cases, issues can be linked to specific repositories by their owners. Also you can decide who can or can’t have access to issues. (read/write etc)
I’m not sure to get it, here are some interesting comparison between Bugzilla and Github issues from one of the links above.
Well, looking at the top distros in Distrowatch, CentOS and KaliLinux use MantisBT, Ubuntu use Launchpad (well distros based on Ubuntu mostly use launchpad), Debian the only one to use their own cgi-based BTS, Arch Linux use flyspray, MX Linux use Drupal, Manjaro uses Gitlab and Kaos and Antergos use Github.
The way Kaos organizes github for bug management is well documented by the way.
IMHO the main reason why developers of big distros don’t move massively to integrated environment is less because of the advantages rather than the amount of work (because they have a huge quantity of issues reported, may they be closed or open). We have the advantage or still being small.
I forgot to mention that it can be done by attributing issues to specific branches. You even can protect branches to avoid people who has authorization to triage bugs to not have rights to merge pull requests or push them.
Good points made by @Colin, @raphael, and @TPG. Some good information and links too. I believe we should have enough information to decide this. There are Linux distro’s that use Github and there are organizations that have switched from Bugzilla to Github for bug reporting. So those questions are answered.
Tracking was the wrong word, however our bugs are filed by the release in Bugzilla, against 2014, Lx 3, or Cooker, ect. and can easily be searched that way. But I am willing to admit our bug reporting system isn’t ideal as it is. There is plenty of room for improvement which should be a major goal if we make this change.
Yes, if we make this change, this would be how to do it I think.
The way Kaos has done this and their documentation does look interesting. Kaos documentation looks like a good guide for our own also. It is short and simple as compared, for instance, to Fedora. Nothing wrong with Fedora’s at all by the way, I use theirs and Arch Linux’s wiki’s and docs a good bit. Just that what Kaos has done seems “right sized” for an organization like OpenMandriva.
Systemd’s labeling of bugs caught my attention in a big way also. There is a good bit of room in there to customize things to fit our needs.
If we are going to do this I believe the timing should be that we would actually make such a change about 1 month to 6 weeks after Lx 4 release. So now is an ideal time to be discussing whether to do this. Gives us plenty of time to lay whatever ground work is needed and to do the work required to do this should we decide to go in that direction. And also to do it without taking time away from Lx 4 development which is our highest priority at this time.
Worth saying is that I strongly believe we need to give ourselves enough time to make such a change both thoughtfully and well. Doing this half assed could and likely would lead to disappointment or worse.
I’ve had a look at the comparison link that has been provided and there are a couple of things that hit me in the eye in the this. The first is that GitHub is not free software and the second is that bug numbering is a very real issue. I don’t think that there is anything here that really provides any great advantage over Bugzilla.
As I said in my previous post what is needed is a proper workflow so that we can assess how workable the process really is. This statement “The process which can be used is to have a generic repositories for all issues” would negate some of the advantages that GitHub is supposed to confer regarding the autmomatic closure of bugs etc. Again I say it GitHub is geared toward individual software project management not distro bug managment. I have looked at the Kaos documentation and looked at their repos and they seem to bear out what I have just said. It just gives you lists; you can’t take advantage of the functionality of GitHub unless you report issues by repository. So we got to a lot of work transferring bugs to something that does not really offer any tangible advantage except perhaps the questionable one that all our bugs will be available for all the world to see as they will be indexed on Google.
The reason it seems to be good is bcause there’s a web page that links you to all the categories but there’s no reason why this can’t be done for Bugzilla.
But hell what do I know? I may be missing some advantage that you can see that I can’t!!
To me it’s the contrary, the advantages jump to my eyes:
simpler workflow, automated actions, more natural and attractive/familiar interface, for dev teams as well as for small contributors who just want to fix a specific issue by submitting a pull request.
tighter integration with Discourse which makes easier for users to follow the work of dev and qa team (and for developers to keep an eye on related users discussions)
easy to follow history and cross references, github teams mentions, milestones created on the flow.
What is less clear to me is what are the technical constraits that would prevent using it.
I insist on the fact we need to explore deeply all the aspects of it, if we at least agree to give a test.
Concerns may be: where to put the default issues.
Do we want to be able to move issues between repos (yes, it’s doable)
How to manage tags, milestones, branches, project management.
Which workflow (ex: user report to forum, if bug then qa team create an issue in generic issue page and cross link with related forum thread, package maintainer can move issue to his repo etc)
I’d like to spend some time with @ben79 to understand all the constraints and requirements and see if github issues is adapted
Sure we can do that. I wish I new more than I actually do but one way to get past that is to do something and learn while you are doing.
As I see it in Bugzilla there are approx. 150 open bug reports to transfer or close. What I don’t have a handle on is how much work is it to do this. I believe there are scripts to do this but it is almost certain we would need to take such a script and modify it.
The rest of it would be as I understand it would consist of:
Creating a workflow and workflow chart.
Writing our documentation for “Issue” reporting and support in general. (I specifically don’t want to much written, I use Kaos documentation as an example not because of the specifics of what they did but mostly as an example of “right sized” for an organization like OMA. Our specifics would and should be different.)
Setting things up in Github how we want them, creating our tags, ect.
In order to get me to agree to do this developers need promise upon penalty of being thrashed with a wet noodle to not ever put packages for released systems like Lx 3 and Lx 4 in updates repos without first putting them in testing repo and giving the QA-Team 7 days to accept or reject the package. Further we need to set up a mechanism to make it virtually impossible to do this. A mechanism that requires a package to go to testing repo first or it can never go to updates. That would probably have to be something in ABF. If we can’t do something this simple we have no business trying to change to a different bug reporting system. (Yes, this implies that if QA does not accept or reject a package in 7 days then it goes in to updates automatically. But at least give as the opportunity to do our part.)
If I’ve left anything out I’m certain someone here will inform me. Number 4 above is non-negotiable for me. I’m beyond tired of seeing that. If any one wants to say that isn’t related to this issue I’ll keep saying “It is to me.”
any thing that happens after that is arbitrary. (This is not a new issue someone asked about this when OMA was organizing in 2013.) I believe this is reflected in our QA documentation in our wiki. The main focus of what is written is regarding creating and testing ISO’s not supporting our customers/users.
I can attempt to write a simple work flow but I never have because I don’t believe we can get people in this organization to follow it. I don’t see the point. We would need to get people in the organization to commit to being just a little bit more organized. And from what I see the resistance to that is massive. We can’t even get people to follow a simple rule to see to it that packages for our public releases have a chance to get tested before they get to the public repository. That is not a small matter to me.
I’m slowly becoming more ambivalent about changing bug reporting to Github. Why?
If developers want to do it they will do it and the rest of us will be stuck regardless of what we think so why waste time on it.
This is by far more important. If we as an organization can not commit to even a rudimentary level of organization we won’t do this well and possibly we even will *#$% it up. To be fair though it probably won’t be worse that what we have it just is unlikely to be better. It won’t matter if @raphael and @ben79 set up something good if people aren’t going to follow it.
I just don’t like this because I personally can’t stand the stupid resistance to even a little bit of organization. And this very much affects my ability to focus time and energy on tasks for OM. For me it causes me at times to doubt whether I even want to because non-organized organizations tend to waste a lot of human capital. (Apparently today is one of my “down” days in this regard.)
Post-edit: I hope this does not sound like I was barking at @raphael. Not at all. Today is a day where one on my weaknesses is showing. Sometimes I just have to say what I think. I appreciate that @raphael is trying to help me do something that could lead to us making a move towards a little bit of organization and I appreciate that very much.
Skepticism abounds when Lx 3.0 was released in 2016-08-14. So here we are 2 years and 3 months later and Lx 4.0 is still pre-Alpha. Does anyone get why I’m skeptical of adding more change on top of the changes we haven’t gotten all the way done on Lx 4.0 yet? Shouldn’t we be focusing our energies and resources on that?
Seems like I’ve been hearing Lx 4.0 will be “soon” for about a year.
I did not take badly the skepticism you have about using github because it’s certainly the best argumentation I’ve seen so far against github (Furthermore, I’m not a supporter of any solution but am for something that works the best, and if it happens that github works worse than bugzilla, then obviously I’m for bugzilla)
That said, organization is indeed a real problem, and if instead of well structured issues we have a bunch of tickets about anything, then of course it’s worse than better.
OTOH I don’t think that it’s a Github vs Bugzilla issue, but as you said an organization issue. Considering what you say, which is very important, we should really see if we can make our organization simpler, clearer and more intuitive.
Thanks for the thoughtful reply and the excellent counter points to my observations. And they were observations and expressions of personal angst. Just me getting something that bothers me personally off my chest. And having done so I need to admit that no one in this organization is more guilty than me of starting or attempting to start a project or task and not finishing it. That is a well known symptom of a lack of organization.
So I need to get past that personal angst and negativity and get back to work and try to use this issue about issues as an opportunity to introduce a little bit of a plan and a workflow for what I may start calling our “customer support” initiative. Especially since I seem to have a willing partner in @raphael and we can hope a few others as well.
So I believe the question @raphael put on the table for me is to come up with a template for Support and/or bug reporting work flow? I’m working on it but today I’ll be distracted by a meeting with an attorney.
Post-edit: At some point you had asked who’s in charge of QA. @Colin is. And we really need to have him as a part of this. He has some excellent points and insights. I believe he has real world experience at this in another field. That type of knowledge and input is invaluable.
This file is a work in progress. It is a beginning and meant for other people to take and improve on until we get a final result. Post-edit: This file and this effort is meant to improve the existing process and infrastructure or to be applied in the event of a switch to Github Issues. Much of the stuff needing done with Github probably will require developer input and assistance. Like for instance changing from 19,000 repositories to a few or one.
If we could come up with a written work flow perhaps one of our talented, artistic contributors (@rugyada) could create a graphic for this?
Also could we request that developers begin the process of getting packages all in one repository per version on Github? Like one for 3.0, one for 4.0, one for Cooker? Or is simply putting the “Issue” reports in one location workable? This as crazy described in a post previously:
Post-edit: I’m sure I don’t know the best way for the package repos but we don’t want users having to navigate 19,000 repos.
I may be missing some advantage that you can see that I can’t!!
