LSARC/2008/061 - Indiana check list

[Brian Cameron]

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.

Understood, but the more information we gather in this area, the better
we understand our relationship, which seems a good thing.  I understand,
though, if people feel it is outside the scope and the question isn't
modified, or if it is removed.

>>>>  >      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?

That seems much more clear.

>> 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.

My suggestion is that it might be good to provide a bit of a
definition of what is meant by fork.  However, it is also
reasonable to expect project teams to know this.

>>>>  >    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

I think that is a better question.

>>>>  >         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.

Brian