> > > * I don't understand the "Release Number" in the HTML form much. > > > We're working on a single release at a time. What's the purpose? > > > > The thought was to support proposing blockers against the next > > release, > > not just the release which is currently under development. Not sure > > it's incredibly important but that was the idea :) > > Yeah, it's for the case when, say, right now you want to propose a > bug > as a blocker for F20 Alpha right now. It'd be unusual at the moment, > but > it does come up later in the cycle. This is the same reason we create > the blocker tracker bugs two releases in advance, not one. Hum, I've never used that approach (proposing something for N+2). If we want to keep the form as simple as possible, we might consider leaving that option out. I guess operating on N+2 is something that not many people do and those people are probably every capable of using the Bugzilla directly. But this is just a cosmetic thing, definitely. > > > > * As the first cut, I think the form is quite fine. But in the > > > future > > > I imagine we should have a bit different process and the form can > > > adjust to it. My very rough idea: > > > - A person can propose any important bug into "QA watchlist". > > > He/she > > > will acknowledge that the bug complies to our basic requirements > > > (it's critical or affecting a lot of users, it doesn't concern > > > just a > > > tiny fraction of hardware, it can't be fixed post-release or > > > significantly lowers user experience, etc). QA goes through the > > > QA > > > watchlist periodically, some bugs are removed right away, some > > > are > > > moved to the blocker/freeze-exc list, some are just kept an eye > > > on. > > > > This is an interesting idea, my only concern would be about who's > > watching the list and any implicit promises that we would be making > > with regard to attention given to a bug. > > > > What would be the end benefit to implementing something like this? > > Making the proposal process easier for people who aren't generally > > involved in the blocker process? Having another grouping of bugs > > that > > aren't blockers, aren't FEs but could be a problem and might be > > worth > > testing more? Yes and somewhat yes. I find it unfortunate that we require all people to distinguish between Alpha/Beta/Final milestones. Some bugs might be proposed for later milestones, just because people are not so familiar with our milestone requirements (and which are not easy to understand at all). So I'd like to give people an option to propose it to a "general" tracker and we should fill the correct milestone. I'd also like to give people some simplified criteria how to decide whether to propose the current bug as a blocker or not. I assumed we could combine this with a watchlist of bugs that are very inconvenient for the user, but not really fitting the blocker process. The can't-install-rpmfusion bug is a good example. So we would have a common pool of important bugs, some of them would get 'upgraded' to proposed blockers, others would serve as a list of things to push developers to fix. I said it was a rough idea, I found it relevant so I mentioned it. I don't have it well thought-out yet. I just wanted to briefly let you know what I've been thinking about. > > Right, I'm not 100% sure what this would be for. That sounds > suspiciously like the old Target tracker, which was dropped because > it > was being roundly ignored by everyone. Sometimes I feel a need for > such > a thing - 'hey, this is important, we should keep an eye on it, but > it's > not an FE' - but then I think, hmm, no-one paid any damn attention to > the last such list we had, so... I didn't know we had such a tracker before. Was it before my time, or was I simply oblivious to it? It's a pity that it didn't work out well. Do you have some ideas why it didn't work and how to make it work? -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
