Zend Framework

Hmm, you bring up an interesting point, but you do need to remember that once we get the mass changes done, it will be more manageable.

Bill is mentioned b/c he did the most recent global replacement for Zend::exception().

All in all, I am attempting to fix some of the standardization of code as well as doc block issues.. See ZF-691.

I personally like being able to see in the files who commited to which specific revision, its nearly as important as which revision that the file is a part of.

I think we should also streamline this page:
http://framework.zend.com/wiki/x/HCs [Who is Responsible for Each Component?]

Bill maintains a list off site in a spreadsheet that is far more comprehensive, and while that works for now, I think in the next 6 months or so we will take the advantages of Jira/Confluence to streamline this too.

Marking this as linked to 691 since it deals with docbook standardization.

Please see my post on the mailing list about standard docbooks and comment there, perhaps there is another file header we should be adding? perhaps a link to the wiki?

your thoughts?

linking

I know that Bill made the changes and why...

But I knew that before 1.5 it was said that no author list is added because otherwise xxx people would have been listed. Now we added the last committer, the things from before 0.15 are not related anymore. So foreign people can see who created a file. It is not clear that the last committer was not the author of the class...

Related to the "who commited which reason"... we have jira where to each SVN also the reason is added. So having the SVN version added would be enough in my opinion.

If we have the main authors of a class listed we could also leave the last bug hunter in the file.

Probable solutions are:

• Having the authors (normally there will be no more than 2 or 3 I think) added to the class header and let the committer as it is
• Having only a link to the wiki erasing the last committer - problem: not all classes have an own page/proposal in the wiki

Concerning subversion: I think the decision to use $Id$ was b/c it is a complex subversion keyword which will include name, date, time filename, and revision number, otherwise you have to add each piece manually. The idea of the $Id$ tag is that when you are working with something like Jira, or even another developer for that matter, you can look in the file to determine which revision it is that you are talking about, and once a bug is resolved / a patch is entered, you can have a milestone (in terms of a revision number) when that solution was introduced.

In any case, I would be against removing the $Id$ tag in the subversion, since technically, you are considered 'bleeding edge' when you decide to use it in production code. I would be encouraging people to be using the stable releases after version 1.0 hits.

That being said, I think the release procedure should include a global search an replace on the tagged subversion export to remove $Id$ and replace with the stable release number. I think that is the best approach. And while it is an internal procedure, should be noted in the coding standards.

As for tracking down who is suppose to be fixing what, Jira should take care of that when bugs are filed against a specific component.

thoughts?

It is a normal and common practice to include $Id$ in source code. We should keep it.

Regarding who edited each revision, this information is accessible in svn logs.

Regarding mistaken information about who created a class, this information was obscured anyway when mike imported the previous source code repository to subversion.