Hey folks,
I'd like to do some triage of the fedmsg issues currently open on Github, then discuss with you what we should prioritize and decide on a roadmap. Triage, first. I haven't had a chance to get to know fedmsg inimately enough so I hope you'll correct me. Here is the list of open issues in reverse chronological order, and the label that I plan to assign to them. Some may be obsolete, I'd love to have your opinion on those.
https://github.com/fedora-infra/fedmsg/issues/373 Extract underylying technology stack into a clearly Fedora independent library? -> enhancement, docs
https://github.com/fedora-infra/fedmsg/issues/372 fedmsg-logger --json-input can't handle multiline json -> bug, easyfix
https://github.com/fedora-infra/fedmsg/issues/371 fedmsg-hub pulls a huge amount of backlog from datagrepper when simply restarted -> enhancement, performance
https://github.com/fedora-infra/fedmsg/issues/370 irc bot no messages -> docs
https://github.com/fedora-infra/fedmsg/issues/365 Add file-based locking to CRL modification -> bug
https://github.com/fedora-infra/fedmsg/issues/339 OS name, release and architecture to meta? -> enhancement, easyfix
https://github.com/fedora-infra/fedmsg/issues/320 BadObject when deleting a branch from git repository -> obsolete?
https://github.com/fedora-infra/fedmsg/issues/312 encoding discrepancies between php and python -> bug
https://github.com/fedora-infra/fedmsg/issues/304 python sample does not work like suggested in docs -> docs
https://github.com/fedora-infra/fedmsg/issues/302 fedmsg-relay --daemon ENVAL and flooding logs -> bug
https://github.com/fedora-infra/fedmsg/issues/260 seperate colors for the secondary arch builds on irc? -> enhancement
https://github.com/fedora-infra/fedmsg/issues/172 Add fedmsg hooks for transifex platform -> enhancement, blocked
https://github.com/fedora-infra/fedmsg/issues/159 Add fedmsg-meta-debian to the topics docs -> docs
https://github.com/fedora-infra/fedmsg/issues/156 Should BaseProcessor default to None for string-returning methods? -> enhancement, breaks-compat
https://github.com/fedora-infra/fedmsg/issues/148 Implement callback to check the state of the socket in fedmsg.tail_messages -> enhancement
https://github.com/fedora-infra/fedmsg/issues/137 Askbot messages should distinguish between answer and comment -> enhancement
https://github.com/fedora-infra/fedmsg/issues/119 static analysis consumer -> enhancement
https://github.com/fedora-infra/fedmsg/issues/114 Add a g+ bot -> enhancement
https://github.com/fedora-infra/fedmsg/issues/91 Rename fedmsg to python-fedmsg in rpm-land. -> obsolete? (fedmsg only contains doc and depends on python-* packages)
https://github.com/fedora-infra/fedmsg/issues/47 fedmsg.text internationalization -> enhancement
I'll go ahead and apply those labels (except the "obsolete" ones) but I'd love to have your thoughts on them and on the general process. Thanks!
Aurélien
On Wed, 2 Nov 2016 16:24:40 +0100 Aurelien Bompard abompard@fedoraproject.org wrote:
Hey folks,
I'd like to do some triage of the fedmsg issues currently open on Github, then discuss with you what we should prioritize and decide on a roadmap. Triage, first. I haven't had a chance to get to know fedmsg inimately enough so I hope you'll correct me. Here is the list of open issues in reverse chronological order, and the label that I plan to assign to them. Some may be obsolete, I'd love to have your opinion on those.
One thought: do we want to look at migrating to pagure and doing the triage there? Or doing triage now and moving later?
https://github.com/fedora-infra/fedmsg/issues/373 Extract underylying technology stack into a clearly Fedora independent library? -> enhancement, docs
https://github.com/fedora-infra/fedmsg/issues/372 fedmsg-logger --json-input can't handle multiline json -> bug, easyfix
https://github.com/fedora-infra/fedmsg/issues/371 fedmsg-hub pulls a huge amount of backlog from datagrepper when simply restarted -> enhancement, performance
https://github.com/fedora-infra/fedmsg/issues/370 irc bot no messages -> docs
https://github.com/fedora-infra/fedmsg/issues/365 Add file-based locking to CRL modification -> bug
https://github.com/fedora-infra/fedmsg/issues/339 OS name, release and architecture to meta? -> enhancement, easyfix
https://github.com/fedora-infra/fedmsg/issues/320 BadObject when deleting a branch from git repository -> obsolete?
This is likely also https://pagure.io/fedora-infrastructure/issue/4022 Perhaps I should close that one UPSTREAM? (I have no idea if it still needs fixing)
https://github.com/fedora-infra/fedmsg/issues/312 encoding discrepancies between php and python -> bug
https://github.com/fedora-infra/fedmsg/issues/304 python sample does not work like suggested in docs -> docs
https://github.com/fedora-infra/fedmsg/issues/302 fedmsg-relay --daemon ENVAL and flooding logs -> bug
https://github.com/fedora-infra/fedmsg/issues/260 seperate colors for the secondary arch builds on irc? -> enhancement
https://github.com/fedora-infra/fedmsg/issues/172 Add fedmsg hooks for transifex platform -> enhancement, blocked
https://github.com/fedora-infra/fedmsg/issues/159 Add fedmsg-meta-debian to the topics docs -> docs
https://github.com/fedora-infra/fedmsg/issues/156 Should BaseProcessor default to None for string-returning methods? -> enhancement, breaks-compat
https://github.com/fedora-infra/fedmsg/issues/148 Implement callback to check the state of the socket in fedmsg.tail_messages -> enhancement
https://github.com/fedora-infra/fedmsg/issues/137 Askbot messages should distinguish between answer and comment -> enhancement
https://github.com/fedora-infra/fedmsg/issues/119 static analysis consumer -> enhancement
https://github.com/fedora-infra/fedmsg/issues/114 Add a g+ bot -> enhancement
https://github.com/fedora-infra/fedmsg/issues/91 Rename fedmsg to python-fedmsg in rpm-land. -> obsolete? (fedmsg only contains doc and depends on python-* packages)
https://github.com/fedora-infra/fedmsg/issues/47 fedmsg.text internationalization -> enhancement
I'll go ahead and apply those labels (except the "obsolete" ones) but I'd love to have your thoughts on them and on the general process. Thanks!
All those sound good to me.
kevin
On Thu, Nov 03, 2016 at 09:18:43AM -0600, Kevin Fenzi wrote:
This is likely also https://pagure.io/fedora-infrastructure/issue/4022 Perhaps I should close that one UPSTREAM? (I have no idea if it still needs fixing)
Nah that's bug in our git hook that is in ansible.
There are two ways to go about it: - Announce git branch that are removed - Don't (on pagure I took the second approach).
If we want to take the first approach, we'll need to adjust fedmsg_meta_fedora_infra for a new topic.
I can take this one, any preferred solution?
Pierre
On Tue, 8 Nov 2016 16:04:38 +0100 Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Thu, Nov 03, 2016 at 09:18:43AM -0600, Kevin Fenzi wrote:
This is likely also https://pagure.io/fedora-infrastructure/issue/4022 Perhaps I should close that one UPSTREAM? (I have no idea if it still needs fixing)
Nah that's bug in our git hook that is in ansible.
There are two ways to go about it:
- Announce git branch that are removed
- Don't
(on pagure I took the second approach).
If we want to take the first approach, we'll need to adjust fedmsg_meta_fedora_infra for a new topic.
I can take this one, any preferred solution?
well, I don't much care honestly. We could just not announce things until someone asks us to add that message? But on the other hand, if we had the message someone might think of some use of it. ;)
kevin
On Tue, Nov 08, 2016 at 04:04:38PM +0100, Pierre-Yves Chibon wrote:
On Thu, Nov 03, 2016 at 09:18:43AM -0600, Kevin Fenzi wrote:
This is likely also https://pagure.io/fedora-infrastructure/issue/4022 Perhaps I should close that one UPSTREAM? (I have no idea if it still needs fixing)
Nah that's bug in our git hook that is in ansible.
There are two ways to go about it:
- Announce git branch that are removed
- Don't
(on pagure I took the second approach).
If we want to take the first approach, we'll need to adjust fedmsg_meta_fedora_infra for a new topic.
I can take this one, any preferred solution?
I don't have a preference on which route you take, Pierre.
But, this brings up a separate, new issue: we did a good thing and a bad thing.
The good thing is that when Mike Bonnet wrote the dist-git message hook for Red Hat's dist-git, we did our best to copy the message format published by the Fedora hook. The goal here is that we can now write message consumers that respond to either Fedora dist-git messages or RH dist-git messages.. and they'll just work (fingers crossed). We can share more infrastructure code!
The bad thing is that we copied the code for the dist-git hook and rewrote it to use the internal message bus tech (my bad). So now, if you add a new message type (deleting a branch) we won't inherit that automatically over on the RH side. We'll have to keep updating our hook every time you update yours. Worse, you may introduce a change that we never notice, and then we'll be weirdly out of sync.
Obviously, neither of us is obligated to stay in sync with the other, but it would be nice to share common message formats. Towards that end, I figured I should just let you all know what we're doing.
On Tue, Nov 08, 2016 at 08:25:45PM -0500, Ralph Bean wrote:
On Tue, Nov 08, 2016 at 04:04:38PM +0100, Pierre-Yves Chibon wrote:
On Thu, Nov 03, 2016 at 09:18:43AM -0600, Kevin Fenzi wrote:
This is likely also https://pagure.io/fedora-infrastructure/issue/4022 Perhaps I should close that one UPSTREAM? (I have no idea if it still needs fixing)
Nah that's bug in our git hook that is in ansible.
There are two ways to go about it:
- Announce git branch that are removed
- Don't
(on pagure I took the second approach).
If we want to take the first approach, we'll need to adjust fedmsg_meta_fedora_infra for a new topic.
I can take this one, any preferred solution?
I don't have a preference on which route you take, Pierre.
But, this brings up a separate, new issue: we did a good thing and a bad thing.
The good thing is that when Mike Bonnet wrote the dist-git message hook for Red Hat's dist-git, we did our best to copy the message format published by the Fedora hook. The goal here is that we can now write message consumers that respond to either Fedora dist-git messages or RH dist-git messages.. and they'll just work (fingers crossed). We can share more infrastructure code!
Cool :)
The bad thing is that we copied the code for the dist-git hook and rewrote it to use the internal message bus tech (my bad). So now, if you add a new message type (deleting a branch) we won't inherit that automatically over on the RH side. We'll have to keep updating our hook every time you update yours. Worse, you may introduce a change that we never notice, and then we'll be weirdly out of sync.
Is there a way/possibility to correct this now?
Thanks for the info, I'll try to keep it in mind and to ping you when we change this hook.
Pierre
On Wed, Nov 09, 2016 at 12:46:48PM +0100, Pierre-Yves Chibon wrote:
On Tue, Nov 08, 2016 at 08:25:45PM -0500, Ralph Bean wrote:
On Tue, Nov 08, 2016 at 04:04:38PM +0100, Pierre-Yves Chibon wrote:
On Thu, Nov 03, 2016 at 09:18:43AM -0600, Kevin Fenzi wrote:
This is likely also https://pagure.io/fedora-infrastructure/issue/4022 Perhaps I should close that one UPSTREAM? (I have no idea if it still needs fixing)
Nah that's bug in our git hook that is in ansible.
There are two ways to go about it:
- Announce git branch that are removed
- Don't
(on pagure I took the second approach).
If we want to take the first approach, we'll need to adjust fedmsg_meta_fedora_infra for a new topic.
I can take this one, any preferred solution?
I don't have a preference on which route you take, Pierre.
But, this brings up a separate, new issue: we did a good thing and a bad thing.
The good thing is that when Mike Bonnet wrote the dist-git message hook for Red Hat's dist-git, we did our best to copy the message format published by the Fedora hook. The goal here is that we can now write message consumers that respond to either Fedora dist-git messages or RH dist-git messages.. and they'll just work (fingers crossed). We can share more infrastructure code!
Cool :)
The bad thing is that we copied the code for the dist-git hook and rewrote it to use the internal message bus tech (my bad). So now, if you add a new message type (deleting a branch) we won't inherit that automatically over on the RH side. We'll have to keep updating our hook every time you update yours. Worse, you may introduce a change that we never notice, and then we'll be weirdly out of sync.
Is there a way/possibility to correct this now?
Not an easy way that I can see. The pygit2 code is mostly the same, but there's a not-small amount of proton[1] boilerplate to get the message out the door.
Thanks for the info, I'll try to keep it in mind and to ping you when we change this hook.
Thanks :)
infrastructure@lists.fedoraproject.org
-
Aurelien Bompard -
Kevin Fenzi -
Pierre-Yves Chibon -
Ralph Bean