intrigeri: > Hi, > > some of us are tired of having to ask for review'n'merge on this list, > duplicating the (semantically more powerful) action of setting > a ticket as Ready for QA in Redmine. Recently, we tend to forget more > and more often to send such email; moreover, some teams (e.g. the doc > and test suite teams) have simply stopped sending them already. > > Besides, I bet that some list subscribers would be glad if such > notifications were opt-in. > > Nevertheless, at least I have always resisted getting rid of these > email, on the grounds that we have no other working, tested and > advertised way of following what changes are proposed to go into > Tails, and of voicing concerns *before* changes land in our release > Git branches. I still strongly feel we need that, but perhaps I'm > overdoing it a little bit. > > So, a few days ago I finally pointed my feed reader at the Atom > feed [1] generated from the "Ready for QA" custom Redmine query [2]. > A few days later, indeed it seems that I got notifications for every > ticket that was flagged as Ready for QA. There's an exception, though: > if a ticket was marked as Ready for QA, and then review'n'merged, and > then flagged as "Fix committed", all that between two fetches of my > feed reader, then I would never get any notification for that ticket. > > I see two options from this point: > > A) Decide that the Atom feed is good enough and document it, with its > aforementioned limitation (so that people can adjust their config). > I volunteer to do that if we decide to go this way. > > B) Decide that it's not good enough, and then look into a push > notification solution. Or, set up a dedicated mailing-list that > a rss2email instance will email. That rss2email will need to run as > often as reasonably possible, so that it misses as few Ready for QA > tickets as possible.. > > With my "OMG we need to provide a Perfect™ way to track this stuff" > hat on, of course I'm inclined to prefer (B). But realistically, > I believe that (A) will be good enough for 99.99% of use cases I care > about, and our sysadmin team is overloaded with new services design > help + deployment requests already, so the benefits of (B) don't seem > worth adding it to that team's plate. > > Thoughts, opinions? > > [1] > https://labs.riseup.net/code/projects/tails/issues.atom?key=MYSECRET&query_id=117 > [2] https://labs.riseup.net/code/projects/tails/issues?query_id=117 > > Cheers, > I'm only in the doc team, so I don't feel overly concerned, but getting rid of those mails is a good idea indeed. Since I won't follow it, I don't have preferences for the notifications, but I think it's good to not overwhelm our infra team, so go with the (A) solution and revisit if people feel it's not good enough?
Cheers, BitingBird _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
