LSARC/2008/061 - Indiana check list

[John Fischer]

Brian,

See below.

Thanks,

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.

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

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


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


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

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

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