Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99647
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 209.85.218.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJW__o1LNbu0F80wd5Eo8LWC5U1e4Wz5f=4_WqzRHCryvA4b=Q@mail.gmail.com>
References: <e982c2fa-e08c-0970-53d2-c0d6421c9573@fleshgrinder.com>
 <CAF+90c-9uSA+ykCWg_+pSRdZpJcLoScHawK8MWVGGjCx+dA59g@mail.gmail.com>
 <31e715a7-d129-17f0-b870-52bc1ca1715d@fleshgrinder.com> <af8671d1-9040-39ca-6a8b-fe589d94e2b5@oracle.com>
 <76397c50-1bb6-a777-2f72-25a7ed9981dc@fleshgrinder.com> <HE1PR02MB1052BE9280284A99AA53466BBAD90@HE1PR02MB1052.eurprd02.prod.outlook.com>
 <4f803b88-813d-dacb-db05-248b5e372899@fleshgrinder.com> <HE1PR02MB1052131D94EA1956D5F785A1BAD90@HE1PR02MB1052.eurprd02.prod.outlook.com>
 <CAL=_i_kvGz6K217VUmyk9HU28BHTOXkMXtL7nJ8H7U8BRoHq_Q@mail.gmail.com> <CAJW__o1LNbu0F80wd5Eo8LWC5U1e4Wz5f=4_WqzRHCryvA4b=Q@mail.gmail.com>
Date: Mon, 26 Jun 2017 19:45:21 -0700
Message-ID: <CACXBjug1mTAA4vgfj_+Jqqbf_7gM_-qTesVYuc8fcsX4vaqDBQ@mail.gmail.com>
To: Kalle Sommer Nielsen <kalle@php.net>
Cc: Joe Watkins <pthreads@pthreads.org>, Anatol Belski <weltling@outlook.de>, 
	Fleshgrinder <php@fleshgrinder.com>, php-internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a11c164a87505070552e81168"
Subject: Re: [PHP-DEV] [RFC] [Vote] Doxygen
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--001a11c164a87505070552e81168
Content-Type: text/plain; charset="UTF-8"

No from me as well. This is wagging the dog by the tail. Picking a
documentation format is the very least of the concerns here. It would be
wonderful to have better internal API documentation, but putting up any
sort of structural restriction like limiting it to a specific header-based
format, isn't going to make such documentation more likely. I couldn't care
less which format such documentation is in. If the folks who are capable of
writing decent API docs want to do it in Microsoft Word, LaTeX or some
weird SGML format, great! Whatever format it might appear in we can use and
convert to whatever makes sense at that point.

-Rasmus

On Mon, Jun 26, 2017 at 5:26 AM, Kalle Sommer Nielsen <kalle@php.net> wrote:

> HI Joe,
>
> 2017-06-26 8:43 GMT+02:00 Joe Watkins <pthreads@pthreads.org>:
> > Morning,
> >
> > I also voted no for similar reasons to Anatol.
> >
> > This is not really a thing that needs a vote, this is a thing that
> requires
> > the handful of people who are actually able to document ZE to spend
> > considerable time doing so. In addition it requires a commitment from the
> > community of developers to continue to maintain, and introduce inline
> > documentation with new code.
> >
> > Additionally, I'm a little concerned that an RFC that has the potential
> to
> > touch every single source file has gone to vote with a simple majority.
> It
> > would seem that we are deciding that new code must be documented in this
> > specific way, to say nothing of the massive task of documenting existing
> > code. That would seem to be a decision that could effect everybody that
> > works on PHP in perpetuity and a simple majority is nothing like a strong
> > enough consensus.
>
> I'm in the same boat as you and Anatol here.
>
> I think it is important to note that all who actively work on the
> Core/Engine have no except for Stas, which also should be a good
> indicator that we should be concerned.
> --
> regards,
>
> Kalle Sommer Nielsen
> kalle@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11c164a87505070552e81168--