- Original Message -
From: James Carlson james.d.carl...@sun.com
Date: Thursday, January 15, 2009 11:33 pm
Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009]
To: Xiang Samuel Zhou Xiang.Zhou at Sun.COM
Cc: Edward Pilatowicz Edward.Pilatowicz at Sun.COM, PSARC-ext at
Since there's no more comments,
I am closing this case as approved :)
--Irene
Alfred Peng wrote:
Hi Irene,
Irene Huang wrote:
Hi, Hugh
Hugh McIntyre wrote:
It's not clear from the public materials if you'll be shipping a man
page or not. It's also not clear from the webkit.org sources
The project team would like to add two more exported interfaces for this
project, as described below. I think it's qualified for self review.
Since this project hasn't been integrate into Nevada yet, I think it
should be OK to just reply to this mail and add new information for
recording
Hello,
please see my comments...
Petr
Jim Walker wrote:
I would like some clarification on jar file porting for
future arc cases.
findbugs plans to integrate the following project private
jar files.
163 f none usr/share/lib/java/findbugs/asm-analysis-3.1.jar
164 f none
Muktha
-- next part --
An HTML attachment was scrubbed...
URL:
http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090116/9062410d/attachment.html
Petr Slechta wrote:
/usr/share/lib/java/
My personal opinion is that sharing all jar libraries is not good idea.
If every application has its own copies of jars then it is independent.
(Uninstallation of other application cannot brake it.) Jar files are
small and today we have disks
Hi Muktha,
On 16.1.2009, at 13:08, Muktha Narayan wrote:
Hi Mark,
Mark Phalan wrote:
On Wed, 2009-01-14 at 15:50 -0800, Mark Carlson wrote:
4. Technical Description:
Elinks is a program for browsing the web in text mode. It is an
advanced and well-established feature-rich text
Brian Utterback wrote:
Petr Slechta wrote:
/usr/share/lib/java/
My personal opinion is that sharing all jar libraries is not good
idea. If every application has its own copies of jars then it is
independent. (Uninstallation of other application cannot brake it.)
Jar files are small and
Brian Utterback writes:
From a sustaining point of view, having multiple copies of things is
a nightmare. Suppose a security issue comes up with one of the
components? We then have to find and fix all those copies. If we do
what you suggest and include pre-compiled components, then we
Petr Slechta wrote:
And I know the provenance of the library. Many O/S projects use Apache
commons libraries for example. Nobody compiles them, everybody just use
them. I trust this library. I can get sources, but would you examine
each line of the code to be sure that the library is OK?
I don't want to argue more about this. I don't agree, but I can do it
the requested way. I hope after the change, there will be no additional
objections. You can see that I was waiting 2 months for LSARC and I
presented package structure as part of the LSARC review. The LSARC is
over and
Petr Slechta writes:
OK, if everything should be compiled (even if there are projects in SFW
that do not do it), should I compile the libraries as part of findbugs
project, or should I create separate project for each library (or set of
libraries)? Like:
I see no reason that the existing
On Fri, Jan 16, 2009 at 7:55 AM, Petr Slechta Petr.Slechta at sun.com wrote:
I strongly believe that nobody will fix jar libraries. If there is a
problem and new library is available, we can get it and replace it. We
don't need to compile it.
Trust, but verify
On Fri, Jan 16, 2009 at 9:08 AM, James Carlson james.d.carlson at sun.com
wrote:
Petr Slechta writes:
OK, if everything should be compiled (even if there are projects in SFW
that do not do it), should I compile the libraries as part of findbugs
project, or should I create separate project for
Dale,
You make some assumptions about a group of people you call 'devs',
and you are correctly describing a certain class of people,
but your description doesn't cover all users of compilers.
There are two different kinds of users in this discussion.
Sometimes they are the same person wearing
On Fri, Jan 16, 2009 at 02:53:30PM +0100, Jan Spitalnik wrote:
On 16.1.2009, at 13:08, Muktha Narayan wrote:
What optional features will be compiled in (from features.conf)?
The default features.conf of the community source base has not been
modified and the features compiled are:
On Fri, Jan 16, 2009 at 12:33:32AM +0800, Xiang Samuel Zhou wrote:
- Original Message -
From: James Carlson James.D.Carlson at Sun.COM
Date: Thursday, January 15, 2009 11:33 pm
Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009]
To: Xiang Samuel Zhou Xiang.Zhou at
Just for clarification:
The existing SS12 installer uses a SYSV package with only
links in it to optionally place links in /usr/bin for SS12.
Solaris 10 packages will normally over-write files that
are already on the system.
The one-pager also describes a separate package for the symlinks.
The
Nicolas Williams wrote:
Of course, looking at it from the point of view of how many Sun Studio
versions we've used in Solaris 10 and Nevada development, we know that
multiple versions are likely going to be needed. But at least for
Solaris consolidations a single bundled version translates
On Fri, Jan 16, 2009 at 10:46:32AM -0800, Chris Quenelle wrote:
Nicolas Williams wrote:
Of course, looking at it from the point of view of how many Sun Studio
versions we've used in Solaris 10 and Nevada development, we know that
multiple versions are likely going to be needed. But at
Mark,
I am submitting the following self-review case,
with requested release binding of minor.
Perhaps, with IPS being the way of the future, it might not matter.
But: shouldn't this be patch binding? Ie it will be unusable in svr4
packaging scripts unless it is backported, because the
/opensolaris-arc/attachments/20090116/a881b58b/attachment.html
22 matches
Mail list logo
