Consider coalescing builder-github comments

[jpouellet]

Not a big deal at all, but currently qubes-builder-github generates 8 comments per issue per commit (fedora 23, fedora 24, debian jessie, and debian, * 2 for testing and stable).

This is a quite useful feature, but a bit excessive imo when just scrolling through issues.

If they could be batched in some way, say, if the packages are pushed for all templates at the same time, then just make one comment per repo with a list of the templates, I think that would be nice.

[marmarek]

Technically they may not be pushed at the same time(*) and builder-github does not know that (it gets called separately for every distribution). But I was thinking about something else: mute messages for some distributions (so have only one for Fedora and one for Debian - * 2 for testing and stable), but still add/remove related labels.
What do you think?

(*) For example sometimes build fails for Debian 7 (still supported for 3.1) and then such package gets pushed later.

[marmarek]

Technically they may not be pushed at the same time(*) and builder-github does not know that (it gets called separately for every distribution). But I was thinking about something else: mute messages for some distributions (so have only one for Fedora and one for Debian - * 2 for testing and stable), but still add/remove related labels.
What do you think?

(*) For example sometimes build fails for Debian 7 (still supported for 3.1) and then such package gets pushed later.

[andrewdavidwong]

But I was thinking about something else: mute messages for some distributions (so have only one for Fedora and one for Debian - * 2 for testing and stable), but still add/remove related labels.
What do you think?

It really depends on who relies on these messages and for what purpose. Are they purely informational for repo-watchers, or are they actionable events for certain devs?

[andrewdavidwong]

But I was thinking about something else: mute messages for some distributions (so have only one for Fedora and one for Debian - * 2 for testing and stable), but still add/remove related labels.
What do you think?

It really depends on who relies on these messages and for what purpose. Are they purely informational for repo-watchers, or are they actionable events for certain devs?

[marmarek]

It really depends on who relies on these messages and for what purpose. Are they purely informational for repo-watchers, or are they actionable events for certain devs?

Messages: mostly to notify reporting user (and anyone else who is affected by the issue) how to install the update. For devs the most useful things are labels (for all kind of filtering, like here: https://github.com/qubesos/qubes-issues/).

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[marmarek]

It really depends on who relies on these messages and for what purpose. Are they purely informational for repo-watchers, or are they actionable events for certain devs?

Messages: mostly to notify reporting user (and anyone else who is affected by the issue) how to install the update. For devs the most useful things are labels (for all kind of filtering, like here: https://github.com/qubesos/qubes-issues/).

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[andrewdavidwong]

In that case, it sounds like your muting solution will work fine.

[andrewdavidwong]

In that case, it sounds like your muting solution will work fine.

[v6ak]

My idea:

• Instead of pushing comments to directly Github, they would be pushed to some queue. It would notice repository and package name and version, that's probably all what we need.
• On repo metadata update, all the comments from queue related to updated repositories would be pushed to Github and removed from the queue.

Drawbacks:

• When metadata update is pefformed somewhere in the middle of the build (when some packages are published and some aren't), it would split the comment to two (or theoretically more).
• It more or less assumes all repository metadata is updated at once.

[v6ak]

My idea:

• Instead of pushing comments to directly Github, they would be pushed to some queue. It would notice repository and package name and version, that's probably all what we need.
• On repo metadata update, all the comments from queue related to updated repositories would be pushed to Github and removed from the queue.

Drawbacks:

• When metadata update is pefformed somewhere in the middle of the build (when some packages are published and some aren't), it would split the comment to two (or theoretically more).
• It more or less assumes all repository metadata is updated at once.

[marmarek]

It more or less assumes all repository metadata is updated at once.

Which isn't true... But the queue idea could still work when using cron instead of metadata update event as a trigger.

[marmarek]

It more or less assumes all repository metadata is updated at once.

Which isn't true... But the queue idea could still work when using cron instead of metadata update event as a trigger.

[v6ak]

Cron can solve the “comment spam”. It, however, does not neccessarily solve posting comments before the packages are available. Some more advanced queue could do the trick. For example, all items would have a published flag. Once everything related to some issue is published, the comment is posted. If queue is implemented as a SQL table, the query could look like `select issue from queue group by issue having min(published)=1`, which would select all issues for posting comments.

[v6ak]

Cron can solve the “comment spam”. It, however, does not neccessarily solve posting comments before the packages are available. Some more advanced queue could do the trick. For example, all items would have a published flag. Once everything related to some issue is published, the comment is posted. If queue is implemented as a SQL table, the query could look like `select issue from queue group by issue having min(published)=1`, which would select all issues for posting comments.