Closed Bug 571886 Opened 10 years ago Closed 8 years ago

Create calendar tool for Firefox sheriffs

Categories

(mozilla.org Graveyard :: Webdev, task, P2)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: morgamic, Assigned: peterbe)

References

()

Details

Tracking bug for sheriff app.
Depends on: 572780
This is staged - what's left before we hit primetime?
Depends on: 584113
We have an infrasec review coming up.
How is the infrasec review going?  It's been another month.  :(
Any update here?
According to mcoates per bug 584113, this probably has to wait until Q4 :|
Okay, so it's now Q2 2011.. what do we need to do here?  SOunds like there was crashiness that is now fixed according to the bug statuses, so we can restart secreview, or is there more to do?
And to elaborate, not having this means we are currently not having sheriffs because we have people on the old calendar who aren't around anymore.  There is resistance to change that calendar because 1) it's hard and 2) this is in the "nearly done" state (for something like eight months now?).
Bueller?
Still need this ASAP - what can we do to help it along?
Assignee: kourge → nobody
He-llll-ooo? </turret>

Who is this blocked on? It would be fantastic if someone could comment on the current status of this -- I understand from offline discussions that this had been stuck in an accidental deadlock between infrasec and webdev, but supposedly that was resolved a week or two ago?
Still trying to establish next steps. Hopefully we can launch this app without rewriting any code. Speaking of, does anyone know where the code is located?

Once the app is stable and up on stage, we can restart the security review and QA.
Priority: -- → P2
https://github.com/kourge/sheriff

1. If it can be gated by MoCo LDAP (entirely behind auth), it's a matter of IT putting is somewhere and hoping that it's still viable.

2. If it has to be relatively open, it's waiting on infrasec.

Notes: Coates is in Maui until next week, IT is super busy right now so not sure what kind of ETA we're looking at but Corey can give us more info.
(In reply to comment #12)
> https://github.com/kourge/sheriff
> 
> 1. If it can be gated by MoCo LDAP (entirely behind auth), it's a matter of
> IT putting is somewhere and hoping that it's still viable.

I'm not the driver for this, but can we gate it on MoCo LDAP now and worry about opening it up later?  I believe all of the sheriffs are MoCo-affiliated ...
(In reply to comment #13)
> I'm not the driver for this, but can we gate it on MoCo LDAP now and worry
> about opening it up later?  I believe all of the sheriffs are
> MoCo-affiliated ...

That's not true. How about just requiring an LDAP account?
or a specific LDAP group, maybe?  scm_level2 seems like sufficiently-trusted for that
(In reply to comment #14)
> (In reply to comment #13)
> > I'm not the driver for this, but can we gate it on MoCo LDAP now and worry
> > about opening it up later?  I believe all of the sheriffs are
> > MoCo-affiliated ...
> 
> That's not true. How about just requiring an LDAP account?

Who is in the sheriff schedule (and actually sheriffs) that is not employed by MoCo?
(In reply to comment #16)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > I'm not the driver for this, but can we gate it on MoCo LDAP now and worry
> > > about opening it up later?  I believe all of the sheriffs are
> > > MoCo-affiliated ...
> > 
> > That's not true. How about just requiring an LDAP account?
> 
> Who is in the sheriff schedule (and actually sheriffs) that is not employed
> by MoCo?

Doesn't matter - I'm the driver for this and boldly assert that LDAP wall is fine, at whatever access level, though I think agree with comment 15 that level2 access is probably a swell touchstone.
(In reply to comment #17)
> Doesn't matter - I'm the driver for this and boldly assert that LDAP wall is
> fine, at whatever access level, though I think agree with comment 15 that
> level2 access is probably a swell touchstone.

If this is going to be done with such access via LDAP alone (and not MoCo VPN) then we need Infrasec approval on this.  I believe that is being handled in 584113..

If, on the other hand, this is MoCo-only, then I might suggest a shared zimbra calendar.  No need for yet another calendar tool that we have to maintain (especially after hearing that this is Ruby and we have no shared infrastructure for Ruby to put this on, making it a one-off)
Would an LDAP wall mean that the current sheriff wouldn't be visible on the tinderbox, or is there a static export system which would allow the sheriff schedule to be public?
(In reply to comment #18)
> If, on the other hand, this is MoCo-only, then I might suggest a shared
> zimbra calendar.  No need for yet another calendar tool that we have to
> maintain (especially after hearing that this is Ruby and we have no shared
> infrastructure for Ruby to put this on, making it a one-off)

I second that. I just created a test calendar on my Zibra, and it comes with two public URLs to consume the data:

(HTML) https://mail.mozilla.com/home/fwenzel@mozilla.com/Test%20Calendar.html
(ical) https://mail.mozilla.com/home/fwenzel@mozilla.com/Test%20Calendar

I can also invite other Zimbra users (read: Moco employees) to be admins on the same calendar with me.

(In reply to comment #19)
> Would an LDAP wall mean that the current sheriff wouldn't be visible on the
> tinderbox, or is there a static export system which would allow the sheriff
> schedule to be public?

I don't know what your tinderbox interface is written in, but perhaps there's an ical library that you can employ for this purpose. Worst thing, you could do some regex magic.
I hate to rain on the parade here, but we already use a shared calendar, and it doesn't work out very well, hence the reason for this app.  It's very disappointing to see all this stop energy on this issue.
(In reply to comment #21)
> I hate to rain on the parade here, but we already use a shared calendar, and
> it doesn't work out very well, hence the reason for this app.  It's very
> disappointing to see all this stop energy on this issue.

What is the issue?  I first heard about this app yesterday.  We (IT) don't have a bug to deploy this, and even if/when we do it will block on an infrasec review.  Common practice.  While we are at it we will need the webdev who owns this project to work with us on documentation so we don't reach any "wtf?" moments next year when something arises and we've lost the tribal knowledge around this app.

Sorry if this sounds like it is a PITA, but it is the right way to go about things.  I suggested Zimbra as an easy alternative because:  1) it is already setup, 2) I have no idea what this app is or does aside from what is in the bug subject, so I'm making a lot of assumptions.

If Zimbra is not the right tool, that's fine, we go forward with this app..
(In reply to comment #22)
> What is the issue?  I first heard about this app yesterday.  We (IT) don't
> have a bug to deploy this, and even if/when we do it will block on an
> infrasec review.

That makes me sad to hear. I and others asked vigorously about this around a year ago, and were told by several IT folks that it was blocked on infrasec review. To hear that there was no bug for that in the first place means it was never on radar. That's a sad breakdown in communication. :(

> While we are at it we will need the
> webdev who owns this project to work with us on documentation so we don't
> reach any "wtf?" moments next year when something arises and we've lost the
> tribal knowledge around this app.

That's Wilson Lee. He was an intern, but may be willing to assist. Perhaps webdev could get in touch with him? Or if I see him around, I can ask him to comment here.
(In reply to comment #23)
> (In reply to comment #22)
> > What is the issue?  I first heard about this app yesterday.  We (IT) don't
> > have a bug to deploy this, and even if/when we do it will block on an
> > infrasec review.

(I just realized you were talking about deployment vs. infrasec review, so my comment may not be relevant.)
(In reply to comment #22)
> What is the issue?
Namely changing the schedule is hard unless you replace one person with another.  Adding someone between two people requires shifting each and every person by one day, and changing the repeat schedule for every person listed.  Johnathan can elaborate more.

> Sorry if this sounds like it is a PITA, but it is the right way to go about
> things.  I suggested Zimbra as an easy alternative because:  1) it is
> already setup, 2) I have no idea what this app is or does aside from what is
> in the bug subject, so I'm making a lot of assumptions.
I understand the process, and why it needs to be done.  What I'm disappointed in is the communication breakdowns that led us here, and how hard it was to get someone to respond about this in the first place since we started poking it again back at the end of April.  We'd love to add people to the sheriff schedule to reduce the burden on those already on it, but we can't right now because changing the schedule is so painful.
Okay folks, back off a bit please - someone like Fred or Corey who's new to this doesn't have the backstory, no sense pouncing on them. Let's reset:

Firefox developers use a "sheriff" system to help keep our code trees healthy. Each sheriff has a shift every month or two during which their job is to watch for bustage or other problems with the tree, generally keep it healthy, and close the tree down when things go too far amiss.

Right now we use a google calendar for this. [1] Each sheriff has a recurring "appointment" every 6 weeks. This has several problems, chiefly:

1) Adding and removing sheriffs is very difficult, since it means shifting everyone else
2) Sheriffs have no good way of being notified when their shift is coming up
3) There is no sheriff-mediated mechanism for organizing day swaps, it goes through me

About two years ago, Vlad and I talked to Morgamic about this problem and asked if we could poof up a tool that would just populate a calendar from a simple list, and let people set email preferences around their own duties. Here was Vlad's email:

== SNIP ==

On 2009-06-29, at 2:42 PM, Vladimir Vukicevic wrote:

Hey morgamic,

Any chance we could get some webdev help to create a little app to help us track sheriffs/sheriff duty?  Probably shouldn't take long, something like this:

Required Features
-----------------
* Maintain a list of users who are sheriffs, allow easy adding/removing from this list.  (If it's easier, this can be tied to ldap, or it can just be bare email addresses.)  This list should be ordered, that is, we shouldn't auto-alphabetize or something.

* Have a small display mode to show who today's, yesterday's, and tomorrow's sherrifs are, for embedding onto the tinderbox page.

* Email notification week before (to each sheriff for the next week, with full week schedule) and day before (to specific sheriff).  Also ability to cc additional email addresses to these (dev.tree.mgmt, etc.).

Optional Features
-----------------
* Calendar view of sheriffs, viewing arbitrary week/date

* Ability for people to log in and trade sheriff duties with someone else, and have that be represented

* ICS calendar URLs, either for full sheriff schedule or for only your own sheriff days (so you can easily auto-add your sheriff days to your calendar).


Let me know if this is something you guys could tackle; it's not a huge priority, but it would let us stop doing a painful job by hand and get some more functionality out of it.

Thanks!
   - Vlad

== END SNIP ==

In the summer of 2010, Wilson Lee had the app mostly ready and deploying it was a matter of infrasec review. As mentioned above, there were some communication breakdowns there but I understood them to be largely resolved now. I also understood the suggestion to put it behind LDAP (gated on commit access) as largely mitigating the concern, though it sounds like Corey has a different understanding there.

The people in this bug who sound irate are reacting, more than anything, to the time elapsed, not the particular suggestions. The recommendation to use a Zimbra calendar, as I hope is clearer now, fails to meet some of the needs of the application's customers, but I don't think anyone is attached to Wilson's implementation specifically if there's another way to solve this problem that would be more expeditious.

Not having this app doesn't mean development grinds to a halt, but feeling like it was just around the corner for a long time has meant that we've (I've!) postponed making changes to the sheriffing schedule that I would have made a while ago had I known that there was still lots of runway. We are leaning on our sheriffs more under the rapid release model and some of the proposals around how we manage development lean still heavier - this is another reason for the increased interest in this bug.

My question then, at the end of all of this, to Mike and Corey is: can we expect this soon, is there any way we can help, or should we make plans on this not being containable for some time?


[1] https://www.google.com/calendar/embed?src=j6tkvqkuf9elual8l2tbuk2umk%40group.calendar.google.com&ctz=America/Toronto
(In reply to comment #26)
> now. I also understood the suggestion to put it behind LDAP (gated on commit
> access) as largely mitigating the concern, though it sounds like Corey has a
> different understanding there.

Typically infrasec requires review on anything that is public, even if it is blocked by ldap auth.  VPN would be the preferred jail method here, and seems in line with the current infrasec status on this app:

<quote>
Per comment 15 we are stopping the security review.  Please update us whenever the application is ready for testing in the future.  The security review is a blocker to moving this app out of the vpn (MPT).
</quote>

> of the application's customers, but I don't think anyone is attached to
> Wilson's implementation specifically if there's another way to solve this
> problem that would be more expeditious.

From an IT POV it would be nice if this app was written to our current standards (python/playdoh) since we do not have a shared infrastructure running Ruby, therefore we would need to set this up somewhere designed for that.  This may not have been the case a year ago.  I'm just stating the way things are right now.   Given the circumstances of the ball being dropped I'm happy to deploy this using whatever, but just stating my wish for an app that fits the playdoh mold..  And unicorns.  I don't expect all of my wishes to be granted.  :)

> My question then, at the end of all of this, to Mike and Corey is: can we
> expect this soon, is there any way we can help, or should we make plans on
> this not being containable for some time?

Not knowing the state of the app I can't make any promises.  I see mention of bugs that were not fixed on this app, so I don't know if it is in a deployable state.  I'll defer to Mike on that.  We are ready to work something up as soon as infrasec gives the okay.
Thanks johnath!  

A quick update from web dev:

The developer who wrote this app is not currently with us.  We don't have a web developer who is familiar with the app, and the app is not working in its current state in the sandbox:
http://sheriff.khan.mozilla.org/

We will have one of our web developers take a look at the app that was written, and make a recommendation of what the next steps are.  We will either:

a) determine that the necessary fixes are minor, update the code to get the app back to a working state, and bring in IT / Infra to review the site and work towards getting the app pushed out.

b) determine that the codebase will take too much work given its current state, and give a proposal for something that help you solve the sheriff schedule problem.  This proposal may consist of rebuilding this app on Django / Playdoh.

Either way, once web dev can make a recommendation about next steps, we will call a meeting and discuss how to proceed.  Thanks!
-> tofumatt to assess current state of Ruby code.
Assignee: nobody → tofumatt
Depends on: 661425
Starting next week, I'll be able assist in deploying this by answering various questions, working on the code, etc, since the harsh quarter will soon be ending, leaving much more time due to the absence of soul-crushing weekly hardware design assignments.
Tofumatt gave an assessment of the deployability of the app over in bug 661425 comment 2. It looks like our best bet is to rewrite this as a playdoh app, while working off the structure and use the assets of the Ruby app.

Ryan Snyder, will you take it from here?
Assignee: tofumatt → nobody
Yes, my group will take a look at possible next steps.  Johnath, we will be reaching out to your team shortly to schedule a meeting and help define a path by which we can move forward. Talk to you soon!
Update: we met, and peterbe has begun implementation of the app using playdoh as a base.  Have emailed infrasec to plan a code review, and filed bug 669391 to get infra for this app.
(In reply to comment #33)
> Update: we met, and peterbe has begun implementation of the app using
> playdoh as a base.  Have emailed infrasec to plan a code review, and filed
> bug 669391 to get infra for this app.

Thanks for the update, Laura. In terms of infrasec review, if it expedites the process at all, the sheriffs are happy to have this LDAP-protected rather than public-facing (at least the admin pieces - I guess the embeddable listing would need to be public-facing). If it doesn't matter, ignore this comment, just making sure you don't perceive requirements I don't intend to be there!
Is this still using the graph server at all?  There's an ACL on the graphs database for this app, and I can't find any config file that claims to be talking to it (but maybe I just don't know where to look).

I need to make changes to that MySQL ACL, and if it's actually being used, it'll break the app if the config isn't changed at the same time.
Peter: Isn't this live?
Assignee: nobody → peterbe
Yes.  Awaiting data load from stakeholders though.
https://sheriffs.mozilla.org/
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.