[Maria-developers] Process suggestion for minor issues
Hi MariaDB Developers, This is a suggestion on how to deal with minor or lower priority bugs and tasks in JIRA, http://mariadb.org/jira . Currently, the process we use makes a clear differentiation between major or higher prioirty issues (called majors altogether after this) and minor or lower priority issues (called minors altogether after this). The majors are the ones that should be fixed for a release and the minors are rolling, meaning that they are done when the corresponding developer has finished his/her majors. This of course sounds logical, but it also leads to a growing number of minors for every consecutive release, many of them which never will be fixed but in the current process will hang around. Here is a suggested process to handle the ever growing amount of minors. If a minor issue isn't fixed after two consecutive releases it's re-reviewed and either priority changed to major (or higher), or the minor issue is closed with resolution Won't Fix and a comment. Example of comment can be that "this is an edge case where effort and benefits doesn't correlate". It should also be noted that after closing an issue in JIRA, it doesn't mean that it disappears. It will still show up in free text searches and among the issues for the version where it was closed. Please provide your thoughts. Do you think it's an OK way to deal with the minors or do you prefer some other way? Best regards, Rasmus
Hi, On 6/14/2013 2:27 PM, Rasmus Johansson wrote:
Hi MariaDB Developers,
This is a suggestion on how to deal with minor or lower priority bugs and tasks in JIRA, http://mariadb.org/jira .
Currently, the process we use makes a clear differentiation between major or higher prioirty issues (called majors altogether after this) and minor or lower priority issues (called minors altogether after this). The majors are the ones that should be fixed for a release and the minors are rolling, meaning that they are done when the corresponding developer has finished his/her majors. This of course sounds logical, but it also leads to a growing number of minors for every consecutive release, many of them which never will be fixed but in the current process will hang around.
Here is a suggested process to handle the ever growing amount of minors. If a minor issue isn't fixed after two consecutive releases it's re-reviewed and either priority changed to major (or higher), or the minor issue is closed with resolution Won't Fix and a comment. Example of comment can be that "this is an edge case where effort and benefits doesn't correlate".
I don't think the algorithm is quite fair. It means that if a really minor bug happens to be found during a relatively slow period, it gets fixed, but another bug, even considerably more important (but still falling into "not major => minor" category), can be by this time closed as "not worth fixing" just because people had been busy with some other stuff and couldn't fix it over two previous releases; while logically, if somebody suddenly has time to fix a minor bug, the latter should be fixed first. I'm fine with closing bugs as "Won't Fix", but imho it should be based on the merits of the bug itself, not on the bad timing of its creation. Since all our developers are very senior and can totally make such a decision on their own, I suppose anyone who a bug is assigned to can take a look at it and either close it as "Won't fix" with a proper explanation, regardless the timing (even right after receiving it), or keep it open. If someone isn't sure, he can always seek for colleague's advice. If somebody disagrees with closing a bug, she can always scream. /E
It should also be noted that after closing an issue in JIRA, it doesn't mean that it disappears. It will still show up in free text searches and among the issues for the version where it was closed.
Please provide your thoughts. Do you think it's an OK way to deal with the minors or do you prefer some other way?
Best regards, Rasmus
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Rasmus Johansson <rasmus@mariadb.com> writes:
This is a suggestion on how to deal with minor or lower priority bugs and tasks in JIRA, http://mariadb.org/jira .
Please provide your thoughts. Do you think it's an OK way to deal with the minors or do you prefer some other way?
The whole Jira thing is a farce. It has been going on for a year or so and it has ended up exactly as bad as I feared. It's so broken I don't know where to start. I spent lots of effort early in MariaDB to get a working release process, now it's totally destroyed, and every single minor release is taken hostage in an attempt to work around missing management of developer time. There is 100% focus on completion of whatever random tasks are in Jira and 0% on ensuring good quality of tasks actually completed. I once read an anecdote from a team at Microsoft (could be anywhere). There was management like this with lists of tasks/bugs to complete and release deadlines and such. The logical consequence of course was to "complete" tasks by pushing empty code - then it was complete, and actually doing the work was then a new "bug". MariaDB development is not a sausage factory. When Jira was initially suggested, my first comment was "we cannot use that". I won't bother people anymore with my opinions on this, they have not changed and are unlikely to do so. Hope this helps, - Kristian.
Hi Kristian, On 6/14/2013 5:39 PM, Kristian Nielsen wrote:
Rasmus Johansson <rasmus@mariadb.com> writes:
This is a suggestion on how to deal with minor or lower priority bugs and tasks in JIRA, http://mariadb.org/jira .
Please provide your thoughts. Do you think it's an OK way to deal with the minors or do you prefer some other way?
The whole Jira thing is a farce. It has been going on for a year or so and it has ended up exactly as bad as I feared.
It's so broken I don't know where to start. I spent lots of effort early in MariaDB to get a working release process, now it's totally destroyed, and every single minor release is taken hostage in an attempt to work around missing management of developer time. There is 100% focus on completion of whatever random tasks are in Jira and 0% on ensuring good quality of tasks actually completed.
I agree that we don't have any quality assurance process. I've been recently trying to gain at least some control over my part, but it's going rather slowly and apparently not very successfully. Whatever suggestions you have in this regard, please let me know, I'll take them into account. /E
I once read an anecdote from a team at Microsoft (could be anywhere). There was management like this with lists of tasks/bugs to complete and release deadlines and such. The logical consequence of course was to "complete" tasks by pushing empty code - then it was complete, and actually doing the work was then a new "bug".
MariaDB development is not a sausage factory.
When Jira was initially suggested, my first comment was "we cannot use that". I won't bother people anymore with my opinions on this, they have not changed and are unlikely to do so.
Hope this helps,
- Kristian.
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
i like the today jira process, if you want a higher priority, do some job solving the problem, after that we could have NEW FEATURE in JIRA, like: send the patch and marke the issue to "PLEASE REVIEW I HAVE SENT A SOLUTION!" (i don't remember but when this occur i set the issue to major (sorry i will not change it)) the automatic won't fix, and the two releases i think it's not nice, i sent some ideas that in my option will take many time to start a development, and maybe with this 2 releases idea it will never be done i think mariadb use jira with the sprint idea, group some issues and work on it, that's why i think changing issue isn't a good idea, the main idea is how to put the issue in the sprint i'm right?
In my opinion many of the new features of MariaDB lacks some proper documentation/benchmarks and sometimes even testing, there are many features and new variables that could be used but almost nobody knows about these or the possible usecases/downsides are not clear and users will just keep it safe and not try these unless they are sure of what they are playing with. It might be better for the end-user to have less new features but more knowledge/clarity about what he can do with the already available ones. In that matter, creating tasks on Jira to follow up features/tools that has been added/modified and putting milestones on the task such as "Create KB page on this", "Do a benchmark for this on this case" or "Document the possible downsides and usecases of that feature" might be a good idea as you can follow up the advancement and other peoples might contribute as well. It might also avoid certain questions on the KB which is IMO poorly designed in that aspect (answers are put in comments). A very short list of examples of these features/options that would benefit from a better documentation/visibility : - The optimize_join_buffer_size optimizer switch is not documented at all and is disabled by default, what is its purpose and why isnt it activated by default (lack of testing of downsides?). - Its not clear on what these variables do and which engine they apply to (there is a bug about that https://mariadb.atlassian.net/browse/MDEV-4395) : deadlock_search_depth_long, deadlock_search_depth_short, deadlock_timeout_long, deadlock_timeout_short. - The default value of aria_repair_threads is 1, are there any downsides if an higher value is set, benchmarks might also come in interest if this value can make great performance differences. - What is the use/action (if any) of the thread_cache_size variable when the threadpool is activated. - More thorough benchmarks on Aria, especially with TRANSACTIONAL = 0 & 1 compaired to MyISAM and InnoDB. - Document how to define a correct value for the segmented key cache of MyISAM (knowing that it is not working like the innodb buffer pool instances) and is there any possible downside on its usage as its deactivated by default (except for some critical bug on it such as MDEV-4409). Le 14/06/2013 17:30, Roberto Spadim a écrit :
about quality assurance process, what should be done? unit tests? test team?
maybe creating a project (in jira) about mariadb docs, could allow do do this, instead using the MDEV project, create a MDOC project to documentation or a MQA (quality) that should do test, documentation and quality features (code standard, benchmark etc etc ) at least if anyone know about something not well documented it could send a issue to this project telling what need to be documented or tested or anything else
Dnia 14-06-2013 o 12:27:22 Rasmus Johansson <rasmus@mariadb.com> napisał(a):
Hi MariaDB Developers,
This is a suggestion on how to deal with minor or lower priority bugs and tasks in JIRA, http://mariadb.org/jira .
Please provide your thoughts. Do you think it's an OK way to deal with the minors or do you prefer some other way?
I agree with Elena that closing bugs which are worth fixing is a bad idea. Even when the devs don't have time to bother with minor bugs there's always a chance that someone else will look at it and try to fix it. When I have some free time I look at the bug list and try to debug/fix something. I also agree there's a bit to much drive for new features. -- Patryk Pomykalski
participants (6)
-
Elena Stepanova -
Jean Weisbuch -
Kristian Nielsen -
Patryk Pomykalski -
Rasmus Johansson -
Roberto Spadim