Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68806
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1377995105.3656.50.camel@guybrush>
References: <1377979523.3656.21.camel@guybrush>
	<CAEZPtU6fuU8cK2gaE5sxk=TqZeA=G8oZEsRBN-+G8RvcQmCe0w@mail.gmail.com>
	<1377995105.3656.50.camel@guybrush>
Date: Sun, 1 Sep 2013 03:01:28 +0200
Message-ID: <CAEZPtU7ZQgLWEOro4bBd-HxGc_AmJ2eiPwpZ_QMyfTGd14CdTg@mail.gmail.com>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] windows.php.net
From: pierre.php@gmail.com (Pierre Joye)

On Sun, Sep 1, 2013 at 2:25 AM, Johannes Schl=FCter
<johannes@schlueters.de> wrote:
> On Sun, 2013-09-01 at 01:50 +0200, Pierre Joye wrote:
>> > Why and for what?
>> >
>> > Few data items:
>> >       * The "news" on w.p.n are not really maintained and provide
>> >         outdated info.
>>
>> I take the blame for that. We have been too busy with (many) other
>> (also non windows specific) QA tasks. The news page issue will be
>> solved soon, early october max.
>
> We hear that for a few years already. Everybody touching pecl is being
> shot back as there are "major" changes coming.

Really? And what do you do? Feel bored and need something to do in
these late summer days? Be serious 2.5 seconds, thanks.

>> >       * Downloads are not using our 90 world-wide mirrors but a single
>> >         site giving worse connection quality than needed
>>
>> Wrong, about the quality. And there are legal reasons why we do not
>> use the mirrors or other php.net download pages.
>
> Well, I got some complains from time to time, obviously hard to tell
> whether it where the cause was, and even if it works acceptable fast
> it's still a single point of failure. 1 vs 90 machines. And for legal
> reasons one can certainly find a solution.

Oh? We have only one machine, nice to know.

> Also I don't consider the separation userfriendly. A user comes to
> php.net and tries to fetch downloads ... that might be streamlined quite
> a bit when properly grouped together.

Many can, could, should or would. Complaining and doing almost nothing
however do not help anyone.

>> >       * Snapshots on that site are outdated since more than a year (on=
e
>> >         can find newer ones when looking at a small note)
>>
>> Wrong but you are uninformed or did not dig it enough, or do not
>> follow internals nor bugs.php.net. For your defense, there is a bug in
>> the snapshot page, blame me too.
>
>> For snapshots, see http://windows.php.net/downloads/snaps/
>
> Read the part in parenthesis. One has to be quite observant to see that.
> I can understand that such a thing doesn't happen immediately after
> svn2git change, but 1.5 years should be enough to either do it or ask
> for volunteers.

what does it have to do with svn2git? (no, please do not answer this
question, I am not interested in discussing this, it is totally wrong
and irrelevant).

>
>> >       * Team lists three people I don't know (might be my fault) who
>> >         probably aren't part of the php.net community (what ever that
>> >         is) and in general I don't understand the need for extra
>> >         credits.
>>
>> Yes, your fault. Follow more closely who does the job and you may know
>> them. Sorry to sound harsh, but I can hardly be diplomatic right now.
>
> As said: I can have missed some of them, still i don't see need for
> extra lists. We have one credits page.

We have no system sections in phpinfo, last time I checked. I may need
to update the QA one tho', not sure if I added Matt and Anatol.

>> >       * The site can only be updated by a small group of people
>> >         different requests to broaden this (i.e. by updating from git
>> >         like other php.net sites) have been rejected (or at least
>> >         ignored, i.e. bug #64277)
>>
>> Like to talk about bugs not being taken care of? Please look at the
>> blocking mysql bugs, which are much more critical than some (c) dates
>> or similar issues, also much older than a week.
>
> Everybody with php karma can fix mysql and other bugs. Work on w.p.n is
> actively being discouraged.

We do report bugs and provide(d) support to the mysql team. However we
do not the time resources to spend days to debug it and fix it. We
found the issues, debug it to the point where we know why it fails,
now it is up to you to fix or ask for further infos without me running
after you. Or do not, but then testing mysql* is becoming harder and
more useless as it should be.

>> >         and probably a different approach to provision the
>> distributions
>> >         directory (git is not thaaat usable with these tons of
>> "large"
>> >         binary files)
>>
>> Not going to happen either, for various reasons, legal, technical,
>> security reasons.
>
> What ind of technical problems are there? It's software. Most of us are
> developers. We have a quite huge community we could invite where
> needed ...

Indeed, we are falling under a huge amount of volunteers knocking at
our doors to contribute or do something. Keep going, it helps.

> If there are security issues on php.net sites they should be fixed. Both
> for providing source as for providing binaries.

Should, could, would, all nice verbs, reallly love them :)


>> >       * handle QA releases similar to snaps, if distributed from
>> w.p.n
>> >         provide direct links from qa.php.net
>>
>> There is a link there.
>>
> I was more like thinking about direct download links, so I can tell a
> user "go to qa.php.net" and him not having to switch sites.

Yes, they go, click on the windows link and they got all they need.

It needs improvements, especially about which version to choose and
the likes. (Constructive) feedback or contributions welcome, as usual.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org