[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d5bcc90-3248-b7bf-6d3e-64fdc6c9a4bc@windriver.com>
Date: Mon, 3 Jul 2017 08:31:05 +0200
From: Mark Hatle <mark.hatle@...driver.com>
To: <oss-security@...ts.openwall.com>
Subject: Re: accepting new members to
(linux-)distros lists
On 7/1/17 4:07 PM, Solar Designer wrote:
> On Sat, Jul 01, 2017 at 01:57:55PM +0200, Mark Hatle wrote:
>> We (Wind River) can take a more active role in at least some of the
>> administrative tasks..
>
> Thank you!
>
>> However, I can assure you we don't have the time or
>> ability to do it ourselves.
>
Sorry I wasn't clear. "time or ability to do it all ourselves" is what I meant
to write.
Between timezones, vacation schedules, etc. I can't promise immediate responses
or even a specific response time to the list.
> No "time or ability" to take care of any one (or preferably more) of the
> administrative micro-roles I listed? This makes no sense to me. All of
> the administrative tasks combined are far less than one full-time job.
> With good discipline and focus, they can probably be taken care of with
> 1 hour of effort per day on average (of course, there will be occasional
> busy days, but also many days with no work of this type). All of them
> at once. I think I know this because of me being the fallback person
> for this type of work so far. OTOH, I do recognize that I listed a few
> additional tasks now - such as producing statistics - and the extent of
> work on tasks involving monitoring external resources can vary greatly.
> So maybe it's more than 1 hour/day on average with those extra tasks and
> desired greater extent now. But not much more.
So really what I'm saying is even for something trivial, there will be times
where I can not promise immediate response.
> What I do understand is needing to temporarily transfer responsibility
> to another distro if your own team subscribed to the list is small and
> many of these people may simultaneously go on vacation.
We effectively have one person monitoring the list, with two backup in case of
vacations. Occasionally all people are out at the same time (usually national
holidays.) I'm happy to offer our help, but as long as my limitations are
understood then I think this will be beneficial. (I doubt we are unique in
this. If we could subscribe all of our developers then the limitations go away
-- but that would be a terrible idea for informational security.) :)
> A reason why I listed so many administrative micro-tasks/roles is that
> I'd like to allow for an even (or close to it) distribution of the
> effort across the distros, where every one of them bears a tiny portion
> of this small total effort of running the list. This would also serve
> to ensure and demonstrate to the rest of us that every distro is still
> an active member, without us needing responsiveness tests.
>
> The technical expertise tasks could be worked on to varying extent,
> including becoming a full-time job for someone or even for several
> people. There's no decision on the exact extent yet, but it should be
> sufficient to almost always avoid things like the recent incomplete fix
> in Sudo.
>
>> So the more then one 'actor' on an action would definitely be what I suggest.
>
> That's within consideration, but we got to start by listing at least one
> distro per task. When we eventually have more than one listed for some
> task, we or they will need to coordinate their activities, and that
> could create extra work. Perhaps a "primary and backup" arrangement for
> two distros sharing a task will work best: will not result in "no one's
> responsibility" and will have low coordination overhead.
>
> The first administrative task of getting back to message senders is so
> trivial that I think it'd make sense to keep it reserved to the distro
> who was last to join, perhaps switching responsibility to them from the
> previous distro once the new member has confirmed they're successfully
> receiving messages through the list. The new distro will be "primary"
> and the previous will be "backup" for that role. Always that way,
> unless the newly joining distro opts for something less trivial right
> away. (I know some people would be offended by being asked to
> participate in this trivial activity. I think they'd be wrong, but we
> can accommodate their egos, no problem.) This will quickly test each
> new distro's responsiveness and get them involved, and hopefully
> encourage them to pick up several of the less trivial tasks as well
> (they will need to, or otherwise they'd be left without a task once
> another distro joins, which would be inappropriate).
Reply that a report made it to the list would certainly be an easy original
task. I've not done it so far, only because others usually beat me to it.
>> Unfortunately I really don't have a good sense (based on the link to the tasks)
>> as to what would be appropriate to volunteer for. I'm open to suggestions.
>
> It's really anything you feel like doing. Perhaps see in which areas
> you have been helping already, and suggest that you focus on those.
Unfortunately I'm on vacation through the end of this week (as are many of us
that are located in North America.) So I can get back with what we can help
with next week. (If tasks are gone, that is fine.)
Thank you for organizing this. I do think it is important.
--Mark
> If you really want me to narrow down the list for you, let me know.
>
> This may also start happening on its own, due to other distros picking
> up tasks. Once a task is taken by one or two distros, I will want
> further distros to volunteer for other tasks. So if you want to have
> more freedom of choice, hurry up.
>
> OTOH, with distros not volunteering for specific tasks (like we've seen
> so far), I might just assign tasks to distros myself.
>
> Alexander
>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
