[Tails-dev] Getting rid of review'n'merge email on this list

Borrar esta mensaxe

Responder a esta mensaxe
Autor: intrigeri
Data:  
Para: tails-dev
Temas novos: [Tails-dev] [review'n'merge:master] doc/no-more-review-n-merge-email [Was: Getting rid of review'n'merge email on this list]
Asunto: [Tails-dev] Getting rid of review'n'merge email on this list
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,
--
intrigeri