Do you think this is a security risk and if not is it a bad UI decision?

Adam Williamson awilliam at redhat.com
Sat May 4 23:28:32 UTC 2013


On Sat, 2013-05-04 at 15:58 -0700, Dan Mashal wrote:

> > 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".

I don't really see any special place for QA in reviewing design
decisions. I've said it before, but my opinion is that the job of QA is
to determine whether things are working as intended, not to decide what
the intentions should be.

As a practical matter, I don't think any of our test cases, release
criteria, or anything else have anything to say on the topic of password
masking; I don't think an unmasked password entry box violates any of
our release requirements.

I don't immediately see any relevance to the 'freeze exception' process,
which used to be called the 'nice to have' process but was renamed to
make its purpose clearer. The 'freeze exception' process is a process
which allows us to decide what changes we should allow as freeze
exceptions. That's really it. I don't immediately see any relevance it
has to this topic. The FE/NTH process is not and never was some kind of
tool for QA or anyone else to force any developers to make any
particular decisions; FE status does not mean 'we have decreed you must
change this to how we think it must be'. The NTH name was very confusing
and could have implied all kinds of things, hence the change to 'freeze
exception', but the actual intent of the process has always been the
same.

> So say I did bring this up as a blocker under new criterion like "This
> isn't broken but probably a bad idea criterion" 

Personally I think that would be a really terrible criterion. The
release criteria are intended to define, as objectively as possible, a
minimum baseline set of functionality that should be operational for any
given Fedora release to go out. The release validation / blocker review
process is not meant to be a talking shop (any more than it needs to
be), a form of code review, or a 'I think this issue is important' list.
It's a tightly focused process which is intended to ensure we reach a
minimum level of functionality for each release point, and that's all it
is. There are many issues that are potentially of extreme importance to
at least _someone_ which, for various reasons, would not make any sense
to consider in the context of the release validation process.

> 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.

So this is turning into an open ended discussion, and I think Kevin gave
you a great reply, but here's one thing I'd add: relax. You're working
on a massive project that involves hundreds/thousands of people. It is
not possible, however you organize such a project, for everyone to have
a voice in everything. It is not possible to subject every decision to
some kind of public review process. It is a statistical certainty that
things you disagree with are going to happen. This is something you need
to reconcile yourself to. Of course you can raise your voice on topics
that concern you, and of course we can try to make our processes as open
as possible, but however we do things, _stuff you don't like is going to
happen_, and you've got to be comfortable with that, or you're going to
get frustrated and burnt out very quickly. I find it helps to keep a
sense of perspective, to be able to say 'okay, I think that's a really
silly design, but it's just not the end of the world, it's a piece of
software, the sun is still shining outside'. We need passionate people,
and I love that you _really care a lot_, but it can be problematic if
you get into the frame of mind that you care so much that you're
convinced that every decision you disagree with, every thing that
happens that you don't think should have happened, is a howling
emergency or a personal failure on your part or someone else's part.
It's not. It's just...the way things are.

> 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 it hurts to have a process for review of really
controversial changes, and of course in some circumstances it's a good
thing for major changes to be proposed and discussed publicly rather
than just being implemented. But it's not practically possible to 'vet'
every single change to every critpath package; how would we ever get any
work done? So there's a line there somewhere, and given the way a
project like Fedora works, the maintainers of any component are going to
have a lot of leeway in determining where that line is drawn, what
changes they think they should propose as features or bring up for
review in some other way and what changes they just go ahead and make.
Someone would have to be drawing that line in a way that a large
majority of people thought was completely wrong, for a long time, before
it would be a good idea to start whacking them with a hammer of some
kind. There are always trade-offs to be drawn, and the problem with 'the
project' or 'management' or whatever keeping too tight a rein on
development and demanding a week of discussion and formal review and
whatever else for every change is that the developers just get
frustrated and either do the minimum possible work, or just quit,
neither of which is a good outcome.

> > 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.

It helps to remember the times when things go well as well as when they
go badly. I think I can think of the two or three things you're thinking
about where you (and several others) and the anaconda team have/had a
Major Difference Of Opinion. But I can also think of cases where you or
I or one of many other people have brought up a concern to the anaconda
team, and changes have been made in response. There have been major
changes to newUI in F19, for instance, in response to feedback from you,
me, the rest of the QA team, and others (on this list, in the forums,
and so forth). There will be times when we're all just going to have to
agree to disagree; as I said above, that's a thing that's just going to
happen. But I think you might be being unfair on the anaconda team and
getting needlessly frustrated if you're starting to think they are
impervious to any form of outside input.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net



More information about the devel mailing list