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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
