LSARC/2008/058 - dcraw

[John Plocher]

In other words, this should go into a repository that Solaris users can
easily update from, and the project team needs to commit to updating that
repository on an agressive and proactive basis.

Sounds like we (Sun/ARCs) need to better understand the repository model(s)
being contemplated here.  If only we had an ARC case for them... :-)

    -John



Lloyd L Chambers wrote:
> As an avid photographer (diglloyd.com),  I'll weigh in here--
> 
> 1.  Unless Sun provides frequent and regular updates automatically to 
> support the latest digital cameras, including 'dcraw' in Solaris is 
> likely to disappoint--new cameras are released on a constant basis, and 
> a RAW-file converter must be constantly updated to keep pace.  IMO, 
> 'dcraw' seems inappapriate for Solaris, unless there is a plan in place 
> to keep pace on the latest cameras.
> 
> By way of comparison, Apple provides RAW support in Aperture, Preview 
> and internal libraries, and they have to issue an update once a quarter 
> or so.  Right now, I have a new camera, and it's not yet supported 
> (though it soon should be).  This becomes annoying; any tool that isn't 
> aggressively updated gets abandoned.
> 
> In short, failure to aggressively update raw-file processing software 
> frequently leads to it being out of date within a year.  To me, that's 
> *much* more important than concerns about whether the interface is 
> 'volatile' or something else--a square peg in a round hole issue IMO.
> 
> Bottom line:  unless we have a team committed to frequent and regular 
> updates, I vote against seeing this included in Solaris *at all*.
> 
> I could be persuaded otherwise provided that there is a *funded* and 
> well-articulated plan for aggressively keeping 'dcraw' current.
> 
> Lloyd
> 
> Lloyd L Chambers
> lloyd.chambers at sun.com
> LSARC
> Sun Microsystems, Inc
> 
> On Jan 30, 2008, at 5:34 AM, James Carlson wrote:
> 
>> John Plocher writes:
>>> Danek Duvall wrote:
>>>> Perhaps we could keep track of these interfaces...
>>>
>>> If you are going to do all that, why not just do a contract - it is
>>> just as much work, plus it is a well known mechanism.
>>>
>>> (I, too wish there was a better way...)
>>
>> I agree with John.  I'll also go further to say that asserting that
>> because a project exports only Volatile interfaces it's somehow
>> specially eligible to import Volatile as well is a syntax error.  It
>> seems to belie a "FOSS == no review" scheme that just doesn't exist.
>>
>> We don't evaluate dependencies based on the stability of interfaces
>> provided by a project.  We evaluate them based on the consolidations
>> across which the dependency exists.
>>
>> In other words, better ways to deal with this issue are:
>>
>>   - Just raise the stability level of the library to an appropriate
>>     level, given the consumers involved.  It's not as unstable as
>>     asserted.
>>
>>   - Create a contract; it's how we enumerate consumers who will be
>>     damaged by unexpected changes.
>>
>>   - Put them in the same consolidation and treat the dependency as
>>     effectively Consolidation Private ("Volatile friends with
>>     benefits").
>>
>> -- 
>> James Carlson, Solaris Networking              <james.d.carlson at sun.com>
>> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
>> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
> 
> ---
> Lloyd L Chambers
> lloyd.chambers at sun.com
> Sun Microsystems, Inc
> 
> 
>