Mailinglist Archive: yast-devel (61 mails)

< Previous Next >
[yast-devel] RFC: New rules for yast-maintainers

As Gabi has pointed-out today, we have a growing list of bugs reported for Yast, assigned to the default assignee: yast-maintainers. Some of the bugs cannot be fixed easily now as we do not have a single person who would take care about "that particular module", "usability" or "design".

For me, this is a perfect way for fixing bugs in an agile way:
- Project manager decides what needs to be fixed and when
- We will find out who can fix or which expertise we need
- And we'll either assign these bugs to respective people in time or try to find help outside

But we need to find a way how not to get lost in bugs assigned to yast-maintainers. And there are several possibilities:

1. NEW bug needs to be checked and either reassigned or at least marked as reviewed/confirmed
2. CONFIRMED bug should have a [yast2-*] in Summary, so we know it has been reviewed already / or we could add new keyword e.g. "reviewed". The current "Yast Maintainer" must make sure that summary describes the issue well
3. IN_PROGRESS should have a real assignee, this would need cooperation with PjM/PM, so they set real priority
4. We will definitely not be able to fix all bugs, so there needs to be a way to drop as CANTFIX/WONTFIX according to given criteria
5. Features should be closed as FEATURE and the reported advised to use FATE.
6. Yast maintainer should take care only about bugs that haven't been reviewed, for that a simple search should be possible (e.g.: doesn't contain `reviewed` flag)

Please review, and/or come with better ideas. I know this is yet another rule-set, maybe you'll have a better idea.



Lukas Ocilka, Systems Management (Yast) Team Leader
Cloud & Systems Management Department, SUSE Linux
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >