John Sonnenschein wrote:
> Shawn Walker wrote:
>> Garrett D'Amore wrote:
>>
>>> ON commits are still, AFAICT, internal only. This is because the
>>> repository still lives inside the SWAN firewall, so you need to have
>>> internal access to Sun's network. (The RTI tools involved are also
>>> still Sun-internal only.)
>>>
>>> That said, its fairly easy for someone internal to take a changeset
>>> from an external contributor and integrate it. The "onerous" parts
>>> of the process for integration (test, SCA/CDDL verification, ARC
>>> approval if appropriate) still apply, and I don't see *those*
>>> portions of the problem going away anytime soon. (I don't think
>>> anyone seriously wants them to -- the various sanity checks play an
>>> important role in assuring the quality of the Solaris product is not
>>> compromised.)
>>>
>>
>> By onerous, I'm primarily referring to the fact that there are still
>> some steps that your sponsor has to perform that you could perform if
>> you knew how or had the access to and that it was a tedious process.
>>
>> I haven't done any integrations since the sponsor program was
>> revamped, so I can't speak for what it's like now. But before, it
>> took a very long time to get anything done at all.
>>
>> I don't see testing, SCA/CDDL verification, or ARC approval as onerous.
>>
>> Those were the least of my worries in my own experience
>>
> Hey Shawn
>
> I should hope that myself and the others have made it a lot less
> painful. If a message comes to request-sponsor now it should be
> accepted within a couple days, and the patches you send should be able
> to be integrated in a couple hours + C ( where the constant of
> integration (heh) in this case is ARC, legal, what have you ). Less
> time if you heed the blog entry I posted a while back on making the
> sponsors job easier ( updating copyrights, cstyle, etc )
The process bits after ARC, legal, and *testing* (and testing is the
biggest one in my experience) are not very tedious. There is updating
the bug database, and filing the RTI, but once you learn the process and
do it once, its not very hard at all. And hg nits or hg pbchk really
helps you get them right. (Updating the bug database can sometimes be
"tedious", but its IMO a necessary step -- putting the root cause
analysis and suggested fix including diffs in the defect tracking system
lets others go back and figure out what you did and why.)
That said, RTI *advocates* may have more tedium to go through, in
reviewing RTI requests for correctness. (I'm not an advocate, but from
my experience the advocates seem very thorough -- although I probably
intentionally choose some of the more rigorous advocates when I select
them for my integrations.)
-- Garrett
