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
