Do you think this is a security risk and if not is it a bad UI decision?
dan.mashal at gmail.com
Sat May 4 22:58:03 UTC 2013
On Sat, May 4, 2013 at 3:42 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> You posted this on friday afternoon, Rauhl re-opened the bug
> friday night. I suspect many anaconda folks have not even seen this
> discussion or the bug reopening yet. Is there some massive hurry here?
> Lets see what anaconda developers say based on the feedback
> and see if they would like to revisit the change or if they still wish
> to keep it. Or perhaps they wish more information or feedback.
> Or perhaps they will revisit it and solve it some other way. There's
> lots of options there.
As I stated before the feeling I got from their response was "this is
our decision based on this and that and too bad", and it's not the
> If they do decide to keep the change, you could escalate it to FESCo.
> However, (speaking only for myself here) I would be VERY reluctant to
> override maintainers on their packages on something that is a design
> decision/judgement call. Where would we draw the line?
I would rather have QA have move oversight on these things. As I only
discovered this while doing QA.
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".
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.
Short of doing that, it's much easier to just bring it to the
attention of this list and see what other people have to say about it.
Again, still a bit lost.
> Fedora isn't a direct democracy, and I don't think such a model would
> work well at all. Especially when it comes to how maintainers or
> people doing the work spend their time. I think it's great to bring up
> things like this and ask they be reconsidered, but mob rule isn't a
> good model.
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.
> Perhaps engage with the folks making those changes and offer to help
> out or provide more direct feedback?
As stated earlier this is not the first time I have tried to do so.
> I'm sure it will work out in the end... :)
I think that bringing it up here made a bit of difference. Thanks.
More information about the devel