On Thu, 2013-01-24 at 06:50 -0500, Kamil Paral wrote: > > 1) Create a set of six unversioned flags, using the name format we > > came > > up with for the blocker aliases (AlphaBlocker, AlphaFreezeException, > > BetaBlocker...), and use the Version: field to track the version > > being > > blocked (so a bug with Version: 18 and AlphaBlocker+ is an accepted > > blocker for F18 Alpha, a bug with Version: 19 and > > BetaFreezeException? > > is a proposed blocker for F19 Beta, etc) > > Can we somehow tell Bugzilla to switch all our flags to ? (or remove > them completely) if Version changes? So that a rejected blocker for > F18 doesn't become a rejected blocker for F19, when somebody changes > Version? Or accepted freeze exception for F18 doesn't became an > accepted freeze exception for F19? We can check these things manually, > yes, but it's tiresome. > > But in all cases, the history gets distorted. By changing Version from > 18 to 19, we no longer can query for that bug in F18. Which means are > statistics won't be fully true. Do we care? > > We can avoid the history distortion if we do a mass-change to all > accepted/rejected blockers/freeze-exceptions after the release is over > and add a special Whiteboard field for them. The statistics would be > then created using the whiteboard fields rather than flags. But that's > an extra work and an extra complexity. It still doesn't solve the > problem for Version changes. Good thinking. I hadn't considered these wrinkles, and you're absolutely right. Some of them actually apply to our current method too, but not as badly. Not much to add here except, yeah, these are legitimate concerns and they make me like this model less. > > 2) Create six versioned flags for each release, one release ahead of > > time (as we do now for blocker bugs); mark flags for finished > > releases > > as 'inactive' (this means they don't appear in the BZ UI but can > > still > > be searched on, which would be exactly what we'd want) > > This seems as a better approach, but who gets to create those flags? > Can you be given the permissions to do that? Or do we need to contact > Bugzilla administrators every time? What's their response time, can we > rely on that? I also don't know what the performance implications are > of having so many flags. So I should've made this clearer, but I checked in with the current RH BZ maintenance team ahead of time, and they didn't seem to be fazed by this idea: we would have to ask them to create the flags, but they say the turnaround time on that can be very fast and they didn't seem to hate the possibility of creating six new flags every release and archiving the old ones, so I'm guessing it's not going to cause a performance problem. > They will have to be versioned, so back from AcceptedBlocker to > f19-blocker. But I don't see it as a major problem. Yes, obviously in this plan the flags would always be versioned. > > I don't have a specific recommendation, really I just wanted to kick > > off > > a discussion and see how people feel about the possibility, and > > whether > > anyone has anything to add to the pro/minus columns. > > Who can set the flags, anyone with Bugzilla account or some special > permissions are needed, like for Blocks field? It can be done either way, and the permissions for setting ? can be made different from the permissions for setting + or -. It would seem obvious that we should let anyone set ?. We could choose to restrict the permissions for setting + or - to a certain group, but that might be overcomplicating things - we haven't had any problems with abuse of the current process, I don't think. > > It's also worth considering the possibility that blocker tracking > > could > > be moved out of BZ itself and into the blocker webapp; this has > > several > > advantages, like better integration with the webapp, reducing BZ > > spam, > > and giving us a mechanism for asynchronous review of blockers without > > BZ > > spam. So that may possibly be the best option, but it depends on > > someone > > (hi Tim!) having time to write the code. Still, it's one of Tim's > > long-term plans, and people may feel it's best to stick with tracker > > bugs until we're ready to go to that plan instead of using flags as > > an > > intermediate step. > > Actually I thought about this just a short time ago when looking at > Tim's new proposal of blocker submission form. We could manage all > that information outside of Bugzilla. What does it bring us? > > 1. faster, better interface (probably) > 2. less BZ spam > > but also > > 3. lots of extra work to duplicate basic functionality - the tracker > app has to be able to manage the list (add/edit/remove items), do > authentication/authorization (not everyone can do everything), offer > notifications, and many more. We are given that automatically by using > Bugzilla. > 4. obligation to maintain it - if something goes wrong with our > current tracker app, we can fall back to Bugzilla just fine, it's just > a bit less convenient. If we move the data into the app, we depend on > it completely. > > I think, for the time being, it's just better to use Bugzilla as a > backend and create a pretty UI for it, as we currently have. We're > quite scarce on human resources even now, I wouldn't want to put more > maintenance burden on us. The benefits of leaving Bugzilla doesn't > seem to outweigh the drawbacks. I didn't mean for this thread to turn into a detailed discussion of this possibility, I was more just including it to make people aware that the flags thing might wind up being just a stopgap. I think Tim will make a detailed proposal of his idea when he's ready. But of course, if we were to definitely reject that plan, it may change the equation with regards to using flags. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
