On Sun, 26 Jul 2009 16:00:57 -0700 Garrett D'Amore wrote:
> Roland Mainz wrote:
> > Alan Coopersmith wrote:
> >
> >> I'm sponsoring this fast-track request on behalf of the
> >> ksh93-integration and busybox projects. The timeout is
> >> set for Friday, July 31, 2009.
> >>
> > [snip]
> >
A "derail" doesn't mean the project is dead. It only means that the ARC
will have to vote and issue an opinion. The word "derail" relates to
"fast-track" -- a fast-track is a case that's "on the fast track to
approval", while the "slow track" means that there could be an actual
meeting, a vote, a
Joerg Schilling wrote:
> Wyllys Ingersoll wrote:
>
>> Wouldn't the logical replacement for Pth be libpthread or Solaris threads?
>> Why bother even attempting to write a new thread library when we have
>> viable alternatives? The goal should be to eliminate the need for Pth
>> in the programs
Personally, I _am_ a bit bothered by behavior that increases the
memory footprint. Consider virtualization: one may well want to
run virtual machines with as little memory as they strictly need,
since that's very easily adjustible, and since the less each guest
uses, the more remains for other gue
Glenn Fowler wrote:
> On Sun, 26 Jul 2009 16:00:57 -0700 Garrett D'Amore wrote:
>
>> Roland Mainz wrote:
>>
>>> Alan Coopersmith wrote:
>>>
>>>
I'm sponsoring this fast-track request on behalf of the
ksh93-integration and busybox projects. The timeout is
set for Fr
Roland Mainz wrote:
> Garret, would you accept the "truce" and remove the "de-rail", please ?
I think you're confused about the process that's in use in the ARC.
"De-rail" does not in any way mean "deny." In fact, it doesn't even
mean that there's anything wrong with the proposed project. I've
On 7/26/09, Josh Hurst wrote:
> On 7/26/09, Jennifer Pioch wrote:
> > On 7/26/09, Garrett D'Amore wrote:
> > > Roland Mainz wrote:
> > >
> > > > John Sonnenschein wrote:
> > > >
> > > >
> > > > > On 25-Jul-09, at 4:59 PM, James Carlson wrote:
> > > > >
> > > > >
> > > > > > Jo
On 7/26/09, Jennifer Pioch wrote:
> On 7/26/09, Garrett D'Amore wrote:
> > Roland Mainz wrote:
> >
> > > John Sonnenschein wrote:
> > >
> > >
> > > > On 25-Jul-09, at 4:59 PM, James Carlson wrote:
> > > >
> > > >
> > > > > John Sonnenschein wrote:
> > > > >
> > > > >
> > > > > > I've
Roland Mainz wrote:
> Alan Coopersmith wrote:
>
>> I'm sponsoring this fast-track request on behalf of the
>> ksh93-integration and busybox projects. The timeout is
>> set for Friday, July 31, 2009.
>>
> [snip]
>
> Just to clarify (since both points have IMHO been either ignored or
> misin
> On Wednesday at the PSARC meeting. Only regular PSARC members can vote.
Who elected the PSARC members?
Jenny
--
Jennifer Pioch, Uni Frankfurt
On 7/26/09, Garrett D'Amore wrote:
> Roland Mainz wrote:
>
> > John Sonnenschein wrote:
> >
> >
> > > On 25-Jul-09, at 4:59 PM, James Carlson wrote:
> > >
> > >
> > > > John Sonnenschein wrote:
> > > >
> > > >
> > > > > I've got a question about this...
> > > > > Whose responsibility is it to upda
On Jul 26, 2009, at 9:44 AM, Jennifer Pioch wrote:
>> On Wednesday at the PSARC meeting. Only regular PSARC members can
>> vote.
>
> Who elected the PSARC members?
Nobody. Sun's CTO founded the ARC 19 years ago. Since then, new
members have been added by having the existing members nominate
Hi Roland,
I'm not against having multiple ways of accessing the man page data as long as
the output is consistent. The solution you mentioned below I think is
reasonable and something that can be maintained. Having the docbook/xml master
source would solve a lot of issues and could be the sin
Alan Coopersmith wrote:
> Garrett D'Amore wrote:
>
>> When the --man output really is a manual page, I still object. It
>> doesn't matter what you call it -- the problem is that we have two
>> copies of the same information, the on-line manual page and the bits in
>> the binary.
>>
>
> Wil
Garrett D'Amore wrote:
> When the --man output really is a manual page, I still object. It
> doesn't matter what you call it -- the problem is that we have two
> copies of the same information, the on-line manual page and the bits in
> the binary.
Will your opinion text also recommend to the PAC
Jennifer Pioch wrote:
> On 7/26/09, Garrett D'Amore wrote:
>
>
> Didn't you read what Roland wrote about the project rules?
>
>> in several major and unbreakable rules for this project which
>> includes:
>> - WE DO NOT FORK THE CODE
>> - WE DO NOT BREAK THE KSH93 TEST SUITE
>> - THE KSH93 TE
Jennifer Pioch wrote:
>> On Wednesday at the PSARC meeting. Only regular PSARC members can vote.
>>
>
> Who elected the PSARC members?
>
> Jenny
>
I'm not sure about the first round, but PSARC members are selected by
other PSARC members after first serving an internship. They are
selec
John Sonnenschein wrote:
> On 25-Jul-09, at 4:59 PM, James Carlson wrote:
> > John Sonnenschein wrote:
> >> I've got a question about this...
> >> Whose responsibility is it to update the man pages and --man
> >> command then? The people whose jobs it is to update man pages, or
> >> the people whos
Garrett D'Amore wrote:
> Alan Coopersmith wrote:
> > Garrett D'Amore wrote:
> >> 1) The commands increase the size of the text segment. Not only does
> >> it add new parsing requirements (you have to at least have enough code
> >> to handle --man, for example), but you also have the text of the m
"I. Szczesniak" wrote:
> On 7/25/09, Garrett D'Amore wrote:
> > Roland Mainz wrote:
> > > Garrett D'Amore wrote:
> > > > Alan Coopersmith wrote:
> > > > > Garrett D'Amore wrote:
[snip]
> > > > Strongly enough that
> > > > I'm contemplating derailing the case.
> > >
> > > And what should we do then
Garrett D'Amore wrote:
> Roland Mainz wrote:
> > Garrett D'Amore wrote:
> >> Alan Coopersmith wrote:
> >>> Garrett D'Amore wrote:
[snip]
> >> There's yet another concern, which is that I've found that man
> >> and command --man do not generate the same document. So we know
> >> introduce a proble
John Sonnenschein wrote:
> On 24-Jul-09, at 11:01 PM, Garrett D'Amore wrote:
> > Roland Mainz wrote:
> >> Garrett D'Amore wrote:
> >>> Alan Coopersmith wrote:
[snip]
> > I will say just one more thing. Where it not for the --man, --
> > nroff, and --html options, I think I would unhesitatingly gi
"Garrett D'Amore" wrote:
> I think you and Wyllys are in violent agreement. :-) The original
> program has to be modified to use pthreads, rather than trying to hide
> this underneath a Pth wrapper. That means that you recompile the
> program, and possibly have to modify the source if it is
re eliding portions of libast::optget() usage strings via #ifdef SOLARIS or
whatever
the optget() usage string contains:
(1) information required for short and long options, and proper rendering
of diagnostics for option errors
(2) version, author and copyright information
(3) optional callb
re concerns about libast::optget() string out of sync with .1 man page
I mentioned this in a previous post but it must have gotten lost
amidst the volume of posts: the separate ksh93 sh.1 man page is an
exception rather than the rule for ast section 1 utilities
in almost all other cases the optg
25 matches
Mail list logo
