It will cost very little extra work to make a list of interfaces and
stabilities now. And if the SQLite community sticks to its track record
to date then going with better than Volatile should cost very little
extra work to update SQLite releases in the future.
The only way this can require extr
This case was closed approved in last PSARC meeting.
Material was updated and saved as 'spec.txt' in case directory. In the
updated material, interface name '/dev/dsp' was changed to
'/dev/private_dsp' so that users won't stumble into it purely by
accident as a consequence of using a famous pat
Nicolas Williams wrote:
> It will cost very little extra work to make a list of interfaces and
> stabilities now. And if the SQLite community sticks to its track record
> to date then going with better than Volatile should cost very little
> extra work to update SQLite releases in the future.
>
John Fischer writes:
> LCMS [Little CMS] [1] is a Color Management System implementing
> the International Color Consortium's ICC.1:2004-10 Specification.
> [2]
The last CMS we had was removed with force due to security problems
... just a sanity check: this new CMS doesn't share
John Fischer writes:
> /usr/lib/libmng.so.1.0.0
> /usr/lib/libmng.so.1 -> /usr/lib/libmng.so.1.0.0
> /usr/lib/libmng.so -> /usr/lib/libmng.so.1.0.0
Same library versioning questions here. This doesn't look right to
me.
> By default, LibMNG installs its header files under
>John Fischer writes:
>> LCMS [Little CMS] [1] is a Color Management System implementing
>> the International Color Consortium's ICC.1:2004-10 Specification.
>> [2]
>
>The last CMS we had was removed with force due to security problems
>... just a sanity check: this new CMS doesn't
James Carlson wrote:
> Ah, I see. Still, when it comes time to do "tomcat6," it'll look a
> little confusing to have "tomcat55" in there, so I'd prefer just "5."
Ok, let's use "tomcat5".
Note (which is not directly related to this case):
"
I believe for Nevada we should try to make Tomcat inde
>James Carlson wrote:
>
>> Ah, I see. Still, when it comes time to do "tomcat6," it'll look a
>> little confusing to have "tomcat55" in there, so I'd prefer just "5."
>
>Ok, let's use "tomcat5".
>
>Note (which is not directly related to this case):
>
>"
>I believe for Nevada we should try to make
John Plocher wrote:
> Petr Sumbera wrote:
>> Tomcat is started (beside manually) via Apache 1.3 init script
>
> What about Apache 2.x - how does this work with that version?
Answer is simple. It doesn't work.
Tomcat was introduced when there was no Apache 2. Tomcat is located in
Apache 1.3 sub
Casper.Dik at Sun.COM writes:
> >I don't think that intermediate symbolic link does anything useful.
> >The linker only records the actual file name (liblcms.so.1.0.16), and
> >only uses the ".so" link to find it, so that liblcms.so.1 just
> >provides obfuscation. ;-}
>
> The linker either record
Petr Sumbera writes:
> >> + /usr/apache/libexec/mod_jk.so uncommitted Apache Tomcat connector
> >
> > I'm a little confused by that. Does this mean that the mod_jserv
> > mentioned in 2002/009 remains in place, and will continue to be used
> > for Tomcat 4.0? (I'm unsure because that case seem
Peter Tribble wrote:
>> We need to *try* to look into our crystal balls to believe if Tomcat
>> will follow a paradigm
>> of "no incomatibilities in Tomcat Minor releases).
>>
>> Also, if the community was to create a compatible 5.6 version, what
>> would we do?
>
> As a user who has deployed ess
Casper.Dik at Sun.COM wrote:
> What level of support can one expect for Tomcat (managed, I think, is the
> current value)
Yes, Tomcat support is managed (as majority of all open source programs
in Solaris).
http://www.sun.com/software/solaris/freeware/
Petr
Petr Sumbera writes:
> > Certainly when we talk about tomcat versions in the day job,
> > it's '5.5' not '5'. (We wouldn't ever want to accidentally get
> > tripped up by 5.0.) So to me 'tomcat55' looks quite natural :-)
>
> Exactly as Peter wrote. We cannot expect anything else beside 5.5 in
> v
James Carlson wrote:
> Casper.Dik at Sun.COM writes:
>>> I don't think that intermediate symbolic link does anything useful.
>>> The linker only records the actual file name (liblcms.so.1.0.16), and
>>> only uses the ".so" link to find it, so that liblcms.so.1 just
>>> provides obfuscation. ;-}
>>
James Carlson wrote:
> Petr Sumbera writes:
+ /usr/apache/libexec/mod_jk.so uncommitted Apache Tomcat connector
>>> I'm a little confused by that. Does this mean that the mod_jserv
>>> mentioned in 2002/009 remains in place, and will continue to be used
>>> for Tomcat 4.0? (I'm unsure beca
Alan Coopersmith writes:
> James Carlson wrote:
> > Casper.Dik at Sun.COM writes:
> >>> I don't think that intermediate symbolic link does anything useful.
> >>> The linker only records the actual file name (liblcms.so.1.0.16), and
> >>> only uses the ".so" link to find it, so that liblcms.so.1 jus
On Fri, Feb 01, 2008 at 05:43:50PM +0800, Elaine Xiong wrote:
> Nicolas Williams wrote:
> > It will cost very little extra work to make a list of interfaces and
> > stabilities now. And if the SQLite community sticks to its track record
> > to date then going with better than Volatile should cost
Elaine Xiong wrote:
> We browser team have no resource to support SQLite 3.x as higher levels
> than "Volatile".
The interface taxonomy is NOT an indication of Sun Support levels (i.e.,
backline, service, sustaining), but instead an indication of how Sun will
manage future interface evolution.
Petr Sumbera wrote:
> John Plocher wrote:
>> Petr Sumbera wrote:
>>> Tomcat is started (beside manually) via Apache 1.3 init script
>>
>> What about Apache 2.x - how does this work with that version?
>
> Answer is simple. It doesn't work.
OK, but...
>
> Tomcat was introduced when there was no
James Carlson wrote:
> The output of pkgconfig itself isn't private; it's used by other
> software to find this library.
>
> The file that is contributed by this library to make pkgconfig work is
> private. Nothing (other than pkgconfig itself) should be reaching
> around into /usr/lib/pkgconf
On Fri, Feb 01, 2008 at 08:47:36AM -0500, James Carlson wrote:
> OK. I haven't seen libraries where SONAME is something other than the
> actual file name ...
We've got a bunch; some even came through psarc:
$ elfdump -d /usr/lib/libdbus-1.so.3.4.0 | grep SONAME
[3] SONAME0x
Petr Sumbera wrote:
> James Carlson wrote:
>>> http://tomcat.apache.org/connectors-doc/generic_howto/workers.html
>> OK; so matching all of this up is "merely" a user configuration
>> problem, right?
>
> Yes.
This seems to be a huge architectural hole - things can't work out of the
box without th
Danek Duvall writes:
> > The file that is contributed by this library to make pkgconfig work is
> > private. Nothing (other than pkgconfig itself) should be reaching
> > around into /usr/lib/pkgconfig directly.
>
> I think that what the spec means to say is that the token "lcms" as a
> pkgconfig
John Plocher writes:
> Petr Sumbera wrote:
> > James Carlson wrote:
> >>> http://tomcat.apache.org/connectors-doc/generic_howto/workers.html
> >> OK; so matching all of this up is "merely" a user configuration
> >> problem, right?
> >
> > Yes.
>
> This seems to be a huge architectural hole - thin
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
Lloyd L Chambers writes:
> 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 roun
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
Elaine/John:
>> We browser team have no resource to support SQLite 3.x as higher
>> levels than "Volatile".
>
> The interface taxonomy is NOT an indication of Sun Support levels (i.e.,
> backline, service, sustaining), but instead an indication of how Sun will
> manage future interface evoluti
I agree that frequent updates to capture new formats are something we
should strive for. Such a simple single source program could be a good
test case to clear some crud out of the plumbing of Sun's processes and
speed things up.
But I'm not convinced frequent updates absolutely crucial to the
Bob Friesenhahn wrote:
> On Fri, 1 Feb 2008, James Carlson wrote:
>
>> The issue with it being Volatile is that nothing can use it. It
>> doesn't matter how often you update it if the result is something that
>> isn't reliable.
>>
>
> If that is the case, perhaps someone should actually ta
On Fri, Feb 01, 2008 at 01:49:29PM -0600, Brian Cameron wrote:
> I believe the main reason the JDS team wants these interfaces to be
> Volatile is so that other Sun groups that wish to depend on the
> interfaces sign contracts with us. This way the JDS team can manage
> the interfaces moving forwa
On Fri, Feb 01, 2008 at 02:09:50PM -0600, Nicolas Williams wrote:
> On Fri, Feb 01, 2008 at 01:49:29PM -0600, Brian Cameron wrote:
> > I believe the main reason the JDS team wants these interfaces to be
> > Volatile is so that other Sun groups that wish to depend on the
> > interfaces sign contract
Nicolas:
> It would still, however, save work to mark the stable parts of the API
> as Uncommitted.
What work would be saved, exactly?
Also, it would make more work if we find, in fact, the interfaces are
not as stable enough to meet Sun's understanding of "Uncommitted"
(which means that the in
On Fri, Feb 01, 2008 at 02:25:48PM -0600, Brian Cameron wrote:
> Nicolas:
> >It would still, however, save work to mark the stable parts of the API
> >as Uncommitted.
>
> What work would be saved, exactly?
Negotiating contracts, informing contract holders of updates. The
trade-off is that it wou
Brian Cameron writes:
> Also, it would make more work if we find, in fact, the interfaces are
> not as stable enough to meet Sun's understanding of "Uncommitted"
> (which means that the interfaces can't change in Solars 11, but only
> in Solaris 12 or later).
Marking it "Uncommitted" means that yo
On Fri, 1 Feb 2008, 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 releas
On Fri, 1 Feb 2008, James Carlson wrote:
>
> The issue with it being Volatile is that nothing can use it. It
> doesn't matter how often you update it if the result is something that
> isn't reliable.
If that is the case, perhaps someone should actually take a look at
this small package and reali
The problem is that RAW isn't a standard format. It's dumping all the
information the sensor receives into the file, hence when new sensors
get in the market their RAW files are different than the supported
ones.
I'm very impressed how projects like dcraw, and my personal favorite
ufraw can keep u
Brian Cameron writes:
> I believe the main reason the JDS team wants these interfaces to be
> Volatile is so that other Sun groups that wish to depend on the
> interfaces sign contracts with us. This way the JDS team can manage
In that case, make them either Project or Consolidation Private.
That
On Fri, Feb 01, 2008 at 03:51:37PM -0500, James Carlson wrote:
> Brian Cameron writes:
> > I believe the main reason the JDS team wants these interfaces to be
> > Volatile is so that other Sun groups that wish to depend on the
> > interfaces sign contracts with us. This way the JDS team can manage
Nicolas Williams writes:
> On Fri, Feb 01, 2008 at 03:51:37PM -0500, James Carlson wrote:
> > Brian Cameron writes:
> > > I believe the main reason the JDS team wants these interfaces to be
> > > Volatile is so that other Sun groups that wish to depend on the
> > > interfaces sign contracts with us
Nicolas:
> On Fri, Feb 01, 2008 at 02:25:48PM -0600, Brian Cameron wrote:
>> Nicolas:
>>> It would still, however, save work to mark the stable parts of the API
>>> as Uncommitted.
>> What work would be saved, exactly?
>
> Negotiating contracts, informing contract holders of updates. The
> trad
On Fri, Feb 01, 2008 at 04:13:00PM -0500, James Carlson wrote:
> Nicolas Williams writes:
> > Brian was right though: Volatile is "public and unstable for folks
> > outside the WOS" and "consolidation private for better-than-volatile
> > consumers in the WOS" (my rough translation of what the taxon
On Fri, Feb 01, 2008 at 03:22:39PM -0600, Brian Cameron wrote:
> Nicolas:
> >On Fri, Feb 01, 2008 at 02:25:48PM -0600, Brian Cameron wrote:
> >>Nicolas:
> >>>It would still, however, save work to mark the stable parts of the API
> >>>as Uncommitted.
> >>What work would be saved, exactly?
> >
> >Neg
Brian Cameron wrote:
> The JDS team does not want other
> teams to depend on interfaces, then get hit by a bug, and expect
> the JDS team to fix their bugs for them.
If the JDS team is the one integrating the feature, it is already
in the position of being involved with fixing bugs found. It s
John:
> If the JDS team is the one integrating the feature, it is already
> in the position of being involved with fixing bugs found. It sounds
> like you are just trying to make sure that your bugfix expectations
> are:
> JDS team will fix bugs that impact firefox,
> other teams will ne
Nicolas:
>> Note if we make SQLite Consolidation Private, this will mean that
>> we will likely opt to not distribute CLI, headers, or other
>> interfaces that other groups or external users would likely want.
>> I suppose we could provide things like the headers to internal
>> teams with contrac
I am sponsoring the following fasttrack for myself, requesting micro/patch
binding and a timeout of 2/13/2008.
-Chris
Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Multipl
> I agree we would be doing that anyways. However, without a
> contract, I am unsure how our team would be aware which other
> Consolidations might be using the interfaces. If we declare the
> interfaces as Uncommitted, then other consolidations do not need to
> tell the JDS consolidation that
Brian Cameron writes:
> It sounds like work is saved for people who want to use the interfaces.
> Not for the JDS team. :) Verifying that interfaces are stable is more
> work than just checking release notes, after all.
Not necessarily. I don't think anybody is expecting a byte-by-byte
examinat
Brian Cameron wrote:
> (which means that the interfaces can't change in Solars 11, but only
> in Solaris 12 or later).
What it means is that the interfaces can only change in a minor version
of the "desktop" consolidation, or whatever consolidation it really is
part of.
Not all the consolidation
Brian Cameron wrote:
> The JDS team would likely be willing to help fix bugs that affect
> other consolidations, but we would prefer contracts in place so we
> can keep track of who is actually using these interfaces.
You probably can't. You won't get contracts from ISVs and customers
who will e
John Plocher wrote:
> Brian Cameron wrote:
>> (which means that the interfaces can't change in Solars 11, but only
>> in Solaris 12 or later).
>
>
> What it means is that the interfaces can only change in a minor version
> of the "desktop" consolidation, or whatever consolidation it really is
> p
On Fri, Feb 01, 2008 at 03:15:57PM -0800, John Plocher wrote:
> Contracts help *SUN* developers; they leave OpenSolaris developers,
> ISVs and Customers out in the cold; worse, they reflect a very non-open
> way of thinking. Isn't the OpenSolaris Desktop CG /more/ than simply
> the Sun GNOME devel
I agree that ufraw would be good to add in the future. Ufraw uses dcraw
internally. Since dcraw isn't a shared library, ufraw has to compile in
new versions of the dcraw source code. It might be nice to fix that so
we don't end up maintaining both the dcraw embedded within ufraw and the
dcraw st
Alan Coopersmith wrote:
> John Plocher wrote:
>> Brian Cameron wrote:
>>> (which means that the interfaces can't change in Solars 11, but only
>>> in Solaris 12 or later).
>>
>> What it means is that the interfaces can only change in a minor version
>> of the "desktop" consolidation, or whatever co
> This case was closed approved in last PSARC meeting.
>
> Material was updated and saved as 'spec.txt' in case directory. In the
> updated material, interface name '/dev/dsp' was changed to
> '/dev/private_dsp' so that users won't stumble into it purely by
^^^
Was that r
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
James:
>> It sounds like work is saved for people who want to use the interfaces.
>> Not for the JDS team. :) Verifying that interfaces are stable is more
>> work than just checking release notes, after all.
>
> Not necessarily. I don't think anybody is expecting a byte-by-byte
> examination
On Fri, Feb 01, 2008 at 06:00:32PM -0600, Brian Cameron wrote:
> James:
> >You don't need to promise to boil away the ocean to see if there might
> >be rusty nails and other bugs at the bottom.
>
> I'm not sure it always makes sense to mark a Solaris interface as
> Committed or Uncommitted just be
Nicholas:
>> I'm not sure it always makes sense to mark a Solaris interface as
>> Committed or Uncommitted just because an external community has the
>> "intent" for stability.
>
> Yes, yes it does always make sense to ... just because ... (and for
> other reasons too). We ship multiple version
On Fri, Feb 01, 2008 at 06:26:15PM -0600, Brian Cameron wrote:
> Nicholas:
> >But we're making a distribution where we add value.
>
> We need to be clever about how we add value. I'm not sure, in the big
> scheme of things, that the stability level of SQLite is where we should
> be focusing our e
On Fri, Feb 01, 2008 at 06:26:15PM -0600, Brian Cameron wrote:
> Nicholas:
>
> >>I'm not sure it always makes sense to mark a Solaris interface as
> >>Committed or Uncommitted just because an external community has the
> >>"intent" for stability.
> >
> >Yes, yes it does always make sense to ... ju
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,
>> inte
Brian Cameron wrote:
> Volatile is only hard to use if the problem you describe actually
> happens. If the interfaces never break because the external community
> has good ABI compatibility, then users depending on that interface
> will probably not notice that the interface is Volatile.
Yet they
On Fri, Feb 01, 2008 at 05:37:41PM -0800, John Plocher wrote:
> I think I agree with Nicolas and DrH - statically link firefox
> with SQLite and don't attempt to make a shared version that you
> are unwilling or unable to properly support for general use.
In that case we could ship the header file
John:
> Yet they *will* need to re-validate and re-certify their stuff *EVERY*
> time you release a patch, upgrade or new version, just to prove that
> things that /could/ break actually didn't. With something stronger,
> they wouldn't.
>
> If you have 10 teams that reuse your stuff, this trans
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080201/4a2ef6b5/attachment.html>
James Carlson wrote:
>In this case, it looks like the original submitter incorrectly marked
>his materials as "Sun Proprietary/Confidential," which I believe
>triggers the omission of the case from the web site. Contact the case
>owner (Kais Belgaied) and intern (Frank Che) to have this fixed.
>
ctory.
Does the committee feel that a commitment review is required, or can we
add this to
next week's ARC Business?
-- mark
-- next part --
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080201/06700306/attachment.html>
This problem has been fixed. Now materials of this case is accessible
from OpenSolaris.
Frank.
Frank Che wrote:
> James Carlson wrote:
>
>> In this case, it looks like the original submitter incorrectly marked
>> his materials as "Sun Proprietary/Confidential," which I believe
>> triggers the o
72 matches
Mail list logo
