On Sat, May 04, 2013 at 15:58:03 -0700, Dan Mashal <dan.mas...@gmail.com> wrote:
I would rather have QA have move oversight on these things. As I only discovered this while doing QA.
QA isn't really the right place to make up policy. This particular case doesn't seem to be something that would merit any action by QA unless the Fedora community developed an over arching possibly on when passwords can and cannot be displayed.
Excuse my cynicism here but this would also require some change to the QA process itself and what are blockers and what are not and the "nice to have" process which should be renamed "we won't hold our breath".
The "Nice to Have" process has been renamed "Freeze Exception", which better describes what it does.
So say I did bring this up as a blocker under new criterion like "This isn't broken but probably a bad idea criterion" that I think should be defined (with a better name) and it was -1'd by the whoever was around during the meeting because most of us have $dayjobs, only then would I feel it appropriate to bring up to FESCo and then possibly the board.
I don't think this would fly as a QA criterion. QA aren't necessarily in the best position to decide on whether or not general things are good or bad ideas.
I'm not saying it should be on everything. But changes to I guess "CRITPATH" packages (which anaconda is one of I think) should be vetted in the community not on the anaconda maintainer list first.
I don't think critpath is the right description to use here. I think where you want to head is the long intended changes to the Feature process. Though I am not sure this subpart of the anconda UI change would really rate a Feature all on its own. The Anaconda rewrite is a Feature and they have been reaching out for feedback.
While I think feedback from the community is nice, I think the maintainers should generally be making the decisions (rather than voting) as the maintainers generally will know more about the problem than random community members.
I also think it is likely that if maintainers start getting overridden by community vote, we are going to start losing maintainers.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
