Closed
Bug 1144589
Opened 9 years ago
Closed 3 years ago
add a sheriff on duty field to treestatus
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: cbook, Unassigned, Mentored)
References
Details
(Keywords: good-first-bug)
Attachments
(2 files)
we got some feedback like : "Sometimes it is not easy to know who is currently on sheriff duty. Probably it could be shown in Treeherder or the IRC channel, so that it would be easier to find." for people outside of irc (and so not getting the |sheriffduty) thing maybe this would be possible like something "sheriff on duty : name" or like when no one is around like "sheriff on duty : #developers " when no one is on duty. Maybe this could setting if you are "onduty" could be integrated in the sheriffing tab in treeherder with some simple checkbox or so to opt-in when you are on duty or so :)
Comment 1•9 years ago
|
||
I wonder if the Sheriffing presence would be helpful even for users who don't have access to the Sheriff menu, or aren't logged in? ie. we could put it in the top navbar as a separate element. And dim/monochrome it, or suppress it entirely when a sheriff is not on duty.
Comment 2•9 years ago
|
||
Oh ya, and noting the icon used above was fa-user-md, RGB 255, 190, 127.
Comment 3•9 years ago
|
||
And guessing in implementation/UX the Sheriff would go into the sheriff panel and make themselves the active Sheriff, from some new ng-model sheriff name dropdown, or similar. And we might want to always set the current sheriff back to "" when they log out, assuming we can establish they aren't logged in from any other client.
Comment 4•9 years ago
|
||
And.. if we don't hide it, a rough mock for no sheriff on duty. If we have different sheriffs for different repos(?), I assume we would need to switch both the state and sheriffid, when switching between repos.
Updated•9 years ago
|
Priority: -- → P3
Hardware: x86 → All
Comment 5•9 years ago
|
||
I think this might be best set in treestatus - it goes quite closely along with tree status, MOTDs, landing rules etc. Treeherder could then pull that data out. Thoughts?
Priority: P3 → P4
Comment 6•9 years ago
|
||
(In reply to Ed Morley [:emorley] from comment #5) > I think this might be best set in treestatus - it goes quite closely along > with tree status, MOTDs, landing rules etc. Treeherder could then pull that > data out. Thoughts? No objections, moving to Treestatus. If/when treestatus supports this, and if you wish for it to be surfaced in Treeherder, please file a new Treeherder bug.
Component: Treeherder → TreeStatus
Priority: P4 → --
Updated•9 years ago
|
Summary: add a sheriff on duty field to treeherder → add a sheriff on duty field to treestatus
Comment 7•9 years ago
|
||
This could be exposed as a feature of pulsebot as well, since it currently supports being requested about the status of a tree.
Assignee | ||
Updated•9 years ago
|
Product: Tree Management → Release Engineering
Updated•9 years ago
|
QA Contact: dustin
Comment 8•9 years ago
|
||
Seems like this is a TH issue?
Component: TreeStatus → Treeherder
Product: Release Engineering → Tree Management
QA Contact: dustin
Comment 9•9 years ago
|
||
No, since: (In reply to Ed Morley [:emorley] from comment #6) > (In reply to Ed Morley [:emorley] from comment #5) > > I think this might be best set in treestatus - it goes quite closely along > > with tree status, MOTDs, landing rules etc. Treeherder could then pull that > > data out. Thoughts? > > No objections, moving to Treestatus. > If/when treestatus supports this, and if you wish for it to be surfaced in > Treeherder, please file a new Treeherder bug.
Component: Treeherder → TreeStatus
Product: Tree Management → Release Engineering
QA Contact: dustin
Updated•8 years ago
|
Whiteboard: [good-first-bug][mentor=dustin]
Updated•8 years ago
|
Whiteboard: [good-first-bug][mentor=dustin] → [good-first-bug]
Updated•8 years ago
|
Mentor: dustin
See Also: → 1283741
Updated•8 years ago
|
Comment 10•8 years ago
|
||
this could also be exposed as a feature of firebot (currently it grabs the sheriff from the topic of #sheriffs).
So, I was thinking... We could just add a new "tree" (called 'sheriffduty' or similar) into Treestatus, and we could just use the "reason" field to store the sheriff on duty. Any tool capable of reading from Treestatus could then check the "sheriffduty" tree and display the sheriff on duty without really having to change anything (other than hardcoding to the "sheriffduty" tree rather than being able to check any tree, I suppose). This new tree could just be in a perpetual `open` state so we wouldn't need to specify a closure reason whenever the sheriff changes. We'd be able to take advantage of the logging already built into treestatus to track who is making changes to the tree, along with timestamps. This would be much easier than trying to add a few feature to Treestatus that would have to be supported forever in RelengAPI, and Treeherder/pulsebot/firebot all already know how to read from Treestatus. We could maybe bloat the scope of bug 1283741 a bit to add the ability to authenticate with RelengAPI to be able to quickly update the status of the sheriffduty "tree" directly from Treeherder, pre-setting the tree status to `open`, unchecking tags, and perhaps setting "remember change" to `false`. Thoughts?
Flags: needinfo?(emorley)
Flags: needinfo?(dustin)
Comment 12•8 years ago
|
||
> This new tree could just be in a perpetual `open` state
... or it could be closed when there is no sheriff on duty...
Comment 13•8 years ago
|
||
While we're at it, we could probably come up with a way to write an arbitrary object-storage frontend on top of the treestatus DB, similar to hacks people have built to implement a FUSE filesystem that backends to the gmail "Drafts" folder. But seriously, this seems like a hack, and I don't see the motivation. I think it would be a bit harder (and certainly a lot more confusing!) than adding a new feature to treestatus to store the sheriff on duty. And I don't think it's any more difficult to modify firebot et al. to fetch the sheriff on duty from a new API than it would be to modify them to fetch that information from a specially-named tree.
Flags: needinfo?(dustin)
Comment 14•8 years ago
|
||
(In reply to Dustin J. Mitchell [:dustin] from comment #13) > But seriously, this seems like a hack, and I don't see the motivation. I > think it would be a bit harder (and certainly a lot more confusing!) than > adding a new feature to treestatus to store the sheriff on duty. +1 this should be immediately discoverable to real people, which means adding it as a true feature. optimising for minimising a one-time change to bots/etc over ongoing discoverability doesn't seem right.
Comment 15•8 years ago
|
||
Agree that's a bit hacky. Also doubt it would be any easier -- the bots etc would still need to perform some kind of mapping, otherwise humans are going to get confused by tree-like status messages that aren't really about a tree.
Flags: needinfo?(emorley)
Reporter | ||
Comment 16•7 years ago
|
||
note, from this years Sheriffs Survey is the most demanded feature to know who is on sheriffduty. This field etc should help a lot with that.
Reporter | ||
Comment 17•7 years ago
|
||
Ed: any idea here to move forward since this would help to fix the top most requested issues from our devs etc
Flags: needinfo?(emorley)
Comment 18•7 years ago
|
||
TreeStatus is owned by Release Engineering, so you could ask if they could include it in next quarters plans? Or you could try out a PR yourself? The source is here: https://github.com/mozilla-releng/services/tree/master/src/releng_treestatus
Flags: needinfo?(emorley)
Comment 19•7 years ago
|
||
As far as implementation goes, the simplest would be to have a single row stored in a new table that is the name of the current sheriff, that gets overwritten on each change. Setting/getting this would then need to be exposed via the API, and UI. Or else if history were desired, something similar to the existing Log model used instead: https://github.com/mozilla-releng/services/blob/0ca3a72b9f816e0780bed7ccc5b47e51d940b8fb/src/releng_treestatus/releng_treestatus/models.py#L59-L88 I see treestatus has alembic in its dependencies -- so you'd need to figure out the best way to run the schema migration using it. In addition, I wonder if there should be some indication of which trees are actually sheriffed? So as a follow-on bug perhaps the Tree model modified to add a `is_sheriffed` bool.
Comment 20•6 years ago
|
||
Hello! I am looking for a bug to get started with my first contribution, is it still a relevant bug? If so please help me get started on this. Thanks
Comment 21•6 years ago
|
||
It is certainly still something we would like, but I'm not a good mentor for it anymore -- the project and I have moved in different directions. Rok, is this something you could mentor?
Flags: needinfo?(rgarbas)
Comment 22•6 years ago
|
||
Hi akanksha, sorry for late reply. this skipped my radar. lets add this functionality to treestatus. For now I propose to create 2 endpoints - get /onduty/<team>/ <- returns current on duty person for that team - patch /onduty/<team>/ <- sets (logged in ) user to be activly on duty Where team is one of: - sherrifs - release - ci Where to start coding - to get up your environment please follow this guide -> https://docs.mozilla-releng.net/develop/contribute.html - code of treestatus can be found here -> https://github.com/mozilla/release-services/tree/master/src/treestatus/api - to get help in realtime we hang in #release-services IRC channel
Flags: needinfo?(rgarbas)
Comment 23•5 years ago
|
||
Hi Rok, I want to take up this bug. I've tried setting up the environment but getting the following error: https://gist.github.com/paras0419/afd7f569f9889b7efd7ea14d93c16514 Need help.
Comment 24•5 years ago
|
||
Hi Rok, I want to take up this bug. I've tried setting up the environment but getting the following error: https://gist.github.com/paras0419/afd7f569f9889b7efd7ea14d93c16514 It'll be great if you can help me fix the env setup. I tried messaging on the #release-services channel, not much of help.
Flags: needinfo?(rgarbas)
Comment 25•5 years ago
|
||
Hi :paras0419, it looks like majority of the team is on vacations. that is why a slow response. let me try to document now how to fix this error and i will provide you a link to that documentation in few hours.
Flags: needinfo?(rgarbas)
Comment 26•5 years ago
|
||
(In reply to Rok Garbas [:garbas] from comment #25) > Hi :paras0419, it looks like majority of the team is on vacations. that is > why a slow response. let me try to document now how to fix this error and i > will provide you a link to that documentation in few hours. Yea I kind of forgot about the holidays. But a document to fix the error would be great and should get me started. Thanks again garbas.
Comment 27•5 years ago
|
||
:paras0419 I managed to document how to start developing treestatus (https://github.com/mozilla/release-services/pull/1766/files) the documentation is not yet merged but i think you should be able to understand it.
Updated•5 years ago
|
Mentor: dustin → rgarbas
Updated•5 years ago
|
QA Contact: dustin → rgarbas
Comment 28•5 years ago
|
||
This should be implemented as a separate service, but consumed from shipit/treestatus and other services.
Component: Applications: TreeStatus → General
QA Contact: rgarbas → catlee
Updated•4 years ago
|
Keywords: good-first-bug
Whiteboard: [good-first-bug]
Comment 29•3 years ago
|
||
Many of the people involved in this bug are no longer here.
I've been wondering if treestatus can become a github repo with flat files...
Resolving incomplete.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•