RE: [PEAR-DEV] [QA] pear install Date
Zitat von Lukas Smith <smith@backendmedia.com>:
> > But that doesn't change the fact that there is a broken (in the sense
> of
> > "unusable") package available that the PEAR group wasn't able to fix
> for
> > TWO months although the fix was applied a few days after the release
> to
> > CVS.
>
> Correct, somewhat disappointing. Then again it is marked as "beta".
That doesn't mean that the package may be unusable. An why is such a small
package in beta state for two months?
> > How do you expect developers to depend on PEAR packages if they
> suddenly
> > disappear, break BC, change the meaning or simply stop to work?
> > The consequence will be that we start to develop everything on our own
> > again
> > instead of relying on a central "high quality" repository.
>
> There was no sudden breakage. Someone write a cron job that would
> overwrite a stable version with a beta version.
That's not the point. I don't know if "beta" is the default preferred state
on a clean PEAR install or not, but at least a lot of packages are only
available if you use this configuration.
And people having this configuration (because they need some packages
otherwise not available) run "pear install Date" and get an unusable
package breaking their applications that rely on it. This has nothing to do
with blindly running "pear upgrade-all".
> And yes we are aware of the problems. Then again where are the people
> willing to remedy this? We need tons more people in pear-qa and
> pear-doc. I know this is the lame excuse open source people always give
> if their qa or docs suck, but it's a fact that can't be changed. We do
> not have money to through at this issue!
That's not the point either. IIRC it was you that fixed Date's package.xml
right after the release and since then a LOT of people reported problems
with the Date package and even pointing on a solution.
The problem is: The solution was already there but hidden in the developers'
space instead of made available publically. And it was/is only a very small
step necessary to fix the package/release a fixed package. No debugging, no
developer action.
> At the same time there are some really dedicated people working on
> building up this infrastructure. The number is actually quite small and
> yet progress is being made.
That's correct and I appreciate their and your efforts a lot. You all do a
great job in raising this building but unfortunately fail in some areas
that I think are very important.
> Anyways since this small group is making progress imagine the progress
> we could be making with every new dedicated developer!
Such issues can't be solved by having more developers (and don't have to, as
well illustrated by the Date example). It's a political or community
problem. With Pierre-Alain and Alan there are two of the most active pear
developers maintainers of this package. I have no idea how much code they
developed since the two months of Date being broken but they didn't yet
managed to get a fixed package out? I know from myself that it's always
much more fun to develop new code than to fix old one, and we aren't much
better with early and often releases in the Horde project.
Though if we don't release a bugfix we hit a lot of people but if a PEAR
package doesn't get fixed that we depend on not only our users but also the
users of all other projects that depend on it get hit.
If PEAR wants to be *the* repository of code solutions for recurring
problems in PHP, the responsibility is much higher since not only your
"customers" but also your customers' customers depend on you.
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
Thread (21 messages)