Git Repository

[weierophinney]

This is the second follow-up to the discussions started last week.

It's taken a bit more time than I expected, mainly due to some
unexpected and un-planned-for differences between the testing setup I
had and what we actually have to work with on the ZF servers. (I'll just
say one word: CentOS.)

However, the Git repository is now created and ready to clone.

You can do so using the following:

    git clone git://git.zendframework.com/zf.git

For right now, we ask that you issue pull requests to myself, Ralph, or
Alex; you can do so using the zf-contributors mailing list, or direct
contact; whatever works best for you. When you do so, either do so by
using "git send-email" or indicating the URL of your repository and the
branch and/or revisions to pull.

If you want your changes pulled you also need to ensure that the
user.email configuration in your clone matches the email address with
which you are registered in JIRA. You can find full details here:

    http://short.ie/zf2-git-readme

If you want to track commits, you have three methods:

 * viewgit: http://git.zendframework.com/?a=summary&p=zf
 * RSS feed: http://git.zendframework.com/feeds/master.xml
 * Email: send an email to [hidden email]

We have a few TODOs left open with the Git repository:

 * Establishing a mirror on Github. I have a request in to the folks at
   Github currently, and hope we can make some arrangement very soon.

 * Establishing a read-only SVN repository mirroring ZF2 development

 * Establishing methodologies around including ZF2 in your Git projects.
   I have some ideas on this, and have one tested approach ready to
   implement if I can't find something simpler. Until the MVC is
   migrated to namespaces, however, this is not as imperative.

 * Splitting out the documentation into a separate repo (will make it
   potentially possible to license docs separately, and thus ease
   contributions)

If you want to be involved, now is the time! For right now, we
particularly encourage working on Service components (any that don't get
migrated to namespaces get axed, with a few exceptions), and non-MVC
components (the MVC components still need to be migrated to namespaces,
which is a task myself and my team will be doing over the next 2-3
weeks).

Ask around on the list or in IRC to find out who is working on what so
you can collaborate, and start feeding us patches!

Thanks everyone for your input and patience over the past few months,
and I look forward to your participation in ZF2 development!

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

[weierophinney]

-- Matthew Weier O'Phinney <[hidden email]> wrote
(on Thursday, 03 June 2010, 03:06 PM -0400):
<snip>
> If you want to be involved, now is the time! For right now, we
> particularly encourage working on Service components (any that don't get
> migrated to namespaces get axed, with a few exceptions), and non-MVC
> components (the MVC components still need to be migrated to namespaces,
> which is a task myself and my team will be doing over the next 2-3
> weeks).
>
> Ask around on the list or in IRC to find out who is working on what so
> you can collaborate, and start feeding us patches!

Just to clarify, as I've seen a few questions:

Read the README-DEV.txt to see what components have been migrated to
namespaces. Right now, this includes everything but the Zend_Service
components, the MVC, and components dependent on the MVC (Application,
Form, Navigation, etc.).

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

[padraicb]

Figured someone would mention it eventually, but would be worth noting somewhere that future fixes to SVN (ZF 1.0) will need to also be migrated to git if relevant. Not everyone is currently using git (or even PHP 5.3) so we could end up with some measure of drift, not only from carelessness (bound to happen until the change is more familiar) but also from commits where the committer isn't entirely sure how to shift gears from a SVN commit to porting the same change to namespaces and git.

The second question isn't urgent just yet - mainly I was wondering how we may handle some of the inevitable replacement of components. Contributors may wish to replace, drastically alter, or make less dramatic changes (all of them changing the API to some degree). Is there any advice to help us figure out where the cut-off point is before we need to create a new proposal? I'm concerned mainly with all the orphaned/unmaintained components - many of which have been adopted in the past week or two as you've probably noticed. They tend to have enough broken bits that it's really tempting to either overhaul it entirely (essentially a replacement) or start adding new features, API elements, etc (new stuff). Having some concensus on when to propose or carry on may avoid some confusion down the line when we start seeing changes nobody ever expected or heard of because they were done unilaterally to a degree.

Paddy

 

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

---

From: Matthew Weier O'Phinney <[hidden email]>
To: [hidden email]
Sent: Thu, June 3, 2010 8:24:36 PM
Subject: Re: [zf-contributors] Git Repository

-- Matthew Weier O'Phinney <[hidden email]> wrote
(on Thursday, 03 June 2010, 03:06 PM -0400):
<snip>
> If you want to be involved, now is the time! For right now, we
> particularly encourage working on Service components (any that don't get
> migrated to namespaces get axed, with a few exceptions), and non-MVC
> components (the MVC components still need to be migrated to namespaces,
> which is a task myself and my team will be doing over the next 2-3
> weeks).
>
> Ask around on the list or in IRC to find out who is working on what so
> you can collaborate, and start feeding us patches!

Just to clarify, as I've seen a few questions:

Read the README-DEV.txt to see what components have been migrated to
namespaces. Right now, this includes everything but the Zend_Service
components, the MVC, and components dependent on the MVC (Application,
Form, Navigation, etc.).

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

[weierophinney]

-- Pádraic Brady <[hidden email]> wrote
(on Thursday, 03 June 2010, 12:57 PM -0700):
> Figured someone would mention it eventually, but would be worth noting
> somewhere that future fixes to SVN (ZF 1.0) will need to also be migrated to
> git if relevant. Not everyone is currently using git (or even PHP 5.3) so we
> could end up with some measure of drift, not only from carelessness (bound to
> happen until the change is more familiar) but also from commits where the
> committer isn't entirely sure how to shift gears from a SVN commit to porting
> the same change to namespaces and git.

Yep -- I've merged from current trunk a few times already, and will do
so again in a couple weeks (can't promise anything before DPC is over!).
Development should continue in the subversion repository trunk for
bugfixes and merged to the release-1.10 branch as normal -- but for
functionality that's been postponed to 2.0 due to BC breaks, or for
doing refactors/rewrites, the git repo is the correct place.

> The second question isn't urgent just yet - mainly I was wondering how we may
> handle some of the inevitable replacement of components. Contributors may wish
> to replace, drastically alter, or make less dramatic changes (all of them
> changing the API to some degree). Is there any advice to help us figure out
> where the cut-off point is before we need to create a new proposal? I'm
> concerned mainly with all the orphaned/unmaintained components - many of which
> have been adopted in the past week or two as you've probably noticed. They tend
> to have enough broken bits that it's really tempting to either overhaul it
> entirely (essentially a replacement) or start adding new features, API
> elements, etc (new stuff). Having some concensus on when to propose or carry on
> may avoid some confusion down the line when we start seeing changes nobody ever
> expected or heard of because they were done unilaterally to a degree.

We've done a few rewrites/refactors already -- Zend\Session is
completely rewritten from scratch at this point (because I couldn't run
the tests before and after to verify the migration... and because it
severely needed it), Zend_Filter became two classes
(Zend\Filter\FilterChain and Zend\Filter\StaticFilter),
Zend_Validate became two classes (Zend\Validator\ValidatorChain and
Zend\Validator\StaticValidator), and a few other minor refactors also
occurred; we also introduced a "Zend\StdLib" namespace for items that we
feel will likely be used in a variety of locations, and Zend\SignalSlot
for adding cross-functional chains and concerns -- things we saw a need
for as we did the migrations, basically.

I would recommend that if you feel a rewrite or a significant refactor
is necessary, write up an informal proposal outlining the rationale, and
the planned API changes, and throw it up for comment on this list or the
wiki. (If posted on the wiki, post to the list to direct traffic there.)
This will give a paper trail for changes, so that we can help build a
migration document and/or tool.

Also, for that matter, please document any API changes in the
working/BC-Breaks.txt document.

> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> From: Matthew Weier O'Phinney <[hidden email]>
> To: [hidden email]
> Sent: Thu, June 3, 2010 8:24:36 PM
> Subject: Re: [zf-contributors] Git Repository
>
> -- Matthew Weier O'Phinney <[hidden email]> wrote
> (on Thursday, 03 June 2010, 03:06 PM -0400):
> <snip>
> > If you want to be involved, now is the time! For right now, we
> > particularly encourage working on Service components (any that don't get
> > migrated to namespaces get axed, with a few exceptions), and non-MVC
> > components (the MVC components still need to be migrated to namespaces,
> > which is a task myself and my team will be doing over the next 2-3
> > weeks).
> >
> > Ask around on the list or in IRC to find out who is working on what so
> > you can collaborate, and start feeding us patches!
>
> Just to clarify, as I've seen a few questions:
>
> Read the README-DEV.txt to see what components have been migrated to
> namespaces. Right now, this includes everything but the Zend_Service
> components, the MVC, and components dependent on the MVC (Application,
> Form, Navigation, etc.).
>
> --
> 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

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

[keith Pope-4]

On 3 June 2010 20:06, Matthew Weier O'Phinney <[hidden email]> wrote:

> This is the second follow-up to the discussions started last week.
>
> It's taken a bit more time than I expected, mainly due to some
> unexpected and un-planned-for differences between the testing setup I
> had and what we actually have to work with on the ZF servers. (I'll just
> say one word: CentOS.)
>
> However, the Git repository is now created and ready to clone.
>
> You can do so using the following:
>
>    git clone git://git.zendframework.com/zf.git
>
> For right now, we ask that you issue pull requests to myself, Ralph, or
> Alex; you can do so using the zf-contributors mailing list, or direct
> contact; whatever works best for you. When you do so, either do so by
> using "git send-email" or indicating the URL of your repository and the
> branch and/or revisions to pull.
>
> If you want your changes pulled you also need to ensure that the
> user.email configuration in your clone matches the email address with
> which you are registered in JIRA. You can find full details here:
>
>    http://short.ie/zf2-git-readme
>
> If you want to track commits, you have three methods:
>
>  * viewgit: http://git.zendframework.com/?a=summary&p=zf
>  * RSS feed: http://git.zendframework.com/feeds/master.xml
>  * Email: send an email to [hidden email]
>
> We have a few TODOs left open with the Git repository:
>
>  * Establishing a mirror on Github. I have a request in to the folks at
>   Github currently, and hope we can make some arrangement very soon.
>
>  * Establishing a read-only SVN repository mirroring ZF2 development
>
>  * Establishing methodologies around including ZF2 in your Git projects.
>   I have some ideas on this, and have one tested approach ready to
>   implement if I can't find something simpler. Until the MVC is
>   migrated to namespaces, however, this is not as imperative.
>
>  * Splitting out the documentation into a separate repo (will make it
>   potentially possible to license docs separately, and thus ease
>   contributions)
>
> If you want to be involved, now is the time! For right now, we
> particularly encourage working on Service components (any that don't get
> migrated to namespaces get axed, with a few exceptions), and non-MVC
> components (the MVC components still need to be migrated to namespaces,
> which is a task myself and my team will be doing over the next 2-3
> weeks).
>
> Ask around on the list or in IRC to find out who is working on what so
> you can collaborate, and start feeding us patches!

Have we got a list of what needs doing or probably more useful what
competents we should not touch for now :)

>
> Thanks everyone for your input and patience over the past few months,
> and I look forward to your participation in ZF2 development!
>
> --
> 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
>

--
------------
http://www.thepopeisdead.com

[Graham Anderson]

On Thursday 03 June 2010 21:06:16 Matthew Weier O'Phinney wrote:
>For right now, we ask that you issue pull requests to myself, Ralph, or
>Alex; you can do so using the zf-contributors mailing list, or direct
>contact; whatever works best for you. When you do so, either do so by
>using "git send-email" or indicating the URL of your repository and the
>branch and/or revisions to pull.

Fantastic, thanks for the work on this Matthew.

I would imagine many people/organisations will use a git service such as
github.com, clone the ZF git repo and then do a "git remote add" so that they
have a public facing repo for pull requests.

I was wandering if there's much interest in a short tutorial on how to setup
managed Git on a linux server/host using Gitosis. This would allow you to
setup a Git service and use this for your pull requests and for your own
development needs.

As we have made the move to Git, and I was a proponent of the change, I can at
least help out with trying to foster the ability of individuals and smaller
organisations to use Git in productive ways.

The benefits of self hosted git service are:
 
  - Easily configured and managed private/public Git service for multiple
    repositories & users
  - Managed, secure ACL for Git (ssh/key based access for private repos)
  - Users don't need a system account, access is defined in the Gitosis config
    and governed by the use of keys
  - Optionally public facing repos for pull requests/cloning
  - Save on the cost of using a git hosting service.


Cheers the noo,
Graham

[daFish]

Hello Matthew.

I like the option to receive updates via RSS. However, would it be possible to add some more information in the headline beside the hashkey, e.g.:

- commiter
- branch
- shortened hashkey (if possible)

And a second thing is the description text which is real cluttered without any newlines and such. Maybe this could also be solved or should I blame Pady for this as you mentioned on Twitter? ;)

All the best,
Marcus

[weierophinney]

-- keith Pope <[hidden email]> wrote
(on Thursday, 03 June 2010, 10:19 PM +0100):
> On 3 June 2010 20:06, Matthew Weier O'Phinney <[hidden email]> wrote:
> > Ask around on the list or in IRC to find out who is working on what so
> > you can collaborate, and start feeding us patches!
>
> Have we got a list of what needs doing or probably more useful what
> competents we should not touch for now :)

In the README-DEV.txt file, there's a checklist of components. Anything
that *has* a checkmark next to is is fair game for working on, as are
all Zend_Service components. :)

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

[weierophinney]

-- Graham Anderson <[hidden email]> wrote
(on Friday, 04 June 2010, 12:23 PM +0200):

> On Thursday 03 June 2010 21:06:16 Matthew Weier O'Phinney wrote:
> > For right now, we ask that you issue pull requests to myself, Ralph, or
> > Alex; you can do so using the zf-contributors mailing list, or direct
> > contact; whatever works best for you. When you do so, either do so by
> > using "git send-email" or indicating the URL of your repository and the
> > branch and/or revisions to pull.
>
> Fantastic, thanks for the work on this Matthew.
>
> I would imagine many people/organisations will use a git service such as
> github.com, clone the ZF git repo and then do a "git remote add" so that they
> have a public facing repo for pull requests.

Yes -- that's my own plan. :) (announcement forth-coming...)

> I was wandering if there's much interest in a short tutorial on how to setup
> managed Git on a linux server/host using Gitosis. This would allow you to
> setup a Git service and use this for your pull requests and for your own
> development needs.

There are a variety of them out there, both for gitosis and gitolite
(we're using gitolite currently). What is lacking is good documentation
on using hooks. The samples provided for pre/post-receive are incredibly
lacking in detail (in fact, there is no exemplar for pre-receive -- I
had to work that one out on my own). Also, there's not a lot of detail
about what the status of the repository is at any given point.

I plan to blog about my experiences soon, as I think they'd be quite
helpful for those who are self-hosting.

> As we have made the move to Git, and I was a proponent of the change, I can at
> least help out with trying to foster the ability of individuals and smaller
> organisations to use Git in productive ways.
>
> The benefits of self hosted git service are:
>  
>   - Easily configured and managed private/public Git service for multiple
>     repositories & users
>   - Managed, secure ACL for Git (ssh/key based access for private repos)

This was actually one of the big reasons we had for self-hosting --
though the ACLs were less important than ensuring CLA status (something
we've had to do manually by manually granting commit access to the SVN
repo). This will be a huge boon to us in the future, and solves a
barrier to contribution for us.

>   - Users don't need a system account, access is defined in the Gitosis config
>     and governed by the use of keys
>   - Optionally public facing repos for pull requests/cloning

Indeed!

>   - Save on the cost of using a git hosting service.

Well, githubis free for OSS projects, so I was less concerned with that.
But you're absolutely right -- for private projects, there is a monetary
cost to hosting elsewhere.

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

[Shaun Farrell]

Is there anyway to keep a checklist for who is working on what?  Sort of like a claim board so no efforts are duplicated?  Maybe we can do this in the wiki or a google doc?

just a thought

Shaun J. Farrell
Washington, DC

On Fri, Jun 4, 2010 at 7:55 AM, Matthew Weier O'Phinney <[hidden email]> wrote:

-- keith Pope <[hidden email]> wrote
(on Thursday, 03 June 2010, 10:19 PM +0100):

> On 3 June 2010 20:06, Matthew Weier O'Phinney <[hidden email]> wrote:

> > Ask around on the list or in IRC to find out who is working on what so
> > you can collaborate, and start feeding us patches!
>
> Have we got a list of what needs doing or probably more useful what
> competents we should not touch for now :)

In the README-DEV.txt file, there's a checklist of components. Anything
that *has* a checkmark next to is is fair game for working on, as are
all Zend_Service components. :)

--

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

[weierophinney]

-- Marcus Stöhr <[hidden email]> wrote
(on Friday, 04 June 2010, 01:34 PM +0200):
> I like the option to receive updates via RSS. However, would it be
> possible to add some more information in the headline beside the
> hashkey, e.g.:
>
> - commiter
> - branch
> - shortened hashkey (if possible)

How would you like to see this information presented, exactly? I can
make it happen...

> And a second thing is the description text which is real cluttered
> without any newlines and such. Maybe this could also be solved or
> should I blame Pady for this as you mentioned on Twitter? ;)

I'll look into it -- the body actually does have newlines, but I wonder
if it's being escaped as CDATA. I'll poke around.

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

[daFish]

Hello Matthew.

Am 04.06.2010 um 14:02 schrieb Matthew Weier O'Phinney:

> -- Marcus Stöhr <[hidden email]> wrote
> (on Friday, 04 June 2010, 01:34 PM +0200):
>> I like the option to receive updates via RSS. However, would it be
>> possible to add some more information in the headline beside the
>> hashkey, e.g.:
>>
>> - commiter
>> - branch
>> - shortened hashkey (if possible)
>
> How would you like to see this information presented, exactly? I can
> make it happen...
>

Example:

matthew || branch/zend_view_refactor || 6f4db368...

Something like that. Maybe others have also ideas about that.

- Marcus

[padraicb]

That's right, blame me ;). Maybe it is me. Newlines for RSS are going to be ignored most of the time anyway (XML newlines are just concatenated with spacing). Depending on the context, you could pass them in as HTML breaks (RSS descriptions can contain HTML).

 

Paddy
 

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

---

From: Marcus Stöhr <[hidden email]>
To: Zend Framework Contributors <[hidden email]>
Sent: Fri, June 4, 2010 12:34:12 PM
Subject: Re: [zf-contributors] Git Repository

Hello Matthew.

I like the option to receive updates via RSS. However, would it be possible to add some more information in the headline beside the hashkey, e.g.:

- commiter
- branch
- shortened hashkey (if possible)

And a second thing is the description text which is real cluttered without any newlines and such. Maybe this could also be solved or should I blame Pady for this as you mentioned on Twitter? ;)

All the best,
Marcus

[Dolf Schimmel]

> Is there anyway to keep a checklist for who is working on what?  Sort of
> like a claim board so no efforts are duplicated?  Maybe we can do this in
> the wiki or a google doc?
> just a thought
>

Which kinda is what we did already. You may want to check out this
page to see who plans on doing what:
http://framework.zend.com/wiki/display/ZFDEV2/Component+Maintainers .
Of course, you could always join us on Freenode #zftalk.dev (see
http://www.zftalk.com ).

Dolf
-- Freeaqingme

>
>
> On Fri, Jun 4, 2010 at 7:55 AM, Matthew Weier O'Phinney <[hidden email]>
> wrote:
>>
>> -- keith Pope <[hidden email]> wrote
>> (on Thursday, 03 June 2010, 10:19 PM +0100):
>> > On 3 June 2010 20:06, Matthew Weier O'Phinney <[hidden email]> wrote:
>> > > Ask around on the list or in IRC to find out who is working on what so
>> > > you can collaborate, and start feeding us patches!
>> >
>> > Have we got a list of what needs doing or probably more useful what
>> > competents we should not touch for now :)
>>
>> In the README-DEV.txt file, there's a checklist of components. Anything
>> that *has* a checkmark next to is is fair game for working on, as are
>> all Zend_Service components. :)
>>
>> --
>> 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
>
>

[weierophinney]

-- Pádraic Brady <[hidden email]> wrote
(on Friday, 04 June 2010, 06:29 AM -0700):
> That's right, blame me ;). Maybe it is me. Newlines for RSS are going to be
> ignored most of the time anyway (XML newlines are just concatenated with
> spacing). Depending on the context, you could pass them in as HTML breaks (RSS
> descriptions can contain HTML).

Maybe I'll run the body through nl2br, then.

> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> From: Marcus St hr <[hidden email]>
> To: Zend Framework Contributors <[hidden email]>
> Sent: Fri, June 4, 2010 12:34:12 PM
> Subject: Re: [zf-contributors] Git Repository
>
> Hello Matthew.
>
> I like the option to receive updates via RSS. However, would it be possible to
> add some more information in the headline beside the hashkey, e.g.:
>
> - commiter
> - branch
> - shortened hashkey (if possible)
>
> And a second thing is the description text which is real cluttered without any
> newlines and such. Maybe this could also be solved or should I blame Pady for
> this as you mentioned on Twitter? ;)
>
> All the best,
> Marcus

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

[padraicb]

If at all possible, utilise the checklist Dolf linked to. Folk should also be aware that seeing a name on the list for a component doesn't mean it's completely sealed up and needs no more contributors. If you want to assist with a component, just grab someone on IRC or email to see if they need assistance.

 

Paddy
 

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

---

From: Dolf Schimmel <[hidden email]>
To: Shaun Farrell <[hidden email]>
Cc: [hidden email]
Sent: Fri, June 4, 2010 2:50:40 PM
Subject: Re: [zf-contributors] Git Repository

> Is there anyway to keep a checklist for who is working on what?  Sort of
> like a claim board so no efforts are duplicated?  Maybe we can do this in
> the wiki or a google doc?
> just a thought
>

Which kinda is what we did already. You may want to check out this
page to see who plans on doing what:
http://framework.zend.com/wiki/display/ZFDEV2/Component+Maintainers .
Of course, you could always join us on Freenode #zftalk.dev (see
http://www.zftalk.com ).

Dolf
-- Freeaqingme

>
>
> On Fri, Jun 4, 2010 at 7:55 AM, Matthew Weier O'Phinney <[hidden email]>
> wrote:
>>
>> -- keith Pope <[hidden email]> wrote
>> (on Thursday, 03 June 2010, 10:19 PM +0100):
>> > On 3 June 2010 20:06, Matthew Weier O'Phinney <[hidden email]> wrote:
>> > > Ask around on the list or in IRC to find out who is working on what so
>> > > you can collaborate, and start feeding us patches!
>> >
>> > Have we got a list of what needs doing or probably more useful what
>> > competents we should not touch for now :)
>>
>> In the README-DEV.txt file, there's a checklist of components. Anything
>> that *has* a checkmark next to is is fair game for working on, as are
>> all Zend_Service components. :)
>>
>> --
>> 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
>
>

[Artem Stepin]

>> Is there anyway to keep a checklist for who is working on what?  Sort of
>> like a claim board so no efforts are duplicated?  Maybe we can do this in
>> the wiki or a google doc?
>> just a thought
>>
>>      
> Which kinda is what we did already. You may want to check out this
> page to see who plans on doing what:
> http://framework.zend.com/wiki/display/ZFDEV2/Component+Maintainers .
> Of course, you could always join us on Freenode #zftalk.dev (see
> http://www.zftalk.com ).
>
> Dolf
> -- Freeaqingme
>
>    

Maybe Google Wave is exactly what we need? It combines email, wiki and
irc ...
https://wave.google.com

[padraicb]

Hi Matthew,

Just to bring this up again, I guess what I was saying is that there is some confusion over how to keep ZF 1.0 and 2.0 fixes synchronised. There are a few factors I'm thinking about:

1. When exactly was the current git revision last synced to 1.0's svn trunk?
2. What is the policy on fixes being made currently to svn trunk, in order to port them into git?
3. Merging (automatically) won't be possible for components where in git there have been changes to class names, or other forms of drift.

You say you will merge from the svn trunk in the future, but is this even possible? It sounds likely to be a partly manual process which will be severely hindered by active development on 2.0.

On IRC, someone came up with some detective work that suggested git is currently synchronised to a svn trunk revision that is approx 1200 commits behind the current svn HEAD (no idea of the breakdown between docs/etc). If correct, that means git has a large maintenance deficit that will continue growing until we resolve exactly how to get fixes from svn to git as they occur. At present there's no indication of a requirement to port fixes across which is a little worrying. This also means all 2.0 components need to be re-synchronised before they can be actively developed in any meaningful way. Otherwise we run the risk of discouraging/putting off a recovery of the maintenance deficit to date since past commits may no longer even bear a resemblance to source code in git as it evolves.

Also, given the uncertainty over the last merge date, at least some of us are likely to take the more comprehensive route and simply re-port from SVN HEAD rather than worry about whether we can generate a proper interval patch capturing the changes necessary to catch up on the maintenance deficit in our components. I'm not necessarily worried about doing that since I was half expecting it anyway.

As I mentioned in the opening paragraph, it's a confusing situation. We have no idea if there are plans/tools/processes in place to mitigate the potential problems, or even if we should develop on git for anything unrelated to outright rewrites to allow for a future sync-up.

Paddy

 

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

---

From: Matthew Weier O'Phinney <[hidden email]>
To: Zend Framework Contributors <[hidden email]>
Sent: Thu, June 3, 2010 9:43:54 PM
Subject: Re: [zf-contributors] Git Repository

-- Pádraic Brady <[hidden email]> wrote
(on Thursday, 03 June 2010, 12:57 PM -0700):
> Figured someone would mention it eventually, but would be worth noting
> somewhere that future fixes to SVN (ZF 1.0) will need to also be migrated to
> git if relevant. Not everyone is currently using git (or even PHP 5.3) so we
> could end up with some measure of drift, not only from carelessness (bound to
> happen until the change is more familiar) but also from commits where the
> committer isn't entirely sure how to shift gears from a SVN commit to porting
> the same change to namespaces and git.

Yep -- I've merged from current trunk a few times already, and will do
so again in a couple weeks (can't promise anything before DPC is over!).
Development should continue in the subversion repository trunk for
bugfixes and merged to the release-1.10 branch as normal -- but for
functionality that's been postponed to 2.0 due to BC breaks, or for
doing refactors/rewrites, the git repo is the correct place.

> The second question isn't urgent just yet - mainly I was wondering how we may
> handle some of the inevitable replacement of components. Contributors may wish
> to replace, drastically alter, or make less dramatic changes (all of them
> changing the API to some degree). Is there any advice to help us figure out
> where the cut-off point is before we need to create a new proposal? I'm
> concerned mainly with all the orphaned/unmaintained components - many of which
> have been adopted in the past week or two as you've probably noticed. They tend
> to have enough broken bits that it's really tempting to either overhaul it
> entirely (essentially a replacement) or start adding new features, API
> elements, etc (new stuff). Having some concensus on when to propose or carry on
> may avoid some confusion down the line when we start seeing changes nobody ever
> expected or heard of because they were done unilaterally to a degree.

We've done a few rewrites/refactors already -- Zend\Session is
completely rewritten from scratch at this point (because I couldn't run
the tests before and after to verify the migration... and because it
severely needed it), Zend_Filter became two classes
(Zend\Filter\FilterChain and Zend\Filter\StaticFilter),
Zend_Validate became two classes (Zend\Validator\ValidatorChain and
Zend\Validator\StaticValidator), and a few other minor refactors also
occurred; we also introduced a "Zend\StdLib" namespace for items that we
feel will likely be used in a variety of locations, and Zend\SignalSlot
for adding cross-functional chains and concerns -- things we saw a need
for as we did the migrations, basically.

I would recommend that if you feel a rewrite or a significant refactor
is necessary, write up an informal proposal outlining the rationale, and
the planned API changes, and throw it up for comment on this list or the
wiki. (If posted on the wiki, post to the list to direct traffic there.)
This will give a paper trail for changes, so that we can help build a
migration document and/or tool.

Also, for that matter, please document any API changes in the
working/BC-Breaks.txt document.

> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> From: Matthew Weier O'Phinney <[hidden email]>
> To: [hidden email]
> Sent: Thu, June 3, 2010 8:24:36 PM
> Subject: Re: [zf-contributors] Git Repository
>
> -- Matthew Weier O'Phinney <[hidden email]> wrote
> (on Thursday, 03 June 2010, 03:06 PM -0400):
> <snip>
> > If you want to be involved, now is the time! For right now, we
> > particularly encourage working on Service components (any that don't get
> > migrated to namespaces get axed, with a few exceptions), and non-MVC
> > components (the MVC components still need to be migrated to namespaces,
> > which is a task myself and my team will be doing over the next 2-3
> > weeks).
> >
> > Ask around on the list or in IRC to find out who is working on what so
> > you can collaborate, and start feeding us patches!
>
> Just to clarify, as I've seen a few questions:
>
> Read the README-DEV.txt to see what components have been migrated to
> namespaces. Right now, this includes everything but the Zend_Service
> components, the MVC, and components dependent on the MVC (Application,
> Form, Navigation, etc.).
>
> --
> 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

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

[padraicb]

Do we need to update http://framework.zend.com/wiki/display/ZFDEV2/ZF+2.0+Coding+Standards+Addendums ?

A lot of stuff appears to mix or alter capitalisation. We have Zend\HTTP instead of Zend\Http, for example. I also located duplicate directory copies in several places where the capitalisation differs, e.g. Pubsubhubbub vs PubSubHubbub. I don't remember any changes being discussed about changing the current capitalisation rules, although I could have missed it.

I also note that the unit tests are not currently in a passing state. JSON is popping up with errors at the moment. Other components are triggering their own errors when attempting to run them alone. Some of this appear to be issues with path resolution when including files. Running Zend\Feed tests, for example, errors on an empty inclusion for some reason (locating the problem in a bit).

Couple the above with my prior email on SVN syncing, and I'm not sure I want to even touch code in here for a while. There's a lot of very brittle looking oddities I don't want to mess with until they're all clarified.

Paddy

 

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

---

From: Pádraic Brady <[hidden email]>
To: Matthew Weier O'Phinney <[hidden email]>
Cc: Zend Framework Contributors <[hidden email]>
Sent: Sat, June 5, 2010 2:28:55 PM
Subject: Re: [zf-contributors] Git Repository

Hi Matthew,

Just to bring this up again, I guess what I was saying is that there is some confusion over how to keep ZF 1.0 and 2.0 fixes synchronised. There are a few factors I'm thinking about:

1. When exactly was the current git revision last synced to 1.0's svn trunk?
2. What is the policy on fixes being made currently to svn trunk, in order to port them into git?
3. Merging (automatically) won't be possible for components where in git there have been changes to class names, or other forms of drift.

You say you will merge from the svn trunk in the future, but is this even possible? It sounds likely to be a partly manual process which will be severely hindered by active development on 2.0.

On IRC, someone came up with some detective work that suggested git is currently synchronised to a svn trunk revision that is approx 1200 commits behind the current svn HEAD (no idea of the breakdown between docs/etc). If correct, that means git has a large maintenance deficit that will continue growing until we resolve exactly how to get fixes from svn to git as they occur. At present there's no indication of a requirement to port fixes across which is a little worrying. This also means all 2.0 components need to be re-synchronised before they can be actively developed in any meaningful way. Otherwise we run the risk of discouraging/putting off a recovery of the maintenance deficit to date since past commits may no longer even bear a resemblance to source code in git as it evolves.

Also, given the uncertainty over the last merge date, at least some of us are likely to take the more comprehensive route and simply re-port from SVN HEAD rather than worry about whether we can generate a proper interval patch capturing the changes necessary to catch up on the maintenance deficit in our components. I'm not necessarily worried about doing that since I was half expecting it anyway.

As I mentioned in the opening paragraph, it's a confusing situation. We have no idea if there are plans/tools/processes in place to mitigate the potential problems, or even if we should develop on git for anything unrelated to outright rewrites to allow for a future sync-up.

Paddy

 

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

---

From: Matthew Weier O'Phinney <[hidden email]>
To: Zend Framework Contributors <[hidden email]>
Sent: Thu, June 3, 2010 9:43:54 PM
Subject: Re: [zf-contributors] Git Repository

-- Pádraic Brady <[hidden email]> wrote
(on Thursday, 03 June 2010, 12:57 PM -0700):
> Figured someone would mention it eventually, but would be worth noting
> somewhere that future fixes to SVN (ZF 1.0) will need to also be migrated to
> git if relevant. Not everyone is currently using git (or even PHP 5.3) so we
> could end up with some measure of drift, not only from carelessness (bound to
> happen until the change is more familiar) but also from commits where the
> committer isn't entirely sure how to shift gears from a SVN commit to porting
> the same change to namespaces and git.

Yep -- I've merged from current trunk a few times already, and will do
so again in a couple weeks (can't promise anything before DPC is over!).
Development should continue in the subversion repository trunk for
bugfixes and merged to the release-1.10 branch as normal -- but for
functionality that's been postponed to 2.0 due to BC breaks, or for
doing refactors/rewrites, the git repo is the correct place.

> The second question isn't urgent just yet - mainly I was wondering how we may
> handle some of the inevitable replacement of components. Contributors may wish
> to replace, drastically alter, or make less dramatic changes (all of them
> changing the API to some degree). Is there any advice to help us figure out
> where the cut-off point is before we need to create a new proposal? I'm
> concerned mainly with all the orphaned/unmaintained components - many of which
> have been adopted in the past week or two as you've probably noticed. They tend
> to have enough broken bits that it's really tempting to either overhaul it
> entirely (essentially a replacement) or start adding new features, API
> elements, etc (new stuff). Having some concensus on when to propose or carry on
> may avoid some confusion down the line when we start seeing changes nobody ever
> expected or heard of because they were done unilaterally to a degree.

We've done a few rewrites/refactors already -- Zend\Session is
completely rewritten from scratch at this point (because I couldn't run
the tests before and after to verify the migration... and because it
severely needed it), Zend_Filter became two classes
(Zend\Filter\FilterChain and Zend\Filter\StaticFilter),
Zend_Validate became two classes (Zend\Validator\ValidatorChain and
Zend\Validator\StaticValidator), and a few other minor refactors also
occurred; we also introduced a "Zend\StdLib" namespace for items that we
feel will likely be used in a variety of locations, and Zend\SignalSlot
for adding cross-functional chains and concerns -- things we saw a need
for as we did the migrations, basically.

I would recommend that if you feel a rewrite or a significant refactor
is necessary, write up an informal proposal outlining the rationale, and
the planned API changes, and throw it up for comment on this list or the
wiki. (If posted on the wiki, post to the list to direct traffic there.)
This will give a paper trail for changes, so that we can help build a
migration document and/or tool.

Also, for that matter, please document any API changes in the
working/BC-Breaks.txt document.

> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> From: Matthew Weier O'Phinney <[hidden email]>
> To: [hidden email]
> Sent: Thu, June 3, 2010 8:24:36 PM
> Subject: Re: [zf-contributors] Git Repository
>
> -- Matthew Weier O'Phinney <[hidden email]> wrote
> (on Thursday, 03 June 2010, 03:06 PM -0400):
> <snip>
> > If you want to be involved, now is the time! For right now, we
> > particularly encourage working on Service components (any that don't get
> > migrated to namespaces get axed, with a few exceptions), and non-MVC
> > components (the MVC components still need to be migrated to namespaces,
> > which is a task myself and my team will be doing over the next 2-3
> > weeks).
> >
> > Ask around on the list or in IRC to find out who is working on what so
> > you can collaborate, and start feeding us patches!
>
> Just to clarify, as I've seen a few questions:
>
> Read the README-DEV.txt to see what components have been migrated to
> namespaces. Right now, this includes everything but the Zend_Service
> components, the MVC, and components dependent on the MVC (Application,
> Form, Navigation, etc.).
>
> --
> 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

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

[padraicb]

Alright, Peter Kokx mentioned the capitalisation issue was discussed somewhere, so maybe I missed it. Can we add it to the addendum? Can I also clarify whether its compulsory - I want to avoid PubSubHubbub (it's bad enough as it was ;)) and having to capitalise all classes (e.g. when assigning a name to a class file name dynamically).

Paddy

 

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

---

From: Pádraic Brady <[hidden email]>
To: Pádraic Brady <[hidden email]>
Cc: Zend Framework Contributors <[hidden email]>
Sent: Sat, June 5, 2010 4:25:04 PM
Subject: [zf-contributors] Git Repo Issues

Do we need to update http://framework.zend.com/wiki/display/ZFDEV2/ZF+2.0+Coding+Standards+Addendums ?

A lot of stuff appears to mix or alter capitalisation. We have Zend\HTTP instead of Zend\Http, for example. I also located duplicate directory copies in several places where the capitalisation differs, e.g. Pubsubhubbub vs PubSubHubbub. I don't remember any changes being discussed about changing the current capitalisation rules, although I could have missed it.

I also note that the unit tests are not currently in a passing state. JSON is popping up with errors at the moment. Other components are triggering their own errors when attempting to run them alone. Some of this appear to be issues with path resolution when including files. Running Zend\Feed tests, for example, errors on an empty inclusion for some reason (locating the problem in a bit).

Couple the above with my prior email on SVN syncing, and I'm not sure I want to even touch code in here for a while. There's a lot of very brittle looking oddities I don't want to mess with until they're all clarified.

Paddy

 

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

---

From: Pádraic Brady <[hidden email]>
To: Matthew Weier O'Phinney <[hidden email]>
Cc: Zend Framework Contributors <[hidden email]>
Sent: Sat, June 5, 2010 2:28:55 PM
Subject: Re: [zf-contributors] Git Repository

Hi Matthew,

Just to bring this up again, I guess what I was saying is that there is some confusion over how to keep ZF 1.0 and 2.0 fixes synchronised. There are a few factors I'm thinking about:

1. When exactly was the current git revision last synced to 1.0's svn trunk?
2. What is the policy on fixes being made currently to svn trunk, in order to port them into git?
3. Merging (automatically) won't be possible for components where in git there have been changes to class names, or other forms of drift.

You say you will merge from the svn trunk in the future, but is this even possible? It sounds likely to be a partly manual process which will be severely hindered by active development on 2.0.

On IRC, someone came up with some detective work that suggested git is currently synchronised to a svn trunk revision that is approx 1200 commits behind the current svn HEAD (no idea of the breakdown between docs/etc). If correct, that means git has a large maintenance deficit that will continue growing until we resolve exactly how to get fixes from svn to git as they occur. At present there's no indication of a requirement to port fixes across which is a little worrying. This also means all 2.0 components need to be re-synchronised before they can be actively developed in any meaningful way. Otherwise we run the risk of discouraging/putting off a recovery of the maintenance deficit to date since past commits may no longer even bear a resemblance to source code in git as it evolves.

Also, given the uncertainty over the last merge date, at least some of us are likely to take the more comprehensive route and simply re-port from SVN HEAD rather than worry about whether we can generate a proper interval patch capturing the changes necessary to catch up on the maintenance deficit in our components. I'm not necessarily worried about doing that since I was half expecting it anyway.

As I mentioned in the opening paragraph, it's a confusing situation. We have no idea if there are plans/tools/processes in place to mitigate the potential problems, or even if we should develop on git for anything unrelated to outright rewrites to allow for a future sync-up.

Paddy

 

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

---

From: Matthew Weier O'Phinney <[hidden email]>
To: Zend Framework Contributors <[hidden email]>
Sent: Thu, June 3, 2010 9:43:54 PM
Subject: Re: [zf-contributors] Git Repository

-- Pádraic Brady <[hidden email]> wrote
(on Thursday, 03 June 2010, 12:57 PM -0700):
> Figured someone would mention it eventually, but would be worth noting
> somewhere that future fixes to SVN (ZF 1.0) will need to also be migrated to
> git if relevant. Not everyone is currently using git (or even PHP 5.3) so we
> could end up with some measure of drift, not only from carelessness (bound to
> happen until the change is more familiar) but also from commits where the
> committer isn't entirely sure how to shift gears from a SVN commit to porting
> the same change to namespaces and git.

Yep -- I've merged from current trunk a few times already, and will do
so again in a couple weeks (can't promise anything before DPC is over!).
Development should continue in the subversion repository trunk for
bugfixes and merged to the release-1.10 branch as normal -- but for
functionality that's been postponed to 2.0 due to BC breaks, or for
doing refactors/rewrites, the git repo is the correct place.

> The second question isn't urgent just yet - mainly I was wondering how we may
> handle some of the inevitable replacement of components. Contributors may wish
> to replace, drastically alter, or make less dramatic changes (all of them
> changing the API to some degree). Is there any advice to help us figure out
> where the cut-off point is before we need to create a new proposal? I'm
> concerned mainly with all the orphaned/unmaintained components - many of which
> have been adopted in the past week or two as you've probably noticed. They tend
> to have enough broken bits that it's really tempting to either overhaul it
> entirely (essentially a replacement) or start adding new features, API
> elements, etc (new stuff). Having some concensus on when to propose or carry on
> may avoid some confusion down the line when we start seeing changes nobody ever
> expected or heard of because they were done unilaterally to a degree.

We've done a few rewrites/refactors already -- Zend\Session is
completely rewritten from scratch at this point (because I couldn't run
the tests before and after to verify the migration... and because it
severely needed it), Zend_Filter became two classes
(Zend\Filter\FilterChain and Zend\Filter\StaticFilter),
Zend_Validate became two classes (Zend\Validator\ValidatorChain and
Zend\Validator\StaticValidator), and a few other minor refactors also
occurred; we also introduced a "Zend\StdLib" namespace for items that we
feel will likely be used in a variety of locations, and Zend\SignalSlot
for adding cross-functional chains and concerns -- things we saw a need
for as we did the migrations, basically.

I would recommend that if you feel a rewrite or a significant refactor
is necessary, write up an informal proposal outlining the rationale, and
the planned API changes, and throw it up for comment on this list or the
wiki. (If posted on the wiki, post to the list to direct traffic there.)
This will give a paper trail for changes, so that we can help build a
migration document and/or tool.

Also, for that matter, please document any API changes in the
working/BC-Breaks.txt document.

> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> From: Matthew Weier O'Phinney <[hidden email]>
> To: [hidden email]
> Sent: Thu, June 3, 2010 8:24:36 PM
> Subject: Re: [zf-contributors] Git Repository
>
> -- Matthew Weier O'Phinney <[hidden email]> wrote
> (on Thursday, 03 June 2010, 03:06 PM -0400):
> <snip>
> > If you want to be involved, now is the time! For right now, we
> > particularly encourage working on Service components (any that don't get
> > migrated to namespaces get axed, with a few exceptions), and non-MVC
> > components (the MVC components still need to be migrated to namespaces,
> > which is a task myself and my team will be doing over the next 2-3
> > weeks).
> >
> > Ask around on the list or in IRC to find out who is working on what so
> > you can collaborate, and start feeding us patches!
>
> Just to clarify, as I've seen a few questions:
>
> Read the README-DEV.txt to see what components have been migrated to
> namespaces. Right now, this includes everything but the Zend_Service
> components, the MVC, and components dependent on the MVC (Application,
> Form, Navigation, etc.).
>
> --
> 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

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