Re: [phplib] [RFC] Future of phplib From: nathan r. hruby (nathan <email protected>)
Date: 07/21/01

Well, that'll teach me to post something and then go to bed :)

I see several trends in the discussion that's going on here:
  1) Move things to PEAR, for PEAR is the future.
    1a) PEAR won't accept phplib as a framework.

  2) Moving to SF is good.
    2a) Moving to SF doesn't buy you anything.

  3) The present leadership of phplib sucks.
    3a) A vision and goal must be decided upon and followed.

So my reactions:

1 & 1a)

PHPLib will not be migrated into PEAR. The group that formed to do that
hasn't. The PEAR folks have said on numerous occasions that they don't
want app frameworks in PEAR. The current thinking is "Maybe, once the
installer is up to snuff, then app frameworks can use PEAR to distribute."
If the devlopment of the installer moves at the same rate as the
devlopment of the PEAR website, this will never happen. Yes, some work
has been done on the installer by Stig and Thomas V. Cox; however it's
still incomplete and depends on the presence of a website that no one has
woked on and everyone has their own ideas about. PEAR is clearly a case
of too many cooks in the kitchen, morover, all the cooks tend to let their
food get a little over-cooked.

PEAR *IS NOT* CPRAN! This has been said on pear-dev, this is what the
PEAR folks think. There's also a very perviasive attitude that PEAR is a
"best of breed" repoistory for certian developers classes. They do not
want multiple template engines, Auth classes, etc.. in PEAR, at least
right now, they want one for each. Getting anything done on pear-dev is
like pulling teeth from a live lion, you're going to get bit no matter
what you do becasue the leaders of PEAR have very insular feelings about
PEAR.

Several people have said migrate the core of phplib to PEAR, that's
impossible, as it's the core they PEAR folks take issue with, DB_SQL,
Template, Auth, and Session are things they don't want. Table, OOHForms,
SQL_Query are things they do.

PEAR and PHPLib don't mix. There are differning attitudes in users,
developers, implementations and design goals. To think that the two will
become one is silly, espically considering the past two series of
disucssions about it. Perhaps over time these issues can be worked out,
but currently they can't be.

2 & 2a)

Moving to SourceForge buys us a lot. It can give more people finer
control over what happens in / to phplib as well as a slightly more
visable stance. Yes it's true that in some time people will go to
pear.php.net to look for class libs. That is not currently the case and I
doubt it will be for a long time.

Yes, phplib.netuse.de has evrything that we need, except control. None of
us have control over anything, all administrative requests must go
through Kristian who doesn't have the time. Giving CVS access to someone
currently gives them access not only to phplib, but to redsys and the
other CVS repositories that exsist on that same machine, which mnakes
giving out CVS access a lot harder. There is no bug tracking unless I
implement it, and that's not something I have time to do. SourceForge is
a much better place for a distributed group of people to get work done,
unless that group has dedicated access to dedicated hardware. SF is the
next best thing.

Moving to SF also has the addtional benifit of seperation from netuse and
Kristian and Ulf, who have said they abaondoned PHPLib. To me it seems
silly to rely on people who don't care anymore. Over time I'm sure the
member of this group will begin to irratate Kris and Ulf. While we stay
on phplib.netuse.de we remain a product and under the control of Kris and
Ulf. Moving to SF makes a clean seperation which brings me to...

3 & 3a)

Yes, there is no leadership. That is why part of this proposal is a
request for help. Leadership is one part of that request. Chris did step
up to take over the devlopment of phplib in January. Chris also has very
little time and that has just caused phplib to "flaot" for another 6
months. I'm no better, obviously, else I would have started doing things
long ago. Pelase some one step up. I have no problems doing
administrative things, but I haven't the time for daily devlopment. I
can't do it with phpslash and I can't do it with phplib either (unless
someone wants to pay me lots of money to do it full time :)

As for a migration to something like Arlo's PHPAPP? I think that's
getting a little ahead of ourselves. People have said phplib needs to
grow (not just maintin stasis) to stay alive, and I belive that it true.
Wheater PHPAPP is a direction we would want to move in is far from me to
say, nor do I think any of us can saty right now becasue PHPLib hasn't
been *maintined* in a way that can allow it to grow. We have a lot of
problems (bugs, design issues, php3-isms that can be done better in
php4) that need to worked out before we can grow. PHPLib needs to get to
a place of advanced stability and currenty in terms of PHP use before we
can take on much larger tasks. At a minimum, we need to patch the handful
of bugs before moving on.

-n 

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
nathan hruby / digital statement
nathan <email protected>
http://www.dstatement.com/

Public GPG key can be found at:
http://www.dstatement.com/nathan-gpg-key.txt
ED54 9A5E 132D BD01 9103  EEF3 E1B9 4738 EC90 801B
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-- 
Abbestellen mit Mail an:   phplib-unsubscribe <email protected>
Kommandoliste mit Mail an: phplib-help <email protected>