Re: [PEAR-QA] A 'graveyard' for packages / unloved packages

Hi,

I will write a better answer later but I think it would be very interesting if we re-did the old log parser we had on pear.php.ne tthat gave us a break down of what pear version was being used and which PHP versions.
It was very primitive and I do believe we could do something much cooler if we actually aggregated it into CouchDB or similar with proper outputs. That would make decisions like these much easier, e.g. we know the actual penetration of PHP 4 still on our code base... well anyway from the people that use the pear installer and use our channel oppose to yum and friends :)

It has been on my TODO list for a long time but always fallen short, as I usually put priority on the installer or similar when I have spare time.

A quick note, moving packages to another channel is currently not supported in PEAR, in terms of, people are not auto migrated over. This would cause problems for people.

- Helgi

On 16 Mar 2010, at 13:02, Daniel O'Connor wrote:

> Hey all,
> So, we're one day going to have pyrus / pear2 as 'stable' and the preferred
> method for installing packages.
> 
> Sadly, some code won't make the cut. An example of this is SQL_Parser.
> 
> Apparently, the entire premise is flawed and needs to be completely
> re-written - Sebastian gave it a shot, but couldn't make the concept work
> (or so I hear - speak up if that's wrong).
> 
> IMO: there are two viewpoints here:
> 
>   - Maintain! BC! For! Ever!
>   - Change/Break everything, god bless unit tests!
> 
> Extreme 1:
> We never, ever make code we've previously distributed unavailable.
> 
> This means that we'll never break someone's application; we avoid upsetting
> the 0.04% or whatever it is of PHP4 users, etc.
> 
> Extreme 2:
> We stampede around, killing of code ("Refactor mercilessly"); screw the
> consequences.
> 
> 
> 
> So; my question for us all is what's the approach we take when we make the
> cutover to pear2?
> Do we just do #2; which is the most liberating; or do we take great efforts
> to port things forward (most stable)?
> 
> What I would like to see is a middle ground. In this world:
> * package 1.0 is dead - no packages remain which are 1.0.
> * PHP 4 is dead too - pyrus is laughing at it's grave
> * You can still get code and install from (somewhere) even if civilisation
> has moved on
> * Non stable and PHP4? -> Swap to PHP5 is acceptable BC breakage (current
> practice)
> 
> To accomplish this, I'd like to introduce a concept or practice of
> graveyarding a pear package - shifting it to its own pear channel (till
> suggests pearfarm or pearhub); doing the appropriate end of life
> announcements, and booting it the heck out of SVN / pear itself.
> 
> SQL_Parser is a good example of the kind of package to target - it's unloved
> and unworkable at the moment -> it can be graveyarded safely.
> 
> The criteria I imagine for graveyarding a package:
> * PHP 4
> * Relatively few downloads
> * Unmaintained
> * package 1.0
> * No one wanting to bring it across to pear2/PHP5 goodness
> 
> 
> Additionally, I'd love to get updated reporting on PHP4 usage stats (I think
> we're about 2 years old on our opinions). Hopefully, with these stats, this
> makes us all relax somewhat about that style of BC break.
> 
> Collective thoughts, PEAR?
> My intention is to trial this with SQL_Parser, and shifting it off to
> another provider by the end of the weekend if no one objects.