Re: [PEAR-DEV]PEAR_Exception-1.0.0beta1 (beta) Released.

My comments are inline...

On Thu, Feb 27, 2014 at 12:55 PM, till <[email protected]> wrote:

> Hey,
>
>
> On Thu, Feb 27, 2014 at 1:37 PM, Alexey Borzov <[email protected]> wrote:
>
>> Hi Till,
>>
>> A couple of questions first:
>>  1) We do have a consensus on releasing a PHP5-only PEAR 1.10?
>>
>
> I personally think that's fine. We can also release a PEAR 2.0 to keep
> semver.
>
>
>>  2) What's your opinion on Christian's suggestion about creating a
>> 1.10-stable branch and cherry-picking changes for that?
>
>
> Fine with that as well.
>
> If we change the minimum PHP version, then maybe a 2.0 is much better. I
> always liked that PEAR keeps proper BC and semver when others don't.
>

I'm fine with all of this.

On 27.02.2014 14:59, till wrote:

> Hey Alexey,
>
> I released PEAR_Exception so people could test PEAR.
>

Is this even necessary? I mean, you can do an install using package.xml
>> from checkout without actually releasing package on the channel.
>>
>
> It seemed necessary in here (but you've seen that PR, I think):
> https://github.com/pear/pear-core/pull/27
>
>
>>
>> This may make sense if we push out 1.10-beta in a few days, but I'd
>> suggest fixing a few things before that.
>>
>>
>>
>>  The weird content-type/charset bugfix you were referring to was fixed in
>>> master (last year) and still not released.
>>>
>>
>> ...and the relevant bug reports were not closed either.
>>
>> OK, I'll also look through commits and close the reports that are
>> probably addressed already.
>
>
> OK, thanks!
>
>
>>
>>
>>
>>  I don't know where this is at right now. I think Ken wanted to split the
>>> PEAR release so the man-files (role-related) are installed seperately and
>>> allow for smoother upgrade process.
>>>
>>
>> Yep, I've read the comments in
>> https://github.com/pear/pear-core/pull/27
>>
>> I agree with Ken here.
>
>
> OK, great.
>
>
>>
>>
Superb :-)

I did this because of the circular dependency of PEAR attempting to install
the bundled man pages before installing the man role handler[s] - I think
this is mentioned in the comments linked to above.


>
>>
>>  I agree this should be released ASAP. There are a ton of fixes in there
>>> which could be shipped. I just don't know a whole lot about the process
>>> and
>>> just hacked my way through it so the guy who reported the bug and opened
>>> a
>>> PR could test master first.
>>>
>>
>> What problems can we face when doing the release? The first thing that
>> comes to mind is replacing the go-pear.phar, is the process automated /
>> documented?
>
>
> I don't know. I'll cc Helgi and Brett and hope they can chime in.
>

Helgi? Brett? Bueller?


 I can't comment on why PEAR contains an HTTP client, I am +1 if you want to
> strip it out.
>

I'll see whether it is possible to integrate HTTP_Request2 with minimal
>> fuss.
>>
>>
That would be brilliant. It would also allow us to test edge cases with
mocks.


> Also a thing to consider: currently PEAR does nothing about peer
>> validation for HTTPS. This may bite us in the ass when PHP 5.6 comes out.
>
>
At first blush, this is probably something we can test with mocks if we
integrate HTTP_Request2.

 Maybe we could use this opportunity to document the process so others can
> go ahead.
>

Fantastic idea, because, tbh, I think a lack of documentation might be why
some of us have been reticent to do anything to pear-core until now,
especially as pear-code/pear installer is so crucial.


> Good idea, should we use the wiki for that?
>> https://wiki.php.net/pear
>
>
> We could also add the release process to the README. At least then it's
> where the code is.
>
> We can link that.
>
>
>>
>>
>> I'd suggest at least documenting that PEAR lives @ github and list people
>> having push access to the repository.
>
>
> Yeah, good idea.
>
> Till
>
>>
>>
>>
>>  On Thu, Feb 27, 2014 at 10:11 AM, Alexey Borzov <[email protected]>
>>> wrote:
>>>
>>>
 <snip>

>
> On 26.02.2014 1:30, Christian Weiske wrote:
>>>>
>>>>  Hello Alexey,
>>>>>
>>>>>
>>>>>   Helgi (or whoever released this), is this a good idea to do a
>>>>>
>>>>>> separate PEAR_Exception without releasing a new PEAR package
>>>>>> simultaneously? Current PEAR package contains PEAR_Exception class as
>>>>>> well and this will probably lead to conflicts.
>>>>>>
>>>>>>  Yes, a new pear release is needed.
>>>>>
>>>>>
>>>>>   I don't quite remember what was the consensus last time this was
>>>>>
>>>>>> discussed, but from my point of view the best solution will be to
>>>>>> push a new PEAR 1.10.*
>>>>>>     * with dependency on PHP 5+
>>>>>>     * without bundled PEAR_Exception class but
>>>>>>     * with a required dependency on new PEAR_Exception package.
>>>>>>
>>>>>>  Yep.
>>>>>
>>>>>   Also a new version of PEAR is long overdue with 1.9.4 released in
>>>>>
>>>>>> 2011 and 82 (!) bugs in the tracker.
>>>>>>
>>>>>> Is anyone working on PEAR at all? If not I may help a bit with bug
>>>>>> triage and possibly send some patches.
>>>>>>
>>>>>>
>>>>> Not really. Clockwerx is merging PRs now and then, but there are - in
>>>>> my eyes - some unstable patches in current master.
>>>>>
>>>>> The work we have to do is
>>>>> - create 1.10 branch
>>>>> - find out which patches can go into 1.10.0
>>>>> - cherry-pick them from master
>>>>>
>>>>> master is too unstable for a no-dedicated-maintainer release.
>>>>> The gpg validation for example is not ready for release
>>>>
>>>>
GPG Validation certainly isn't ready for prime-time and I'm also left
wondering if we should integrate Crypt_GPG instead of using the peargpg.php
file currently present in the codebase.

Another thing to cogitate on are tools such as
https://github.com/c9s/Onionwhich generate package.
xml files from a simpler syntax as there are interesting ideas there. If we
lower the barrier-to-entry we might perhaps not lose too much relevance
(considering Composer).

I'm also tempted, when and as we work on them, that the files in pear-core
are brought up to standard as per our own Coding Standards.

Ken

-- 
http://about.me/kenguest/