On Friday, May 22, 2015 03:02:35 PM David A. Cafaro wrote:
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.
Well, I don't want to over emphasis the meeting and its importance to the
overall operation of the team. It really serves no purpose other than a
rallying time for everyone to be online at the same time and perhaps a
convenient time for people to ask questions.
That said, I'll send out a new whenisgood poll on a new message to get
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.
We've been following the current policy for nonresponsive package
maintainers and I feel good about using that policy. It's simple and
accepted by the development community.
3.b. Policy on Critical/Important tickets regarding non/slow
maintainers. Should we give them less time than say moderate or less
Probably. Critical and important issues are... well... important. If you
look at the moderate and low categories you'll see that they are difficult to
exploit and/or have limited results. Honestly, I've really not looked at
moderates or lows for closure since we have so many important (and that one,
pesky, critical) CVEs in Fedora/EPEL now.
Can we have a list of volunteer proven packagers that can help
us push through criticals/importants when we are having issues with the
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.
I think that's a good resource to have. I know jsmith has offered up his
services but I'm sure there are others. As far as our "authority" we seem
be operating under the good graces of release engineering. They care about
security vulnerabilities in their repos and have been very reponsive to
getting packages retired when we've hit the end of our rope. I think
consistency is important here and we should all be on the same page when it
comes to dealing with the bugs.
4. Continue to improve the security page documentation on the
and rules of engagement and good links for how to instigate certain
procedures (assume people are unfamiliar with the ways of fedora