No it’s not your fault. Simply people does not feel the change is a benefit.
Attempt to draw a list of pro and cons.
The list is not exhaustive, the items are rather copy/pasted from several discussions I have found around till now. Feel free to add further items and to make corrections as you wish.
.
It should help devs a lot to follow and fix issues, as all the work is concentrated in github (or ABF). Then no need to follow a different place.
We can track it with kanban board
It is easier to migrate from github to, let’s say, gitlab if ever we consider it than migrate from separate tools.
Github api is open, it will be easy to migrate with a totally FOSS alternative (Gitlab or whatever), and when we do, all is migrated.
Github, and by extension some alternatives like gitlab, are known to be very userfriendly. Success of Github comes from its userfrienlyness.
We need a tool that integrate every thing into a single environment, both for sysadmin maintainance and development workflow
It gives visibility to us. See we are even in the UNESCO software heritage.
Our developers are already in Github, a part of them is almost only in Github
Integration between discourse and github.
Better integrated with our repositories
Less work to apply an attached patch
Easier to link to many upstream projects’ bugs
Most people already have an account
.
It is not possible to load the repository list in mobile view (this has been fixed now)
“This is the only organization to which I can’t validate my invitation (nginx 504 error)”. (This has been fixed now)
One less thing under our control. one more thing under the control of untrusted companies (THAT is my main concern, but otoh, as github API is really open, it should be easy to migrate to Gitlab a day or another)
Current bugs might get lost (from @angrypenguin post reported by @ben79, it seems doable through a script)
Harder to find the right subproject to report a bug to (It seems that github is pretty flexible and let many workflow to work)
.
2 Likes
The post is wikified, so you can easily edit it.
2 Likes
This was fault of invitation system. When invitation’s sender ticked one groups as a default for invitation’s reciever then some strange http errors occured. Dunno if this still occurs.
2 Likes
PS>
The fact that you’ll find more than in the list, just means that I have found more sentences written in favour than against.
So, either the pros are more … or the people pushing for github are just more verbose 
1 Like
That’s what you got out of this thread?
I’m more interested in discussing the nuts and bolts of how this would work if we do it. I can’t really make a decision on the issue until I know more. And I am reading and looking.
What Linux distros currently use Github Issues and what is their experience?
What Linux distros were using Bugzilla and switched to Github Issues?
What organizations have integrated existing Bugzilla into Github? How did they do it? What was their experience? How much work was it?
What happens to all the existing bugs?
Are we going to attempt to integrate existing Bugzilla in to Github Issues?
How do we do that?
Who does that?
How much work is this?
Is this really a project we should be taking on while we still are trying to develop the LX 4 Release? Isn’t getting Lx 4 ready for release supposed to be our # 1 priority right now?
If it’s really “no trouble, no effort, just a couple of mouse clicks” to integrate our existing Bugzilla that’s one thing. But I don’t believe it is anything like that easy.
Note: I’m sure there are some other questions needing answering but I would be greatly relieved if we had a sensible discussion about the above. IF we are going to do this someone or ones are going to have to do some work. To me that should be QA-Team meaning me among others. And this is looking like a substantial amount of work to me.
Note-2: I am more interested in fact than opinion regarding the above questions. No, not every single question absolutely has to have a specific answer. It is the general gist of the process I want to get a handle on.
Note-3: It is perfectly OK to answer the above questions with links for us to read. That may be best even.
Note-4: Yes I sort of am approaching this as if it is a forgone conclusion that there are more votes “For” than “Against”. (Just looking at the make up of Council and/or TC-Committee.)
1 Like
Thanks , very nice and structured post!
I’ll try to reply with good structure, and improve also @rugyada’s pros and cons.
Just a distro that comes to my mind is ClearLinux
edit: few others
- Issues · solus-project/solbuild · GitHub
- Issues · Antergos/antergos-packages · GitHub
- Issues · triton/triton · GitHub
- Issues · ataraxialinux/ataraxia · GitHub
- Issues · AwlsomeAlex/StarLinux · GitHub
Also Rancher OS which is a quite big project:
2 Likes
Thanks for this Ben79…What really concerns me about this whole thing is the aspects of it being instituted before there was any discussion. This is a sure recipe for conflict and disagreement when individuals make changes and apply effort when a change has not been at least discussed by all those directly affected by it. Can’t you see how divisive this is. It makes people feel guilty because so and so has done all this work and such and such has already created a situation where bugs are in two places potentially creating additional work.
This kind of behaviour creates resentment on both sides so lets not do things this way please.
Regards Ben’s post there seems to be an important point missing as far as I can see and that is reporting mechanisms. Can anyone point to anything equivalent to the bug report generation system that is available on our bugzilla.
As far as I can see to be able to raise issues on a specific OMA repository requires write access to that repository. I could find no way of controlling this on the repository pages though it may exist in some other less obvious form. I for one would not want our git repos to be totally public.
Another problem that I cannot see could be easily addressed is that of releases. If we assume that our current model continues what would be the process for example of filing a bug against Lx3 as opposed to cooker. Do all the issues appear against in the same list or are they differentiated in some way?
Finally on reading the list rugyada provided I can see very little that would indicate any PRACTICAL advantage over our current bugzilla. For example the frequency to which patches are attched to our bugzilla bug reports is close to zero so how can “Less work to apply and attached patch” be an advantage when we don’t do it anyway. From a QA point of view I would like to see a list of real operations that it would make easier as I believe that the GitHub reporting system is geared toward software project management and not distro bug reporting. This is borne out by the fact that a special repository has to be created for all other bugs which don’t fit into any other category.
The fact that there are only two Distributions using it (one of which is structured in a manner that would better suit GitHub (docker project images) does seem to indicate that it may not be suitable for that purpose. Why have not some of the larger distros jumped on the bandwagon?
I will probably be thought negative in my views but I feel we must be more pragmatic about such changes.
If we are to make this change then there should be proper detailed workflow drawn up to show that as a system it is actually workable.
I suggested during the TC that there seemed to be a possibilty of a hybrid approach where bugs directly related to applications/projects could be transmitted as issues to GitHub because Bugzilla can filter bugs by release this could be quite useful since it is cooker bugs that the proponents on the change are really interested in. This is perhaps a way that to more useful aspects of GitHub could be harnessed.
1 Like
Thanks for the reply. I am asking about major Linux distros like Arch, Fedora, openSUSE, Cent OS, and so on. I’m all ready aware of all the little projects that use Github. I’m talking distros that need to track bugs by Release version like we do. I don’t see how that is done in Github and it is a concern.
Post-edit: Even more important would be those organizations, if any, that have integrated an existing Bugzilla in to Github Issues. Again especially if they are more or less major, recognized Linux distributions.
Post-edit-2: Managing bug reports for a Linux distribution is different, and inherently more complex, than managing bug reports for a project.
Some good points on the practical aspects of bug reporting and fixing @Colin.
Not everyone here seems to get that you are asking people that have spent over 5 years with our current Bugzilla based system to just drop it and change in the middle of also trying to get an Lx 4 release done that is very late already. It certainly feels like the work of those of us involved with Bugzilla is being trivialized by some people here. This is being talked about as if a bug reporting system is no work at all. Well that is just wrong. It is work and mostly is pain in the rear end, no glory, kind of work.
OpenMandriva can be stupid about change and when to do it and we are getting close to that here.
We already have decided to devote all our resources to getting our Lx 4 release done and released to public. Even to the extent that we don’t fix many bugs in Lx 3 and instead include those bug fixes in Lx 4. Why don’t we stick to what we have already decided until we get it done? To much to ask? (Emphasis on “devote all resources to”). This is already a fairly extreme decision for a Linux distro let’s not compound it by putting another major change on top of what we have already decided to do for the short term.
Then after Lx 4 is released and the initial phase of bug fixing for the inevitable bugs new releases always seem to have that testers and devs miss are dealt with (6 weeks give or take). Then it would be time to change to something else for bug reporting if we decide to make that change.
Change can be a good thing, sometimes a very good thing. But a good change done at the wrong time can go wrong and maybe even turn in to a disaster. To avoid that we must be smart not only about what changes we make but when we make them.
2 Likes
+1
Like for the /contrib repository topic, right now it would be better to focus on getting a good Lx 4.0 release.
1 Like
Yes, that (contrib repo) is for discussion at this time. Any major change should come later. Again after Lx 4 release.
1 Like
At this point it’s unfortunately not something i can have arguments pro and against. If Github issues has not what is needed for managing a distro this indeed can be a blocker. But if it has, I see the advantage of simplifiying workflow plus gathering potential contributors more easily.
Is it possible to list what exactly is needed for our workflow so we can check/uncheck their availability in Github issues compared to bugzilla, and see if we can go forward and analyze advantages?
1 Like
A very @AngryPenguin provided these links. Very much on topic. Should be required reading for anyone discussing this issue.
https://www.theozimmermann.net/2017/10/bugzilla-to-github/
“Migrating to GitHub Issues and Projects — Xamarin Community Forums”
The Theo Zimmermann link about Coq’s transition is more like what I believe we should do if we make this change.
Also should be required reading:
Githubs basic beginning of documentation for “Issues”
Article about effective bug reporting issues on Github.
Article with tips about managing your Github issue tracker.
2 Likes
As a group we are very resistant to organization. I’m one that has long wished for just a little more organization.
As for QA what is published is:
https://wiki.openmandriva.org/en/OpenMandriva_Release_QA
https://wiki.openmandriva.org/en/QA
https://wiki.openmandriva.org/en/How_to_report_a_bug
I don’t think there is an actual description or chart of our workflow in there. I believe there should be a workflow description with a chart. I would also like bug triaging introduced and defined.
So there is a work flow but it is not a defined policy and tends to happen by osmosis or something like that. I believe we could do better for our users by being just a little bit more organized at this. Just a little, not to much.
Post-edit: By group I was referring to the overall group of contributors not just QA-Team.
2 Likes
But to subscribe to this mailing list, you had to get moderator approval and, for some time, no one was administrating this mailing list anymore.
Why does something look familiar? 
Edit: the first article is very interesting, especially the difficulties they met and how they solved them.
1 Like
edit from raphael: this post which was starting another thread has been moved here as it contains useful links and text for current discussion.
There is discussion about switching our bug reporting from Bugzilla to Github. Anyone on the QA-Team or participating with QA should read that thread. Some or most in the Development Community are in favor and even excited about making this change. But they are currently the only people all that familiar with Github.
This issue has not yet been decided, except that in the near term we continue with Bugzilla for user level bug reports while QA-Team and others discuss and decide this. But as this very much affects QA-Team I want to encourage anyone who has time to do a little reading and get a sense of how this could work in OpenMandriva. This will help us all to make the best decision for OpenMandriva.
https://help.github.com/articles/managing-your-work-with-issues/
https://coenjacobs.me/2013/12/06/effective-bug-reports-on-github/
I’m not advocating any view point here. I have not read the above articles yet myself, but they are on my To-Read list. I don’t even know for sure these are the best articles for us to be reading so if anyone has better suggestions please post them here.
I am advocating that we all inform ourselves so as to approach this issue and decision with knowledge rather than prejudice.
1 Like
I’d say we are far form tracikg bugs per release on current bugzilla.
On github this can be easily done. Like you can create project for every important thing, that needs to be done, as github allows not only bugs to be tracked.
BTW: systemd does uses github for issues tracking and project progress
As you may noticed that bugs are taged, labelled, and that helps tracking it, by using kanban board.
Unfortunately projects are not visible for non systemd devs.
1 Like
Best option would be to migrate all the “not closed” bugs to github, shutdown our bugzilla and set up redirect from issues.openmandriva.org to https://github.com/OpenMandrivaAssociation/OpenMandrivaLx/issues
1 Like