Quantcast

A Rant From Mr. Grumpy on ZF2

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

A Rant From Mr. Grumpy on ZF2

padraicb
Hi all,


As everyone knows, I have a terrible personality flaw. I'm Irish. I'm a moaner, a complainer and an instigator. If I went out on a perfect Summer day for a walk, I'd probably spend an hour ranting to God that his methodology for developing the Sun sucked ass. Incidentally, it did. If God had done it correctly, we could simply read the unit tests instead of the blind reaching, experimentation and guesswork we call Science. I have no doubt that the fact that I haven't been struck by lightening to date is due to a bug. God is a terrible programmer.

The road to Zend Framework 2 has not been interesting (oddly the best description I can think of). It has involved a lot of cleanup to support PHP 5.3 followed by a lot of waiting for the arrival of the near mythical MVC prototypes. With no end in sight, the lack of having interesting things to do is nearing the point where comic relief becomes not only warranted, but necessary, in order to maintain our sanity in between those conversations where we each affirm our complete ignorance of what is going on in Zend Framework.

I've repeatedly requested that someone, anyone, from Zend summarise ZF2 progress on some frequent basis. This continues not to occur and the result is that, frankly, it's hard to know what is happening in Zend Framework 2. The best we're getting are hints dropped at random in unrelated emails. Unfortunately, I can't even be on IRC 24/7 and even that looks a little downsized recently. I don't understand what is so hard about sending an email once in a while to keep the community informed, not to mention the developers who presumably will be called upon to contribute to ZF2. You're killing me here, guys.

A long time ago, the plan of action was to have a set of prototypes released so the community could start piling in. These prototypes have yet to materialise in a coherent whole that people feel comfortable dissecting, discussing, proposing on and writing code against. This is especially worrying because, in my experience, having a prototype that has seen countless hours of work is no prototype at all. It's a fully fledged implementation which will exhibit all the usual traits of one. Those traits include, most importantly, having a high resistance to change - the precise opposite of what a prototype is designed to achieve. For future reference, let's define "prototype" as source code scraped together overnight that probably works and is gifted to the community in a rusty old bucket. We want to get our hands dirty on that stuff and not a collection of pristine code accompanied by a ton of unit tests that will supress change with the inevitable certainty
 of an avalanche moving downhill.

I'm basically 99% convinced at this point that whatever "prototype" appears will be what is released as Zend Framework 2.0 barring minor changes. This was never what the community intended (by a long shot), of course, but we've waited this long that people just want Zend Framework 2.0 out and gone so long as it's functional and can hold its own against Symfony 2's performance. That pressure will only increase as more and more people get to choose between Symfony 2 and the empty air we're delusionally calling Zend Framework 2.

The reaction to this has already started. We've expressed our wish that Zend Framework enter a more frequent major release cycle with Zend Framework 3.0 potentially being released within 18 months. This would have a few impacts primarily requiring far closer collaboration with the community because I can't see anyone so much as contemplating going through the ZF2 twiddling-thumbs experience again. We noticed and do remember that there was no concrete response to this from Zend and, believe me, we're already expecting the answer to be in the negative, but hey, at least put us out of our misery so we can plan ahead on what other projects to dedicate time to.

This brings me to a final point. When everyone and their pet rabbit was in the belly of Zend Framework 1 writing source code and seeing proposals adopted which served the community well, there was no problem. However, Zend Framework 2 is exposing a lot of cracks in the open governance of the project. A lack of communication, lack of inclusiveness in decision making, uncertainty over CLA legalities (for 3rd party licensed code), and a shortage of basic information like a timeline is an intolerable situation for an open source project. It stymies the very objective of the open source movement and this can turn into a very slippery slope, faster than people might realise, towards a four letter word for a piece of cutlery.

The worst of this situation is that there are professional programmers who probably charge clients their first born child, per hour, sitting around on their bums bored silly with the current situation. Letting the lifeblood of Zend Framework go to waste for month after month is incomprehensible. We're contributors not peer reviewers.

I'll readily agree that this email shines a harsh light on where we're going but, me being me, I can either stick it in an alarmist email or keep my thoughts private for the undetermined length of time it will take for Zend Framework 2 to surprise us all by becoming a reality. And really, since when have I ever done that?

Paddy

 

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Adam Lundrigan
Pádraic,

I haven't spent much time with ZF2, so I don't feel anywhere near the same
level of frustration, but I definitely get where you're coming from.

I've inserted my thoughts below.  If i'm offbase anywhere, feel free to
mercilessly chew me out at will ;)

Adam Lundrigan, B.Sc, ZCE
[hidden email]


On Fri, Aug 5, 2011 at 12:52 PM, Pádraic Brady <[hidden email]>wrote:

> I've repeatedly requested that someone, anyone, from Zend summarise ZF2
> progress on some frequent basis. This continues not to occur and the result
> is that, frankly, it's hard to know what is happening in Zend Framework 2.
> The best we're getting are hints dropped at random in unrelated emails.
> Unfortunately, I can't even be on IRC 24/7 and even that looks a little
> downsized recently. I don't understand what is so hard about sending an
> email once in a while to keep the community informed, not to mention the
> developers who presumably will be called upon to contribute to ZF2. You're
> killing me here, guys.
>

Absolutely agree.  Personally, I think this is where the SVN/Git choice made
early on in the ZF2 process really falls down, and the reason is their main
difference: SVN is centralized, Git is not.

With SVN everything that is committed is on the SVN server, and with proper
branch structuring it should be easy to find and dive into someone else's
branch to see what they are working on.  I know that may be oversimplfying
the lay of the land, as SVN has it's own challenges, but in theory it
works.  The only thing we can't see in SVN is the uncommitted files the
branch owner has in his/her working copy. (but if you belive the addage
"work that isn't committed doesn't exist", or something like that, then
those files don't count)

With Git, it's decentralization all the way, at the cost of a definitive
source by which we can measure progress.  Right now ZF2 progress is spread
across dozens (at least) of contributor's forks of the ZF2  github repo,
each with it's own branches tracking the fork owner's exploratory forays
from the existing source.  Some contributors (like Matthew) are (or were)
doing exploratory work in their own private repos (on github or elsewhere)
not inherently connected to the ZF2 github repo.  On top of that, Git's
decentralized nature does introduce a lag in getting the "bleeding edge" out
there; committing changes from your local copy requires a concious effort to
also push those changes up to your ZF2 fork before they are "out there" for
those interested to see, and are still an accepted pull request away from
being included in the definitive source for ZF2 code (the zendframework/zf2
github repo), where most of the interested people would go to find the
latest ZF2 code.  I'm not saying git was a bad choice (my feeling is quite
the opposite, actually), but that the sprawl of repositories, forks and
branches needs to organized properly in order to work well.  The switch from
SVN to Git greatly reduced the entry barrier for contributing to ZF2, and
that is great, but it does introduce other issues that need to be addressed.


As an example, a while back I added code to Zend_Locale to expose
defaultNumberSystem from CLDR (ZF-10728) and figured I would update ZF2
Zend\Locale to expose it as well.  I forked ZF2 from github, added the
necessary code, and put in a pull request only to be told that the
Zend\Locale component in zendframework/zf2 was the wrong one; it was being
refactored elsewhere (thomasweidner/zf2).  There was no indication that the
Zend\Locale code in zendframework/zf2 is not the one I should be looking
at.  It wasn't much work, so it didn't bother me, but that kind of
disconnect does put a damper on one's enthusiasm to contribute.

This comes back around to something that I brought up in an earlier mailing
list post: a "ZF2 status page", of sorts  (see:
http://zend-framework-community.634137.n4.nabble.com/ZF2-feedback-td3620779.html).
Summary:

I would like to see a ZF2 status page, on the wiki or elsewhere, where we
can go to see when a particular component was last merged into official repo

and a link to the contributor fork(s) (if they are public) where the
bleeding-edge work is taking place.  That would go a long way to helping
people like us get in early, watch the progress and offer feedback.

Even if it was as simple as a wiki page with a section for each component,
and under each section list the git repos where work is being done with a
short summary of the purpose of each branch within.  That would lower the
entry barrier (and frustration level for people like Pádraic ;)) to diving
into ZF2.  For instance, I could go to that page, look up Zend\Mvc (or
whatever the MVC package is), see that Matthew has two branches and Ralph
has one where they are throwing out ideas around how the MVC should be
structured. Or, for another example, I could look up Zend\Soap, see that
nobody is working on it for ZF2, and throw my hat in the ring to take it
over.   (disclaimer: those are examples for illustratory purposes, and may
or may not have a basis in reality)

Again, my knowledge of Git and GitHub is not very extensive (and neither is
my knowledge of how ZF2 development is being managed and steered), so if i'm
missing something fundamental (like a "find all forks which have modified a
particular file" feature, for instance) please let me know i'm offbase with
my criticism and point out my errant way....i'll be eternally grateful :)


> The reaction to this has already started. We've expressed our wish that
> Zend Framework enter a more frequent major release cycle with Zend Framework
> 3.0 potentially being released within 18 months. This would have a few
> impacts primarily requiring far closer collaboration with the community
> because I can't see anyone so much as contemplating going through the ZF2
> twiddling-thumbs experience again. We noticed and do remember that there was
> no concrete response to this from Zend and, believe me, we're already
> expecting the answer to be in the negative, but hey, at least put us out of
> our misery so we can plan ahead on what other projects to dedicate time to.
>

This is one proposal/argument I at first supported, but have found myself
coming around to the other side lately.  I think that's down to version
fatigue now that Google Chrome and Mozilla Firefox are both <sarcasm>
pumping out new "major" versions every day </sarcasm>.  It's a game of major
version psychology meant to make a bigger deal out of something that really
isn't.  It doesn't affect the pace of outcome (ie: code, features), just how
it's labelled.  If you bump from v3.4 -> v3.5 no one really cares, but v3 ->
v4 people pay attention because historical use of the major version number
indicated a major application change.

But, I digress.

I guess it really comes down to how ZF's managers plan to handle adding new
features.  Will it be like ZF1, where new features/components were added
seemingly at every minor (1.x) version?  Or will there be a feature freeze
between major versions, with only bugfixes between?


>
> This brings me to a final point. When everyone and their pet rabbit was in
> the belly of Zend Framework 1 writing source code and seeing proposals
> adopted which served the community well, there was no problem. However, Zend
> Framework 2 is exposing a lot of cracks in the open governance of the
> project. A lack of communication, lack of inclusiveness in decision making,
> uncertainty over CLA legalities (for 3rd party licensed code), and a
> shortage of basic information like a timeline is an intolerable situation
> for an open source project. It stymies the very objective of the open source
> movement and this can turn into a very slippery slope, faster than people
> might realise, towards a four letter word for a piece of cutlery.
>
> The worst of this situation is that there are professional programmers who
> probably charge clients their first born child, per hour, sitting around on
> their bums bored silly with the current situation. Letting the lifeblood of
> Zend Framework go to waste for month after month is incomprehensible. We're
> contributors not peer reviewers.
>

I do understand that most ZF contributors are, like myself, volunteers.  I
do it because it gives me a warm, fuzzy feeling inside every time I get to
mark a bug as "resolved".  Some others do it because it's part of their job,
or make a living off it in other ways, and so contribute back.  Regardless,
there has to be a certain level of pressure put on contributors to
contribute in a way that is conducive to a high-quality open source
project.

In my mind, chief among those requirements should be that code isn't
developed in isolation; the repo(s) where code is being developed should be
well known to the community (by that I mean information on them should be
readily available to those who care to look into the wiki to find out) and
there should be an avenue for offering comments and contributions to them.
The current setup of git + github is very good for this, but it is difficult
to get a meaningful overview of the extent of ZF2's progress towards
stability, or even work ongoing on a specific component.

Also important is keeping "documentation" (unit tests, manual pages, wiki
pages, docblocks, etc) up to date with the code.  For instance, in ZF2
master, where the Zend\Di implementation is out of sync with the unit tests
and manual sources.  It took a bit of digging to find out that setProperty
has changed to setParameters, and the signature was slightly different.
That change is mentioned in bug ZF2-42, and i'm willing to jump in and fix
it, but am wary to do so with the possibility that it's already been fixed
in a branch in someone's ZF2 fork.  This comes back to my previous comment
about a ZF2 status page and knowing where the bleeding edge is located.  (I
know I can just email the component manintainer to find out it's status, but
that's extra bother and work on them, so I feel as though that kind of
information should recorded and availalble on the wiki).

------

Now i'll apologize for rambling on and on (and on), and thank you for
reading all the way to the end :)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Pádraic Brady
Hi Adam,

It's discussed in another thread (and I don't want to go off topic too much)
but there are reasons why accelerated major releases make sense. The first
is that having the opportunity to break backwards compatibility, on a more
frequent basis, allows a gentler migration slope and allows for sensible
improvements to be rolled out faster. The jump from ZF1 to ZF2 will be big.
From ZF2 to ZF3 could be much smaller. The second is that, with PHP 5.4
around the corner, it offers a chance to adopt new PHP features closer to
the beginning of the adoption curve rather than at the tail end. Adoption
would be slower but when the time comes, having a mature framework supported
for those versions ready to rock and rumble isn't a bad thing. PHP 5.4
offers Traits, for example, which can do an awful lot in removing
duplication and simplifying concepts such as Action Helpers. Thirdly, an
aggressive schedule focuses contributor resources. We're dragging a lot of
weight with components and they can't be allowed to stagnate too long (MVC
is remarkably tiny in comparison to the framework's current scope). Short of
independent versioning, there needs to be an allowance for component renewal
of less than the 5-6 years ZF1 has taken along with the necessary
deprecation if needed.

In a sense we're not talking about massive revolutionary overhauls every 18
months - more of a gentler incremental improvement schedule that's easier to
migrate across over time. Happy to debate further (though make a new thread
for it!).

Thanks for chipping in with your own opinions.

Paddy.

On Fri, Aug 5, 2011 at 7:01 PM, Adam Lundrigan <[hidden email]> wrote:

> Pádraic,
>
> I haven't spent much time with ZF2, so I don't feel anywhere near the same
> level of frustration, but I definitely get where you're coming from.
>
> I've inserted my thoughts below.  If i'm offbase anywhere, feel free to
> mercilessly chew me out at will ;)
>
> Adam Lundrigan, B.Sc, ZCE
> [hidden email]
>
>
> On Fri, Aug 5, 2011 at 12:52 PM, Pádraic Brady <[hidden email]
> >wrote:
>
> > I've repeatedly requested that someone, anyone, from Zend summarise ZF2
> > progress on some frequent basis. This continues not to occur and the
> result
> > is that, frankly, it's hard to know what is happening in Zend Framework
> 2.
> > The best we're getting are hints dropped at random in unrelated emails.
> > Unfortunately, I can't even be on IRC 24/7 and even that looks a little
> > downsized recently. I don't understand what is so hard about sending an
> > email once in a while to keep the community informed, not to mention the
> > developers who presumably will be called upon to contribute to ZF2.
> You're
> > killing me here, guys.
> >
>
> Absolutely agree.  Personally, I think this is where the SVN/Git choice
> made
> early on in the ZF2 process really falls down, and the reason is their main
> difference: SVN is centralized, Git is not.
>
> With SVN everything that is committed is on the SVN server, and with proper
> branch structuring it should be easy to find and dive into someone else's
> branch to see what they are working on.  I know that may be oversimplfying
> the lay of the land, as SVN has it's own challenges, but in theory it
> works.  The only thing we can't see in SVN is the uncommitted files the
> branch owner has in his/her working copy. (but if you belive the addage
> "work that isn't committed doesn't exist", or something like that, then
> those files don't count)
>
> With Git, it's decentralization all the way, at the cost of a definitive
> source by which we can measure progress.  Right now ZF2 progress is spread
> across dozens (at least) of contributor's forks of the ZF2  github repo,
> each with it's own branches tracking the fork owner's exploratory forays
> from the existing source.  Some contributors (like Matthew) are (or were)
> doing exploratory work in their own private repos (on github or elsewhere)
> not inherently connected to the ZF2 github repo.  On top of that, Git's
> decentralized nature does introduce a lag in getting the "bleeding edge"
> out
> there; committing changes from your local copy requires a concious effort
> to
> also push those changes up to your ZF2 fork before they are "out there" for
> those interested to see, and are still an accepted pull request away from
> being included in the definitive source for ZF2 code (the zendframework/zf2
> github repo), where most of the interested people would go to find the
> latest ZF2 code.  I'm not saying git was a bad choice (my feeling is quite
> the opposite, actually), but that the sprawl of repositories, forks and
> branches needs to organized properly in order to work well.  The switch
> from
> SVN to Git greatly reduced the entry barrier for contributing to ZF2, and
> that is great, but it does introduce other issues that need to be
> addressed.
>
>
> As an example, a while back I added code to Zend_Locale to expose
> defaultNumberSystem from CLDR (ZF-10728) and figured I would update ZF2
> Zend\Locale to expose it as well.  I forked ZF2 from github, added the
> necessary code, and put in a pull request only to be told that the
> Zend\Locale component in zendframework/zf2 was the wrong one; it was being
> refactored elsewhere (thomasweidner/zf2).  There was no indication that the
> Zend\Locale code in zendframework/zf2 is not the one I should be looking
> at.  It wasn't much work, so it didn't bother me, but that kind of
> disconnect does put a damper on one's enthusiasm to contribute.
>
> This comes back around to something that I brought up in an earlier mailing
> list post: a "ZF2 status page", of sorts  (see:
>
> http://zend-framework-community.634137.n4.nabble.com/ZF2-feedback-td3620779.html
> ).
> Summary:
>
> I would like to see a ZF2 status page, on the wiki or elsewhere, where we
> can go to see when a particular component was last merged into official
> repo
>
> and a link to the contributor fork(s) (if they are public) where the
> bleeding-edge work is taking place.  That would go a long way to helping
> people like us get in early, watch the progress and offer feedback.
>
> Even if it was as simple as a wiki page with a section for each component,
> and under each section list the git repos where work is being done with a
> short summary of the purpose of each branch within.  That would lower the
> entry barrier (and frustration level for people like Pádraic ;)) to diving
> into ZF2.  For instance, I could go to that page, look up Zend\Mvc (or
> whatever the MVC package is), see that Matthew has two branches and Ralph
> has one where they are throwing out ideas around how the MVC should be
> structured. Or, for another example, I could look up Zend\Soap, see that
> nobody is working on it for ZF2, and throw my hat in the ring to take it
> over.   (disclaimer: those are examples for illustratory purposes, and may
> or may not have a basis in reality)
>
> Again, my knowledge of Git and GitHub is not very extensive (and neither is
> my knowledge of how ZF2 development is being managed and steered), so if
> i'm
> missing something fundamental (like a "find all forks which have modified a
> particular file" feature, for instance) please let me know i'm offbase with
> my criticism and point out my errant way....i'll be eternally grateful :)
>
>
> > The reaction to this has already started. We've expressed our wish that
> > Zend Framework enter a more frequent major release cycle with Zend
> Framework
> > 3.0 potentially being released within 18 months. This would have a few
> > impacts primarily requiring far closer collaboration with the community
> > because I can't see anyone so much as contemplating going through the ZF2
> > twiddling-thumbs experience again. We noticed and do remember that there
> was
> > no concrete response to this from Zend and, believe me, we're already
> > expecting the answer to be in the negative, but hey, at least put us out
> of
> > our misery so we can plan ahead on what other projects to dedicate time
> to.
> >
>
> This is one proposal/argument I at first supported, but have found myself
> coming around to the other side lately.  I think that's down to version
> fatigue now that Google Chrome and Mozilla Firefox are both <sarcasm>
> pumping out new "major" versions every day </sarcasm>.  It's a game of
> major
> version psychology meant to make a bigger deal out of something that really
> isn't.  It doesn't affect the pace of outcome (ie: code, features), just
> how
> it's labelled.  If you bump from v3.4 -> v3.5 no one really cares, but v3
> ->
> v4 people pay attention because historical use of the major version number
> indicated a major application change.
>
> But, I digress.
>
> I guess it really comes down to how ZF's managers plan to handle adding new
> features.  Will it be like ZF1, where new features/components were added
> seemingly at every minor (1.x) version?  Or will there be a feature freeze
> between major versions, with only bugfixes between?
>
>
> >
> > This brings me to a final point. When everyone and their pet rabbit was
> in
> > the belly of Zend Framework 1 writing source code and seeing proposals
> > adopted which served the community well, there was no problem. However,
> Zend
> > Framework 2 is exposing a lot of cracks in the open governance of the
> > project. A lack of communication, lack of inclusiveness in decision
> making,
> > uncertainty over CLA legalities (for 3rd party licensed code), and a
> > shortage of basic information like a timeline is an intolerable situation
> > for an open source project. It stymies the very objective of the open
> source
> > movement and this can turn into a very slippery slope, faster than people
> > might realise, towards a four letter word for a piece of cutlery.
> >
> > The worst of this situation is that there are professional programmers
> who
> > probably charge clients their first born child, per hour, sitting around
> on
> > their bums bored silly with the current situation. Letting the lifeblood
> of
> > Zend Framework go to waste for month after month is incomprehensible.
> We're
> > contributors not peer reviewers.
> >
>
> I do understand that most ZF contributors are, like myself, volunteers.  I
> do it because it gives me a warm, fuzzy feeling inside every time I get to
> mark a bug as "resolved".  Some others do it because it's part of their
> job,
> or make a living off it in other ways, and so contribute back.  Regardless,
> there has to be a certain level of pressure put on contributors to
> contribute in a way that is conducive to a high-quality open source
> project.
>
> In my mind, chief among those requirements should be that code isn't
> developed in isolation; the repo(s) where code is being developed should be
> well known to the community (by that I mean information on them should be
> readily available to those who care to look into the wiki to find out) and
> there should be an avenue for offering comments and contributions to them.
> The current setup of git + github is very good for this, but it is
> difficult
> to get a meaningful overview of the extent of ZF2's progress towards
> stability, or even work ongoing on a specific component.
>
> Also important is keeping "documentation" (unit tests, manual pages, wiki
> pages, docblocks, etc) up to date with the code.  For instance, in ZF2
> master, where the Zend\Di implementation is out of sync with the unit tests
> and manual sources.  It took a bit of digging to find out that setProperty
> has changed to setParameters, and the signature was slightly different.
> That change is mentioned in bug ZF2-42, and i'm willing to jump in and fix
> it, but am wary to do so with the possibility that it's already been fixed
> in a branch in someone's ZF2 fork.  This comes back to my previous comment
> about a ZF2 status page and knowing where the bleeding edge is located.  (I
> know I can just email the component manintainer to find out it's status,
> but
> that's extra bother and work on them, so I feel as though that kind of
> information should recorded and availalble on the wiki).
>
> ------
>
> Now i'll apologize for rambling on and on (and on), and thank you for
> reading all the way to the end :)
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

weierophinney
Administrator
In reply to this post by padraicb
Paddy --

Thank you for your post. There's much that I agree with, and other
points of yours I "get" but see differently.

Timing sucks, as it's Friday, and I'm technically off work today. I need
some time to digest, and to discuss with Ralph, Enrico, and Zeev before
I do a more formal reply. In the meantime, just know that you're being
heard, and not ignored.

-- Pádraic Brady <[hidden email]> wrote
(on Friday, 05 August 2011, 08:22 AM -0700):

> As everyone knows, I have a terrible personality flaw. I'm Irish. I'm
> a moaner, a complainer and an instigator. If I went out on a perfect
> Summer day for a walk, I'd probably spend an hour ranting to God that
> his methodology for developing the Sun sucked ass. Incidentally, it
> did. If God had done it correctly, we could simply read the unit tests
> instead of the blind reaching, experimentation and guesswork we call
> Science. I have no doubt that the fact that I haven't been struck by
> lightening to date is due to a bug. God is a terrible programmer.
>
> The road to Zend Framework 2 has not been interesting (oddly the best
> description I can think of). It has involved a lot of cleanup to
> support PHP 5.3 followed by a lot of waiting for the arrival of the
> near mythical MVC prototypes. With no end in sight, the lack of having
> interesting things to do is nearing the point where comic relief
> becomes not only warranted, but necessary, in order to maintain our
> sanity in between those conversations where we each affirm our
> complete ignorance of what is going on in Zend Framework.
>
> I've repeatedly requested that someone, anyone, from Zend summarise
> ZF2 progress on some frequent basis. This continues not to occur and
> the result is that, frankly, it's hard to know what is happening in
> Zend Framework 2. The best we're getting are hints dropped at random
> in unrelated emails. Unfortunately, I can't even be on IRC 24/7 and
> even that looks a little downsized recently. I don't understand what
> is so hard about sending an email once in a while to keep the
> community informed, not to mention the developers who presumably will
> be called upon to contribute to ZF2. You're killing me here, guys.
>
> A long time ago, the plan of action was to have a set of prototypes
> released so the community could start piling in. These prototypes have
> yet to materialise in a coherent whole that people feel comfortable
> dissecting, discussing, proposing on and writing code against. This is
> especially worrying because, in my experience, having a prototype that
> has seen countless hours of work is no prototype at all. It's a fully
> fledged implementation which will exhibit all the usual traits of one.
> Those traits include, most importantly, having a high resistance to
> change - the precise opposite of what a prototype is designed to
> achieve. For future reference, let's define "prototype" as source code
> scraped together overnight that probably works and is gifted to the
> community in a rusty old bucket. We want to get our hands dirty on
> that stuff and not a collection of pristine code accompanied by a ton
> of unit tests that will supress change with the inevitable certainty
>  of an avalanche moving downhill.
>
> I'm basically 99% convinced at this point that whatever "prototype"
> appears will be what is released as Zend Framework 2.0 barring minor
> changes. This was never what the community intended (by a long shot),
> of course, but we've waited this long that people just want Zend
> Framework 2.0 out and gone so long as it's functional and can hold its
> own against Symfony 2's performance. That pressure will only increase
> as more and more people get to choose between Symfony 2 and the empty
> air we're delusionally calling Zend Framework 2.
>
> The reaction to this has already started. We've expressed our wish
> that Zend Framework enter a more frequent major release cycle with
> Zend Framework 3.0 potentially being released within 18 months. This
> would have a few impacts primarily requiring far closer collaboration
> with the community because I can't see anyone so much as contemplating
> going through the ZF2 twiddling-thumbs experience again. We noticed
> and do remember that there was no concrete response to this from Zend
> and, believe me, we're already expecting the answer to be in the
> negative, but hey, at least put us out of our misery so we can plan
> ahead on what other projects to dedicate time to.
>
> This brings me to a final point. When everyone and their pet rabbit
> was in the belly of Zend Framework 1 writing source code and seeing
> proposals adopted which served the community well, there was no
> problem. However, Zend Framework 2 is exposing a lot of cracks in the
> open governance of the project. A lack of communication, lack of
> inclusiveness in decision making, uncertainty over CLA legalities (for
> 3rd party licensed code), and a shortage of basic information like a
> timeline is an intolerable situation for an open source project. It
> stymies the very objective of the open source movement and this can
> turn into a very slippery slope, faster than people might realise,
> towards a four letter word for a piece of cutlery.
>
> The worst of this situation is that there are professional programmers
> who probably charge clients their first born child, per hour, sitting
> around on their bums bored silly with the current situation. Letting
> the lifeblood of Zend Framework go to waste for month after month is
> incomprehensible. We're contributors not peer reviewers.
>
> I'll readily agree that this email shines a harsh light on where we're
> going but, me being me, I can either stick it in an alarmist email or
> keep my thoughts private for the undetermined length of time it will
> take for Zend Framework 2 to surprise us all by becoming a reality.
> And really, since when have I ever done that?

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Wil Moore III
In reply to this post by Adam Lundrigan
@Padraic:

I'm basically 99% convinced at this point that whatever "prototype" appears
> will be what is released as Zend Framework 2.0 barring minor changes. This
> was never what the community intended...


Agreed. And to add to that...I'm still not convinced that we _NEED_ another
MVC implementation. What is wrong with collaborating with SF2 and just
making that even better (BTW, it is awesome as-is anyway).

@Adam:


> With Git, it's decentralization all the way, at the cost of a
> definitive source by which we can measure progress.
>

My feeling is that the source repository is not a communication tool in and
of itself. If we were somehow using it that way, this is wrong and is likely
to not be reachable (for the masses) anyway. Of course, Github blurs that
line a little bit; however, on the surface, I would prefer not to even
allude to Git or SVN playing any part in this communication break down.

I would like to see a ZF2 status page, on the wiki or elsewhere, where
> we can go to see when a particular component was last merged into official
> repo


I can get behind this request actually. This makes sense from a
communication stand-point.

Again, my knowledge of Git and GitHub is not very extensive...


Adam, I don't think it matters because at the end of the day, you just want
an indicator as to where things are at. You shouldn't have to rely on Git
for that...
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Pádraic Brady
Hi Wil,

The problem I have with adopting Symfony's MVC may be a bit whimsical, but
I'd prefer we have two strong competitors over a merger that
leaves...whatever the next big gun is. I'm assuming Lithium or CakePHP in
our class. Competition breeds rivalry, normally. It may be obviously too
late for that to influence ZF2, but let's not leap right into surrender and
resignation as just a component library. In PHP, I have a very low tolerance
for competition being lax. It seems to open the door to crackpot programmers
who wouldn't recognise secure code if it leaped up and bit them. On the
lightweight end, we have CodeIgniter ruling the roost, and I would rather
you shoot me now than have me use it for anything remotely important.
Digging around its code is like time travelling back to the 90s. It's
criminal that Kohana has not overtaken it yet. No sir, a little competition
is a healthy prod to keep the improvements and high standards rolling.

Besides, ZF2 will be faster than Symfony 2 which is fundamentally essential
;). http://symfony.com/six-good-technical-reasons#fast

Paddy

On Fri, Aug 5, 2011 at 8:01 PM, Wil Moore III <[hidden email]>wrote:

> @Padraic:
>
> I'm basically 99% convinced at this point that whatever "prototype" appears
> > will be what is released as Zend Framework 2.0 barring minor changes.
> This
> > was never what the community intended...
>
>
> Agreed. And to add to that...I'm still not convinced that we _NEED_ another
> MVC implementation. What is wrong with collaborating with SF2 and just
> making that even better (BTW, it is awesome as-is anyway).
>
> @Adam:
>
>
> > With Git, it's decentralization all the way, at the cost of a
> > definitive source by which we can measure progress.
> >
>
> My feeling is that the source repository is not a communication tool in and
> of itself. If we were somehow using it that way, this is wrong and is
> likely
> to not be reachable (for the masses) anyway. Of course, Github blurs that
> line a little bit; however, on the surface, I would prefer not to even
> allude to Git or SVN playing any part in this communication break down.
>
> I would like to see a ZF2 status page, on the wiki or elsewhere, where
> > we can go to see when a particular component was last merged into
> official
> > repo
>
>
> I can get behind this request actually. This makes sense from a
> communication stand-point.
>
> Again, my knowledge of Git and GitHub is not very extensive...
>
>
> Adam, I don't think it matters because at the end of the day, you just want
> an indicator as to where things are at. You shouldn't have to rely on Git
> for that...
>



--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
*Zend Framework Community Review Team <http://framework.zend.com/>*
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Wil Moore III
>
> ...resignation as just a component library.


But a good component library it would make -- not to mention, it is a race
that nobody else is running. I'd mention PEAR, but, why? :)


> In PHP, I have a very low tolerance for competition being lax. It seems to
> open the door to crackpot programmers who wouldn't recognise secure code if
> it leaped up and bit them.


I have to agree with you here...


> On the lightweight end, we have CodeIgniter ruling the roost,


Unfortunately yes. I guess to each his own, but really, this just comes down
to two things:

1 - Type of projects -- I suspect many PHP developers are still doing lots
of page-based brochure/marketing sites rather than
line-of-business/mission-critical apps.
2 - So-called freelancers doing work for next to nothing on
rentacoder.com(more like
work-for-free-coder.com).

But I digress here. At the end of the day, two well designed MVC
implementations isn't particularly bad, it is just that, I'm having trouble
seeing the point outside of the competitive slant. Of course, only time will
tell if I am just not seeing the bigger picture here. That could very well
be the case and I'd be happy to look back at this email later and realize I
was being short-sighted.
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Artur Bodera
In reply to this post by Pádraic Brady
My 2 cents.

Git and github are just versioning systems. ZF is a project. I don't believe
this discussion as per
the first post from Padraic is related to the software. It's more a problem
with project
management. I've come in as a contributor just recently, but I've been using
and observing the
growth of ZF since it's beginning.

I might sound blunt, but I'd like to remind you of a few basic things.

First of all, a major version change (historically) means breaking
compatibility. That is both a
problem and a bliss. This means, that we absolutely NEED to brainstorm more
and put a lot
of thought into the core. If we're gonna break it, now it's the time. Forget
about refactoring and
API changes for many months after ZF2 RC and official release. NOW is the
time to play in the
sandbox, bring up the craziest ideas and introduce the most advanced,
cutting-edge and
(sometimes borrowed from other frameworks) solutions.


No 2 - Feature-set. That's very important part of community-style project
management.
Because there is no schedule, there is no "freeze" date. Because there is no
freeze date, we
are confused on whether new features should go into ZF2, or ZF1-ported-2 or
should we just
forget about them? There are different schools for that, but looking back at
some other open-
source projects I remember, that many of them USED major version switch to
push in some
amazing features. It's optional, but has to be accounted for. No developer
likes to do double
work - currently, because ZF1 is constantly patched and ZF2 was forked a
long time ago,
there is some redundancy with that. It's not necessarily bad, as we're smart
and efficient :-) We
can do the double-patching, but we need to know that we should do it and how
(organisation-wise).


No 3 - github is cool. I like decentralization. Again - don't confuse code
decentralization with
project coordination problems. In SVN times, people check-out on their
machines, hack away
and after they are happy with results, they commit. I see little difference
with GIT+GitHub. It's
just prettier and there is *more* transparency as you can peek inside my
repository. The problems
you've mentioned - i.e. not knowing the progress of work, or state of
things, is NOT git's job.
That's what wikis+mail-list are for! That's what project-management tools
are for. Throw in a
 project calendar, milestone tickets meter from bugtracker, mix with some
creative goal setting
(see wiki and ZF2 roadmap) and courageous milestone date setting and you're
set.
Adam - Gantt's chart, have you heard of it ? :-)


No 4 - performance. It's a mixed bag. Performance is important, but not THAT
important! I'd say
performance scalability (in the sense of framework performing predictably in
smaller and bigger
applications) is more important. But looking at big picture, no php
framework is a candidate to
run facebook on. If you want to go per-thread ultra-fast, go with language
other than php. If you
want to go super fast with php - go procedural, shallow-objective and
compile your own C modules
for busy parts. That's got little to do with frameworks. PHP frameworks are
born to be easy to
use and accelerate development NOT code itself. A framework is a code on a
code which will
by definition slow the whole vehicle down.

Now if you take performance out of the equation, you begin to look at things
like Padraic
mentioned before - go future, not 1990's and mysql_pconnect() my
&foobar_function ! Focus on
the framework being easy to use, very fast *to build on* and feature-full.
That's why I picked
ZF in the first place. There are few frameworks (let alone php) that offer
that many up-to-date
components.

Dear developer:
If you're truly successful with your ZF app and want to serve tens of
thousands a second,
go scale up and out! If you've got the traffic (and business plan) you
surely, already got the money to
do so. If not, codeigniter nor kohana nor node.js is gonna help you out.


Looking from a perspective, ZF2 timing clashes with PHP 5.3/5.4 and
introduction of some very smart
concepts in php world. I'd really hate to see ZF2 to be only an "upgrade" to
ZF1 to use namespaces
and some performance improvement. Unfortunately, I don't think it is
possible to achieve much more
without some stir and a little craziness... unless we want to have ZF2 RC
ready for Easter 2014 or
have a product that is just a well-unit-tested ZF1 on steroids.


Have a nice day!

Arthur.


--

      __
     /.)\   +48 695 600 936
     \(./   [hidden email]


On Fri, Aug 5, 2011 at 9:39 PM, Pádraic Brady <[hidden email]>wrote:

> Hi Wil,
>
> The problem I have with adopting Symfony's MVC may be a bit whimsical, but
> I'd prefer we have two strong competitors over a merger that
> leaves...whatever the next big gun is. I'm assuming Lithium or CakePHP in
> our class. Competition breeds rivalry, normally. It may be obviously too
> late for that to influence ZF2, but let's not leap right into surrender and
> resignation as just a component library. In PHP, I have a very low
> tolerance
> for competition being lax. It seems to open the door to crackpot
> programmers
> who wouldn't recognise secure code if it leaped up and bit them. On the
> lightweight end, we have CodeIgniter ruling the roost, and I would rather
> you shoot me now than have me use it for anything remotely important.
> Digging around its code is like time travelling back to the 90s. It's
> criminal that Kohana has not overtaken it yet. No sir, a little competition
> is a healthy prod to keep the improvements and high standards rolling.
>
> Besides, ZF2 will be faster than Symfony 2 which is fundamentally essential
> ;). http://symfony.com/six-good-technical-reasons#fast
>
> Paddy
>
> On Fri, Aug 5, 2011 at 8:01 PM, Wil Moore III <[hidden email]
> >wrote:
>
> > @Padraic:
> >
> > I'm basically 99% convinced at this point that whatever "prototype"
> appears
> > > will be what is released as Zend Framework 2.0 barring minor changes.
> > This
> > > was never what the community intended...
> >
> >
> > Agreed. And to add to that...I'm still not convinced that we _NEED_
> another
> > MVC implementation. What is wrong with collaborating with SF2 and just
> > making that even better (BTW, it is awesome as-is anyway).
> >
> > @Adam:
> >
> >
> > > With Git, it's decentralization all the way, at the cost of a
> > > definitive source by which we can measure progress.
> > >
> >
> > My feeling is that the source repository is not a communication tool in
> and
> > of itself. If we were somehow using it that way, this is wrong and is
> > likely
> > to not be reachable (for the masses) anyway. Of course, Github blurs that
> > line a little bit; however, on the surface, I would prefer not to even
> > allude to Git or SVN playing any part in this communication break down.
> >
> > I would like to see a ZF2 status page, on the wiki or elsewhere, where
> > > we can go to see when a particular component was last merged into
> > official
> > > repo
> >
> >
> > I can get behind this request actually. This makes sense from a
> > communication stand-point.
> >
> > Again, my knowledge of Git and GitHub is not very extensive...
> >
> >
> > Adam, I don't think it matters because at the end of the day, you just
> want
> > an indicator as to where things are at. You shouldn't have to rely on Git
> > for that...
> >
>
>
>
> --
> Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> *Zend Framework Community Review Team <http://framework.zend.com/>*
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Kevin McArthur-2
In reply to this post by Pádraic Brady
> but let's not leap right into surrender and
> resignation as just a component library.
+10,000

--

Kevin

On 11-08-05 12:39 PM, Pádraic Brady wrote:

> Hi Wil,
>
> The problem I have with adopting Symfony's MVC may be a bit whimsical, but
> I'd prefer we have two strong competitors over a merger that
> leaves...whatever the next big gun is. I'm assuming Lithium or CakePHP in
> our class. Competition breeds rivalry, normally. It may be obviously too
> late for that to influence ZF2, but let's not leap right into surrender and
> resignation as just a component library. In PHP, I have a very low tolerance
> for competition being lax. It seems to open the door to crackpot programmers
> who wouldn't recognise secure code if it leaped up and bit them. On the
> lightweight end, we have CodeIgniter ruling the roost, and I would rather
> you shoot me now than have me use it for anything remotely important.
> Digging around its code is like time travelling back to the 90s. It's
> criminal that Kohana has not overtaken it yet. No sir, a little competition
> is a healthy prod to keep the improvements and high standards rolling.
>
> Besides, ZF2 will be faster than Symfony 2 which is fundamentally essential
> ;). http://symfony.com/six-good-technical-reasons#fast
>
> Paddy
>
> On Fri, Aug 5, 2011 at 8:01 PM, Wil Moore III<[hidden email]>wrote:
>
>> @Padraic:
>>
>> I'm basically 99% convinced at this point that whatever "prototype" appears
>>> will be what is released as Zend Framework 2.0 barring minor changes.
>> This
>>> was never what the community intended...
>>
>> Agreed. And to add to that...I'm still not convinced that we _NEED_ another
>> MVC implementation. What is wrong with collaborating with SF2 and just
>> making that even better (BTW, it is awesome as-is anyway).
>>
>> @Adam:
>>
>>
>>> With Git, it's decentralization all the way, at the cost of a
>>> definitive source by which we can measure progress.
>>>
>> My feeling is that the source repository is not a communication tool in and
>> of itself. If we were somehow using it that way, this is wrong and is
>> likely
>> to not be reachable (for the masses) anyway. Of course, Github blurs that
>> line a little bit; however, on the surface, I would prefer not to even
>> allude to Git or SVN playing any part in this communication break down.
>>
>> I would like to see a ZF2 status page, on the wiki or elsewhere, where
>>> we can go to see when a particular component was last merged into
>> official
>>> repo
>>
>> I can get behind this request actually. This makes sense from a
>> communication stand-point.
>>
>> Again, my knowledge of Git and GitHub is not very extensive...
>>
>>
>> Adam, I don't think it matters because at the end of the day, you just want
>> an indicator as to where things are at. You shouldn't have to rely on Git
>> for that...
>>
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

derek miranda-2
In reply to this post by Pádraic Brady
I couldn't agree with Paddy more an every single point.

Sent from my iPhone

On Aug 5, 2011, at 3:39 PM, Pádraic Brady <[hidden email]> wrote:

> Hi Wil,
>
> The problem I have with adopting Symfony's MVC may be a bit whimsical, but
> I'd prefer we have two strong competitors over a merger that
> leaves...whatever the next big gun is. I'm assuming Lithium or CakePHP in
> our class. Competition breeds rivalry, normally. It may be obviously too
> late for that to influence ZF2, but let's not leap right into surrender and
> resignation as just a component library. In PHP, I have a very low tolerance
> for competition being lax. It seems to open the door to crackpot programmers
> who wouldn't recognise secure code if it leaped up and bit them. On the
> lightweight end, we have CodeIgniter ruling the roost, and I would rather
> you shoot me now than have me use it for anything remotely important.
> Digging around its code is like time travelling back to the 90s. It's
> criminal that Kohana has not overtaken it yet. No sir, a little competition
> is a healthy prod to keep the improvements and high standards rolling.
>
> Besides, ZF2 will be faster than Symfony 2 which is fundamentally essential
> ;). http://symfony.com/six-good-technical-reasons#fast
>
> Paddy
>
> On Fri, Aug 5, 2011 at 8:01 PM, Wil Moore III <[hidden email]>wrote:
>
>> @Padraic:
>>
>> I'm basically 99% convinced at this point that whatever "prototype" appears
>>> will be what is released as Zend Framework 2.0 barring minor changes.
>> This
>>> was never what the community intended...
>>
>>
>> Agreed. And to add to that...I'm still not convinced that we _NEED_ another
>> MVC implementation. What is wrong with collaborating with SF2 and just
>> making that even better (BTW, it is awesome as-is anyway).
>>
>> @Adam:
>>
>>
>>> With Git, it's decentralization all the way, at the cost of a
>>> definitive source by which we can measure progress.
>>>
>>
>> My feeling is that the source repository is not a communication tool in and
>> of itself. If we were somehow using it that way, this is wrong and is
>> likely
>> to not be reachable (for the masses) anyway. Of course, Github blurs that
>> line a little bit; however, on the surface, I would prefer not to even
>> allude to Git or SVN playing any part in this communication break down.
>>
>> I would like to see a ZF2 status page, on the wiki or elsewhere, where
>>> we can go to see when a particular component was last merged into
>> official
>>> repo
>>
>>
>> I can get behind this request actually. This makes sense from a
>> communication stand-point.
>>
>> Again, my knowledge of Git and GitHub is not very extensive...
>>
>>
>> Adam, I don't think it matters because at the end of the day, you just want
>> an indicator as to where things are at. You shouldn't have to rely on Git
>> for that...
>>
>
>
>
> --
> Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> *Zend Framework Community Review Team <http://framework.zend.com/>*

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: [zf-contributors] A Rant From Mr. Grumpy on ZF2

Adam Lundrigan
*Forgot to hit reply-all (*smack* bad Adam).  Apologies to Pádraic, who will
get this twice.*

As it was a bit off-topic I didn't delve too far into it, but I do
understand the rationale behind rapid major releases.  ZF is still maturing;
there are many things in ZFv1 that would be changed if BC breaks were
allowed, and this is the reason for ZFv2.  However, there does need to be
some balance...an approach like Firefox and Google Chrome have taken is
quite extreme, with new "major" releases every month or so.  Major releases
should come rapidly enough that we can do what is necessary to keep the
framework fresh, but not so rapidly that we leave existing websites "hung
out to dry" in terms of critical fixes.  There would need to be some
discussion with and direction from the involved Zend staff on what that
compromise should be, what the window of support for each release is, etc.

My point was to mock the psychological aspect of version numbering, and the
approach the likes of Google and Mozilla have taken.  For ZF, rapid major
releases would likely be a good thing, but the risk of version fatigue is
real.  A quick succession of major releases, each with a short lifespan,
could drive developers away as they would either have to port all of their
applications forward once the version they are using EOLed or do their own
critical fix backporting (or let the site run on an unsupported framework
version, I guess).

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]

Sent from my Motorola Atrix smartphone


On 2011-08-05 4:10 PM, "Pádraic Brady" <[hidden email]> wrote:
> Hi Adam,
>
> It's discussed in another thread (and I don't want to go off topic too
much)
> but there are reasons why accelerated major releases make sense. The first
> is that having the opportunity to break backwards compatibility, on a more
> frequent basis, allows a gentler migration slope and allows for sensible
> improvements to be rolled out faster. The jump from ZF1 to ZF2 will be
big.
> From ZF2 to ZF3 could be much smaller. The second is that, with PHP 5.4
> around the corner, it offers a chance to adopt new PHP features closer to
> the beginning of the adoption curve rather than at the tail end. Adoption
> would be slower but when the time comes, having a mature framework
supported
> for those versions ready to rock and rumble isn't a bad thing. PHP 5.4
> offers Traits, for example, which can do an awful lot in removing
> duplication and simplifying concepts such as Action Helpers. Thirdly, an
> aggressive schedule focuses contributor resources. We're dragging a lot of
> weight with components and they can't be allowed to stagnate too long (MVC
> is remarkably tiny in comparison to the framework's current scope). Short
of
> independent versioning, there needs to be an allowance for component
renewal
> of less than the 5-6 years ZF1 has taken along with the necessary
> deprecation if needed.
>
> In a sense we're not talking about massive revolutionary overhauls every
18
> months - more of a gentler incremental improvement schedule that's easier
to
> migrate across over time. Happy to debate further (though make a new
thread
> for it!).
>
> Thanks for chipping in with your own opinions.
>
> Paddy.
>
> On Fri, Aug 5, 2011 at 7:01 PM, Adam Lundrigan <[hidden email]>
wrote:
>
>> Pádraic,
>>
>> I haven't spent much time with ZF2, so I don't feel anywhere near the
same

>> level of frustration, but I definitely get where you're coming from.
>>
>> I've inserted my thoughts below. If i'm offbase anywhere, feel free to
>> mercilessly chew me out at will ;)
>>
>> Adam Lundrigan, B.Sc, ZCE
>> [hidden email]
>>
>>
>> On Fri, Aug 5, 2011 at 12:52 PM, Pádraic Brady <[hidden email]
>> >wrote:
>>
>> > I've repeatedly requested that someone, anyone, from Zend summarise ZF2
>> > progress on some frequent basis. This continues not to occur and the
>> result
>> > is that, frankly, it's hard to know what is happening in Zend Framework
>> 2.
>> > The best we're getting are hints dropped at random in unrelated emails.
>> > Unfortunately, I can't even be on IRC 24/7 and even that looks a little
>> > downsized recently. I don't understand what is so hard about sending an
>> > email once in a while to keep the community informed, not to mention
the
>> > developers who presumably will be called upon to contribute to ZF2.
>> You're
>> > killing me here, guys.
>> >
>>
>> Absolutely agree. Personally, I think this is where the SVN/Git choice
>> made
>> early on in the ZF2 process really falls down, and the reason is their
main
>> difference: SVN is centralized, Git is not.
>>
>> With SVN everything that is committed is on the SVN server, and with
proper

>> branch structuring it should be easy to find and dive into someone else's
>> branch to see what they are working on. I know that may be oversimplfying
>> the lay of the land, as SVN has it's own challenges, but in theory it
>> works. The only thing we can't see in SVN is the uncommitted files the
>> branch owner has in his/her working copy. (but if you belive the addage
>> "work that isn't committed doesn't exist", or something like that, then
>> those files don't count)
>>
>> With Git, it's decentralization all the way, at the cost of a definitive
>> source by which we can measure progress. Right now ZF2 progress is spread

>> across dozens (at least) of contributor's forks of the ZF2 github repo,
>> each with it's own branches tracking the fork owner's exploratory forays
>> from the existing source. Some contributors (like Matthew) are (or were)
>> doing exploratory work in their own private repos (on github or
elsewhere)
>> not inherently connected to the ZF2 github repo. On top of that, Git's
>> decentralized nature does introduce a lag in getting the "bleeding edge"
>> out
>> there; committing changes from your local copy requires a concious effort
>> to
>> also push those changes up to your ZF2 fork before they are "out there"
for
>> those interested to see, and are still an accepted pull request away from
>> being included in the definitive source for ZF2 code (the
zendframework/zf2

>> github repo), where most of the interested people would go to find the
>> latest ZF2 code. I'm not saying git was a bad choice (my feeling is quite
>> the opposite, actually), but that the sprawl of repositories, forks and
>> branches needs to organized properly in order to work well. The switch
>> from
>> SVN to Git greatly reduced the entry barrier for contributing to ZF2, and
>> that is great, but it does introduce other issues that need to be
>> addressed.
>>
>>
>> As an example, a while back I added code to Zend_Locale to expose
>> defaultNumberSystem from CLDR (ZF-10728) and figured I would update ZF2
>> Zend\Locale to expose it as well. I forked ZF2 from github, added the
>> necessary code, and put in a pull request only to be told that the
>> Zend\Locale component in zendframework/zf2 was the wrong one; it was
being
>> refactored elsewhere (thomasweidner/zf2). There was no indication that
the
>> Zend\Locale code in zendframework/zf2 is not the one I should be looking
>> at. It wasn't much work, so it didn't bother me, but that kind of
>> disconnect does put a damper on one's enthusiasm to contribute.
>>
>> This comes back around to something that I brought up in an earlier
mailing
>> list post: a "ZF2 status page", of sorts (see:
>>
>>
http://zend-framework-community.634137.n4.nabble.com/ZF2-feedback-td3620779.html

>> ).
>> Summary:
>>
>> I would like to see a ZF2 status page, on the wiki or elsewhere, where we
>> can go to see when a particular component was last merged into official
>> repo
>>
>> and a link to the contributor fork(s) (if they are public) where the
>> bleeding-edge work is taking place. That would go a long way to helping
>> people like us get in early, watch the progress and offer feedback.
>>
>> Even if it was as simple as a wiki page with a section for each
component,
>> and under each section list the git repos where work is being done with a
>> short summary of the purpose of each branch within. That would lower the
>> entry barrier (and frustration level for people like Pádraic ;)) to
diving
>> into ZF2. For instance, I could go to that page, look up Zend\Mvc (or
>> whatever the MVC package is), see that Matthew has two branches and Ralph
>> has one where they are throwing out ideas around how the MVC should be
>> structured. Or, for another example, I could look up Zend\Soap, see that
>> nobody is working on it for ZF2, and throw my hat in the ring to take it
>> over. (disclaimer: those are examples for illustratory purposes, and may
>> or may not have a basis in reality)
>>
>> Again, my knowledge of Git and GitHub is not very extensive (and neither
is
>> my knowledge of how ZF2 development is being managed and steered), so if
>> i'm
>> missing something fundamental (like a "find all forks which have modified
a
>> particular file" feature, for instance) please let me know i'm offbase
with
>> my criticism and point out my errant way....i'll be eternally grateful :)
>>
>>
>> > The reaction to this has already started. We've expressed our wish that
>> > Zend Framework enter a more frequent major release cycle with Zend
>> Framework
>> > 3.0 potentially being released within 18 months. This would have a few
>> > impacts primarily requiring far closer collaboration with the community
>> > because I can't see anyone so much as contemplating going through the
ZF2
>> > twiddling-thumbs experience again. We noticed and do remember that
there
>> was
>> > no concrete response to this from Zend and, believe me, we're already
>> > expecting the answer to be in the negative, but hey, at least put us
out

>> of
>> > our misery so we can plan ahead on what other projects to dedicate time
>> to.
>> >
>>
>> This is one proposal/argument I at first supported, but have found myself
>> coming around to the other side lately. I think that's down to version
>> fatigue now that Google Chrome and Mozilla Firefox are both <sarcasm>
>> pumping out new "major" versions every day </sarcasm>. It's a game of
>> major
>> version psychology meant to make a bigger deal out of something that
really
>> isn't. It doesn't affect the pace of outcome (ie: code, features), just
>> how
>> it's labelled. If you bump from v3.4 -> v3.5 no one really cares, but v3
>> ->
>> v4 people pay attention because historical use of the major version
number
>> indicated a major application change.
>>
>> But, I digress.
>>
>> I guess it really comes down to how ZF's managers plan to handle adding
new

>> features. Will it be like ZF1, where new features/components were added
>> seemingly at every minor (1.x) version? Or will there be a feature freeze
>> between major versions, with only bugfixes between?
>>
>>
>> >
>> > This brings me to a final point. When everyone and their pet rabbit was
>> in
>> > the belly of Zend Framework 1 writing source code and seeing proposals
>> > adopted which served the community well, there was no problem. However,
>> Zend
>> > Framework 2 is exposing a lot of cracks in the open governance of the
>> > project. A lack of communication, lack of inclusiveness in decision
>> making,
>> > uncertainty over CLA legalities (for 3rd party licensed code), and a
>> > shortage of basic information like a timeline is an intolerable
situation
>> > for an open source project. It stymies the very objective of the open
>> source
>> > movement and this can turn into a very slippery slope, faster than
people
>> > might realise, towards a four letter word for a piece of cutlery.
>> >
>> > The worst of this situation is that there are professional programmers
>> who
>> > probably charge clients their first born child, per hour, sitting
around
>> on
>> > their bums bored silly with the current situation. Letting the
lifeblood
>> of
>> > Zend Framework go to waste for month after month is incomprehensible.
>> We're
>> > contributors not peer reviewers.
>> >
>>
>> I do understand that most ZF contributors are, like myself, volunteers. I
>> do it because it gives me a warm, fuzzy feeling inside every time I get
to
>> mark a bug as "resolved". Some others do it because it's part of their
>> job,
>> or make a living off it in other ways, and so contribute back.
Regardless,
>> there has to be a certain level of pressure put on contributors to
>> contribute in a way that is conducive to a high-quality open source
>> project.
>>
>> In my mind, chief among those requirements should be that code isn't
>> developed in isolation; the repo(s) where code is being developed should
be
>> well known to the community (by that I mean information on them should be
>> readily available to those who care to look into the wiki to find out)
and
>> there should be an avenue for offering comments and contributions to
them.
>> The current setup of git + github is very good for this, but it is
>> difficult
>> to get a meaningful overview of the extent of ZF2's progress towards
>> stability, or even work ongoing on a specific component.
>>
>> Also important is keeping "documentation" (unit tests, manual pages, wiki
>> pages, docblocks, etc) up to date with the code. For instance, in ZF2
>> master, where the Zend\Di implementation is out of sync with the unit
tests
>> and manual sources. It took a bit of digging to find out that setProperty
>> has changed to setParameters, and the signature was slightly different.
>> That change is mentioned in bug ZF2-42, and i'm willing to jump in and
fix
>> it, but am wary to do so with the possibility that it's already been
fixed
>> in a branch in someone's ZF2 fork. This comes back to my previous comment
>> about a ZF2 status page and knowing where the bleeding edge is located.
(I

>> know I can just email the component manintainer to find out it's status,
>> but
>> that's extra bother and work on them, so I feel as though that kind of
>> information should recorded and availalble on the wiki).
>>
>> ------
>>
>> Now i'll apologize for rambling on and on (and on), and thank you for
>> reading all the way to the end :)
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Pádraic Brady
In reply to this post by derek miranda-2
Nothing I disagree with in there ;). I would emphasise that the version
incrementing would not be a marketing tool - 18 months is bandied with
simply because of the arrival of PHP 5.4. Should PHP 5.5 take three years,
and nothing worth improving is located in the meantime, then doing an 18
month cycle for ZF 4.0 in that instance might not be suitable. I completely
agree that the rapid versioning of browsers is a bit silly. You can as
easily push new features into minor releases as major ones. It's primarily a
psychological effect though it will be interesting to see if it has the
desired effect on something like Mozilla's development process.

Anyway, there is tons to debate on the topic as it relates to ZF whenever
Zend actually respond to the proposal. In another topic, of course :P.

Paddy

On Sat, Aug 6, 2011 at 3:00 PM, Adam Lundrigan <[hidden email]> wrote:

> Pádraic,
>
> As it was a bit off-topic I didn't delve too far into it, but I do
> understand the rationale behind rapid major releases.  ZF is still maturing;
> there are many things in ZFv1 that would be changed if BC breaks were
> allowed, and this is the reason for ZFv2.  However, there does need to be
> some balance...an approach like Firefox and Google Chrome have taken is
> quite extreme, with new "major" releases every month or so.  Major releases
> should come rapidly enough that we can do what is necessary to keep the
> framework fresh, but not so rapidly that we leave existing websites "hung
> out to dry" in terms of critical fixes.  There would need to be some
> discussion with and direction from the involved Zend staff on what that
> compromise should be, what the window of support for each release is, etc.
>
> My point was to mock the psychological aspect of version numbering, and the
> approach the likes of Google and Mozilla have taken.  For ZF, rapid major
> releases would likely be a good thing, but the risk of version fatigue is
> real.  A quick succession of major releases, each with a short lifespan,
> could drive developers away as they would either have to port all of their
> applications forward once the version they are using EOLed or do their own
> critical fix backporting (or let the site run on an unsupported framework
> version, I guess).
>
> --
>
> Adam Lundrigan, B.Sc, ZCE
> [hidden email]
>
> Sent from my Motorola Atrix smartphone
> On 2011-08-05 4:10 PM, "Pádraic Brady" <[hidden email]> wrote:
> > Hi Adam,
> >
> > It's discussed in another thread (and I don't want to go off topic too
> much)
> > but there are reasons why accelerated major releases make sense. The
> first
> > is that having the opportunity to break backwards compatibility, on a
> more
> > frequent basis, allows a gentler migration slope and allows for sensible
> > improvements to be rolled out faster. The jump from ZF1 to ZF2 will be
> big.
> > From ZF2 to ZF3 could be much smaller. The second is that, with PHP 5.4
> > around the corner, it offers a chance to adopt new PHP features closer to
> > the beginning of the adoption curve rather than at the tail end. Adoption
> > would be slower but when the time comes, having a mature framework
> supported
> > for those versions ready to rock and rumble isn't a bad thing. PHP 5.4
> > offers Traits, for example, which can do an awful lot in removing
> > duplication and simplifying concepts such as Action Helpers. Thirdly, an
> > aggressive schedule focuses contributor resources. We're dragging a lot
> of
> > weight with components and they can't be allowed to stagnate too long
> (MVC
> > is remarkably tiny in comparison to the framework's current scope). Short
> of
> > independent versioning, there needs to be an allowance for component
> renewal
> > of less than the 5-6 years ZF1 has taken along with the necessary
> > deprecation if needed.
> >
> > In a sense we're not talking about massive revolutionary overhauls every
> 18
> > months - more of a gentler incremental improvement schedule that's easier
> to
> > migrate across over time. Happy to debate further (though make a new
> thread
> > for it!).
> >
> > Thanks for chipping in with your own opinions.
> >
> > Paddy.
> >
> > On Fri, Aug 5, 2011 at 7:01 PM, Adam Lundrigan <[hidden email]>
> wrote:
> >
> >> Pádraic,
> >>
> >> I haven't spent much time with ZF2, so I don't feel anywhere near the
> same
> >> level of frustration, but I definitely get where you're coming from.
> >>
> >> I've inserted my thoughts below. If i'm offbase anywhere, feel free to
> >> mercilessly chew me out at will ;)
> >>
> >> Adam Lundrigan, B.Sc, ZCE
> >> [hidden email]
> >>
> >>
> >> On Fri, Aug 5, 2011 at 12:52 PM, Pádraic Brady <[hidden email]
> >> >wrote:
> >>
> >> > I've repeatedly requested that someone, anyone, from Zend summarise
> ZF2
> >> > progress on some frequent basis. This continues not to occur and the
> >> result
> >> > is that, frankly, it's hard to know what is happening in Zend
> Framework
> >> 2.
> >> > The best we're getting are hints dropped at random in unrelated
> emails.
> >> > Unfortunately, I can't even be on IRC 24/7 and even that looks a
> little
> >> > downsized recently. I don't understand what is so hard about sending
> an
> >> > email once in a while to keep the community informed, not to mention
> the
> >> > developers who presumably will be called upon to contribute to ZF2.
> >> You're
> >> > killing me here, guys.
> >> >
> >>
> >> Absolutely agree. Personally, I think this is where the SVN/Git choice
> >> made
> >> early on in the ZF2 process really falls down, and the reason is their
> main
> >> difference: SVN is centralized, Git is not.
> >>
> >> With SVN everything that is committed is on the SVN server, and with
> proper
> >> branch structuring it should be easy to find and dive into someone
> else's
> >> branch to see what they are working on. I know that may be
> oversimplfying
> >> the lay of the land, as SVN has it's own challenges, but in theory it
> >> works. The only thing we can't see in SVN is the uncommitted files the
> >> branch owner has in his/her working copy. (but if you belive the addage
> >> "work that isn't committed doesn't exist", or something like that, then
> >> those files don't count)
> >>
> >> With Git, it's decentralization all the way, at the cost of a definitive
> >> source by which we can measure progress. Right now ZF2 progress is
> spread
> >> across dozens (at least) of contributor's forks of the ZF2 github repo,
> >> each with it's own branches tracking the fork owner's exploratory forays
> >> from the existing source. Some contributors (like Matthew) are (or were)
> >> doing exploratory work in their own private repos (on github or
> elsewhere)
> >> not inherently connected to the ZF2 github repo. On top of that, Git's
> >> decentralized nature does introduce a lag in getting the "bleeding edge"
> >> out
> >> there; committing changes from your local copy requires a concious
> effort
> >> to
> >> also push those changes up to your ZF2 fork before they are "out there"
> for
> >> those interested to see, and are still an accepted pull request away
> from
> >> being included in the definitive source for ZF2 code (the
> zendframework/zf2
> >> github repo), where most of the interested people would go to find the
> >> latest ZF2 code. I'm not saying git was a bad choice (my feeling is
> quite
> >> the opposite, actually), but that the sprawl of repositories, forks and
> >> branches needs to organized properly in order to work well. The switch
> >> from
> >> SVN to Git greatly reduced the entry barrier for contributing to ZF2,
> and
> >> that is great, but it does introduce other issues that need to be
> >> addressed.
> >>
> >>
> >> As an example, a while back I added code to Zend_Locale to expose
> >> defaultNumberSystem from CLDR (ZF-10728) and figured I would update ZF2
> >> Zend\Locale to expose it as well. I forked ZF2 from github, added the
> >> necessary code, and put in a pull request only to be told that the
> >> Zend\Locale component in zendframework/zf2 was the wrong one; it was
> being
> >> refactored elsewhere (thomasweidner/zf2). There was no indication that
> the
> >> Zend\Locale code in zendframework/zf2 is not the one I should be looking
> >> at. It wasn't much work, so it didn't bother me, but that kind of
> >> disconnect does put a damper on one's enthusiasm to contribute.
> >>
> >> This comes back around to something that I brought up in an earlier
> mailing
> >> list post: a "ZF2 status page", of sorts (see:
> >>
> >>
> http://zend-framework-community.634137.n4.nabble.com/ZF2-feedback-td3620779.html
> >> ).
> >> Summary:
> >>
> >> I would like to see a ZF2 status page, on the wiki or elsewhere, where
> we
> >> can go to see when a particular component was last merged into official
> >> repo
> >>
> >> and a link to the contributor fork(s) (if they are public) where the
> >> bleeding-edge work is taking place. That would go a long way to helping
> >> people like us get in early, watch the progress and offer feedback.
> >>
> >> Even if it was as simple as a wiki page with a section for each
> component,
> >> and under each section list the git repos where work is being done with
> a
> >> short summary of the purpose of each branch within. That would lower the
> >> entry barrier (and frustration level for people like Pádraic ;)) to
> diving
> >> into ZF2. For instance, I could go to that page, look up Zend\Mvc (or
> >> whatever the MVC package is), see that Matthew has two branches and
> Ralph
> >> has one where they are throwing out ideas around how the MVC should be
> >> structured. Or, for another example, I could look up Zend\Soap, see that
> >> nobody is working on it for ZF2, and throw my hat in the ring to take it
> >> over. (disclaimer: those are examples for illustratory purposes, and may
> >> or may not have a basis in reality)
> >>
> >> Again, my knowledge of Git and GitHub is not very extensive (and neither
> is
> >> my knowledge of how ZF2 development is being managed and steered), so if
> >> i'm
> >> missing something fundamental (like a "find all forks which have
> modified a
> >> particular file" feature, for instance) please let me know i'm offbase
> with
> >> my criticism and point out my errant way....i'll be eternally grateful
> :)
> >>
> >>
> >> > The reaction to this has already started. We've expressed our wish
> that
> >> > Zend Framework enter a more frequent major release cycle with Zend
> >> Framework
> >> > 3.0 potentially being released within 18 months. This would have a few
> >> > impacts primarily requiring far closer collaboration with the
> community
> >> > because I can't see anyone so much as contemplating going through the
> ZF2
> >> > twiddling-thumbs experience again. We noticed and do remember that
> there
> >> was
> >> > no concrete response to this from Zend and, believe me, we're already
> >> > expecting the answer to be in the negative, but hey, at least put us
> out
> >> of
> >> > our misery so we can plan ahead on what other projects to dedicate
> time
> >> to.
> >> >
> >>
> >> This is one proposal/argument I at first supported, but have found
> myself
> >> coming around to the other side lately. I think that's down to version
> >> fatigue now that Google Chrome and Mozilla Firefox are both <sarcasm>
> >> pumping out new "major" versions every day </sarcasm>. It's a game of
> >> major
> >> version psychology meant to make a bigger deal out of something that
> really
> >> isn't. It doesn't affect the pace of outcome (ie: code, features), just
> >> how
> >> it's labelled. If you bump from v3.4 -> v3.5 no one really cares, but v3
> >> ->
> >> v4 people pay attention because historical use of the major version
> number
> >> indicated a major application change.
> >>
> >> But, I digress.
> >>
> >> I guess it really comes down to how ZF's managers plan to handle adding
> new
> >> features. Will it be like ZF1, where new features/components were added
> >> seemingly at every minor (1.x) version? Or will there be a feature
> freeze
> >> between major versions, with only bugfixes between?
> >>
> >>
> >> >
> >> > This brings me to a final point. When everyone and their pet rabbit
> was
> >> in
> >> > the belly of Zend Framework 1 writing source code and seeing proposals
> >> > adopted which served the community well, there was no problem.
> However,
> >> Zend
> >> > Framework 2 is exposing a lot of cracks in the open governance of the
> >> > project. A lack of communication, lack of inclusiveness in decision
> >> making,
> >> > uncertainty over CLA legalities (for 3rd party licensed code), and a
> >> > shortage of basic information like a timeline is an intolerable
> situation
> >> > for an open source project. It stymies the very objective of the open
> >> source
> >> > movement and this can turn into a very slippery slope, faster than
> people
> >> > might realise, towards a four letter word for a piece of cutlery.
> >> >
> >> > The worst of this situation is that there are professional programmers
> >> who
> >> > probably charge clients their first born child, per hour, sitting
> around
> >> on
> >> > their bums bored silly with the current situation. Letting the
> lifeblood
> >> of
> >> > Zend Framework go to waste for month after month is incomprehensible.
> >> We're
> >> > contributors not peer reviewers.
> >> >
> >>
> >> I do understand that most ZF contributors are, like myself, volunteers.
> I
> >> do it because it gives me a warm, fuzzy feeling inside every time I get
> to
> >> mark a bug as "resolved". Some others do it because it's part of their
> >> job,
> >> or make a living off it in other ways, and so contribute back.
> Regardless,
> >> there has to be a certain level of pressure put on contributors to
> >> contribute in a way that is conducive to a high-quality open source
> >> project.
> >>
> >> In my mind, chief among those requirements should be that code isn't
> >> developed in isolation; the repo(s) where code is being developed should
> be
> >> well known to the community (by that I mean information on them should
> be
> >> readily available to those who care to look into the wiki to find out)
> and
> >> there should be an avenue for offering comments and contributions to
> them.
> >> The current setup of git + github is very good for this, but it is
> >> difficult
> >> to get a meaningful overview of the extent of ZF2's progress towards
> >> stability, or even work ongoing on a specific component.
> >>
> >> Also important is keeping "documentation" (unit tests, manual pages,
> wiki
> >> pages, docblocks, etc) up to date with the code. For instance, in ZF2
> >> master, where the Zend\Di implementation is out of sync with the unit
> tests
> >> and manual sources. It took a bit of digging to find out that
> setProperty
> >> has changed to setParameters, and the signature was slightly different.
> >> That change is mentioned in bug ZF2-42, and i'm willing to jump in and
> fix
> >> it, but am wary to do so with the possibility that it's already been
> fixed
> >> in a branch in someone's ZF2 fork. This comes back to my previous
> comment
> >> about a ZF2 status page and knowing where the bleeding edge is located.
> (I
> >> know I can just email the component manintainer to find out it's status,
> >> but
> >> that's extra bother and work on them, so I feel as though that kind of
> >> information should recorded and availalble on the wiki).
> >>
> >> ------
> >>
> >> Now i'll apologize for rambling on and on (and on), and thank you for
> >> reading all the way to the end :)
> >>
>



--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
*Zend Framework Community Review Team <http://framework.zend.com/>*
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Adam Lundrigan
In reply to this post by Wil Moore III
Wil,


> > With Git, it's decentralization all the way, at the cost of a
> > definitive source by which we can measure progress.
> >
>
> My feeling is that the source repository is not a communication tool in and
> of itself. If we were somehow using it that way, this is wrong and is
> likely
> to not be reachable (for the masses) anyway. Of course, Github blurs that
> line a little bit;
>

Agreed.  The point I was trying to make is that with git and github, the sum
total of ZF2 progress is scattered across dozens of forks and branches.
This in and of itself is not necessarily a bad thing, but it does mean that
we need to be better organized and better communicators so that everyone who
wants to contribute is able to keep in the loop (this is, after all, an open
collaborative project).  I didn't mean to insinuate that the VCS system
needed to take on that role, but you are right in saying that github does
blur those lines.  The medium used isn't important to me, as long as there
is a location an interested developer can go to, look up the component they
are interested in and get back a list of repos where it's being worked on
(or prototypes are being hashed out, experiments taking place, etc).

I would prefer not to even
> allude to Git or SVN playing any part in this communication break down.
>

Fair point, it's not really about the VCS being used, but the level of
communication required.  My point was that, because Git is decentralized,
you can't just pop into a code browser (like WebSVN, in ZFv1's case) and
dive down through the contributor branches to get a grip on what's
happening, confident in the knowledge that the repo contains the sum total
of contributor work.  No one repo contains the whole "bleeding edge" of the
ZF2 codebase, so it becomes a scavenger hunt to find out which repo has a
particular part of that bleeding edge.  Again it just comes down to extra
communication; the component maintainers have to tell us where the bleeding
edge is located (repo + branch), or any of us who are interested in knowing
would have to contact the lead to find out.

Ideally, any time a branch is created to work on a particular component, the
contributor goes to the wiki, looks up the ZF2 status page for that
component, and adds the URL to their new branch along with a short
description of the work planned.  For instance, Thomas is working on
Zend\Locale in this github fork of ZF2, so he would do something like this:

*Zend\Locale*

   - https://github.com/thomasweidner/zf2/tree/feature/Locale2.0
      - Refactoring Zend_Locale for ZF2


A quick update to the wiki page like this would be enough to allow other
contributors to know where the work is happening, and if they are looking
for something specific the short summary would help steer them the right
way.  Obviously, there would be some exceptions, such as for bugfix branches
that aren't long-lived.

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Wil Moore III
>
> No one repo contains the whole "bleeding edge" of the ZF2 codebase, so it
> becomes a scavenger hunt to find out which repo has a particular part of
> that bleeding edge.
>

addressed below:


> Ideally, any time a branch is created to work on a particular component,
> the contributor goes to the wiki...
>
A quick update to the wiki page like this would be enough to allow other
> contributors to know where the work is happening, and if they are looking
> for something specific the short summary would help steer them the right
> way.
>

Agreed. Something like this needs to be incorporated into the workflow. Blog
posts all over the place won't get it done. Those blog posts are great, but
they should be supplemental rather than the main source.

This would effectively solve the "issue" (if there is one) of decentralized
version control. If anything, DVCS simply illuminates the core problem which
again, is communication (or rather lack thereof).
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Adam Lundrigan
In reply to this post by Artur Bodera
My two cents (see below) with yours makes 4 cents :P

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]





> Git and github are just versioning systems. ZF is a project. I don't
> believe
> this discussion as per
> the first post from Padraic is related to the software. It's more a problem
> with project
> management. I've come in as a contributor just recently, but I've been
> using
> and observing the
> growth of ZF since it's beginning.
>


I know the distinction, but your point is valid: it is a project management
issue.  However, a direct consequence of that is a lack of formal
communication regarding who is doing what and where they are doing it.  Git
exacerbates this problem because of it's distributed nature.  With SVN,
everything that's committed is on the server, and you can see it using a
tool like WebSVN, provided you're willing to invest the time to dig.  But
with Git, there is no central place where you can go to do that....for ZF2
there are dozens of forks which make up the sum total of the project.

So, you are right, it isn't really about git+github, but they make getting
around the core issue (communication) more difficult.


> I might sound blunt, but I'd like to remind you of a few basic things.
>
> First of all, a major version change (historically) means breaking
> compatibility. That is both a
> problem and a bliss. This means, that we absolutely NEED to brainstorm more
> and put a lot
> of thought into the core. If we're gonna break it, now it's the time.
> Forget
> about refactoring and
> API changes for many months after ZF2 RC and official release. NOW is the
> time to play in the
> sandbox, bring up the craziest ideas and introduce the most advanced,
> cutting-edge and
> (sometimes borrowed from other frameworks) solutions.
>

(disclaimer: below is merely my opinion.  If Matthew or someone else in the
know wants to set the record straight, feel free)

The feeling I get from having watched the mailing list and wiki over the
past year is that the time has long passed for brainstorming on the core.
We can't forget that, in reality, this is Zend's project, and they have put
Matthew and his team in the drivers seat.  Matthew and his team have
solicited input from the community over the past year around what we didn't
like about ZF1, where the performance bottlenecks and steep learning curves
existed, what we'd like to see added in ZF2, and other such important
questions. They have a plan to tackle those requirements (one would assume)
for the core components like MVC, DI, EventManager, etc, while leaving
maintainers of the other components to manage their own migration from ZF1
to ZF2.

That said, the time for feedback and iterative improvement have not passed.
Our job as the ZF community is to take what Matthew and his team are
producing (prototypes and examples) and run them through their paces then
offer feedback and patches.  I'm sure that anyone who wants to "play in the
sandbox", as you say, is more than free to do so.  If you have a crazy idea
and don't mind spending the time to flesh it out then by all means go right
ahead, but the final decision on it's fate will rest with both Matthew's
team and the Community Review team.


>
>
> No 2 - Feature-set. That's very important part of community-tyle project
> management.
> Because there is no schedule, there is no "freeze" date. Because there is
> no
> freeze date, we
> are confused on whether new features should go into ZF2, or ZF1-ported-2 or
> should we just
> forget about them? There are different schools for that, but looking back
> at
> some other open-
> source projects I remember, that many of them USED major version switch to
> push in some
> amazing features. It's optional, but has to be accounted for.



ZF2 will have dependency injection, an event manager, and revamped MVC just
to name a few.  Those are pretty sweet features in my book :)



> No developer
> likes to do double
> work - currently, because ZF1 is constantly patched and ZF2 was forked a
> long time ago,
> there is some redundancy with that. It's not necessarily bad, as we're
> smart
> and efficient :-) We
> can do the double-patching, but we need to know that we should do it and
> how
> (organisation-wise).
>


Pulling patches forward from ZF1 (and backporting from ZF2 to ZF1 where
appropriate, as well) which were applied after the two repos split will need
to be done, and will be an ongoing process up to the point in time where ZF1
is declared end of life.  That's just the reality of having multiple major
versions of your software out there.  This is one area where the community
can really step up and do good, and it's one of the things I plan to do
myself for ZF2.



>
> No 3 - github is cool. I like decentralization. Again - don't confuse code
> decentralization with
> project coordination problems. In SVN times, people check-out on their
> machines, hack away
> and after they are happy with results, they commit. I see little difference
> with GIT+GitHub. It's
> just prettier and there is *more* transparency as you can peek inside my
> repository. The problems
> you've mentioned - i.e. not knowing the progress of work, or state of
> things, is NOT git's job.
> That's what wikis+mail-list are for! That's what project-management tools
> are for. Throw in a
>  project calendar, milestone tickets meter from bugtracker, mix with some
> creative goal setting
> (see wiki and ZF2 roadmap) and courageous milestone date setting and you're
> set.
>

I talked about this above, so i'll just summarize:  You are right, but
git+github do play a role is exacerbating the problem, and that's the point
I was hoping to make.


> Adam - Gantt's chart, have you heard of it ? :-)
>

Only every day....and every day I wish they had never been invented :P


>
> Looking from a perspective, ZF2 timing clashes with PHP 5.3/5.4 and
> introduction of some very smart
> concepts in php world. I'd really hate to see ZF2 to be only an "upgrade"
> to
> ZF1 to use namespaces
> and some performance improvement. Unfortunately, I don't think it is
> possible to achieve much more
> without some stir and a little craziness... unless we want to have ZF2 RC
> ready for Easter 2014 or
> have a product that is just a well-unit-tested ZF1 on steroids.
>
>
From what I understand from listening to the conversations around ZF2,
Matthew's team is trying to move ZF2 in a development direction that will
make taking advantage of the features of PHP 5.4 easier.  If I recall
correctly, there was some discussion about how ZF2 could adopt some of the
goodies from 5.4 (like traits) to simplify the ZF2 code base without
breaking BC.

Outside of the core components (MVC, EventManager, DI) I think much of the
framework will remain largely the same, with the other components of the
framework being simply (relatively, anyway) refactored into namespaces.
Some components from ZF1 have design choices inherent which many would like
to see changed, and ZF2 is the time to do those overhauls as well.  There
are many components which, IMO, don't need any significant changes and might
only see incremental improvements between ZF1 and ZF2, depending on what the
component lead would like to see done.



>
> Have a nice day!
>
> Arthur.
>
>
> --
>
>      __
>     /.)\   +48 695 600 936
>     \(./   [hidden email]
>
>
> On Fri, Aug 5, 2011 at 9:39 PM, Pádraic Brady <[hidden email]
> >wrote:
>
> > Hi Wil,
> >
> > The problem I have with adopting Symfony's MVC may be a bit whimsical,
> but
> > I'd prefer we have two strong competitors over a merger that
> > leaves...whatever the next big gun is. I'm assuming Lithium or CakePHP in
> > our class. Competition breeds rivalry, normally. It may be obviously too
> > late for that to influence ZF2, but let's not leap right into surrender
> and
> > resignation as just a component library. In PHP, I have a very low
> > tolerance
> > for competition being lax. It seems to open the door to crackpot
> > programmers
> > who wouldn't recognise secure code if it leaped up and bit them. On the
> > lightweight end, we have CodeIgniter ruling the roost, and I would rather
> > you shoot me now than have me use it for anything remotely important.
> > Digging around its code is like time travelling back to the 90s. It's
> > criminal that Kohana has not overtaken it yet. No sir, a little
> competition
> > is a healthy prod to keep the improvements and high standards rolling.
> >
> > Besides, ZF2 will be faster than Symfony 2 which is fundamentally
> essential
> > ;). http://symfony.com/six-good-technical-reasons#fast
> >
> > Paddy
> >
> > On Fri, Aug 5, 2011 at 8:01 PM, Wil Moore III <[hidden email]
> > >wrote:
> >
> > > @Padraic:
> > >
> > > I'm basically 99% convinced at this point that whatever "prototype"
> > appears
> > > > will be what is released as Zend Framework 2.0 barring minor changes.
> > > This
> > > > was never what the community intended...
> > >
> > >
> > > Agreed. And to add to that...I'm still not convinced that we _NEED_
> > another
> > > MVC implementation. What is wrong with collaborating with SF2 and just
> > > making that even better (BTW, it is awesome as-is anyway).
> > >
> > > @Adam:
> > >
> > >
> > > > With Git, it's decentralization all the way, at the cost of a
> > > > definitive source by which we can measure progress.
> > > >
> > >
> > > My feeling is that the source repository is not a communication tool in
> > and
> > > of itself. If we were somehow using it that way, this is wrong and is
> > > likely
> > > to not be reachable (for the masses) anyway. Of course, Github blurs
> that
> > > line a little bit; however, on the surface, I would prefer not to even
> > > allude to Git or SVN playing any part in this communication break down.
> > >
> > > I would like to see a ZF2 status page, on the wiki or elsewhere, where
> > > > we can go to see when a particular component was last merged into
> > > official
> > > > repo
> > >
> > >
> > > I can get behind this request actually. This makes sense from a
> > > communication stand-point.
> > >
> > > Again, my knowledge of Git and GitHub is not very extensive...
> > >
> > >
> > > Adam, I don't think it matters because at the end of the day, you just
> > want
> > > an indicator as to where things are at. You shouldn't have to rely on
> Git
> > > for that...
> > >
> >
> >
> >
> > --
> > Pádraic Brady
> >
> > http://blog.astrumfutura.com
> > http://www.survivethedeepend.com
> > *Zend Framework Community Review Team <http://framework.zend.com/>*
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Artur Bodera
In reply to this post by Adam Lundrigan
It's great you brought these examples up. Firefox would be the perfect
example how not to do things. I've been firefox fan since 1beta1, I
remember the worldwide event around release of ver 2, then 3. I've had
ver 3 for a loooong time, then it prompted if I wanted the
cutting-edge ver 4. Wow, bring it on. Well, minutes later, half of
extensions were dead, it was pretty and slow as hell. I thought -well,
they'll polish it eventually, so I had ver 4 for months. Some time 2
months ago, a prompt pops up - wanna go to the moon with ver 5? I
thought: well, they probably couldn't fix v4 so I guess ver 5 will
finally bring down mem usage below 2gb (sick). It didn't. Only 2 weeks
later (!!!!) I got invitation to ver 7. The same day I learned, that
ver 8 is gonna have some amazing new engine... Blah bla blah.

As you probably suspect by now, that was the day I switched to chrome.


Sent from my iPad

On 6 sie 2011, at 16:02, Adam Lundrigan <[hidden email]> wrote:

> *Forgot to hit reply-all (*smack* bad Adam).  Apologies to Pádraic, who will
> get this twice.*
>
> As it was a bit off-topic I didn't delve too far into it, but I do
> understand the rationale behind rapid major releases.  ZF is still maturing;
> there are many things in ZFv1 that would be changed if BC breaks were
> allowed, and this is the reason for ZFv2.  However, there does need to be
> some balance...an approach like Firefox and Google Chrome have taken is
> quite extreme, with new "major" releases every month or so.  Major releases
> should come rapidly enough that we can do what is necessary to keep the
> framework fresh, but not so rapidly that we leave existing websites "hung
> out to dry" in terms of critical fixes.  There would need to be some
> discussion with and direction from the involved Zend staff on what that
> compromise should be, what the window of support for each release is, etc.
>
> My point was to mock the psychological aspect of version numbering, and the
> approach the likes of Google and Mozilla have taken.  For ZF, rapid major
> releases would likely be a good thing, but the risk of version fatigue is
> real.  A quick succession of major releases, each with a short lifespan,
> could drive developers away as they would either have to port all of their
> applications forward once the version they are using EOLed or do their own
> critical fix backporting (or let the site run on an unsupported framework
> version, I guess).
>
> --
> Adam Lundrigan, B.Sc, ZCE
> [hidden email]
>
> Sent from my Motorola Atrix smartphone
>
>
> On 2011-08-05 4:10 PM, "Pádraic Brady" <[hidden email]> wrote:
>> Hi Adam,
>>
>> It's discussed in another thread (and I don't want to go off topic too
> much)
>> but there are reasons why accelerated major releases make sense. The first
>> is that having the opportunity to break backwards compatibility, on a more
>> frequent basis, allows a gentler migration slope and allows for sensible
>> improvements to be rolled out faster. The jump from ZF1 to ZF2 will be
> big.
>> From ZF2 to ZF3 could be much smaller. The second is that, with PHP 5.4
>> around the corner, it offers a chance to adopt new PHP features closer to
>> the beginning of the adoption curve rather than at the tail end. Adoption
>> would be slower but when the time comes, having a mature framework
> supported
>> for those versions ready to rock and rumble isn't a bad thing. PHP 5.4
>> offers Traits, for example, which can do an awful lot in removing
>> duplication and simplifying concepts such as Action Helpers. Thirdly, an
>> aggressive schedule focuses contributor resources. We're dragging a lot of
>> weight with components and they can't be allowed to stagnate too long (MVC
>> is remarkably tiny in comparison to the framework's current scope). Short
> of
>> independent versioning, there needs to be an allowance for component
> renewal
>> of less than the 5-6 years ZF1 has taken along with the necessary
>> deprecation if needed.
>>
>> In a sense we're not talking about massive revolutionary overhauls every
> 18
>> months - more of a gentler incremental improvement schedule that's easier
> to
>> migrate across over time. Happy to debate further (though make a new
> thread
>> for it!).
>>
>> Thanks for chipping in with your own opinions.
>>
>> Paddy.
>>
>> On Fri, Aug 5, 2011 at 7:01 PM, Adam Lundrigan <[hidden email]>
> wrote:
>>
>>> Pádraic,
>>>
>>> I haven't spent much time with ZF2, so I don't feel anywhere near the
> same
>>> level of frustration, but I definitely get where you're coming from.
>>>
>>> I've inserted my thoughts below. If i'm offbase anywhere, feel free to
>>> mercilessly chew me out at will ;)
>>>
>>> Adam Lundrigan, B.Sc, ZCE
>>> [hidden email]
>>>
>>>
>>> On Fri, Aug 5, 2011 at 12:52 PM, Pádraic Brady <[hidden email]
>>>> wrote:
>>>
>>>> I've repeatedly requested that someone, anyone, from Zend summarise ZF2
>>>> progress on some frequent basis. This continues not to occur and the
>>> result
>>>> is that, frankly, it's hard to know what is happening in Zend Framework
>>> 2.
>>>> The best we're getting are hints dropped at random in unrelated emails.
>>>> Unfortunately, I can't even be on IRC 24/7 and even that looks a little
>>>> downsized recently. I don't understand what is so hard about sending an
>>>> email once in a while to keep the community informed, not to mention
> the
>>>> developers who presumably will be called upon to contribute to ZF2.
>>> You're
>>>> killing me here, guys.
>>>>
>>>
>>> Absolutely agree. Personally, I think this is where the SVN/Git choice
>>> made
>>> early on in the ZF2 process really falls down, and the reason is their
> main
>>> difference: SVN is centralized, Git is not.
>>>
>>> With SVN everything that is committed is on the SVN server, and with
> proper
>>> branch structuring it should be easy to find and dive into someone else's
>>> branch to see what they are working on. I know that may be oversimplfying
>>> the lay of the land, as SVN has it's own challenges, but in theory it
>>> works. The only thing we can't see in SVN is the uncommitted files the
>>> branch owner has in his/her working copy. (but if you belive the addage
>>> "work that isn't committed doesn't exist", or something like that, then
>>> those files don't count)
>>>
>>> With Git, it's decentralization all the way, at the cost of a definitive
>>> source by which we can measure progress. Right now ZF2 progress is spread
>
>>> across dozens (at least) of contributor's forks of the ZF2 github repo,
>>> each with it's own branches tracking the fork owner's exploratory forays
>>> from the existing source. Some contributors (like Matthew) are (or were)
>>> doing exploratory work in their own private repos (on github or
> elsewhere)
>>> not inherently connected to the ZF2 github repo. On top of that, Git's
>>> decentralized nature does introduce a lag in getting the "bleeding edge"
>>> out
>>> there; committing changes from your local copy requires a concious effort
>>> to
>>> also push those changes up to your ZF2 fork before they are "out there"
> for
>>> those interested to see, and are still an accepted pull request away from
>>> being included in the definitive source for ZF2 code (the
> zendframework/zf2
>>> github repo), where most of the interested people would go to find the
>>> latest ZF2 code. I'm not saying git was a bad choice (my feeling is quite
>>> the opposite, actually), but that the sprawl of repositories, forks and
>>> branches needs to organized properly in order to work well. The switch
>>> from
>>> SVN to Git greatly reduced the entry barrier for contributing to ZF2, and
>>> that is great, but it does introduce other issues that need to be
>>> addressed.
>>>
>>>
>>> As an example, a while back I added code to Zend_Locale to expose
>>> defaultNumberSystem from CLDR (ZF-10728) and figured I would update ZF2
>>> Zend\Locale to expose it as well. I forked ZF2 from github, added the
>>> necessary code, and put in a pull request only to be told that the
>>> Zend\Locale component in zendframework/zf2 was the wrong one; it was
> being
>>> refactored elsewhere (thomasweidner/zf2). There was no indication that
> the
>>> Zend\Locale code in zendframework/zf2 is not the one I should be looking
>>> at. It wasn't much work, so it didn't bother me, but that kind of
>>> disconnect does put a damper on one's enthusiasm to contribute.
>>>
>>> This comes back around to something that I brought up in an earlier
> mailing
>>> list post: a "ZF2 status page", of sorts (see:
>>>
>>>
> http://zend-framework-community.634137.n4.nabble.com/ZF2-feedback-td3620779.html
>>> ).
>>> Summary:
>>>
>>> I would like to see a ZF2 status page, on the wiki or elsewhere, where we
>>> can go to see when a particular component was last merged into official
>>> repo
>>>
>>> and a link to the contributor fork(s) (if they are public) where the
>>> bleeding-edge work is taking place. That would go a long way to helping
>>> people like us get in early, watch the progress and offer feedback.
>>>
>>> Even if it was as simple as a wiki page with a section for each
> component,
>>> and under each section list the git repos where work is being done with a
>>> short summary of the purpose of each branch within. That would lower the
>>> entry barrier (and frustration level for people like Pádraic ;)) to
> diving
>>> into ZF2. For instance, I could go to that page, look up Zend\Mvc (or
>>> whatever the MVC package is), see that Matthew has two branches and Ralph
>>> has one where they are throwing out ideas around how the MVC should be
>>> structured. Or, for another example, I could look up Zend\Soap, see that
>>> nobody is working on it for ZF2, and throw my hat in the ring to take it
>>> over. (disclaimer: those are examples for illustratory purposes, and may
>>> or may not have a basis in reality)
>>>
>>> Again, my knowledge of Git and GitHub is not very extensive (and neither
> is
>>> my knowledge of how ZF2 development is being managed and steered), so if
>>> i'm
>>> missing something fundamental (like a "find all forks which have modified
> a
>>> particular file" feature, for instance) please let me know i'm offbase
> with
>>> my criticism and point out my errant way....i'll be eternally grateful :)
>>>
>>>
>>>> The reaction to this has already started. We've expressed our wish that
>>>> Zend Framework enter a more frequent major release cycle with Zend
>>> Framework
>>>> 3.0 potentially being released within 18 months. This would have a few
>>>> impacts primarily requiring far closer collaboration with the community
>>>> because I can't see anyone so much as contemplating going through the
> ZF2
>>>> twiddling-thumbs experience again. We noticed and do remember that
> there
>>> was
>>>> no concrete response to this from Zend and, believe me, we're already
>>>> expecting the answer to be in the negative, but hey, at least put us
> out
>>> of
>>>> our misery so we can plan ahead on what other projects to dedicate time
>>> to.
>>>>
>>>
>>> This is one proposal/argument I at first supported, but have found myself
>>> coming around to the other side lately. I think that's down to version
>>> fatigue now that Google Chrome and Mozilla Firefox are both <sarcasm>
>>> pumping out new "major" versions every day </sarcasm>. It's a game of
>>> major
>>> version psychology meant to make a bigger deal out of something that
> really
>>> isn't. It doesn't affect the pace of outcome (ie: code, features), just
>>> how
>>> it's labelled. If you bump from v3.4 -> v3.5 no one really cares, but v3
>>> ->
>>> v4 people pay attention because historical use of the major version
> number
>>> indicated a major application change.
>>>
>>> But, I digress.
>>>
>>> I guess it really comes down to how ZF's managers plan to handle adding
> new
>>> features. Will it be like ZF1, where new features/components were added
>>> seemingly at every minor (1.x) version? Or will there be a feature freeze
>>> between major versions, with only bugfixes between?
>>>
>>>
>>>>
>>>> This brings me to a final point. When everyone and their pet rabbit was
>>> in
>>>> the belly of Zend Framework 1 writing source code and seeing proposals
>>>> adopted which served the community well, there was no problem. However,
>>> Zend
>>>> Framework 2 is exposing a lot of cracks in the open governance of the
>>>> project. A lack of communication, lack of inclusiveness in decision
>>> making,
>>>> uncertainty over CLA legalities (for 3rd party licensed code), and a
>>>> shortage of basic information like a timeline is an intolerable
> situation
>>>> for an open source project. It stymies the very objective of the open
>>> source
>>>> movement and this can turn into a very slippery slope, faster than
> people
>>>> might realise, towards a four letter word for a piece of cutlery.
>>>>
>>>> The worst of this situation is that there are professional programmers
>>> who
>>>> probably charge clients their first born child, per hour, sitting
> around
>>> on
>>>> their bums bored silly with the current situation. Letting the
> lifeblood
>>> of
>>>> Zend Framework go to waste for month after month is incomprehensible.
>>> We're
>>>> contributors not peer reviewers.
>>>>
>>>
>>> I do understand that most ZF contributors are, like myself, volunteers. I
>>> do it because it gives me a warm, fuzzy feeling inside every time I get
> to
>>> mark a bug as "resolved". Some others do it because it's part of their
>>> job,
>>> or make a living off it in other ways, and so contribute back.
> Regardless,
>>> there has to be a certain level of pressure put on contributors to
>>> contribute in a way that is conducive to a high-quality open source
>>> project.
>>>
>>> In my mind, chief among those requirements should be that code isn't
>>> developed in isolation; the repo(s) where code is being developed should
> be
>>> well known to the community (by that I mean information on them should be
>>> readily available to those who care to look into the wiki to find out)
> and
>>> there should be an avenue for offering comments and contributions to
> them.
>>> The current setup of git + github is very good for this, but it is
>>> difficult
>>> to get a meaningful overview of the extent of ZF2's progress towards
>>> stability, or even work ongoing on a specific component.
>>>
>>> Also important is keeping "documentation" (unit tests, manual pages, wiki
>>> pages, docblocks, etc) up to date with the code. For instance, in ZF2
>>> master, where the Zend\Di implementation is out of sync with the unit
> tests
>>> and manual sources. It took a bit of digging to find out that setProperty
>>> has changed to setParameters, and the signature was slightly different.
>>> That change is mentioned in bug ZF2-42, and i'm willing to jump in and
> fix
>>> it, but am wary to do so with the possibility that it's already been
> fixed
>>> in a branch in someone's ZF2 fork. This comes back to my previous comment
>>> about a ZF2 status page and knowing where the bleeding edge is located.
> (I
>>> know I can just email the component manintainer to find out it's status,
>>> but
>>> that's extra bother and work on them, so I feel as though that kind of
>>> information should recorded and availalble on the wiki).
>>>
>>> ------
>>>
>>> Now i'll apologize for rambling on and on (and on), and thank you for
>>> reading all the way to the end :)
>>>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Artur Bodera
In reply to this post by Adam Lundrigan
Now chrome - that was a bad example. It's got its stealth-update-mode.
I remember installing chrome 9. Last time I checked, it's magically
evolved to chrome 13 ;) I guess their strategy is: just install "da
browser for gods sakes", replace IE.. We'll take care of rest.

A good example of ver migrations strategies would probably be:
symphony 1-> 2
Drupal 6 -> 7
Debian

I think pushing BC break moment to 2.1 is the most counter-intuitive
thing we can possibly do. How about we break API in 1.14, just because
we decided so. And yeah, we'll announce it on the we page.  ... Wrong!
That's what minor vs major versions are for. If it's compatible, you
increase minor. I you're about to break most of the API (vide
namespaces, brokers, new mvc etc.) you increase major.

Rotating major ver every 12 months sound to me like a weak project
planning or eng. decisions. Why would we need new mvc or loading style
every 12 mo? On the other hand, there are features. You don't need new
major ver to introduce another 10 great components (take a look at
number of classes between zf 1.11 and say, 1.05. Night and day.)

A.

On 6 sie 2011, at 16:02, Adam Lundrigan <[hidden email]> wrote:

> *Forgot to hit reply-all (*smack* bad Adam).  Apologies to Pádraic, who will
> get this twice.*
>
> As it was a bit off-topic I didn't delve too far into it, but I do
> understand the rationale behind rapid major releases.  ZF is still maturing;
> there are many things in ZFv1 that would be changed if BC breaks were
> allowed, and this is the reason for ZFv2.  However, there does need to be
> some balance...an approach like Firefox and Google Chrome have taken is
> quite extreme, with new "major" releases every month or so.  Major releases
> should come rapidly enough that we can do what is necessary to keep the
> framework fresh, but not so rapidly that we leave existing websites "hung
> out to dry" in terms of critical fixes.  There would need to be some
> discussion with and direction from the involved Zend staff on what that
> compromise should be, what the window of support for each release is, etc.
>
> My point was to mock the psychological aspect of version numbering, and the
> approach the likes of Google and Mozilla have taken.  For ZF, rapid major
> releases would likely be a good thing, but the risk of version fatigue is
> real.  A quick succession of major releases, each with a short lifespan,
> could drive developers away as they would either have to port all of their
> applications forward once the version they are using EOLed or do their own
> critical fix backporting (or let the site run on an unsupported framework
> version, I guess).
>
> --
> Adam Lundrigan, B.Sc, ZCE
> [hidden email]
>
> Sent from my Motorola Atrix smartphone
>
>
> On 2011-08-05 4:10 PM, "Pádraic Brady" <[hidden email]> wrote:
>> Hi Adam,
>>
>> It's discussed in another thread (and I don't want to go off topic too
> much)
>> but there are reasons why accelerated major releases make sense. The first
>> is that having the opportunity to break backwards compatibility, on a more
>> frequent basis, allows a gentler migration slope and allows for sensible
>> improvements to be rolled out faster. The jump from ZF1 to ZF2 will be
> big.
>> From ZF2 to ZF3 could be much smaller. The second is that, with PHP 5.4
>> around the corner, it offers a chance to adopt new PHP features closer to
>> the beginning of the adoption curve rather than at the tail end. Adoption
>> would be slower but when the time comes, having a mature framework
> supported
>> for those versions ready to rock and rumble isn't a bad thing. PHP 5.4
>> offers Traits, for example, which can do an awful lot in removing
>> duplication and simplifying concepts such as Action Helpers. Thirdly, an
>> aggressive schedule focuses contributor resources. We're dragging a lot of
>> weight with components and they can't be allowed to stagnate too long (MVC
>> is remarkably tiny in comparison to the framework's current scope). Short
> of
>> independent versioning, there needs to be an allowance for component
> renewal
>> of less than the 5-6 years ZF1 has taken along with the necessary
>> deprecation if needed.
>>
>> In a sense we're not talking about massive revolutionary overhauls every
> 18
>> months - more of a gentler incremental improvement schedule that's easier
> to
>> migrate across over time. Happy to debate further (though make a new
> thread
>> for it!).
>>
>> Thanks for chipping in with your own opinions.
>>
>> Paddy.
>>
>> On Fri, Aug 5, 2011 at 7:01 PM, Adam Lundrigan <[hidden email]>
> wrote:
>>
>>> Pádraic,
>>>
>>> I haven't spent much time with ZF2, so I don't feel anywhere near the
> same
>>> level of frustration, but I definitely get where you're coming from.
>>>
>>> I've inserted my thoughts below. If i'm offbase anywhere, feel free to
>>> mercilessly chew me out at will ;)
>>>
>>> Adam Lundrigan, B.Sc, ZCE
>>> [hidden email]
>>>
>>>
>>> On Fri, Aug 5, 2011 at 12:52 PM, Pádraic Brady <[hidden email]
>>>> wrote:
>>>
>>>> I've repeatedly requested that someone, anyone, from Zend summarise ZF2
>>>> progress on some frequent basis. This continues not to occur and the
>>> result
>>>> is that, frankly, it's hard to know what is happening in Zend Framework
>>> 2.
>>>> The best we're getting are hints dropped at random in unrelated emails.
>>>> Unfortunately, I can't even be on IRC 24/7 and even that looks a little
>>>> downsized recently. I don't understand what is so hard about sending an
>>>> email once in a while to keep the community informed, not to mention
> the
>>>> developers who presumably will be called upon to contribute to ZF2.
>>> You're
>>>> killing me here, guys.
>>>>
>>>
>>> Absolutely agree. Personally, I think this is where the SVN/Git choice
>>> made
>>> early on in the ZF2 process really falls down, and the reason is their
> main
>>> difference: SVN is centralized, Git is not.
>>>
>>> With SVN everything that is committed is on the SVN server, and with
> proper
>>> branch structuring it should be easy to find and dive into someone else's
>>> branch to see what they are working on. I know that may be oversimplfying
>>> the lay of the land, as SVN has it's own challenges, but in theory it
>>> works. The only thing we can't see in SVN is the uncommitted files the
>>> branch owner has in his/her working copy. (but if you belive the addage
>>> "work that isn't committed doesn't exist", or something like that, then
>>> those files don't count)
>>>
>>> With Git, it's decentralization all the way, at the cost of a definitive
>>> source by which we can measure progress. Right now ZF2 progress is spread
>
>>> across dozens (at least) of contributor's forks of the ZF2 github repo,
>>> each with it's own branches tracking the fork owner's exploratory forays
>>> from the existing source. Some contributors (like Matthew) are (or were)
>>> doing exploratory work in their own private repos (on github or
> elsewhere)
>>> not inherently connected to the ZF2 github repo. On top of that, Git's
>>> decentralized nature does introduce a lag in getting the "bleeding edge"
>>> out
>>> there; committing changes from your local copy requires a concious effort
>>> to
>>> also push those changes up to your ZF2 fork before they are "out there"
> for
>>> those interested to see, and are still an accepted pull request away from
>>> being included in the definitive source for ZF2 code (the
> zendframework/zf2
>>> github repo), where most of the interested people would go to find the
>>> latest ZF2 code. I'm not saying git was a bad choice (my feeling is quite
>>> the opposite, actually), but that the sprawl of repositories, forks and
>>> branches needs to organized properly in order to work well. The switch
>>> from
>>> SVN to Git greatly reduced the entry barrier for contributing to ZF2, and
>>> that is great, but it does introduce other issues that need to be
>>> addressed.
>>>
>>>
>>> As an example, a while back I added code to Zend_Locale to expose
>>> defaultNumberSystem from CLDR (ZF-10728) and figured I would update ZF2
>>> Zend\Locale to expose it as well. I forked ZF2 from github, added the
>>> necessary code, and put in a pull request only to be told that the
>>> Zend\Locale component in zendframework/zf2 was the wrong one; it was
> being
>>> refactored elsewhere (thomasweidner/zf2). There was no indication that
> the
>>> Zend\Locale code in zendframework/zf2 is not the one I should be looking
>>> at. It wasn't much work, so it didn't bother me, but that kind of
>>> disconnect does put a damper on one's enthusiasm to contribute.
>>>
>>> This comes back around to something that I brought up in an earlier
> mailing
>>> list post: a "ZF2 status page", of sorts (see:
>>>
>>>
> http://zend-framework-community.634137.n4.nabble.com/ZF2-feedback-td3620779.html
>>> ).
>>> Summary:
>>>
>>> I would like to see a ZF2 status page, on the wiki or elsewhere, where we
>>> can go to see when a particular component was last merged into official
>>> repo
>>>
>>> and a link to the contributor fork(s) (if they are public) where the
>>> bleeding-edge work is taking place. That would go a long way to helping
>>> people like us get in early, watch the progress and offer feedback.
>>>
>>> Even if it was as simple as a wiki page with a section for each
> component,
>>> and under each section list the git repos where work is being done with a
>>> short summary of the purpose of each branch within. That would lower the
>>> entry barrier (and frustration level for people like Pádraic ;)) to
> diving
>>> into ZF2. For instance, I could go to that page, look up Zend\Mvc (or
>>> whatever the MVC package is), see that Matthew has two branches and Ralph
>>> has one where they are throwing out ideas around how the MVC should be
>>> structured. Or, for another example, I could look up Zend\Soap, see that
>>> nobody is working on it for ZF2, and throw my hat in the ring to take it
>>> over. (disclaimer: those are examples for illustratory purposes, and may
>>> or may not have a basis in reality)
>>>
>>> Again, my knowledge of Git and GitHub is not very extensive (and neither
> is
>>> my knowledge of how ZF2 development is being managed and steered), so if
>>> i'm
>>> missing something fundamental (like a "find all forks which have modified
> a
>>> particular file" feature, for instance) please let me know i'm offbase
> with
>>> my criticism and point out my errant way....i'll be eternally grateful :)
>>>
>>>
>>>> The reaction to this has already started. We've expressed our wish that
>>>> Zend Framework enter a more frequent major release cycle with Zend
>>> Framework
>>>> 3.0 potentially being released within 18 months. This would have a few
>>>> impacts primarily requiring far closer collaboration with the community
>>>> because I can't see anyone so much as contemplating going through the
> ZF2
>>>> twiddling-thumbs experience again. We noticed and do remember that
> there
>>> was
>>>> no concrete response to this from Zend and, believe me, we're already
>>>> expecting the answer to be in the negative, but hey, at least put us
> out
>>> of
>>>> our misery so we can plan ahead on what other projects to dedicate time
>>> to.
>>>>
>>>
>>> This is one proposal/argument I at first supported, but have found myself
>>> coming around to the other side lately. I think that's down to version
>>> fatigue now that Google Chrome and Mozilla Firefox are both <sarcasm>
>>> pumping out new "major" versions every day </sarcasm>. It's a game of
>>> major
>>> version psychology meant to make a bigger deal out of something that
> really
>>> isn't. It doesn't affect the pace of outcome (ie: code, features), just
>>> how
>>> it's labelled. If you bump from v3.4 -> v3.5 no one really cares, but v3
>>> ->
>>> v4 people pay attention because historical use of the major version
> number
>>> indicated a major application change.
>>>
>>> But, I digress.
>>>
>>> I guess it really comes down to how ZF's managers plan to handle adding
> new
>>> features. Will it be like ZF1, where new features/components were added
>>> seemingly at every minor (1.x) version? Or will there be a feature freeze
>>> between major versions, with only bugfixes between?
>>>
>>>
>>>>
>>>> This brings me to a final point. When everyone and their pet rabbit was
>>> in
>>>> the belly of Zend Framework 1 writing source code and seeing proposals
>>>> adopted which served the community well, there was no problem. However,
>>> Zend
>>>> Framework 2 is exposing a lot of cracks in the open governance of the
>>>> project. A lack of communication, lack of inclusiveness in decision
>>> making,
>>>> uncertainty over CLA legalities (for 3rd party licensed code), and a
>>>> shortage of basic information like a timeline is an intolerable
> situation
>>>> for an open source project. It stymies the very objective of the open
>>> source
>>>> movement and this can turn into a very slippery slope, faster than
> people
>>>> might realise, towards a four letter word for a piece of cutlery.
>>>>
>>>> The worst of this situation is that there are professional programmers
>>> who
>>>> probably charge clients their first born child, per hour, sitting
> around
>>> on
>>>> their bums bored silly with the current situation. Letting the
> lifeblood
>>> of
>>>> Zend Framework go to waste for month after month is incomprehensible.
>>> We're
>>>> contributors not peer reviewers.
>>>>
>>>
>>> I do understand that most ZF contributors are, like myself, volunteers. I
>>> do it because it gives me a warm, fuzzy feeling inside every time I get
> to
>>> mark a bug as "resolved". Some others do it because it's part of their
>>> job,
>>> or make a living off it in other ways, and so contribute back.
> Regardless,
>>> there has to be a certain level of pressure put on contributors to
>>> contribute in a way that is conducive to a high-quality open source
>>> project.
>>>
>>> In my mind, chief among those requirements should be that code isn't
>>> developed in isolation; the repo(s) where code is being developed should
> be
>>> well known to the community (by that I mean information on them should be
>>> readily available to those who care to look into the wiki to find out)
> and
>>> there should be an avenue for offering comments and contributions to
> them.
>>> The current setup of git + github is very good for this, but it is
>>> difficult
>>> to get a meaningful overview of the extent of ZF2's progress towards
>>> stability, or even work ongoing on a specific component.
>>>
>>> Also important is keeping "documentation" (unit tests, manual pages, wiki
>>> pages, docblocks, etc) up to date with the code. For instance, in ZF2
>>> master, where the Zend\Di implementation is out of sync with the unit
> tests
>>> and manual sources. It took a bit of digging to find out that setProperty
>>> has changed to setParameters, and the signature was slightly different.
>>> That change is mentioned in bug ZF2-42, and i'm willing to jump in and
> fix
>>> it, but am wary to do so with the possibility that it's already been
> fixed
>>> in a branch in someone's ZF2 fork. This comes back to my previous comment
>>> about a ZF2 status page and knowing where the bleeding edge is located.
> (I
>>> know I can just email the component manintainer to find out it's status,
>>> but
>>> that's extra bother and work on them, so I feel as though that kind of
>>> information should recorded and availalble on the wiki).
>>>
>>> ------
>>>
>>> Now i'll apologize for rambling on and on (and on), and thank you for
>>> reading all the way to the end :)
>>>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

Artur Bodera
In reply to this post by Pádraic Brady
Padraic - I would refrain from attaching zf ver rotation to php
versions. Php has stalled before 5.3, but it's evolving quite steadily
right now. But it's evolving, not revolting or changing completely.
5.4 might bring in traits, 5.5 might bring some more OO goodies, but I
don't think it's worth pursing at all cost, as frameworks's job is to
iron out language, modules and environment differences (adapters,
compat checks, etc).
I'd rather have ZF2 that would live for a longer time to "support" my
project till php6. Otherwise, it's another piece of software that
needs my attention and satisfying its internal reqs.

A.

On 6 sie 2011, at 16:34, Pádraic Brady <[hidden email]> wrote:

> Nothing I disagree with in there ;). I would emphasise that the version
> incrementing would not be a marketing tool - 18 months is bandied with
> simply because of the arrival of PHP 5.4. Should PHP 5.5 take three years,
> and nothing worth improving is located in the meantime, then doing an 18
> month cycle for ZF 4.0 in that instance might not be suitable. I completely
> agree that the rapid versioning of browsers is a bit silly. You can as
> easily push new features into minor releases as major ones. It's primarily a
> psychological effect though it will be interesting to see if it has the
> desired effect on something like Mozilla's development process.
>
> Anyway, there is tons to debate on the topic as it relates to ZF whenever
> Zend actually respond to the proposal. In another topic, of course :P.
>
> Paddy
>
> On Sat, Aug 6, 2011 at 3:00 PM, Adam Lundrigan <[hidden email]> wrote:
>
>> Pádraic,
>>
>> As it was a bit off-topic I didn't delve too far into it, but I do
>> understand the rationale behind rapid major releases.  ZF is still maturing;
>> there are many things in ZFv1 that would be changed if BC breaks were
>> allowed, and this is the reason for ZFv2.  However, there does need to be
>> some balance...an approach like Firefox and Google Chrome have taken is
>> quite extreme, with new "major" releases every month or so.  Major releases
>> should come rapidly enough that we can do what is necessary to keep the
>> framework fresh, but not so rapidly that we leave existing websites "hung
>> out to dry" in terms of critical fixes.  There would need to be some
>> discussion with and direction from the involved Zend staff on what that
>> compromise should be, what the window of support for each release is, etc.
>>
>> My point was to mock the psychological aspect of version numbering, and the
>> approach the likes of Google and Mozilla have taken.  For ZF, rapid major
>> releases would likely be a good thing, but the risk of version fatigue is
>> real.  A quick succession of major releases, each with a short lifespan,
>> could drive developers away as they would either have to port all of their
>> applications forward once the version they are using EOLed or do their own
>> critical fix backporting (or let the site run on an unsupported framework
>> version, I guess).
>>
>> --
>>
>> Adam Lundrigan, B.Sc, ZCE
>> [hidden email]
>>
>> Sent from my Motorola Atrix smartphone
>> On 2011-08-05 4:10 PM, "Pádraic Brady" <[hidden email]> wrote:
>>> Hi Adam,
>>>
>>> It's discussed in another thread (and I don't want to go off topic too
>> much)
>>> but there are reasons why accelerated major releases make sense. The
>> first
>>> is that having the opportunity to break backwards compatibility, on a
>> more
>>> frequent basis, allows a gentler migration slope and allows for sensible
>>> improvements to be rolled out faster. The jump from ZF1 to ZF2 will be
>> big.
>>> From ZF2 to ZF3 could be much smaller. The second is that, with PHP 5.4
>>> around the corner, it offers a chance to adopt new PHP features closer to
>>> the beginning of the adoption curve rather than at the tail end. Adoption
>>> would be slower but when the time comes, having a mature framework
>> supported
>>> for those versions ready to rock and rumble isn't a bad thing. PHP 5.4
>>> offers Traits, for example, which can do an awful lot in removing
>>> duplication and simplifying concepts such as Action Helpers. Thirdly, an
>>> aggressive schedule focuses contributor resources. We're dragging a lot
>> of
>>> weight with components and they can't be allowed to stagnate too long
>> (MVC
>>> is remarkably tiny in comparison to the framework's current scope). Short
>> of
>>> independent versioning, there needs to be an allowance for component
>> renewal
>>> of less than the 5-6 years ZF1 has taken along with the necessary
>>> deprecation if needed.
>>>
>>> In a sense we're not talking about massive revolutionary overhauls every
>> 18
>>> months - more of a gentler incremental improvement schedule that's easier
>> to
>>> migrate across over time. Happy to debate further (though make a new
>> thread
>>> for it!).
>>>
>>> Thanks for chipping in with your own opinions.
>>>
>>> Paddy.
>>>
>>> On Fri, Aug 5, 2011 at 7:01 PM, Adam Lundrigan <[hidden email]>
>> wrote:
>>>
>>>> Pádraic,
>>>>
>>>> I haven't spent much time with ZF2, so I don't feel anywhere near the
>> same
>>>> level of frustration, but I definitely get where you're coming from.
>>>>
>>>> I've inserted my thoughts below. If i'm offbase anywhere, feel free to
>>>> mercilessly chew me out at will ;)
>>>>
>>>> Adam Lundrigan, B.Sc, ZCE
>>>> [hidden email]
>>>>
>>>>
>>>> On Fri, Aug 5, 2011 at 12:52 PM, Pádraic Brady <[hidden email]
>>>>> wrote:
>>>>
>>>>> I've repeatedly requested that someone, anyone, from Zend summarise
>> ZF2
>>>>> progress on some frequent basis. This continues not to occur and the
>>>> result
>>>>> is that, frankly, it's hard to know what is happening in Zend
>> Framework
>>>> 2.
>>>>> The best we're getting are hints dropped at random in unrelated
>> emails.
>>>>> Unfortunately, I can't even be on IRC 24/7 and even that looks a
>> little
>>>>> downsized recently. I don't understand what is so hard about sending
>> an
>>>>> email once in a while to keep the community informed, not to mention
>> the
>>>>> developers who presumably will be called upon to contribute to ZF2.
>>>> You're
>>>>> killing me here, guys.
>>>>>
>>>>
>>>> Absolutely agree. Personally, I think this is where the SVN/Git choice
>>>> made
>>>> early on in the ZF2 process really falls down, and the reason is their
>> main
>>>> difference: SVN is centralized, Git is not.
>>>>
>>>> With SVN everything that is committed is on the SVN server, and with
>> proper
>>>> branch structuring it should be easy to find and dive into someone
>> else's
>>>> branch to see what they are working on. I know that may be
>> oversimplfying
>>>> the lay of the land, as SVN has it's own challenges, but in theory it
>>>> works. The only thing we can't see in SVN is the uncommitted files the
>>>> branch owner has in his/her working copy. (but if you belive the addage
>>>> "work that isn't committed doesn't exist", or something like that, then
>>>> those files don't count)
>>>>
>>>> With Git, it's decentralization all the way, at the cost of a definitive
>>>> source by which we can measure progress. Right now ZF2 progress is
>> spread
>>>> across dozens (at least) of contributor's forks of the ZF2 github repo,
>>>> each with it's own branches tracking the fork owner's exploratory forays
>>>> from the existing source. Some contributors (like Matthew) are (or were)
>>>> doing exploratory work in their own private repos (on github or
>> elsewhere)
>>>> not inherently connected to the ZF2 github repo. On top of that, Git's
>>>> decentralized nature does introduce a lag in getting the "bleeding edge"
>>>> out
>>>> there; committing changes from your local copy requires a concious
>> effort
>>>> to
>>>> also push those changes up to your ZF2 fork before they are "out there"
>> for
>>>> those interested to see, and are still an accepted pull request away
>> from
>>>> being included in the definitive source for ZF2 code (the
>> zendframework/zf2
>>>> github repo), where most of the interested people would go to find the
>>>> latest ZF2 code. I'm not saying git was a bad choice (my feeling is
>> quite
>>>> the opposite, actually), but that the sprawl of repositories, forks and
>>>> branches needs to organized properly in order to work well. The switch
>>>> from
>>>> SVN to Git greatly reduced the entry barrier for contributing to ZF2,
>> and
>>>> that is great, but it does introduce other issues that need to be
>>>> addressed.
>>>>
>>>>
>>>> As an example, a while back I added code to Zend_Locale to expose
>>>> defaultNumberSystem from CLDR (ZF-10728) and figured I would update ZF2
>>>> Zend\Locale to expose it as well. I forked ZF2 from github, added the
>>>> necessary code, and put in a pull request only to be told that the
>>>> Zend\Locale component in zendframework/zf2 was the wrong one; it was
>> being
>>>> refactored elsewhere (thomasweidner/zf2). There was no indication that
>> the
>>>> Zend\Locale code in zendframework/zf2 is not the one I should be looking
>>>> at. It wasn't much work, so it didn't bother me, but that kind of
>>>> disconnect does put a damper on one's enthusiasm to contribute.
>>>>
>>>> This comes back around to something that I brought up in an earlier
>> mailing
>>>> list post: a "ZF2 status page", of sorts (see:
>>>>
>>>>
>> http://zend-framework-community.634137.n4.nabble.com/ZF2-feedback-td3620779.html
>>>> ).
>>>> Summary:
>>>>
>>>> I would like to see a ZF2 status page, on the wiki or elsewhere, where
>> we
>>>> can go to see when a particular component was last merged into official
>>>> repo
>>>>
>>>> and a link to the contributor fork(s) (if they are public) where the
>>>> bleeding-edge work is taking place. That would go a long way to helping
>>>> people like us get in early, watch the progress and offer feedback.
>>>>
>>>> Even if it was as simple as a wiki page with a section for each
>> component,
>>>> and under each section list the git repos where work is being done with
>> a
>>>> short summary of the purpose of each branch within. That would lower the
>>>> entry barrier (and frustration level for people like Pádraic ;)) to
>> diving
>>>> into ZF2. For instance, I could go to that page, look up Zend\Mvc (or
>>>> whatever the MVC package is), see that Matthew has two branches and
>> Ralph
>>>> has one where they are throwing out ideas around how the MVC should be
>>>> structured. Or, for another example, I could look up Zend\Soap, see that
>>>> nobody is working on it for ZF2, and throw my hat in the ring to take it
>>>> over. (disclaimer: those are examples for illustratory purposes, and may
>>>> or may not have a basis in reality)
>>>>
>>>> Again, my knowledge of Git and GitHub is not very extensive (and neither
>> is
>>>> my knowledge of how ZF2 development is being managed and steered), so if
>>>> i'm
>>>> missing something fundamental (like a "find all forks which have
>> modified a
>>>> particular file" feature, for instance) please let me know i'm offbase
>> with
>>>> my criticism and point out my errant way....i'll be eternally grateful
>> :)
>>>>
>>>>
>>>>> The reaction to this has already started. We've expressed our wish
>> that
>>>>> Zend Framework enter a more frequent major release cycle with Zend
>>>> Framework
>>>>> 3.0 potentially being released within 18 months. This would have a few
>>>>> impacts primarily requiring far closer collaboration with the
>> community
>>>>> because I can't see anyone so much as contemplating going through the
>> ZF2
>>>>> twiddling-thumbs experience again. We noticed and do remember that
>> there
>>>> was
>>>>> no concrete response to this from Zend and, believe me, we're already
>>>>> expecting the answer to be in the negative, but hey, at least put us
>> out
>>>> of
>>>>> our misery so we can plan ahead on what other projects to dedicate
>> time
>>>> to.
>>>>>
>>>>
>>>> This is one proposal/argument I at first supported, but have found
>> myself
>>>> coming around to the other side lately. I think that's down to version
>>>> fatigue now that Google Chrome and Mozilla Firefox are both <sarcasm>
>>>> pumping out new "major" versions every day </sarcasm>. It's a game of
>>>> major
>>>> version psychology meant to make a bigger deal out of something that
>> really
>>>> isn't. It doesn't affect the pace of outcome (ie: code, features), just
>>>> how
>>>> it's labelled. If you bump from v3.4 -> v3.5 no one really cares, but v3
>>>> ->
>>>> v4 people pay attention because historical use of the major version
>> number
>>>> indicated a major application change.
>>>>
>>>> But, I digress.
>>>>
>>>> I guess it really comes down to how ZF's managers plan to handle adding
>> new
>>>> features. Will it be like ZF1, where new features/components were added
>>>> seemingly at every minor (1.x) version? Or will there be a feature
>> freeze
>>>> between major versions, with only bugfixes between?
>>>>
>>>>
>>>>>
>>>>> This brings me to a final point. When everyone and their pet rabbit
>> was
>>>> in
>>>>> the belly of Zend Framework 1 writing source code and seeing proposals
>>>>> adopted which served the community well, there was no problem.
>> However,
>>>> Zend
>>>>> Framework 2 is exposing a lot of cracks in the open governance of the
>>>>> project. A lack of communication, lack of inclusiveness in decision
>>>> making,
>>>>> uncertainty over CLA legalities (for 3rd party licensed code), and a
>>>>> shortage of basic information like a timeline is an intolerable
>> situation
>>>>> for an open source project. It stymies the very objective of the open
>>>> source
>>>>> movement and this can turn into a very slippery slope, faster than
>> people
>>>>> might realise, towards a four letter word for a piece of cutlery.
>>>>>
>>>>> The worst of this situation is that there are professional programmers
>>>> who
>>>>> probably charge clients their first born child, per hour, sitting
>> around
>>>> on
>>>>> their bums bored silly with the current situation. Letting the
>> lifeblood
>>>> of
>>>>> Zend Framework go to waste for month after month is incomprehensible.
>>>> We're
>>>>> contributors not peer reviewers.
>>>>>
>>>>
>>>> I do understand that most ZF contributors are, like myself, volunteers.
>> I
>>>> do it because it gives me a warm, fuzzy feeling inside every time I get
>> to
>>>> mark a bug as "resolved". Some others do it because it's part of their
>>>> job,
>>>> or make a living off it in other ways, and so contribute back.
>> Regardless,
>>>> there has to be a certain level of pressure put on contributors to
>>>> contribute in a way that is conducive to a high-quality open source
>>>> project.
>>>>
>>>> In my mind, chief among those requirements should be that code isn't
>>>> developed in isolation; the repo(s) where code is being developed should
>> be
>>>> well known to the community (by that I mean information on them should
>> be
>>>> readily available to those who care to look into the wiki to find out)
>> and
>>>> there should be an avenue for offering comments and contributions to
>> them.
>>>> The current setup of git + github is very good for this, but it is
>>>> difficult
>>>> to get a meaningful overview of the extent of ZF2's progress towards
>>>> stability, or even work ongoing on a specific component.
>>>>
>>>> Also important is keeping "documentation" (unit tests, manual pages,
>> wiki
>>>> pages, docblocks, etc) up to date with the code. For instance, in ZF2
>>>> master, where the Zend\Di implementation is out of sync with the unit
>> tests
>>>> and manual sources. It took a bit of digging to find out that
>> setProperty
>>>> has changed to setParameters, and the signature was slightly different.
>>>> That change is mentioned in bug ZF2-42, and i'm willing to jump in and
>> fix
>>>> it, but am wary to do so with the possibility that it's already been
>> fixed
>>>> in a branch in someone's ZF2 fork. This comes back to my previous
>> comment
>>>> about a ZF2 status page and knowing where the bleeding edge is located.
>> (I
>>>> know I can just email the component manintainer to find out it's status,
>>>> but
>>>> that's extra bother and work on them, so I feel as though that kind of
>>>> information should recorded and availalble on the wiki).
>>>>
>>>> ------
>>>>
>>>> Now i'll apologize for rambling on and on (and on), and thank you for
>>>> reading all the way to the end :)
>>>>
>>
>
>
>
> --
> Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> *Zend Framework Community Review Team <http://framework.zend.com/>*

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

localheinz
In reply to this post by Kevin McArthur-2

>> but let's not leap right into surrender and
>> resignation as just a component library.
> +10,000

I'd like to see ZF kick some ass.

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A Rant From Mr. Grumpy on ZF2

robertbasic
In reply to this post by Adam Lundrigan
Please, keep the version numbering debate in it's own thread :)

On Sat, Aug 6, 2011 at 4:57 PM, Adam Lundrigan <[hidden email]> wrote:

>
> Ideally, any time a branch is created to work on a particular component,
> the
> contributor goes to the wiki, looks up the ZF2 status page for that
> component, and adds the URL to their new branch along with a short
> description of the work planned.


But also have links to that wiki page all over the place :) this would make
life much easier.

Don't know how well this wiki page is known
http://framework.zend.com/wiki/pages/viewpage.action?pageId=42303506 ? It
has some useful links already, please add more stuff to it :)

Pulling patches forward from ZF1 (and backporting from ZF2 to ZF1 where
> appropriate, as well) which were applied after the two repos split will
> need
> to be done, and will be an ongoing process up to the point in time where
> ZF1
> is declared end of life.  That's just the reality of having multiple major
> versions of your software out there.  This is one area where the community
> can really step up and do good, and it's one of the things I plan to do
> myself for ZF2.


For example I did this already for Zend\Dojo, it really isn't that scary and
can be done fairly easily. I don't think it took me more than 5 days to
completely tidy up Zend\Dojo and forward all the patches.

BTW, what happened to the community team? I know Paddy is in it, but who
else? Does that team still exist? Or was it assembled only to review new
proposals?

--
~Robert Basic;
http://robertbasic.com/
123
Loading...