On 08/11/10 08:57 PM, Ienup Sung wrote:
This case extends fnmatch(3C) to have the support for FNM_CASEFOLD,
FNM_FILE_NAME, FNM_IGNORECASE, and FNM_LEADING_DIR flags as specified in [2].
This is to be more compatible with other platforms such as Linux distros
and BSD variants including MacOS X
On 08/ 5/10 01:21 AM, Fuyuki Hasegawa wrote:
Hi Sebastien,
Agreed. I've moved out the default change from the material
and also updated the IAM file.
/shared/sac/Archives/Projects/2010/20100729_kazuhiko.maekawa
If no more objection for this case, could you vote your +1?
Yes, +1. Could you
On 07/29/10 09:49 AM, Fuyuki Hasegawa wrote:
This case is also to change system default IMF from IIIMF to IBus
which becomes de-facto standard in recent major Linux distributions.
Locales that IMF is invoked by default is also changed from all UTF-8
locales to only Asian
On 08/ 4/10 01:07 PM, Jerry Jelinek wrote:
This case was approved at todays PSARC meeting.
I've marked it closed approved.
I gave the case a +1 during the meeting, and am doing so here as well.
-Seb
___
opensolaris-arc mailing list
On 08/ 2/10 09:19 PM, Roger A. Faulkner wrote:
As a result of suggestions made in the email for this case,
I am sending this revised, final version of the proposal
(with additional bugids included and with the description
of getprogname(), setprogname() and __progname included):
This case was
On 07/21/10 01:56 PM, Cynthia McGuire wrote:
This case seeks patch binding. The timer is shorter than the standard
1-week to accomodate a tight integration schedule. If anyone needs
additional time to review this, let us know.
Is there a reason why the localized contents of the reason-long
On 07/26/10 01:35 PM, Peter Dennis wrote:
The case will be updated so as _not_ to include /etc/rmt.
The change to the /etc/skel profiles will be documented as
well.
The other changes within ON are internal to the commands used
and are small changes.
As mentioned by others now is the time to
On 07/26/10 04:49 PM, Sebastien Roy wrote:
I think at this point, we've identified that this is at least not
uncontroversial, and thus fails the fast-track test. As a result, I'm
derailing this case.
Also, as is customary, I'll own the full case and have placed it in
waiting need meeting
On 07/22/10 11:13 PM, Mark Haywood wrote:
Nicolas Williams wrote:
On Thu, Jul 22, 2010 at 09:43:37AM -0400, Mark Haywood wrote:
What is the console message ?
As mentioned in the case:
Similarly, if the IPMP service is disabled while IPMP groups are
configured, the service stop method will
On 07/21/10 01:56 PM, Cynthia McGuire wrote:
This case seeks patch binding. The timer is shorter than the standard
1-week to accomodate a tight integration schedule. If anyone needs
additional time to review this, let us know.
We already went through this litany during the PSARC meeting
On 07/21/10 02:19 PM, Sebastien Roy wrote:
On 07/21/10 01:56 PM, Cynthia McGuire wrote:
This case seeks patch binding. The timer is shorter than the standard
1-week to accomodate a tight integration schedule. If anyone needs
additional time to review this, let us know.
We already went through
I'm happy with the updated spec. +1
-Seb
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
On 07/ 4/10 02:08 AM, Shawn Emery wrote:
I've made updates based on Sebastien and Nico comments:
+1
-Seb
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
Gavin,
On 07/ 6/10 05:20 PM, Gavin Maltby wrote:
On 07/07/10 02:26, Sebastien Roy wrote:
Cynthia,
I've placed this case in waiting need spec since the spec was never sent
to the case log. Please do so.
It's there - once you click the case from something like the New listing
on sac.sfbay
On 06/30/10 06:29 PM, Shawn Emery wrote:
On Jun 30, 2010, at 12:19 PM, Sebastien Roysebastien@oracle.com wrote:
A couple of quick questions:
1. What is the release binding?
It follows the CIFS project, which I don't know off the top of my head.
I don't see how CIFS is relevant to the
On 06/30/10 08:33 PM, Barry Harding wrote:
Since our new project will support the functionality covered by the
other case (PSARC 2009/467),
I think it does obsolete that other case and that it could/should get
withdrawn...
You cannot withdraw an approved case, but it can be superseded. Please
On 07/ 1/10 02:43 PM, Kevin Song wrote:
On 07/01/10 11:31 AM, Sebastien Roy wrote:
On 07/ 1/10 01:58 PM, Kevin Song wrote:
Jim,
Please derail PSARC 2009/467 with a note of PSARC 2010/252.
Two things:
1. 2009/467 was already approved, and so it cannot be derailed.
2. 2009/467 was a full
On 07/ 1/10 01:58 PM, Kevin Song wrote:
Jim,
Please derail PSARC 2009/467 with a note of PSARC 2010/252.
Two things:
1. 2009/467 was already approved, and so it cannot be derailed.
2. 2009/467 was a full case, and so it cannot be derailed (derailing is
only for fast-tracks that need a full
A couple of quick questions:
1. What is the release binding?
2. I assume that this is a C API. What library does it live in? If
it's a new library, where does it live and as part of what package?
Thanks,
-Seb
___
opensolaris-arc mailing list
On 06/17/10 09:17 PM, John Fischer wrote:
Please review these new materials and the draft opinion. Either provide
feedback
or vote on the case by COB Wednesday, June 30th, 2010.
My vote is approve.
-Seb
___
opensolaris-arc mailing list
This case was approved during last week's meeting. Note that the final
spec is enclosed in the materials directory.
-Seb
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
On 06/17/10 11:21 AM, Garrett D'Amore wrote:
On Thu, 2010-06-17 at 10:54 +0100, Darren J Moffat wrote:
My only concern is this paragraph:
The project team reserves the right to revise the exact list of
certificates and/or choose an entirely different source of certifcates
at anytime without
On 06/16/10 11:26 AM, Hillel Lubman wrote:
I'm trying to configure ejabberd
...
This is off-topic for this mailing list. This purpose of this list is
to hold architectural reviews of projects under development. Try
desktop-disc...@opensolaris.org.
-Seb
+1, I have no issues.
-Seb
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
Hello Nils,
On 06/11/10 05:03 PM, Nils Goroll wrote:
I just noticed the commit msg for this case. I understand the ARC case is
unpublished, but would it be possible to get some basic background information
about it?
The case synopsis (EOF lx brand) captures most of what is
architecturally
On 06/ 9/10 04:38 PM, Alan Coopersmith wrote:
It appears the Network Configuration is IPv4 only. Shouldn't we
be prepared for IPv6 at this point?
The common case for IPv6 will likely be stateless address
autoconfiguration, which doesn't require specifying a static IPv6
address. As a
Neal,
On 06/ 9/10 04:45 PM, Neal Pollack wrote:
Off Topic
Yes indeed. Please ask such questions directly to the appropriate
project team members or to a more appropriate mailing list. This
external mailing list is for open architecture reviews of specific PSARC
cases, and mail sent here
On 06/ 8/10 01:50 PM, Suhasini Peddada wrote:
Hi James,
On 06/08/10 10:35 AM, James Carlson wrote:
I'm not opposed to the project, but I do think it'd be much simpler if
we had a higher-level (say, architectural) review of the delivery
mechanisms themselves.
In reviewing the Brownian motion
On 06/ 4/10 09:44 AM, Sebastien Roy wrote:
I'll send a note once we have an updated spec.
An updated spec (with '+' change marks in the left column) has been
placed in the materials directory. Note that the materials update
constitutes clarifications and not a change in the architecture
On 06/ 7/10 10:23 AM, James Carlson wrote:
Sebastien Roy wrote:
On 06/ 4/10 09:44 AM, Sebastien Roy wrote:
I'll send a note once we have an updated spec.
An updated spec (with '+' change marks in the left column) has been
placed in the materials directory. Note that the materials update
I'm submitting this fast-track for Cathy Zhou, timing out on 06/14/2010.
The design document referenced below is contained in the materials
directory.
Problem Area
TCP, as a protocol widely used for reliable end-to-end network
communication, the users must often perform
On 06/ 2/10 01:43 PM, James Carlson wrote:
James Carlson wrote:
That's the part that still confuses me. I'd expected that, just as
installation was based on NWAM in OpenSolaris, this would be the
pattern for the future as well.
And, now, I understand Mark's last reply, where he said:
I
On 06/ 2/10 04:08 PM, Tom Erickson wrote:
Sebastien Roy wrote:
I only have one comment regarding the zfs pool version handling:
C.2. Version Compatibility
To get the full benefit of the options described in this case, the ZFS
pool needs to be at version 22 (received properties) or later
On 05/25/10 04:01 PM, Dan Price wrote:
I am filing this case on behalf of myself. This case completes work
begun half a decade ago in PSARC/2005/592, by EOFing the FMLI facility.
Given the context of lu going away, this is rather straightforward. +1
-Seb
This case was approved during last week's meeting.
-Seb
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
On 05/12/10 05:17 PM, Darren Reed wrote:
There seems to be a lot of questions about the details on this case,
as one of the few remaining PSARC members,
There are fifteen PSARC members, twelve of which are currently active
(meaning not on sabbatical), but that's beside the point.
does this
I'm changing the status of this case to waiting need spec while the
project team and other interested parties hold offline discussions on
the specifics of this case and its greater context. Thanks to those who
reviewed this case and provided constructive input. Please hold further
comments
On 05/13/10 07:32 PM, Edward Pilatowicz wrote:
On Thu, May 13, 2010 at 04:10:05PM -0700, Darren Reed wrote:
On 13/05/10 01:29 PM, sowmini.varad...@oracle.com wrote:
Rishi Srivatsavai is looking into the work entailed to have mac-nospoof
enabled for NGZ by default.. just talked to Rishi, and I
I'm submitting this fast-track for Sowmini Varadhan. The release
binding is Minor and new zonecfg(1M) properties are Committed.
Summary:
---
This case proposes a solution for
6944327 need to support address and defrouter resources for
exclusive-IP zones
Problem Description
On 04/30/10 08:48 PM, Albert Lee wrote:
On Fri, 30 Apr 2010 17:31:44 -0400, Sebastien Roy
sebastien@oracle.com wrote:
What kinds of source URLs are supported (e.g., http://, https://,
file://, ftp://, all of the above?)? Does this deal with HTTP
proxies?
How?
pkgtool invokes external
On 05/ 1/10 08:14 AM, Laszlo (Laca) Peter wrote:
Thanks Albert for answering the questions for me :)
Agreed on all counts.
On Fri, 2010-04-30 at 20:48 -0400, Albert Lee wrote:
The initial request in my original comment was for the stability level
of the spec file syntax. I would guess that
A couple of minor questions:
The spec file syntax is also conceptually an exported interface, and it
needs a stability level. It would be nice if the spec file syntax were
part of the materials (I'm guessing it's documented somewhere anyway).
How will the tools handle a hypothetical
On 04/23/10 10:09 AM, Darren J Moffat wrote:
2. Device visibility
...
Within each zone, lofiadm(1m) is only allowed to see, or modify,
the nodes it has created. The global zone can access all nodes,
however, for example:
# lofiadm
Block Device File
I'm submitting this fast-track for Anurag Maskey. It times out on
04/29/2010. The release binding is Minor.
Libinetcfg library removal
--
This case removes the libinetcfg library introduced into ON by
PSARC/2001/544 as a Consolidation Private library and modified in
On 03/31/10 12:19 PM, Garrett D'Amore wrote:
The project team has decided to change the proposal to remove the
contentious builtins for /usr/gnu. Instead, only /usr/bin and
/usr/xpg4,xpg6 utilities are being provided as builtins. As these
utilities will hopefully one day be converted to use the
On 04/21/10 01:27 PM, Jim Walker wrote:
(reminder - I extended this until Friday)
Here is the opinion for PSARC/2010/059 SNAP BE Management.
http://arc.opensolaris.org/caselog/PSARC/2010/059/opinion_draft.txt
I request a commitment email vote.
Suggestion: Perhaps a subject line starting
On 04/21/10 01:19 PM, Bart Smaalders wrote:
On 04/21/10 09:14, John Fischer wrote:
2.1. Availability through OpenSolaris /contrib repository
The OpenSolaris /contrib repository [1] is a more appropriate
mechanism for delivering Areca Backup to interested consumers.
A separate and independent
Ken,
This is off-topic for opensolaris-...@opensolaris.org. This mailing
list is used by the ARC community to conduct architecture reviews of
specific software projects as they go through the development process.
It looks like you might have meant to send this to
48 matches
Mail list logo
