LSARC/2008/061 - Indiana check list

[John Fischer]

Brian,

See below.

John


Brian Cameron wrote:
> 
> John:
> 
>>>
>>>  >      Indicate Sun's involvement in the community
>>>  >      [ ] Maintainer
>>>  >      [ ] Contributor
>>>  >      [ ] Monitoring
>>>
>>> Rather than ask whether we are a contributor or a maintainer, we should
>>> ask how the project is involved.  Build fixes, code enhancements,
>>> integration with Sun-specific services, G11N support, documentation
>>> support, QA, a11y.  All of the above?
>>
>> This question was placed in the check list to better understand what
>> influence we might have on the project.  It actually is informational
>> only and could be removed.
> 
> I agree it is useful.  I just think it would be more useful to tease out
> more specifically what involvement we have.

Yes.  But that will not cause us to say that the project needs further
review by the committee.

>>>  >      Will changes be feed back to the community?
>>>  >      [ ] Yes
>>>  >      [ ] No - briefly explain
>>>
>>> I think it would be good to "briefly explain" when the answer is Yes.
>>> We should tease out what sort of involvement exists, and what is
>>> planned.  Only Solaris-specific build/bug fixes?  G11N support?
>>> What, exactly.
>>
>> This question was to understand why we would be forking from the
>> community and not providing the changes back (i.e., we actually
>> are not participating in the community).
> 
> The question probably should say "fed" instead of "feed".  I think
> I have trouble with the term "changes" being a bit vague.  Perhaps a
> better way to word this would be "Will we work with the community to
> get our changes upstream?"

How about:

   Will the project team work with the upstream community to resolve
   architectural issues of interest to Sun?

> Note that we can't always get our changes upstream because sometimes
> maintainers don't like our changes.  But we can try.
> 
>>>  >      Will we or are we forking from the community?
>>>  >      [ ] Yes - ARC review required prior to forking
>>>  >      [ ] No
>>>
>>> There often is debate about whether applying patches is a "fork".
>>> At what point do we define a fork?  How many patches?  Or do patches
>>> not have anything to do with forking?
>>
>> Exactly.  If we are required to fork from the community then we
>> need to understand that perspective as a committee and company.
>> Thus we would want further review.  If the patches are eventually
>> delivered to the up-stream then that would not be considered a fork
>> by me.
> 
> The GNOME project has over 200 patches that are unlikely to go upstream.
> We have over 400 pages in total, and I am probably being generous
> thinking that 250 of them will eventually go upstream.
> 
> However, I wouldn't characterize GNOME as being a fork.  The fact we
> modify GNOME for branding purposes, and to support things like Trusted
> Solaris, is probably not really a fork.  We just apply a set of changes
> to the base code that are probably not appropriate to go upstream.
> 
> However, when I talk to some people within Sun, they seem to think
> if we have even a single patch, we are forking.  It might be good if
> "fork" had a more clear definition.  Otherwise you'll get random
> answers to the question.
> 
> I think forking typically requires a separate project with its own
> maintainer and different goals, etc.  It is not applying a patch
> to make a function work on Solaris.

I would not characterize the Gnome patches as forking from the
community either.  The team attempts to get these patches into
the upstream community.  In terms of branding purposes those
are legitimate reasons for Sun.  Again not what we are getting
at for this issue.  If the project can not determine if the
changes they are providing are for Sun branding and whether or
not they are forking then perhaps they need a review anyhow.

>>>  >    2.2.3 Licensing
>>>  >      Indicate the license for the component(s)
>>>  >      [ ] GPL
>>>  >      [ ] Other
>>>
>>> This question seems less than useful.  What about LGPL, MIT, etc.?
>>> A fill-in-the-blank would be better.  Perhaps should also ask if the
>>> license has any exceptions (like media programs sometimes have to
>>> allow IP plugins).
>>
>> Viral licensing is a concern from an architectural perspective.  This
>> is only what I am asking about.  The other licenses that you point
>> out are not viral.
> 
> Might be better to simply ask if the license is viral then, and use
> GPL as an example.  GPL isn't the only viral license.

How about:

   Is the license viral?  GPL is an example of a viral license.
   [ ] Yes
   [ ] No

>>>  >         3.1.2 Share and Sharable
>>>  >      Are any components shared with other Free Open Souce Software
>>>  > (FOSS)?
>>>  >      [ ] Yes
>>>  >      [ ] No
>>>
>>> I am not clear what this means.  Could you explain, perhaps provide
>>> an example?
>>
>> This is an attempt to get the project team thinking about component
>> packaging.  If the component is interesting to other project then
>> it should be packaged in a sharable way.  Think of the NSPR & NSS issues
>> we have had from the Mozilla organization.  If those had originally
>> been packaged in a sharable manor then we would have potentially
>> saved ourselves much headache.
> 
> Perhaps the question could be worded better.  Why does the question ask
> if the components are shared with other FOSS.  A module could install
> a component used by a non-FOSS project.  For example, GTK+ is shared
> with non-FOSS things like Adobe Reader.
> 
> Perhaps "Does this module include any components that are used or
> shared by other projects" or something would be more clear?

That is fine wording.

>>> I see no questions about the following sorts of things which would
>>> be useful, I'd think:
>>
>> True.  That was on purpose.  Several of the committee members talked
>> about these types of issues in IRC.  We decided that we would not
>> require a full review unless the projects did not fit our security
>> and installation model.  These were the low hanging fruit or
>> requirements.
> 
> Is this because ARC is not so interested in worrying about whether
> FOSS projects meets requirements outside of security/installation
> issues?
> 
>  > Encryption should be caught in a legal review.  Though
>> it could be added.  The question we would need to ask is would we
>> require a review if encryption was included?  What if it wasn't
>> included?  If the answer is no to either one of those questions
>> then it is not needed in the check list.  For those on IRC it
>> was a no.
> 
> Okay.
> 
>>> - degree of I18N support
>>> - existence of manpages and whether they describe the interfaces
>>>   reasonably well.
>>> - existence of installed API documentation for libraries or other
>>>   interface documentation (such as gtk-docs)
>>> - existence of any encryption
>>> - whether the interface duplicates the functionality of another module
>>>   we already ship (is it yet another database, for example).  If yes,
>>>   please explain
>>> - degree of a11y support (perhaps several questions for each use case
>>>   GOK, orca, theming, keynav, etc.)
>>> - Does the program follow usability style guide (such as GNOME HIG if it
>>>   is a GNOME Program, or CLIP).
>>> - Does the project install a GPL library to /usr/lib?
>>> - Does the project install C++ interfaces
> 
> Brian