[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 ___ 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
Re: [Maria-developers] Process suggestion for minor issues
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 ___ 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
Re: [Maria-developers] Review request: mdev-4635
Hi Sergei,
On 06/14/2013 04:30 PM, Sergei Golubchik wrote:
Hi, Alexander!
On Jun 13, Alexander Barkov wrote:
On 06/13/2013 08:16 PM, Sergei Golubchik wrote:
=== modified file 'mysql-test/r/strict.result'
--- mysql-test/r/strict.result 2011-06-05 02:56:06 +
+++ mysql-test/r/strict.result 2013-06-13 12:15:43 +
@@ -213,11 +213,11 @@ ERROR 22007: Incorrect date value: '2004
INSERT INTO t1 (col1) VALUES(STR_TO_DATE('0.10.2004 15.30','%d.%m.%Y
%H.%i'));
ERROR 22007: Incorrect date value: '2004-10-00 15:30:00' for column 'col1'
at row 1
INSERT INTO t1 (col1) VALUES(STR_TO_DATE('31.9.2004 15.30','%d.%m.%Y
%H.%i'));
-ERROR 22007: Incorrect date value: '2004-09-31 15:30:00' for column 'col1' at
row 1
+ERROR HY000: Incorrect datetime value: '31.9.2004 15.30' for function
str_to_date
Hmm, I don't know. I liked the old error message more.
Indeed, datetime value '31.9.2004 15.30' is just fine for a function
str_to_date().
But '2004-09-31 15:30:00' is not fine for column 'col1' in the strict mode.
Why did that change?
Before the change the warning was generated in
Field_timestamp::store_TIME_with_warning.
Now this warning is generated much earlier,
in Item_func_str_to_date::get_date(),
after check_date() is called.
Which, I think, it wrong. The date is perfectly ok, as far as
STR_TO_DATE is concerted, it's wrong for a field.
The problem was that Item_func_str_to_date:
a. checked TIME_NO_ZERO_DATE
b. did not check TIME_NO_ZERO_IN_DATE (the bug)
c. did not check invalid dates
After the patch it:
a. checks TIME_NO_ZERO_DATE
b. checks TIME_NO_ZERO_IN_DATE
c. checks invalid dates
I thought it would be good to check everything,
for consistency. But a side effect is a different warning.
I agree, it should check everything. But, perhaps, the field should not
pass TIME_NO_ZERO_DATE|TIME_NO_ZERO_IN_DATE down to the arg-get_date() ?
It does not. The above warnings are not about zeros.
They are about wrong dates: for example, there is no September 31,
like in '31.9.2004 15.30'.
The last version of the patch does not change the warnings.
It works as follows:
- str_to_date checks TIME_NO_ZERO_DATE and TIME_NO_ZERO_IN_DATE
with help of check_date(), but only if the caller wants it
(CONVERT_TZ wants, field does not).
- str_to_date suppresses checking of invalid dates inside
check_date() and leaves this responsibility to the caller
(like it was before the patch).
If we want check invalid dates inside check_date() in str_to_date,
then this warning
Incorrect date value: '2004-09-31 15:30:00' for column 'col1' at row 1
won't be possible, because str_to_date does not know the name of
the column it's being inserted into.
But we could try to produce something like this:
Incorrect datetime value: '2004-09-31 15:30:00'
I.e. a better formatted value, but without the column name.
Regards,
Sergei
___
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
Re: [Maria-developers] Process suggestion for minor issues
Rasmus Johansson ras...@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. ___ 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
Re: [Maria-developers] Process suggestion for minor issues
Hi Kristian, On 6/14/2013 5:39 PM, Kristian Nielsen wrote: Rasmus Johansson ras...@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 ___ 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
Re: [Maria-developers] Process suggestion for minor issues
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? ___ 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
Re: [Maria-developers] Process suggestion for minor issues
about quality assurance process, what should be done? unit tests? test team? ___ 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
Re: [Maria-developers] Process suggestion for minor issues
(warning: it's a long one) Hi Sergei, On 6/14/2013 6:26 PM, Sergei Golubchik wrote: Hi, Elena! On Jun 14, Elena Stepanova wrote: On 6/14/2013 2:27 PM, Rasmus Johansson wrote: 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. This algorithm has a re-reviewed and either priority changed to major... step, so it's not just the timing. Not like automatic closing of old bugs. Yes, I got that part; but it doesn't change the potential faulty result. Lets say we have imaginary priorities 1-5 which are all minor, 1 being the lowest. For a while you had had a bug of priority 4. After 2 releases the reviewing force reviewed it, decided it was minor (rightly so), and closed it. A few days later you got a bug of priority 1. A few more days later you suddenly have time to fix a bug -- you are stuck at your main task and need a distraction, or you've got a headache and can't work on anything serious, or you only have half an hour before you need to go pick up kids... whatever. Naturally, you go to the list of your open bugs, take a quick look and pick whatever fits. If you still had the bug of priority 4, you'd fix it now, but instead you fix the bug of priority 1. I don't know about others, but I do keep a bunch of open low-priority tasks, and while rarely, sometimes it happens that I can do something about a minor one. And then I look at them and pick by importance and suitability for the moment, not by the creation time. 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. The main issue I didn't like - what that algorithm is making an attempt of solving - is a growing pile of minor bugs that we aren't going to fix. I agree, there is no point at keeping those that we are really not going to fix. But I don't see anything critically bad at preserving those that we *want* to fix, just currently don't have time to -- as long as we don't schedule them for the closest release, thus lying to users and to ourselves (more on that later). I also think it's two essentially different categories. Later here you are saying that a closed bug can always be reopened later and fixed. If we put the don't have resources to fix bugs into the same trash bin as we currently use for really won't fix bugs, re-opening will never happen. Who will go through the whole bunch of Won't fix bugs, review them *again* and see if they are really not worth fixing, or if we had to close them because we didn't have resources? Certainly you can't do it when you just have little time to fix one-two small bugs, you'll spend more time searching. A bug is real, so it's difficult to say won't fix, it's much easier, psychologically, to say, okay, I'll fix it, *when I have time*. But really, for minor bugs this might never happen. But sooner or later somebody who's reviewing them will dare close it anyway?.. Okay, I agree that psychologically it is easier to reject a bug *together with somebody* than make such a decision on your own, group mentality and all that, I get it and have it myself; so if it's all about having some kind of committee for closing such bugs, let it be. (I don't really know who could this committee consist of. Generally, I'm a big supporter of a triage team, it makes the process less personal. But in a company where everyone is pretty much unique in his area, it's a bit strange, because at the end only the expert can bring in an educated verdict -- and this would normally be the person the bug is already assigned to anyway; others will just be there to hold his hand.) And de-facto this leads to wrong expectations (users believe the bug will be fixed in a specific version, but it isn't) and us lying to our users. True, but I think the new approach will mess up more than it will fix. Now we
Re: [Maria-developers] Process suggestion for minor issues
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? ___ 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
Re: [Maria-developers] Process suggestion for minor issues
Dnia 14-06-2013 o 12:27:22 Rasmus Johansson ras...@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 ___ 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
