Re[2]: [PATCH] JUnit test for org.apache.geronimo.cache.SimpleInstanceCache

[Ed Letifov <e....@chello.nl>]

Hello Bruce,

EL>> Anyway, the test is in the attachment. As I said before: started with
EL>> the simplest, hope it helps.

BS> I can certainly commit this test as I'll be writing a bunch of these
BS> later tonight.

Thank you, but still, how does one submit multiple new files? As a jar
archive to achieve portability and preserve directory/package
structure?

Also,  for  the  future, should the @author tags be specified? I don't
mind  an  impersonal  collective  ownership  at all, but I can imagine
someone  bugging  you  someday,  since  you  will  be the one actually
performing commit.

BS>  However, I'd like to try to make a decision on what we're
BS> going to do to to determine spec coverage first. Although spec coverage
BS> is crucial, we also just need some simple test coverage of the existing
BS> code base.

Understood. I guess while you are making this decision having the simple test
coverage growing won't hurt?

BS> I'm wondering if there's a need for two kinds of tests - unit and
BS> spec. Of course, these two can be achieved in the same *Test.java files
BS> and separated simply by a comment line.

I personally like the 'separate spec test' idea more, but I have to
admit that a gut feeling exists that it will end up in the same files,
and moreover without that comment line.

-- 
Best regards,
 Ed                            mailto:e.letifov@chello.nl

Re: Author Tags

[Richard Monson-Haefel <Ri...@Monson-Haefel.com>]

Author tags in source code is a bad idea.  As many  have pointed out 
you can determine responsibility from cvs and give credit on a web 
page.  To me, its important that the entire community feels that they 
have ownership (responsibility and credit) for all the code. That's 
what open source is all about, after all.  Author tags serve no other 
purpose, IMO, than to give a developer bragging rights to some portion 
of the project.  A credits page would be a much more effective 
instrument for giving credit.

On Tuesday, August 12, 2003, at 02:17  AM, Jason Dillon wrote:

>> Code responsibility means that even though anyone may leap in and 
>> hack on
>> a piece, the long term future of a piece of code is the 
>> responsibility of
>> known people. Effectively code-ownership [bad] is implementation while
>> code responsibility [good] is design. Author tags signify code
>> responsibility.
>

Re: Author Tags

[Jason Dillon <ja...@coredevelopers.net>]

> Code responsibility means that even though anyone may leap in and hack 
> on
> a piece, the long term future of a piece of code is the responsibility 
> of
> known people. Effectively code-ownership [bad] is implementation while
> code responsibility [good] is design. Author tags signify code
> responsibility.

I agree.  Anyone who assumes ownership of such code simply needs a 
little reminder of how things work.

--jason

Re: Author Tags

[Richard Monson-Haefel <Ri...@Monson-Haefel.com>]

On Tuesday, August 12, 2003, at 02:20  AM, Bruce Snyder wrote:
>
>
> This is already provided via the mavenized site temporarily available
> here:
>
>     http://www.apache.org/~jstrachan/geronimo/team-list.html
>
>

Why is my e-mail address richardmf? What does the "mf" part stand for? 
No, don't tell me ... I think I know.  Can someone change this to "mh"? 
  or just change the whole thing user id to "rmh". Thanks.

Re: Author Tags

[Bruce Snyder <fe...@frii.com>]

This one time, at band camp, Alex Blewitt said:

AB>> changelog files are a much better indication of whom to liase with than
AB>> historic @Author tags, particularly as the project matures and the 
AB>> people
AB>> change.
AB>>
AB>> James provides a page of credits where people can be publicly named and
AB>> thanked which I believe is also more appropriate than @Author tags.
AB>
AB>I think this is an excellent approach. Most people want to see their 
AB>name 'in print', and use @author tags to do it, but then the issues of 
AB>code ownership raise their ugly heads.

This is already provided via the mavenized site temporarily available
here:

    http://www.apache.org/~jstrachan/geronimo/team-list.html

Bruce
-- 
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

Re: Author Tags

[Alex Blewitt <Al...@ioshq.com>]

> changelog files are a much better indication of whom to liase with than
> historic @Author tags, particularly as the project matures and the 
> people
> change.
>
> James provides a page of credits where people can be publicly named and
> thanked which I believe is also more appropriate than @Author tags.

I think this is an excellent approach. Most people want to see their 
name 'in print', and use @author tags to do it, but then the issues of 
code ownership raise their ugly heads.

Having a separate credits page will solve that issue, and then any 
code-responsibility questions can be directed to those in the 
changelogs.

> We have
> also discussed the use of CVS keyword replacement "$id$" (is that 
> right?) in
> the @Author tag to at least identify the last comitter to work on a 
> file.
> The jury is out on the merit of that one, as it is carried into the 
> released
> javadocs, which may be problematic as the comitter may not be the 
> actual
> author of the changes.

I think that with a project where there are many developers and only a 
few commiters, having the commiter's ID doesn't really add much, but 
may be useful for checking why particular patches went through.

> I would expect that any external (non-contributor) requests for help 
> would
> be better directed to the appropriate list and not the @Author, and 
> likewise
> I would also expect any responsible contributor to review the change 
> log and
> relevant commit logs for the code they are interested in if they want 
> to
> discuss issues with a specific previous author. Otherwise the normal 
> means
> of communication (dev- lists) can be used as normal.

Agree completely.

Alex.

RE: Author Tags

[Danny Angus <da...@apache.org>]

Henri wrote:

> Code responsibility means that even though anyone may leap in and hack on
> a piece, the long term future of a piece of code is the responsibility of
> known people. Effectively code-ownership [bad] is implementation while
> code responsibility [good] is design. Author tags signify code
> responsibility.

The James project recently removed @Author tags from all of our code, and
the world didn't end.

In a new project with many new contributors contributing large amounts of
code I would expect that the value of avoiding any notion of ownership and
the rise of fiefdoms would far outweigh the benefit of attribution *in the
code*. Particularly so if the codebase is expanding to such an extent that
only small teams with special interest are actually directly involved with
certain encapsulated (isolated?) packages.

In dynamic projects such as these (Apache) it is my opinion that status and
changelog files are a much better indication of whom to liase with than
historic @Author tags, particularly as the project matures and the people
change.

James provides a page of credits where people can be publicly named and
thanked which I believe is also more appropriate than @Author tags. We have
also discussed the use of CVS keyword replacement "$id$" (is that right?) in
the @Author tag to at least identify the last comitter to work on a file.
The jury is out on the merit of that one, as it is carried into the released
javadocs, which may be problematic as the comitter may not be the actual
author of the changes.

I would expect that any external (non-contributor) requests for help would
be better directed to the appropriate list and not the @Author, and likewise
I would also expect any responsible contributor to review the change log and
relevant commit logs for the code they are interested in if they want to
discuss issues with a specific previous author. Otherwise the normal means
of communication (dev- lists) can be used as normal.

d.

Re: Author Tags

[Henri Yandell <ba...@generationjava.com>]

On Mon, 11 Aug 2003, Greg Stein wrote:

> Exactly. And even for the case where the change/commit came from somebody
> else, that will (should) be noted in the log message. You can always find
> out who wrote any particular change.

CVS change/commit logs don't go into the javadoc, which is often the major
way in which a user looks at the code.

> > Also, I think author tags are a way that code gets 'assigned' to
> > someone, and I would like to avoid the problem of code ownership that I
> > have seen in other open source project I have worked on.  Although, I
> > think the Apache system is designed to reduce the impact of such
> > problems, I think not having author tags will help.

Code ownership is bad. But only in terms of the old corporate concept that
only Mr X can change a piece of code. Code responsibility is important
however. I've found that when you throw away code ownership, you often end
up with no one caring.

Code responsibility means that even though anyone may leap in and hack on
a piece, the long term future of a piece of code is the responsibility of
known people. Effectively code-ownership [bad] is implementation while
code responsibility [good] is design. Author tags signify code
responsibility.

Hen

Re: Author Tags

[Greg Stein <gs...@lyra.org>]

On Mon, Aug 11, 2003 at 06:43:11PM -0500, Dain Sundstrom wrote:
>...
> I used to be strongly for @author tags, but Greg Stein convinced me 
> otherwise.  Author tags are not really definitive,  if you really want 
> to know who did something to a file you need to check the CVS log.

Exactly. And even for the case where the change/commit came from somebody
else, that will (should) be noted in the log message. You can always find
out who wrote any particular change.

> Also, I think author tags are a way that code gets 'assigned' to 
> someone, and I would like to avoid the problem of code ownership that I 
> have seen in other open source project I have worked on.  Although, I 
> think the Apache system is designed to reduce the impact of such 
> problems, I think not having author tags will help.

Agreed on both parts. While the Apache "system" as you call it (or "the
Apache Way" in other parts) disables fiefdoms ("you can't change that!
that's my code/responsibility!"), there can always be underlying notions of
"ownership". Eliminating author tags is yet another tool to avoid those
disruptive notions. Sure... if somebody is really gung ho on "owning" code,
then any tool you use isn't going to help. But the hope is that people like
that won't become committers in the first place. Further, every tool that
you use to get rid of the ownership concept is a bonus, and is very
necessary to establishing the most important part: a robust and healthy
community devoid of fractures and islands.

In June, I wrote a pretty long email about the topic:

    http://marc.theaimsgroup.com/?l=apache-community&m=105712356510449&w=2

And last year, I wrote some to the avalon-dev list (which spawned the thread
above):

    http://marc.theaimsgroup.com/?l=avalon-dev&m=103822961201266&w=2
    http://marc.theaimsgroup.com/?l=avalon-dev&m=103827529520851&w=2

    (also check out the rest of the avalon-dev thread)

Serge Knystautas defined a good policy for handling the recognition of
contributors:

    http://marc.theaimsgroup.com/?l=james-dev&m=103898649308900&w=2

> (Hopefully Greg will post his feelings on this.) 

Done :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Author Tags (was: JUnit test for...)

[Dain Sundstrom <da...@coredevelopers.net>]

On Monday, August 11, 2003, at 06:04 PM, Ed Letifov wrote:

> Also,  for  the  future, should the @author tags be specified? I don't
> mind  an  impersonal  collective  ownership  at all, but I can imagine
> someone  bugging  you  someday,  since  you  will  be the one actually
> performing commit.

I used to be strongly for @author tags, but Greg Stein convinced me 
otherwise.  Author tags are not really definitive,  if you really want 
to know who did something to a file you need to check the CVS log.  
Also, I think author tags are a way that code gets 'assigned' to 
someone, and I would like to avoid the problem of code ownership that I 
have seen in other open source project I have worked on.  Although, I 
think the Apache system is designed to reduce the impact of such 
problems, I think not having author tags will help.

Just my 2 cents,

-dain

(Hopefully Greg will post his feelings on this.) 
  

Re: Re[2]: [PATCH] [Testing]

[Alex Blewitt <Al...@ioshq.com>]

> BS> I'm wondering if there's a need for two kinds of tests - unit and
> BS> spec. Of course, these two can be achieved in the same *Test.java 
> files
> BS> and separated simply by a comment line.
>
> I personally like the 'separate spec test' idea more, but I have to
> admit that a gut feeling exists that it will end up in the same files,
> and moreover without that comment line.

Is there no reason why we couldn't have separate source directories, 
rather than having them in the same directory as the class itself? That 
way we could have:

src\org\apache\cache\Cache.java
unit\org\apache\cache\CacheTest.java
spec\org\apache\cache\CacheSpec.java

Plus it makes it a lot easier to build without test code, rather than 
relying on a naming convention. Don't know how easy it would be to 
integrate this into the maven build process, but since I've done it a 
few times with ant then it shouldn't be that difficult.

Alex.

Re: Re[2]: [PATCH] JUnit test for org.apache.geronimo.cache.SimpleInstanceCache

[James Strachan <ja...@yahoo.co.uk>]

On Tuesday, August 12, 2003, at 12:04  am, Ed Letifov wrote:

> Hello Bruce,
>
> EL>> Anyway, the test is in the attachment. As I said before: started 
> with
> EL>> the simplest, hope it helps.
>
> BS> I can certainly commit this test as I'll be writing a bunch of 
> these
> BS> later tonight.
>
> Thank you, but still, how does one submit multiple new files? As a jar
> archive to achieve portability and preserve directory/package
> structure?

Sure, that'd be cool.

> BS>  However, I'd like to try to make a decision on what we're
> BS> going to do to to determine spec coverage first. Although spec 
> coverage
> BS> is crucial, we also just need some simple test coverage of the 
> existing
> BS> code base.
>
> Understood. I guess while you are making this decision having the 
> simple test
> coverage growing won't hurt?

Absolutely not. The more unit tests the merrier in my book.


> BS> I'm wondering if there's a need for two kinds of tests - unit and
> BS> spec. Of course, these two can be achieved in the same *Test.java 
> files
> BS> and separated simply by a comment line.
>
> I personally like the 'separate spec test' idea more, but I have to
> admit that a gut feeling exists that it will end up in the same files,
> and moreover without that comment line.

I'd prefer to keep them separate. Unit tests tend to be focussed on 1 
class at a time. Functional tests typically work on a collection of 
classes. We should probably have different package trees for them. e.g. 
use the org.apache.geronimo.functional package for any functional tests 
etc.

James
-------
http://radio.weblogs.com/0112098/