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
|

Re: A Rant From Mr. Grumpy on ZF2

Adam Lundrigan
>
> Please, keep the version numbering debate in it's own thread :)
>

Paddy started it! :P


> >
> > 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 :)
>
>
I did stumble upon that page recently, and am glad I did.



> 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.
>

I think it would help if we, the general masses of ZF developers, knew more
about the status of each component.  For instance, I've contemplated pulling
forward ZF1 patches into Zend\Soap, but I don't know which code base I
should do it against (ie: is Zend\Soap in zendframework/zf2 on github the
right one?).  Is that component scheduled for a major rewrite, which would
make my work moot?  I could contact the maintainer directly, but it would be
nice if that information is cataloged somewhere (as my previous replies to
this thread show).  More on that in a few minutes, in a separate email ;)


> 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?
>
>
A couple of weeks (months?) back there was an exchange on the mailing list
about how to notify those "in charge" of new patches ready to be reviewed
for inclusion into ZF1.  Ralph responded saying they were reviewing the
procedures for that and the role of the CR team in that respect and would
respond when ready.  I haven't heard back.


> --
> ~Robert Basic;
> http://robertbasic.com/
>
Reply | Threaded
Open this post in threaded view
|

Re: A Rant From Mr. Grumpy on ZF2

Adam Lundrigan
In reply to this post by Wil Moore III
To get the ball rolling on a "Component Status Page" thingy, I've created
this page with much help from Benoit Durand:

http://framework.zend.com/wiki/display/~adamlundrigan/Example+Development+Status+Page<http://framework.zend.com/wiki/display/%7Eadamlundrigan/Example+Development+Status+Page>

Comments?

Should I have created a separate sub-page for each component, and define a
template that each page should follow? (ie: like is done in ZFPROP)
(that would allow more flexibility in what can be included (ie: stuff like
links to slides/tutorials/blogposts for each component) without clutting the
single page too much)


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


On Sat, Aug 6, 2011 at 12:43 PM, Wil Moore III <[hidden email]>wrote:

> >
> > 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).
>
Reply | Threaded
Open this post in threaded view
|

Re: A Rant From Mr. Grumpy on ZF2

robertbasic
In reply to this post by Adam Lundrigan
This might be slightly off-topic, but would it make sense to add more people
to the zendframework organisation on Github, so they could help out in,
among other things, reviewing and accepting pull requests? For example, add
the community review team, or each component maintainer, so each component
maintainer can accept pull requests for their own components. I think that
would help Matthew a lot. For example, the majority of currently open pull
requests are about Locale/Translate stuff and are opened by Thomas, who is,
AFAIK, the leader of said components. If he would be a member of the
organisation he could merge those pull requests on his own.

The only thing that I see which can step in the way to this is the fact that
the github repo is only a mirror of the original repo.

Thoughts?

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|

Re: A Rant From Mr. Grumpy on ZF2

Pádraic Brady
In reply to this post by Adam Lundrigan
Hi Adam,

It's important to put your second point in context. We discussed Zend's
approach 14 months ago in May/June 2010 and it ended with Zend heading off
to do prototypes. Prototypes do not require 14 months of development and
that's the fallacy of this whole situation. Zend are not releasing
prototypes. They are releasing betas. This means the community has been
excluded for some unknown reason out of the very process they expected to be
involved in. We won't be brainstorming, experimenting, proposing or debating
the finer points of API preferences to arrive at a community consensus.
We'll be peer reviewing what Zend intend to release in a matter of months of
us getting sight of it. I could be wrong. Doubt it though.

P.S. Let's all put responses unrelated to the topic of my rant into new
threads please. We're diluting the topic for others and I hear Robert Basic
will hunt down offenders ;).

Paddy


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

> 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/>*
> > >
> >
>



--
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
|

Re: A Rant From Mr. Grumpy on ZF2

robertbasic
In reply to this post by Adam Lundrigan
On Sat, Aug 6, 2011 at 9:21 PM, Adam Lundrigan <[hidden email]> wrote:

> To get the ball rolling on a "Component Status Page" thingy, I've created
> this page with much help from Benoit Durand:
>
>
> http://framework.zend.com/wiki/display/~adamlundrigan/Example+Development+Status+Page
> <
> http://framework.zend.com/wiki/display/%7Eadamlundrigan/Example+Development+Status+Page
> >
>
> Comments?
>
> Should I have created a separate sub-page for each component, and define a
> template that each page should follow? (ie: like is done in ZFPROP)
> (that would allow more flexibility in what can be included (ie: stuff like
> links to slides/tutorials/blogposts for each component) without clutting
> the
> single page too much)
>
>
This looks great! I'd leave the single overview page and add separate
sub-pages on a per need basis.

/me goes and adds info on Zend\Dojo

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|

Re: A Rant From Mr. Grumpy on ZF2

Artur Bodera
In reply to this post by Pádraic Brady
On Sat, Aug 6, 2011 at 9:30 PM, Pádraic Brady <[hidden email]>wrote:

> Prototypes do not require 14 months of development and
> that's the fallacy of this whole situation.

 P.S. Let's all put responses unrelated to the topic of my rant into new

 threads please. We're diluting the topic for others and I hear Robert Basic
> will hunt down offenders ;).
>

+1 to that
Our ideas around code organisation might or might not be implemented, but we
are moving away from the main topic - which is: stagnation mixed with chaos
with a hint of community disappointment. Dear leaders, please keep in mind
that we, "contributors" are representatives of the community (and avid ZF
users). Which means, that if there are 3 people on this list rambling about
problem X, this means there are at least 3000 other anonymous ZF users
who concur but have no voice here. They will just go on and download
symphony2 :-)

A.
Reply | Threaded
Open this post in threaded view
|

Re: A Rant From Mr. Grumpy on ZF2

Artur Bodera
In reply to this post by Adam Lundrigan
>
> 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.
>

If you want to see other people's work -- go to ZF2 on github and click
[FORKS] in upper right corner. That does the trick.

Branching in SVN and viewing in websvn is basically the same thing, but
github is better in many ways (i.e. I'd rather see Matthew or Ralph using
their brain cells getting DI polished than constantly maintaining 10's of
svn accounts, resetting passwords, setting acls, etc).

Your idea is fine with 20 contributors. You can click through WebSVN, browse
and do what you said you'd do... but how about 10.000? that would mean
30.000 branches in centralized svn. Forget it :-) That's why small and large
OS projects so eagerly move to github, because of its (not very unique)
ability to accommodate larger number of random (i.e. not-associated)
developers forking, fixing bugs and bringing in new features.

What you've brought up, again and again, is *organisation* - i.e. knowing
who does what and what's current progress. Not svn nor git gives you that
out of the box - that's where Jira comes into play.

I believe we have all the toys we need.
But we just sit in the sandbox staring at each other doing nothing.

A.
Reply | Threaded
Open this post in threaded view
|

Re: A Rant From Mr. Grumpy on ZF2

Pádraic Brady
I think we need to be careful discussing git - back in the day we'd develop
a component outside of Zend Framework until it reached a point where adding
it to the incubator made sense. Where it was developed beforehand was on a
PC or possibly a public SVN repository. With git, we've entered a period of
programming where we expect to see practically ALL works in progress on
Github because it's so damn easy to put it up there. With SVN, that
expectation wasn't so prevelant and the existence of a public repository was
more of a function of the implementaiton-oriented proposal process. So, in a
sense, there isn't an organisational problem with how the source code is
managed at all (barring the stuff that doesn't exist yet!). Presumably, once
WIPs are sufficiently complete to warrant wider use and testing, Matthew
will integrate them fully into the central ZF2 repo as a branch.

Also remember that much of ZF2 is currently categorised as refactoring so
there isn't necessarily a proposal or a documentation trail to track those.
I saw the new status page being setup, and that looks like a solid step in
getting that information out to those looking for it.

Paddy

On Sat, Aug 6, 2011 at 9:16 PM, Artur Bodera <[hidden email]> wrote:

> >
> > 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.
> >
>
> If you want to see other people's work -- go to ZF2 on github and click
> [FORKS] in upper right corner. That does the trick.
>
> Branching in SVN and viewing in websvn is basically the same thing, but
> github is better in many ways (i.e. I'd rather see Matthew or Ralph using
> their brain cells getting DI polished than constantly maintaining 10's of
> svn accounts, resetting passwords, setting acls, etc).
>
> Your idea is fine with 20 contributors. You can click through WebSVN,
> browse
> and do what you said you'd do... but how about 10.000? that would mean
> 30.000 branches in centralized svn. Forget it :-) That's why small and
> large
> OS projects so eagerly move to github, because of its (not very unique)
> ability to accommodate larger number of random (i.e. not-associated)
> developers forking, fixing bugs and bringing in new features.
>
> What you've brought up, again and again, is *organisation* - i.e. knowing
> who does what and what's current progress. Not svn nor git gives you that
> out of the box - that's where Jira comes into play.
>
> I believe we have all the toys we need.
> But we just sit in the sandbox staring at each other doing nothing.
>
> A.
>



--
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
|

Re: A Rant From Mr. Grumpy on ZF2

Marc Bennewitz (private)
In reply to this post by Pádraic Brady
For ZF I really like way to version it in base of bc breaks.
mini   = fixes only
minor = fixes + new features
major = fixes + new features + bc break

The questing is how important is the bc break to ship a new major version.
This would need some discussions and rules.
For me:
 - min. supported version of PHP will no longer be supported by PHP
 - a new version of PHP will be incompatible
 - Security-Fix needs a bc-break
 - Fixes without a workaround needs bc-break
 - new functionalities needs a bc-break and are marked as a required feature
 - new functionalities doesn't work with min. supported version of PHP
and are marked as a required feature

Greetings
Marc

On 06.08.2011 16:34, Pádraic Brady 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 :)
>>>>
>
>

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


Reply | Threaded
Open this post in threaded view
|

Re: A Rant From Mr. Grumpy on ZF2

Alex Major
In reply to this post by robertbasic
On Sat, Aug 6, 2011 at 8:26 PM, Robert Basic <[hidden email]>wrote:

> This might be slightly off-topic, but would it make sense to add more
> people
> to the zendframework organisation on Github, so they could help out in,
> among other things, reviewing and accepting pull requests? For example, add
> the community review team, or each component maintainer, so each component
> maintainer can accept pull requests for their own components. I think that
> would help Matthew a lot. For example, the majority of currently open pull
> requests are about Locale/Translate stuff and are opened by Thomas, who is,
> AFAIK, the leader of said components. If he would be a member of the
> organisation he could merge those pull requests on his own.
>
> The only thing that I see which can step in the way to this is the fact
> that
> the github repo is only a mirror of the original repo.
>
> Thoughts?
>
> --
> ~Robert Basic;
> http://robertbasic.com/
>

Hi Robert & all,

I don't see the need to give every component maintainer access to the ZF
Github organisation. The whole reason git was conceived was around handling
large projects with many people working towards it through a chain of trust.
The idea was that Linus had people he trusted looking after components that
they knew much more about, and he would only allow those people to change
code to those components. When they submitted patches for certain components
he knew that the code quality was right, it had been validated to work and
any Kernel requirements had been met. He wouldn't need to check the commits
nor did he care whether the component maintainer himself had done them or
they had been merged from XYZ.

With Zend we have component maintainers who are responsible for those
components. I would suggest that any code for a component only gets added by
the component maintainer; If I want to submit a path for Zend\Local then I
submit a pull request to the Zend\Local maintainer who reviews it and merges
it - they then submit a pull request to the zf2 repo. This way, Matthew (or
whoever) can quite quickly process pull requests as they are all known to
have come from pre-qualified sources. Any pull request which is opened by a
non component maintainer for a component should be redirected to the
maintainers repo. This is the model I've worked with in the past on open
source projects and means that the person at the centre doesn't need to be
expert in every bit; he can delegate that trust further down the chain.

There are only two problems that I can think of:

1) Zend has (annoying) CLA requirements. All code has to come from people
who have signed a CLA - the component maintainer who need to validate the
person who has submitted the pull request. I'm not sure whether it has to be
Matthew or a Zend official who stamps each pull request. If Matthew has to
review the request each and every time then it defeats the purpose of the
git model.

2) Inactive component maintainers - this would only exacerbation problems in
Inactive component maintainers as no further work could be done a component.
This should be handled anyway and I don't see it as a problem of the
workflow in mind.

On the broader topic of zf2, I'd like to provide my insights as a Zend user
that had an interest in becoming a contributor.

The whole zf2 road has been ridiculously slow. I have been trying to follow
discussions but I can't be an active IRC user - therefore I watch the zf2
github repo, the wiki, the mailing lists, follow Matthew / Ralph on twitter,
slideshare, follow Zend / PHP conferences. But I couldn't tell you what was
done, which components were ported, what the MVC will look like, when a beta
was likely.

The wiki is perhaps the most frustrating part; its just one big dead end. (I
would like to have been able to link to specific threads but its once again
throwing 502 proxy errors; a separate issue but the Wiki has been down every
other day this week and very regularly over the last month.)

The wiki was dead in terms of activity at the start of this year, then there
was a re-sort of zf2 topics, a 2 week set of activity and then dead after
March. Then there was the topic "MVC Initial brainstorm" from May / June;
there was a 10 day burst of activity on it which was incredible to read and
very encouraging. Some really good ideas both in the initial requirement set
by Matthew and the 90 odd comments. I was particularly pleased as the April
beta target had been missed, but it really felt like there was interest in
getting things back on track. Since then, it has once again completely died;
no firm MVC proposal (how can we be talking about a prototype if we haven't
got to a firm MVC proposal?) and there has been very little discussion
(barely one or two comments a week) around any zf2 topics. There are
numerous zf2 proposals scattered around the general ZendFramework area
outside of the zf2 section, and a lot of the topics in the zf2 zone were
started in early 2010; they don't reflect any of the spirit or purpose of
the ZF2 rewrite in my opinion. As someone outside of IRC, it honestly does
not feel like there is an active push towards zf2 at all; too much talk
about what will be on the other side of the bridge but no one actually
looking at the bridge itself. Once Holidays end we have meetings scheduled
to talk about moving parts of the application away from Zend because the
team just doesn't see any end in sight.

The lack of visible activity in any coordinated manner really does not
reflect well on the Zend Framework at all. It's extremely frustrating to be
working amongst developers who are interested in Frameworks but constantly
disregard Zend. There was an expectation of a beta last year, then April
this year was much talked about and at this rate I'd barely expect one
before December. We've been in the MVC stage for months, yet haven't got
past brainstorming?

We use Zend in a large scale application alongside Cassandra. I submit
patches to Cassandra and PHP amongst others regularly, and I'm exactly the
kind of person that would commit to Zend. We built a whole Zend\Cassandra
component around Match/April and use it in production, but we're in a limbo
around submitting it. It's namespaced and uses PHP 5.3 only features so it
can't be submitted as a proposal against zf1, but until we have some clue
around Zend\Cache, Zend\Thrift (which is a nice proposal in formation) and
co, we're not making moves to start the proposal process. We have no
interest in trying to hit a constantly moving target.

Personally, I would like to see firm proposals with prototypes (in the sense
that Padraic spoke of, unpolished and open for changes) for all of the core
set of functionality (MVC, Cache, etc.) within the next week or two. That
way more general components can start to get an idea about what they might
look like. We work for a couple of weeks refining the prototypes until a
freeze date where we push out a complete zf2 beta.

I also fully support all of Padraics' comments around how to manage the
project/community going forward with the exception of his points around git.
If the "prototype" MVC we get isn't really a prototype then I really do
wonder what the purpose of having the community are. It *almost* feels as if
its a "Zend will look after the important bits and you can just add extra
components for us so that we have a bigger package to sell" situation.

Alex.
Reply | Threaded
Open this post in threaded view
|

Re: A Rant From Mr. Grumpy on ZF2

weierophinney
Administrator
In reply to this post by Wil Moore III
-- Wil Moore III <[hidden email]> wrote
(on Friday, 05 August 2011, 01:01 PM -0600):
> 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).

One key differentiator between Symfony and ZF is not related to code,
but to process: we utilize a CLA. The reasons for this are not relevant
for many, but for those living in countries with strong Intellectual
Property laws, it can be a make-or-break issue. I've spoken to a number
of developers and companies where one key reason for adopting ZF has
been the combination of BSD+CLA -- BSD by itself would not pass their
legal requirements.

So, it's not as easy as saying, "let's use another project's MVC." That
project must _also_ utilize CLAs as part of their process.

--
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
|

Re: A Rant From Mr. Grumpy on ZF2

weierophinney
Administrator
In reply to this post by Alex Major
-- Alex Major <[hidden email]> wrote
(on Sunday, 07 August 2011, 11:58 PM +0100):
> On Sat, Aug 6, 2011 at 8:26 PM, Robert Basic <[hidden email]>wrote:
> 1) Zend has (annoying) CLA requirements. All code has to come from people
> who have signed a CLA - the component maintainer who need to validate the
> person who has submitted the pull request. I'm not sure whether it has to be
> Matthew or a Zend official who stamps each pull request. If Matthew has to
> review the request each and every time then it defeats the purpose of the
> git model.

It's actually really easy. In most cases, I know the author, and can
simply apply the patch. In the cases I don't, it takes a few seconds to
lookup. In the case that somebody has merged code from a non-CLA'd
author, when I attempt to push to our master repository, we have a
pre-receive hook that will catch this, which allows me to back out the
changes on my local branch and notify the person who gave me the pull
request.

The other nice thing about this process is that I find I'm doing much
more active code review than I've traditionally done in ZF1, which helps
ensure better cohesion.

--
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
|

Re: A Rant From Mr. Grumpy on ZF2

padraicb


Sent from my iPhone

On 8 Aug 2011, at 14:56, Matthew Weier O'Phinney <[hidden email]> wrote:

> -- Alex Major <[hidden email]> wrote
> (on Sunday, 07 August 2011, 11:58 PM +0100):
>> On Sat, Aug 6, 2011 at 8:26 PM, Robert Basic <[hidden email]>wrote:
>> 1) Zend has (annoying) CLA requirements. All code has to come from people
>> who have signed a CLA - the component maintainer who need to validate the
>> person who has submitted the pull request. I'm not sure whether it has to be
>> Matthew or a Zend official who stamps each pull request. If Matthew has to
>> review the request each and every time then it defeats the purpose of the
>> git model.
>
> It's actually really easy. In most cases, I know the author, and can
> simply apply the patch. In the cases I don't, it takes a few seconds to
> lookup. In the case that somebody has merged code from a non-CLA'd
> author, when I attempt to push to our master repository, we have a
> pre-receive hook that will catch this, which allows me to back out the
> changes on my local branch and notify the person who gave me the pull
> request.
>
> The other nice thing about this process is that I find I'm doing much
> more active code review than I've traditionally done in ZF1, which helps
> ensure better cohesion.
>
> --
> 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]
>
>

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


Reply | Threaded
Open this post in threaded view
|

Re: A Rant From Mr. Grumpy on ZF2

Pádraic Brady
In reply to this post by weierophinney
Hi Matthew,
To everyone else - apparently tired fingers + phone = blank emails ;).
Sorry.

>One key differentiator between Symfony and ZF is not related to code,
>but to process: we utilize a CLA. The reasons for this are not relevant
>for many, but for those living in countries with strong Intellectual
>Property laws, it can be a make-or-break issue. I've spoken to a number
>of developers and companies where one key reason for adopting ZF has
>been the combination of BSD+CLA -- BSD by itself would not pass their
>legal requirements.
>
>So, it's not as easy as saying, "let's use another project's MVC." That
>project must _also_ utilize CLAs as part of their process.

A quick comment, because people tend to confuse to two, is that the CLA
doesn't prohibit dependencies on other projects but only the reuse of source
code from those projects. Additional limitations beyond that are, to the
best of my knowledge, Zend's company policy.

In other words, we still don't know what limitations are in effect. We have
a nebulous "do not use" policy that needs to be clarified once and for all.

For example, if I created \Starship\Enterprise with a dependency on
\Symfony\Torpedoes\Photon, commited that code (valid under CLA) and added an
install script for \Symfony\Torpedoes to the downloadable archive (or an
optional dependency under PEAR) - how many invisible rules did I just break?

Paddy

On Mon, Aug 8, 2011 at 2:24 PM, Matthew Weier O'Phinney <[hidden email]>wrote:

> -- Wil Moore III <[hidden email]> wrote
> (on Friday, 05 August 2011, 01:01 PM -0600):
> > 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).
>
> One key differentiator between Symfony and ZF is not related to code,
> but to process: we utilize a CLA. The reasons for this are not relevant
> for many, but for those living in countries with strong Intellectual
> Property laws, it can be a make-or-break issue. I've spoken to a number
> of developers and companies where one key reason for adopting ZF has
> been the combination of BSD+CLA -- BSD by itself would not pass their
> legal requirements.
>
> So, it's not as easy as saying, "let's use another project's MVC." That
> project must _also_ utilize CLAs as part of their process.
>
> --
> 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]
>
>
>


--
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
|

Re: A Rant From Mr. Grumpy on ZF2

Wil Moore III
In reply to this post by weierophinney
> So, it's not as easy as saying, "let's use another project's MVC."
> That project must _also_ utilize CLAs as part of their process.
>

So when people on the outside ask why we have so many similar MVC
implementations, would it be accurate to say?:

ZF MVC is less about additional MVC competition (though it could be a side
effect) but more about providing an MVC implementation that is compatible
with the strictest of legal requirements.
--
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
|

Re: A Rant From Mr. Grumpy on ZF2

weierophinney
Administrator
In reply to this post by Pádraic Brady
-- Pádraic Brady <[hidden email]> wrote
(on Monday, 08 August 2011, 04:19 PM +0100):

> > One key differentiator between Symfony and ZF is not related to code,
> > but to process: we utilize a CLA. The reasons for this are not relevant
> > for many, but for those living in countries with strong Intellectual
> > Property laws, it can be a make-or-break issue. I've spoken to a number
> > of developers and companies where one key reason for adopting ZF has
> > been the combination of BSD+CLA -- BSD by itself would not pass their
> > legal requirements.
> >
> > So, it's not as easy as saying, "let's use another project's MVC." That
> > project must _also_ utilize CLAs as part of their process.
>
> A quick comment, because people tend to confuse to two, is that the CLA
> doesn't prohibit dependencies on other projects but only the reuse of source
> code from those projects. Additional limitations beyond that are, to the
> best of my knowledge, Zend's company policy.
>
> In other words, we still don't know what limitations are in effect. We have
> a nebulous "do not use" policy that needs to be clarified once and for all.

The CLA applies to code we _ship_ in Zend Framework, not code built on
top of it.

It allows us to _link_ to non-CLA'd code (examples: Zend\Config\Yaml can
use sfYaml, Zend_Http_UserAgent can consume WURFL, ZendX_Jquery can
provide code generation and interop with jQuery, etc.).

Basically, this allows us to provide adapters, bridges, etc. that depend
on third-party code, but not to ship that third-party code, unless it
also falls under a compatible CLA. (This is why we can ship Dojo, but
not jQuery.)

> For example, if I created \Starship\Enterprise with a dependency on
> \Symfony\Torpedoes\Photon, commited that code (valid under CLA) and
> added an install script for \Symfony\Torpedoes to the downloadable
> archive (or an optional dependency under PEAR) - how many invisible
> rules did I just break?

None. :) We did similarly with WURFL for Zend_Http_UserAgent (minus the
script for automatically downloading the WURFL library -- but we link to
it in the manual).

The only caveat is that we try to keep dependencies to third-party
libraries optional whenever possible (e.g., Zend_Config_Yaml has a
limited internal parser; UserAgent provides adapters for device
detection; Queue has multiple adapters, etc.).

However, if the above fictional component were your own, and not part of
ZF's, this caveat doesn't even apply -- it's your own code, and the use
case is entirely covered by the BSD.

The point when it comes to the MVC, however, is that the MVC provides
core architecture for the framework -- this is what applications are
built on top of. So, having an MVC that falls under our CLA is fairly
critical to the framework.

--
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
|

Re: A Rant From Mr. Grumpy on ZF2

NickBelhomme
Hi all,

For me the main topic is: communication.

I have been trying to contribute and give feedback on various components.
Even tried to write some blog posts on the current implementations of those
same components, only to learn that I was targetting the wrong repo, because
I should have taken a look at another fork / branch...

These things break down my eagerness to contribute, write, even follow on a
daily basis...
Pressing the FORK button in github to see who has forked and done what is
not the way to go.

I do like the idea of the wiki page where as soon as one starts to implement
a feature, he/she posts it with the repo which will take that feature...

It provides easy tracking and avoids a lot of irritation on trying to find
the current status reading blog posts and repo checking. It shouldn't feel
like a scavengers hunt all the time...

I also like the initiative Paddy took by creating his mailing list
summary... It is a major step forward but it should be an official
representative providing even more high level detail (and not only
implementation details)...

my 50 cents
Nick

2011/8/8 Matthew Weier O'Phinney <[hidden email]>

> -- Pádraic Brady <[hidden email]> wrote
> (on Monday, 08 August 2011, 04:19 PM +0100):
> > > One key differentiator between Symfony and ZF is not related to code,
> > > but to process: we utilize a CLA. The reasons for this are not relevant
> > > for many, but for those living in countries with strong Intellectual
> > > Property laws, it can be a make-or-break issue. I've spoken to a number
> > > of developers and companies where one key reason for adopting ZF has
> > > been the combination of BSD+CLA -- BSD by itself would not pass their
> > > legal requirements.
> > >
> > > So, it's not as easy as saying, "let's use another project's MVC." That
> > > project must _also_ utilize CLAs as part of their process.
> >
> > A quick comment, because people tend to confuse to two, is that the CLA
> > doesn't prohibit dependencies on other projects but only the reuse of
> source
> > code from those projects. Additional limitations beyond that are, to the
> > best of my knowledge, Zend's company policy.
> >
> > In other words, we still don't know what limitations are in effect. We
> have
> > a nebulous "do not use" policy that needs to be clarified once and for
> all.
>
> The CLA applies to code we _ship_ in Zend Framework, not code built on
> top of it.
>
> It allows us to _link_ to non-CLA'd code (examples: Zend\Config\Yaml can
> use sfYaml, Zend_Http_UserAgent can consume WURFL, ZendX_Jquery can
> provide code generation and interop with jQuery, etc.).
>
> Basically, this allows us to provide adapters, bridges, etc. that depend
> on third-party code, but not to ship that third-party code, unless it
> also falls under a compatible CLA. (This is why we can ship Dojo, but
> not jQuery.)
>
> > For example, if I created \Starship\Enterprise with a dependency on
> > \Symfony\Torpedoes\Photon, commited that code (valid under CLA) and
> > added an install script for \Symfony\Torpedoes to the downloadable
> > archive (or an optional dependency under PEAR) - how many invisible
> > rules did I just break?
>
> None. :) We did similarly with WURFL for Zend_Http_UserAgent (minus the
> script for automatically downloading the WURFL library -- but we link to
> it in the manual).
>
> The only caveat is that we try to keep dependencies to third-party
> libraries optional whenever possible (e.g., Zend_Config_Yaml has a
> limited internal parser; UserAgent provides adapters for device
> detection; Queue has multiple adapters, etc.).
>
> However, if the above fictional component were your own, and not part of
> ZF's, this caveat doesn't even apply -- it's your own code, and the use
> case is entirely covered by the BSD.
>
> The point when it comes to the MVC, however, is that the MVC provides
> core architecture for the framework -- this is what applications are
> built on top of. So, having an MVC that falls under our CLA is fairly
> critical to the framework.
>
> --
> 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]
>
>
>


--
Nick Belhomme
Software Architect
(PHP5 Zend Certified Engineer +
Zend Framework Certified Engineer)
http://www.nickbelhomme.com
------------------------------
--------------------------------
For questions please phone or email me:
Phone number: +32 (0) 494 29 77 70
E-mail: [hidden email]

Profile: http://www.LinkedIn.com/in/nickbelhomme
Blog: http://blog.nickbelhomme.com
--------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: A Rant From Mr. Grumpy on ZF2

padraicb
My rant is going to cost me dearly in the next ML summary :(.

<Stares at all the new threads popping up> :P

On 10 Aug 2011, at 10:36, Nick Belhomme Software Architect <[hidden email]> wrote:

> Hi all,
>
> For me the main topic is: communication.
>
> I have been trying to contribute and give feedback on various components.
> Even tried to write some blog posts on the current implementations of those
> same components, only to learn that I was targetting the wrong repo, because
> I should have taken a look at another fork / branch...
>
> These things break down my eagerness to contribute, write, even follow on a
> daily basis...
> Pressing the FORK button in github to see who has forked and done what is
> not the way to go.
>
> I do like the idea of the wiki page where as soon as one starts to implement
> a feature, he/she posts it with the repo which will take that feature...
>
> It provides easy tracking and avoids a lot of irritation on trying to find
> the current status reading blog posts and repo checking. It shouldn't feel
> like a scavengers hunt all the time...
>
> I also like the initiative Paddy took by creating his mailing list
> summary... It is a major step forward but it should be an official
> representative providing even more high level detail (and not only
> implementation details)...
>
> my 50 cents
> Nick
>
> 2011/8/8 Matthew Weier O'Phinney <[hidden email]>
>
>> -- Pádraic Brady <[hidden email]> wrote
>> (on Monday, 08 August 2011, 04:19 PM +0100):
>>>> One key differentiator between Symfony and ZF is not related to code,
>>>> but to process: we utilize a CLA. The reasons for this are not relevant
>>>> for many, but for those living in countries with strong Intellectual
>>>> Property laws, it can be a make-or-break issue. I've spoken to a number
>>>> of developers and companies where one key reason for adopting ZF has
>>>> been the combination of BSD+CLA -- BSD by itself would not pass their
>>>> legal requirements.
>>>>
>>>> So, it's not as easy as saying, "let's use another project's MVC." That
>>>> project must _also_ utilize CLAs as part of their process.
>>>
>>> A quick comment, because people tend to confuse to two, is that the CLA
>>> doesn't prohibit dependencies on other projects but only the reuse of
>> source
>>> code from those projects. Additional limitations beyond that are, to the
>>> best of my knowledge, Zend's company policy.
>>>
>>> In other words, we still don't know what limitations are in effect. We
>> have
>>> a nebulous "do not use" policy that needs to be clarified once and for
>> all.
>>
>> The CLA applies to code we _ship_ in Zend Framework, not code built on
>> top of it.
>>
>> It allows us to _link_ to non-CLA'd code (examples: Zend\Config\Yaml can
>> use sfYaml, Zend_Http_UserAgent can consume WURFL, ZendX_Jquery can
>> provide code generation and interop with jQuery, etc.).
>>
>> Basically, this allows us to provide adapters, bridges, etc. that depend
>> on third-party code, but not to ship that third-party code, unless it
>> also falls under a compatible CLA. (This is why we can ship Dojo, but
>> not jQuery.)
>>
>>> For example, if I created \Starship\Enterprise with a dependency on
>>> \Symfony\Torpedoes\Photon, commited that code (valid under CLA) and
>>> added an install script for \Symfony\Torpedoes to the downloadable
>>> archive (or an optional dependency under PEAR) - how many invisible
>>> rules did I just break?
>>
>> None. :) We did similarly with WURFL for Zend_Http_UserAgent (minus the
>> script for automatically downloading the WURFL library -- but we link to
>> it in the manual).
>>
>> The only caveat is that we try to keep dependencies to third-party
>> libraries optional whenever possible (e.g., Zend_Config_Yaml has a
>> limited internal parser; UserAgent provides adapters for device
>> detection; Queue has multiple adapters, etc.).
>>
>> However, if the above fictional component were your own, and not part of
>> ZF's, this caveat doesn't even apply -- it's your own code, and the use
>> case is entirely covered by the BSD.
>>
>> The point when it comes to the MVC, however, is that the MVC provides
>> core architecture for the framework -- this is what applications are
>> built on top of. So, having an MVC that falls under our CLA is fairly
>> critical to the framework.
>>
>> --
>> 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]
>>
>>
>>
>
>
> --
> Nick Belhomme
> Software Architect
> (PHP5 Zend Certified Engineer +
> Zend Framework Certified Engineer)
> http://www.nickbelhomme.com
> ------------------------------
> --------------------------------
> For questions please phone or email me:
> Phone number: +32 (0) 494 29 77 70
> E-mail: [hidden email]
>
> Profile: http://www.LinkedIn.com/in/nickbelhomme
> Blog: http://blog.nickbelhomme.com
> --------------------------------------------------------------

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


Reply | Threaded
Open this post in threaded view
|

Re: A Rant From Mr. Grumpy on ZF2

EvanDotPro
Hi all,

To supplement the wiki status page that Adam started on, I decided to
throw a little tool together using the GitHub API to help give a
picture of where exactly development is occurring in ZF2.

http://zf2.evan.pro/

It's not perfect yet, (it tries to guess the component based on info
in the commits, and only tracks a list of hand-picked forks for now)
but I have quite a few ideas on ways to improve the usefulness of a
tool like this. I'd love to hear what you guys think.

---
Evan Coury

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


Reply | Threaded
Open this post in threaded view
|

Re: A Rant From Mr. Grumpy on ZF2

Adam Lundrigan
@Evan

Love it!  I was picking away at building much the same tool, but it turns
out you've beaten me to it :P

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


On Wed, Aug 10, 2011 at 3:24 PM, Evan Coury <[hidden email]> wrote:

> Hi all,
>
> To supplement the wiki status page that Adam started on, I decided to
> throw a little tool together using the GitHub API to help give a
> picture of where exactly development is occurring in ZF2.
>
> http://zf2.evan.pro/
>
> It's not perfect yet, (it tries to guess the component based on info
> in the commits, and only tracks a list of hand-picked forks for now)
> but I have quite a few ideas on ways to improve the usefulness of a
> tool like this. I'd love to hear what you guys think.
>
> ---
> Evan Coury
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
123