Ticket tracking system for LTP
Hi!
Recently, as there has been more people working on LTP in SUSE than myself, we started to accumulate LTP TODO items in our internal tool. These include general ideas about LTP improvements, missing coverage, broken tests, etc.
Keeping this backlog behind closed door is unhealty for upstream project so I'm looking into some kind of system to track these where everyone can create new tickets/bugs/issues whatever it is called and act on them.
The main problem here is to choose right tool for the job, which is the main reason for this email. I would like to avoid clumsy solutions such as wiki table or a spreadsheet (I've been there and it was painful even for a team of two people).
Here are some requirements I came up for it:
* Supports creating/commenting/closing issues/tickets/bugs or whatever is single smallest entity is called as by anybody (possibly after a simple registration)
* Should be reasonably simple and be able to handle >100 of open issues, which I suppose rules out things that are tailored to be used to support agile workflow such as trello that would end up visually incomprehensible
* Should have basic text search capabilities
* Ideally we will not maintain the instance ourselves
- that rules out things like redmine unless there is an instance we can easily tap into
* Data export is a plus
- I want to avoid situation where we loose our data after a database corruption
* Should be reasonably estabilished
- I want to avoid a situation where we start to use some tool only to find it has been discontinued half a year later
* Ideally it should be opensource
- however beggars can't be choosers we use GitHub quite extensively after all
There is a list of poissibilities I have so far:
* GitHub issues
- probably the easiest solution
- we can create a specific labels to sort these out
- needs GitHub account which everybody has already
- some operations could be done only by LTP project members I'm not sure if random users can add labels for example
* Some instance of Bugzilla
(maybe bugzilla.kernel.org if we happen to get LTP category there)
- while this would be OK for missing coverage and broken test I find bugzilla clumsy general ideas tracking
* I've been told that JIRA is free for opensource projects but I have no idea how the tool works or if it's at least reasonable fit. I looks to me like it has far to many features we do not need at all.
* ??? (anything else any of you can think of?)
Rant: Actually I'm a bit disappointed that there is no command line tool
similar to taskwarrior.org maybe with a git backend for this kind of backlog/team management...
Signature · 2 lines
Cyril Hrubis [email protected]
Quoted 45 lines · Cyril Hrubis
Hi!
Recently, as there has been more people working on LTP in SUSE than myself, we started to accumulate LTP TODO items in our internal tool. These include general ideas about LTP improvements, missing coverage, broken tests, etc.Keeping this backlog behind closed door is unhealty for upstream project so I'm looking into some kind of system to track these where everyone can create new tickets/bugs/issues whatever it is called and act on them.
The main problem here is to choose right tool for the job, which is the main reason for this email. I would like to avoid clumsy solutions such as wiki table or a spreadsheet (I've been there and it was painful even for a team of two people).
Here are some requirements I came up for it:
* Supports creating/commenting/closing issues/tickets/bugs or whatever is single smallest entity is called as by anybody (possibly after a simple registration)
* Should be reasonably simple and be able to handle >100 of open issues, which I suppose rules out things that are tailored to be used to support agile workflow such as trello that would end up visually incomprehensible
* Should have basic text search capabilities
* Ideally we will not maintain the instance ourselves
- that rules out things like redmine unless there is an instance we can easily tap into* Data export is a plus
- I want to avoid situation where we loose our data after a database corruption* Should be reasonably estabilished
- I want to avoid a situation where we start to use some tool only to find it has been discontinued half a year later* Ideally it should be opensource
- however beggars can't be choosers we use GitHub quite extensively after all
Quoted 9 lines
There is a list of poissibilities I have so far:
* GitHub issues
- probably the easiest solution
- we can create a specific labels to sort these out
- needs GitHub account which everybody has already
- some operations could be done only by LTP project members I'm not sure if random users can add labels for example
I would opt for this solution, as it seems some folks are already using it to some extent.
Quoted 24 lines
* Some instance of Bugzilla
(maybe bugzilla.kernel.org if we happen to get LTP category there)
- while this would be OK for missing coverage and broken test I find bugzilla clumsy general ideas tracking* I've been told that JIRA is free for opensource projects but I have no idea how the tool works or if it's at least reasonable fit. I looks to me like it has far to many features we do not need at all.
* ??? (anything else any of you can think of?)
Rant: Actually I'm a bit disappointed that there is no command line tool
similar to taskwarrior.org maybe with a git backend for this kind of backlog/team management...--
Cyril Hrubis
[email protected]--
Mailing list info: https://lists.linux.it/listinfo/ltp
Signature · 4 lines
Seb/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linux.it/pipermail/ltp/attachments/20180411/fee470ff/attachment.html>
Quoted 45 lines · Cyril Hrubis
Hi!
Recently, as there has been more people working on LTP in SUSE than myself, we started to accumulate LTP TODO items in our internal tool. These include general ideas about LTP improvements, missing coverage, broken tests, etc.Keeping this backlog behind closed door is unhealty for upstream project so I'm looking into some kind of system to track these where everyone can create new tickets/bugs/issues whatever it is called and act on them.
The main problem here is to choose right tool for the job, which is the main reason for this email. I would like to avoid clumsy solutions such as wiki table or a spreadsheet (I've been there and it was painful even for a team of two people).
Here are some requirements I came up for it:
* Supports creating/commenting/closing issues/tickets/bugs or whatever is single smallest entity is called as by anybody (possibly after a simple registration)
* Should be reasonably simple and be able to handle >100 of open issues, which I suppose rules out things that are tailored to be used to support agile workflow such as trello that would end up visually incomprehensible
* Should have basic text search capabilities
* Ideally we will not maintain the instance ourselves
- that rules out things like redmine unless there is an instance we can easily tap into* Data export is a plus
- I want to avoid situation where we loose our data after a database corruption* Should be reasonably estabilished
- I want to avoid a situation where we start to use some tool only to find it has been discontinued half a year later* Ideally it should be opensource
- however beggars can't be choosers we use GitHub quite extensively after all
Quoted 8 lines
There is a list of poissibilities I have so far:
* GitHub issues
- probably the easiest solution
- we can create a specific labels to sort these out
- needs GitHub account which everybody has already
- some operations could be done only by LTP project members I'm not sure if random users can add labels for example
+1. It meets the requirements (except open source), and is already established. To be successful, LTP's github probably needs more curation. I see a lot of pull requests and issues opened for a long time without any action. This is true of any solution, of course.
Also, importantly, github is where the developers are (like it or not).
Quoted 4 lines
* Some instance of Bugzilla
(maybe bugzilla.kernel.org if we happen to get LTP category there)
- while this would be OK for missing coverage and broken test I find bugzilla clumsy general ideas tracking
-1.. The world of open source bug tracking is a bit sad. We're looking at moving LKFT's bugzilla to phabricator
(https://github.com/phacility/phabricator). Still, moving from perl to php feels like an improvement but not a solution (or maybe my biases are showing).
Quoted 3 lines
* I've been told that JIRA is free for opensource projects but I have no idea how the tool works or if it's at least reasonable fit. I looks to me like it has far to many features we do not need at all.
-10. Just, don't use jira.
Quoted 1 line
* ??? (anything else any of you can think of?)
I think github is a great solution for this project.
Dan
Quoted 12 lines
Rant: Actually I'm a bit disappointed that there is no command line tool
similar to taskwarrior.org maybe with a git backend for this kind of backlog/team management...Signature · 5 lines
Cyril Hrubis [email protected] -- Mailing list info: https://lists.linux.it/listinfo/ltp
Hi!
Quoted 11 lines
Quoted 6 lines
* GitHub issues
- probably the easiest solution
- we can create a specific labels to sort these out
- needs GitHub account which everybody has already
- some operations could be done only by LTP project members I'm not sure if random users can add labels for example+1. It meets the requirements (except open source), and is already established. To be successful, LTP's github probably needs more curation. I see a lot of pull requests and issues opened for a long time without any action. This is true of any solution, of course.
Well I should be a bit more proactive there, most of the issues that stay open for long time are these where the original author lost interest in getting the changes upstream, quite a few of them could be closed with "no response" at this point.
Quoted 1 line
Also, importantly, github is where the developers are (like it or not).
True.
There were two responses so far with two +1 for GitHub so I suppose that this is the way forward.
Signature · 2 lines
Cyril Hrubis [email protected]
Hi,
Quoted 2 lines
Quoted 1 line
Also, importantly, github is where the developers are (like it or not).
True.
Yes, but most of valid / useful patches we got via mailing list.
Quoted 2 lines
There were two responses so far with two +1 for GitHub so I suppose that this is the way forward.
I'd like to note to README.md, that we prefer get patches over mailing list (+ note patchwork), than via github pull request.
Kind regards,
Petr
Hi!
Quoted 3 lines
Quoted 2 lines
There were two responses so far with two +1 for GitHub so I suppose that this is the way forward.
I'd like to note to README.md, that we prefer get patches over mailing list (+ note patchwork), than via github pull request.
The point here is that mailing list is generally unsuitable for managing backlog/todo-list at least I cannot imagine how can we use it that way...
Signature · 2 lines
Cyril Hrubis [email protected]
Hi Cyril,
Quoted 3 lines
Quoted 3 lines
Quoted 2 lines
There were two responses so far with two +1 for GitHub so I suppose that this is the way forward.
I'd like to note to README.md, that we prefer get patches over mailing list (+ note patchwork), than via github
pull request.
Quoted 2 lines
The point here is that mailing list is generally unsuitable for managing backlog/todo-list at least I cannot imagine how can we use it that way...
I'm not talking about taking mailing list as a bug tracker. I mean I'd prefer github being just for bug tracking only. I.e. Not using it much for pull requests.
Kind regards,
Petr
Hi!
Quoted 3 lines
I'm not talking about taking mailing list as a bug tracker. I mean I'd prefer github being just for bug tracking only. I.e. Not using it much for pull requests.
I do prefer maliling lists for patches over github pull request as well however trying to stop people from sending pull requests is like trying to reverse river stream with your bare hands. You will be flushed down with the stream either way no matter how hard you try. So what I do is to ask people nicely to send patches over to the mailing list but I will certainly not force anyone.
Signature · 2 lines
Cyril Hrubis [email protected]
Quoted 18 lines · Cyril Hrubis
Hi!
Quoted 11 lines
Quoted 6 lines
* GitHub issues
- probably the easiest solution
- we can create a specific labels to sort these out
- needs GitHub account which everybody has already
- some operations could be done only by LTP project members I'm not sure if random users can add labels for example+1. It meets the requirements (except open source), and is already established. To be successful, LTP's github probably needs more curation. I see a lot of pull requests and issues opened for a long time without any action. This is true of any solution, of course.
Well I should be a bit more proactive there, most of the issues that stay open for long time are these where the original author lost interest in getting the changes upstream, quite a few of them could be closed with "no response" at this point.
Quoted 6 lines
Quoted 1 line
Also, importantly, github is where the developers are (like it or not).
True.
There were two responses so far with two +1 for GitHub so I suppose that this is the way forward.
FWIW, +1 :).
- ssp
Quoted 7 lines
Signature · 6 lines
-- Cyril Hrubis [email protected] -- Mailing list info: https://lists.linux.it/listinfo/ltp