Garrett D'Amore wrote:
> Sebastien Roy wrote:
>> (moved out of the case review, and over to arc-discuss)
>>
>> On Thu, 2009-07-09 at 12:38 -0500, Nicolas Williams wrote:
>>
>>> On Thu, Jul 09, 2009 at 10:18:48AM -0700, Bart Smaalders wrote:
>>>
>>>> One of the problems that PSARC has had is that those who are doing
>>>> interesting work often found it difficult to justify the time
>>>> commitment involved in active participation. This would sometimes
>>>> lead to having folks involved on PSARC who hadn't actually delivered
>>>> a project involving substantial change to the system in many years.
>>>>
>>> The obvious solution to this is blow up the number of members so as to
>>> spread the load. That might not work for other reasons, it's worth
>>> doing _something_ to keep the ARC function while addressing the above
>>> problem. Another solution would be to rotate members into and out of
>>> the ARC, so that members don't get stuck with heavy ARC load for more
>>> than, say, 1 year, sort of how gatekeeping used to be (you'd do your
>>> stint as GK, and then go back to normal projects).
>>>
>>> Even with OpenSolaris, which might change user expectations of
>>> interface
>>> stability to match Linux user expectations of that, the ARC function
>>> is,
>>> IMO, very important. If it's not working out well now, we should look
>>> at how to make it work well.
>>>
>>
>> One related thing I've thought about is collapsing the ARCs into one
>> ARC. Having the ability to draw from a wider range of expertise and
>> more members and interns on a given case review could be a good thing.
>>
>
> This sounds like a good idea, but I think there are simply too many
> cases such that normal humans would probably spend too much time just
> triaging cases and deciding whether or not it is relevant. Spreading
> the load via LSARC/PSARC split I think actually works pretty well.
>
> The reality is that PSARC duties really are not *that* onerous. And,
> if we had more members, it would help even further reduce the load
> imposed on the individual members. I know I try to read every case
> now that I'm chair, but as an ordinary member, if I see other cases
> that other members with more relevant expertise than I have are
> commenting on, then there's a good chance I'll just ignore it and
> defer to the other member(s) who are reviewing the case materials.
>
As an aside -- to me the model of a community group that is functioning
almost perfectly, both in the "open and transparent" sense and in the
"we're highly efficient engineers" sense is the SMF community. I'm sure
that there are other teams that may do this, but that particular team,
as a *norm*, pre-reviews their stuff well in advance of the official ARC
review. By the time their integrations come to the official ARC door,
they've been eyeballed for several weeks already, including,
coincidentally, by ARC members. I don't know if that's an argument for
extending timers on reviews or not. I just want to point out that there
is at least one well oiled cog cranking away out there.
As a totally different aside, I find it odd that the LSARC has, for the
last few months, very little casework -- or certainly much, much less
relative to PSARC. I suspect that's probably cyclic, anyway (and
certain M&A activities may have some impact). I find it sometimes
amusing, though, that so very many cases come through PSARC that I would
classify as FOSS. Probably 90% of it "familiarity" cases, and arguably
90% of those integrating below the level of "layered" software --
therefore the {P} designation. What if the roles were shifted? What if
LSARC were chartered with reviewing things that generally originate
outside the community, and PSARC the non-layered, Sun (or community)
originating cases? I'm asking purely from a caseload/time management
perspective. I realize that the originating source of origin of
integrating projects isn't, today, a determiner of which ARC it is
reviewed in, but I see at least some of the things that LSARC is
currently dealing with are issues of almost all FOSS projects, and while
the bits continue to flip from FOSS -> ARC -> OS to FOSS -> /REPO -> OS,
I see that LSARC is the closest to that happening from a casework sense.
