Why ? What is the reason ? What are advantages of using bugzilla ?
Why we cann ot use github for issues, so we can track it with kanban board ?
What is wrong to use Kanban board, which already exist and works?
1 Like
@TPG I can only tell you that the topic has been discussed, as you wished, and the people there expressed some concerns. Sad that you were not able to attend, as you might have illustrated some points in favour that we are not aware.
Please have a look to the log here.
1 Like
Sorry I missed the meeting as I’m also strongly in favour of Github issues for several reasons.
I’m really sad I couldn’t participate in this debate as I had prepared a lot of arguments in favour of using it.
Especially I’m disappointed because I wanted to suggest a test period and worked on tight integration between discourse and github.
I guess my work is useless then.
1 Like
Also it’s easier to migrate from github to, let’s say, gitlab if ever we consider it than migrate from separate tools.
1 Like
Well imho the topic could be discussed more.
We were missing @TPG in the conversation, as already noticed both in TC meeting and here above. Actually he, and now we’re learning also you, can bring some yet unconsidered points in favour.
2 Likes
At the risk of answering questions with questions. How do Y’all expect an issue to be decided in a TC-Meeting if the people supporting the issue aren’t present? We normally make decisions based on the information in front of us. The issue was presented as if we had to make some decision so we did based on what we knew at the time.
For me looking at Github for bug reports from a user perspective for a few minutes during the meeting I found it confusing. It also does not look to me like ordinary users belong in Github. Why I only looked for a few minutes during meeting? Because I did not know the issue was on the table.
So don’t give up but do make your collective cases and inform us.
I make no claim whatsoever to be fully informed on this issue at present and consider it still open for discussion. The decision at present was, by the way, to continue with Bugzilla for user level bug reports. There was discussion and general agreement that there is no reason why developers can’t continue to use Github for development and packaging issues.
To make decisions like this requires more than a few minutes of discussion and also more than a few minutes of research on the part of people involved in the discussion.
In retrospect I think it was arguably wrong to expect or ask for a decision in this TC-Meeting.
Post-edit: Forgot to sign my post…
2 Likes
If we are going to continue to discuss this, and we should, we need to start a new thread with the issue properly titled.
Post-edit: Or change the title of this thread. That would work for me. 
2 Likes
I think we should not migrate or reject before deeply testing pros and cons (ie listening all arguments, I admit there may be some I’m unaware of that are blockers) but we definitely should take time for studying it seriously.
Just a quote that seems interesting to me from this blog post (a personal opinion which compares what KDE does better and what GNOME does better):
What GNOME does better
There are three main areas that struck me as game changers.
- Newcomers experience . […]
- GitLab** . KDE uses a mix of tools such as Phabricator, Bugzilla, CLI tools, Travis for CI, etc. **For us, switching to GitLab (or any tool that would integrate everything into a single tool as good as GitLab) has been a massive win both in sysadmin maintenance and in development workflows.
https://csorianognome.wordpress.com/2018/08/24/a-gnome-dev-enters-an-akademy-and/
2 Likes
Done 
2 Likes
For record, a generic repository for bug report has been created by @TPG, note that there may be other workflows that can be studied.
edit: And a related issue
Yes, we found that yesterday. And one of the other things we found was this.
So now we have “issues” in 2 different places. Needless to say a lot of us have a problem with that. Not to mention how confusing this would get for our users. Doesn’t mean there isn’t a way to sort this all out and make it work but if there is it was not presented in yesterday’s TC-Meeting.
Another thought I have when looking at Github for issues from user perspective is if it would be more of a learning process for our users to use correctly? And I don’t really know the answer to that but it is a very important consideration. It is also true that some users are intimidated by Bugzilla.
There is also the question I’ve asked several times, “Do we really want our users poking around in Github?” That I’m skeptical of so far. I can easily see that turning into a “Be careful what you wish for” for our developers.
This entry was created on 27 July 2016
https://github.com/OpenMandrivaAssociation/OpenMandrivaLx/issues/2
Topic is not new, and somehow that defiance do really wonders me. What is really important we may get more bugreporters, as people tends to use github.
More information:
This seems generic, anyone in github with an issue mentioning openmandriva is listed here.
For my part i was not aware of a place already created for issues. But it’s a good thing for testing process. My idea would be keeping Bugzilla as official tool and a small team test Github issues, until the migration is approved, or rejected. It should be indeed a short time (as the request is long, it was even asked before when we used openproject, before github had project management)
W
Well, Github, and by extension some alternatives like gitlab, are known to be very userfriendly. Success of Github comes from its userfrienlyness. Attracting users and developers is certainly a good reason to use Github.
If the question is, do we want to depend on a non FOSS service provider, I’m indeed not in favour. There are two things: first we need (I think we need) a tool that integrate every thing into a single environment, both for sysadmin maintainance and development workflow. Is Github the best solution, from a FOSS pov no, but at our current situation yes. It gives visibility to us. See we are even in the UNESCO software heritage.
Github’s api is open, it will be easy, when we are ready, to migrate with a totally FOSS alternative (Gitlab or whatever), and when we do, all is migrated.
Our developers are already in Github, a part of them is almost only in Github. OTOH our users or visitors mainly come to Discourse/forum, and it would be easy to create this workflow:
A user create a post in forum support category, if support team considers it’s a bug, a issue can be opened in github and a single link in discourse to the issue (or even the commit, comment, card etc) create a linkback in github, making it easy for developers to follow the discussion inside discourse from github, and for users to see how the dev are working on the issue. No need to say that for QA it should be easier because there is no third party software where you need another account, not dynamically linked to the others.
It’s certainly not defiance, I was in favour of using github but not aware of this testing issue tracker. @ben79 and most people discover it, and thanks to his effectiveness and @rugyada’s effectiveness, we are finally pushing this topic forward. Again thanks both for creating this thread.
Note: I see that @fedya seems also in favour of using Github. (unless I misunderstood the “+++++”)
1 Like
yes this is just a generic search for “openmandriva” keyword in github search.
@TPG In fact we/I did not forget your proposal.
On the contrary indeed I have shared a TODO list in Council since 30 September and one item is
I think you received it at that time, if not you can still read the topic in Council forum.
That is kind of irrelevant since no one on QA-Team was aware of this report. We did not even realize we should be looking in Github for anything like this or any bug reports for that matter. While it may not be a new issue for @TPG as noted above it is a new issue for me and AFAIK most people of the QA-Team. If this was announced a lot of us missed it and there does not seem to have been any follow up until now. So now is when it is getting dealt with.
What defiance. In my case I (along with @rugyada) am one of the people that insisted we continue discussing this. That isn’t defiance to me.
That is entirely possible and would be a good thing if it turns out that way. But you are asking people to make a decision on something most of us don’t understand how it works yet. Please give this some time so we can inform ourselves.
Don’t know how many times I need to say this but I have no reason not to “like” or “prefer” Github except lack of familiarity. I am not locked in to Bugzilla but there is literally years of familiarity with it. I will not decide to throw away Bugzilla without having the time to investigate and compare it to Github.
1 Like
Let’s all do our homework on this, especially those of us that aren’t all that familiar with Github. See this in QA Forum:
Just a fast dig, found topic from 2016-09-02
Wow, then it’s my bad, I did not push/advertize this topic enough, sorry…
I even forgot I started it…
Edit: yes I remember the concern I had about the workflow (using OpenMandrivaAssociation or Software or other as a host for issues) and at this time there was also something that prevented to invite people in OpenMandrivaAssociation