[yast-devel] Refactoring areas and/or modules with several bugs
I've gone through the full list of bugs assigned to the YaST Team or some of its members with the intention of closing obsolete stuff that are not real issues anymore. In the process I found out there are some YaST modules or areas that have quite some open bugs. Some of them are modules that never receive attention (no-man shows, as HuHa likes to call them). Localization bugs (mainly problems with non-latin languages): 22 open bugs dns-server && dhcp-server (they are so related that even share bugs): 20 open bugs, aprox. NTP: 13 open bugs Bootloader: 20 open bugs, aprox. NFS: 12 open bugs, I already plan to focus the firepower of the storage squad here for the following sprint(s). Storage: 30 open bugs, aprox. but they are under control ;-) Network: hard to say, at least 50. If reducing the number of bugs is a goal, I think it would be worth to create small groups of 2-3 developers to focus on a given module for a month or two. That would be enough time to gather the knowledge about the topic and refactor the most important parts (those modules are usually not that big). In some cases, that can mean up to 20 bugs solved and a more sane codebase (plus some refreshed knowledge) for the future. Let's assume two small refactoring squads (2-3 people each) working in parallel. I think that, for example, DNS+DHCP+NFS+NTP could all be brought into shape in less than two months. That would be around 45 fewer bug reports. What do you think? Cheers PS.- Network is, of course, a completely different story. I hope we can close many bugs as obsolete in something like two years from now, when network-ng would had already replaced the current implementation. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 2019-12-20 10:03, Ancor Gonzalez Sosa wrote:
I've gone through the full list of bugs assigned to the YaST Team or some of its members with the intention of closing obsolete stuff that are not real issues anymore.
In the process I found out there are some YaST modules or areas that have quite some open bugs. Some of them are modules that never receive attention (no-man shows, as HuHa likes to call them).
Localization bugs (mainly problems with non-latin languages): 22 open bugs
dns-server && dhcp-server (they are so related that even share bugs): 20 open bugs, aprox.
NTP: 13 open bugs
Bootloader: 20 open bugs, aprox.
NFS: 12 open bugs, I already plan to focus the firepower of the storage squad here for the following sprint(s).
Storage: 30 open bugs, aprox. but they are under control ;-)
Network: hard to say, at least 50.
Great job!! Thanks a lot. Have you categorized the bugs somehow? I mean, do you have the list of bugs for each area?
If reducing the number of bugs is a goal, I think it would be worth to create small groups of 2-3 developers to focus on a given module for a month or two. That would be enough time to gather the knowledge about the topic and refactor the most important parts (those modules are usually not that big). In some cases, that can mean up to 20 bugs solved and a more sane codebase (plus some refreshed knowledge) for the future.
Let's assume two small refactoring squads (2-3 people each) working in parallel. I think that, for example, DNS+DHCP+NFS+NTP could all be brought into shape in less than two months. That would be around 45 fewer bug reports.
What do you think?
IMHO, this is a great idea. Solving bugs one by one without being focused in a specific topic/module would be quite more difficult. That small refactoring squads could make the job easier. -- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 20/12/19 10:25, José Iván López wrote:
On 2019-12-20 10:03, Ancor Gonzalez Sosa wrote:
I've gone through the full list of bugs assigned to the YaST Team or some of its members with the intention of closing obsolete stuff that are not real issues anymore.
In the process I found out there are some YaST modules or areas that have quite some open bugs. Some of them are modules that never receive attention (no-man shows, as HuHa likes to call them).
Localization bugs (mainly problems with non-latin languages): 22 open bugs
dns-server && dhcp-server (they are so related that even share bugs): 20 open bugs, aprox.
NTP: 13 open bugs
Bootloader: 20 open bugs, aprox.
NFS: 12 open bugs, I already plan to focus the firepower of the storage squad here for the following sprint(s).
Storage: 30 open bugs, aprox. but they are under control ;-)
Network: hard to say, at least 50.
Great job!! Thanks a lot. Have you categorized the bugs somehow? I mean, do you have the list of bugs for each area?
If reducing the number of bugs is a goal, I think it would be worth to create small groups of 2-3 developers to focus on a given module for a month or two. That would be enough time to gather the knowledge about the topic and refactor the most important parts (those modules are usually not that big). In some cases, that can mean up to 20 bugs solved and a more sane codebase (plus some refreshed knowledge) for the future.
Let's assume two small refactoring squads (2-3 people each) working in parallel. I think that, for example, DNS+DHCP+NFS+NTP could all be brought into shape in less than two months. That would be around 45 fewer bug reports.
What do you think?
IMHO, this is a great idea. Solving bugs one by one without being focused in a specific topic/module would be quite more difficult. That small refactoring squads could make the job easier.
+1 Thanks Ancor. -- David Díaz González YaST Team at SUSE Linux GmbH
On 20.12.19 11:25, José Iván López wrote:
If reducing the number of bugs is a goal, I think it would be worth to create small groups of 2-3 developers to focus on a given module for a month or two. ...
IMHO, this is a great idea. Solving bugs one by one without being focused in a specific topic/module would be quite more difficult. That small refactoring squads could make the job easier.
+1 CU -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Software Solutions Germany GmbH Geschäftsführer: Felix Imendörffer HRB 36809 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
V Fri, 20 Dec 2019 11:03:32 +0100 Ancor Gonzalez Sosa <ancor@suse.de> napsáno:
I've gone through the full list of bugs assigned to the YaST Team or some of its members with the intention of closing obsolete stuff that are not real issues anymore.
In the process I found out there are some YaST modules or areas that have quite some open bugs. Some of them are modules that never receive attention (no-man shows, as HuHa likes to call them).
Hi, let me first ask few question to get more details:
Localization bugs (mainly problems with non-latin languages): 22 open bugs
by non-latin you means with fancy images like chinese or right to left ones? I think that is the most affected ones and I am not sure if openqa covers it, so maybe we should try to invest to convince openqa guys to test those two specific areas.
dns-server && dhcp-server (they are so related that even share bugs): 20 open bugs, aprox.
NTP: 13 open bugs
Is it NTP SLE12 and older or NTP SLE15 and newer? As I did massive rewrite/simplification of ntp-client in SLE15 with switch from ntp to chrony. So it is important info.
Bootloader: 20 open bugs, aprox.
Can you point me to it? I am a bit curious what are they? I probably overlook them as I usually try to quickly react on bootloader problems. Sometimes they are hidden storage bugs as bootloader is a bit sensitive to some boot scenarios.
NFS: 12 open bugs, I already plan to focus the firepower of the storage squad here for the following sprint(s).
Storage: 30 open bugs, aprox. but they are under control ;-)
same here, we have old and new storage, so it would be interesting to get at least ration.
Network: hard to say, at least 50.
Yep, problem is that many are for old pre network-ng and some are basically rotting for long time or cannot be reproduced.
If reducing the number of bugs is a goal, I think it would be worth to create small groups of 2-3 developers to focus on a given module for a month or two. That would be enough time to gather the knowledge about the topic and refactor the most important parts (those modules are usually not that big). In some cases, that can mean up to 20 bugs solved and a more sane codebase (plus some refreshed knowledge) for the future.
+ ideally increase test coverage for such modules, so we are less scare in future to touch them.
Let's assume two small refactoring squads (2-3 people each) working in parallel. I think that, for example, DNS+DHCP+NFS+NTP could all be brought into shape in less than two months. That would be around 45 fewer bug reports.
What do you think?
In general good idea. Ideally we should collect that bugs in one card, then analyze them ( as often problem is not in yast or contain many duplicates ) and if it really confirm issue, then work on them. BTW I a bit missing autoyast in a list. Either we improve it so much or it is well hidden bugs ( do you have autoyast-maintainers in your query? )
Cheers
Thanks for heads-up. Josef
PS.- Network is, of course, a completely different story. I hope we can close many bugs as obsolete in something like two years from now, when network-ng would had already replaced the current implementation.
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 12/20/19 1:11 PM, Josef Reidinger wrote:
V Fri, 20 Dec 2019 11:03:32 +0100 Ancor Gonzalez Sosa <ancor@suse.de> napsáno:
I've gone through the full list of bugs assigned to the YaST Team or some of its members with the intention of closing obsolete stuff that are not real issues anymore.
In the process I found out there are some YaST modules or areas that have quite some open bugs. Some of them are modules that never receive attention (no-man shows, as HuHa likes to call them).
Hi, let me first ask few question to get more details:
Localization bugs (mainly problems with non-latin languages): 22 open bugs
by non-latin you means with fancy images like chinese or right to left ones? I think that is the most affected ones and I am not sure if openqa covers it, so maybe we should try to invest to convince openqa guys to test those two specific areas.
Basically Arabic, Chinese and friends.
dns-server && dhcp-server (they are so related that even share bugs): 20 open bugs, aprox.
NTP: 13 open bugs
Is it NTP SLE12 and older or NTP SLE15 and newer? As I did massive rewrite/simplification of ntp-client in SLE15 with switch from ntp to chrony. So it is important info.
A bit of both. Previous to the rewrite: https://bugzilla.suse.com/show_bug.cgi?id=983486 https://bugzilla.suse.com/show_bug.cgi?id=1089990 https://bugzilla.suse.com/show_bug.cgi?id=1016454 https://bugzilla.suse.com/show_bug.cgi?id=1142054 https://bugzilla.suse.com/show_bug.cgi?id=1157743 https://bugzilla.suse.com/show_bug.cgi?id=1092274 After the rewrite (I think): https://bugzilla.suse.com/show_bug.cgi?id=1082369 https://bugzilla.suse.com/show_bug.cgi?id=1039985 https://bugzilla.suse.com/show_bug.cgi?id=1155046 https://bugzilla.suse.com/show_bug.cgi?id=1157772
Bootloader: 20 open bugs, aprox.
Can you point me to it? I am a bit curious what are they? I probably overlook them as I usually try to quickly react on bootloader problems. Sometimes they are hidden storage bugs as bootloader is a bit sensitive to some boot scenarios.
NFS: 12 open bugs, I already plan to focus the firepower of the storage squad here for the following sprint(s).
Storage: 30 open bugs, aprox. but they are under control ;-)
same here, we have old and new storage, so it would be interesting to get at least ration.
Basically all for the new storage. But don't panic, many of them are small things we simply don't want to forget about. We managed to close as WONTFIX almost all the pre-storage-ng bugs.
Network: hard to say, at least 50.
Yep, problem is that many are for old pre network-ng and some are basically rotting for long time or cannot be reproduced.
I know. That's what I wrote in the post-data. I guess they will just be closed as WONTFIX in a couple of years, just like we did with storage.
If reducing the number of bugs is a goal, I think it would be worth to create small groups of 2-3 developers to focus on a given module for a month or two. That would be enough time to gather the knowledge about the topic and refactor the most important parts (those modules are usually not that big). In some cases, that can mean up to 20 bugs solved and a more sane codebase (plus some refreshed knowledge) for the future.
+ ideally increase test coverage for such modules, so we are less scare in future to touch them.
Of course.
Let's assume two small refactoring squads (2-3 people each) working in parallel. I think that, for example, DNS+DHCP+NFS+NTP could all be brought into shape in less than two months. That would be around 45 fewer bug reports.
What do you think?
In general good idea. Ideally we should collect that bugs in one card, then analyze them ( as often problem is not in yast or contain many duplicates ) and if it really confirm issue, then work on them.
BTW I a bit missing autoyast in a list. Either we improve it so much or it is well hidden bugs ( do you have autoyast-maintainers in your query?
Yes, I do have autoyast-maintainers as part of the criteria. But it's quite hard to separate AutoYaST from the rest. There are many bugs like "AutoYaST fails to configure NTP", or "AutoYaST can't import a certain disk layout" or "Bootloader wrongly configured in AutoYaST". In those cases, I have included the bugs in the corresponding categories of NTP, storage or bootloader. Of course, there are things that are exclusively caused by AutoYaST itself, but I'm relunctanct just search for "AutoYaST" and group everything into its own category. For example, from the aprox. 30 bugs I said we have in storage, actually 7 of them are AutoYaST-specific. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (5)
-
Ancor Gonzalez Sosa -
David Díaz -
Josef Reidinger -
José Iván López -
Stefan Hundhammer