2:02 p.m.
On 05/21/2015 11:26 AM, Eric Christensen wrote:
I started this morning's meeting and no one showed up. I
understand that the
time isn't great (did it used to be great?) and we should probably revisit it.
I also want to convey that participation in the meetings is *not* a
prerequisite to participating on the team.
Currently the problem is the change from EST to EDT time (silly day
light savings). So now the meeting is at 10am instead of 9am which
pushes it more into prime work day. I had planned on making the meeting
this week (I did get online at about 10:25, but well over by then) but
things got busy.
Below is the agenda for today's meeting along with some discussion points I
wanted to make. Please feel free to reply and comment on things inline so we
can continue the discussion.
* #topic Follow up on last week's tasks
** jsmith to patch rubygem-activesupport as provenpackager (BZ 905374)
I believe this is still in progress. Jared, can you comment?
** pjp started non-responsive maintainer against rubygem-activesupport in
EPEL6
Whatever happened with this?
** Team Goal: All important CVEs from 2014 and before should be fixed by the
end of June.
More on that below...
* #topic 90-Day Challenge
** #link https://ethercalc.org/90-day-challenge
** #info 90-Day Challenge has a goal to close all 2014 and prior Important
CVEs in Fedora
** #info As of 2015-04-29, of the 38 target bugs 14 have been closed, 1 is
On_QA, and 23 are Open
We had a few bugs that were On_QA move over to the Closed-Errata status since
the last time I looked. We're currently up to a little over a third of our
target bugs being closed. We've got a little over a month to get the rest of
them done. Lets see if we can make a big push over the coming week.
I've had a lot of tickets start moving forward lately, and still have
one ticket I need to push into non-responsive maintainer.
* #topic Outstanding BZ Tickets
** #info Thursday's numbers: Critical 1, Important 40 (+2), Moderate 370
(+22), Low 160 (0), Total 571, Trend +24
** #info Current tickets owned: 107 (~19%)
** #info Tickets closed: 315 (+11)
While cases are still getting closed, the number of tickets actively being
worked (or owned, really) is being reduced. It would appear that we aren't
picking up new cases to work. I've noticed over the past few months that
participation has dropped significantly, too. I'd love to know why.
I picked up about 5 new important tickets this week to start working as
well, but hard to pick up new tickets when it takes so much effort to
get the old tickets moving.
* #topic Loss of momentum
** #info The FST has been around for almost a year. Our participation is
dropping like flies.
Anyone have any ideas? A new meeting time? Rewards/swag? Something more
interesting to do?
I know this isn't the most fun job in Fedora but I'd like to think we're
making a difference. Perhaps we need to talk more about what we're doing in
public (or, more in public)?
Some things that might help:
1. Some kind of official swag award is nice (would love something) but
not sure that will pull in long term participants.
2. Meeting time is always going to be hard, specially with daylight
savings time in the US messing everything up. But 9am is fine, and 10am
isn't to bad, but will cause some conflicts some times. Given
participants across the globe, not sure there is a better time.
3. Clear rules and standards. I think we need to set down some hard
fast rules that are agreed upon by not just the security team but to
some extant Fedora management as well. Things we need defined:
3.a. How much time and/or attempts to reach a maintainer is allowed
before they are considered non-responsive.
3.b. Policy on Critical/Important tickets regarding non/slow response
maintainers. Should we give them less time than say moderate or less
issues. Can we have a list of volunteer proven packagers that can help
us push through criticals/importants when we are having issues with the
maintainers.
I think the above would help eliminate some of the indecision and
dragging on of some of the work. It get's frustrating pinging someone
who never responds for months because it's not clear when you have the
authority to say this ends.
4. Continue to improve the security page documentation on the process
and rules of engagement and good links for how to instigate certain
procedures (assume people are unfamiliar with the ways of fedora
packaging procedures).
If we can get more of the above in place it might make it less daunting
to the new recruits. I certainly know it's been a fair amount of
learning for myself (know security, don't know fedora ways), I'm just
stubborn enough to stick it out.
Cheers,
David