Marnie McCormack wrote:
Hi Carl,
Comments inline ....
On Tue, Dec 2, 2008 at 1:47 PM, Carl Trieloff <[EMAIL PROTECTED]> wrote:
I looked at the last spin artifacts. I think we have some cleanup /
decision to make before the next spin
1. Ruby & Python README's need some, how to use comments (I have pinging
Rafi)
2. .NET ( we have a 0-8 client that has no changed since M2 and the new 010
client. However the 010 client
is in a subdir, 0-8 is not. Should we move the 0-8 client into a subdir or
just delete it, as it can be obtained from M3
or M2? It is problematic that the RELEASE_NOTES talk about M2 at the top
level and confusing
We need to retain the 0-8 version as it is in use and may be upgraded. There
were several fixes and enhancements to the 0-8 version in M3. I think a
separate discussion on the 0-10 .Net client would be useful as I know some
concerns existed around the review.
I don't know if you're referring to some comments I made on IM, but my
concerns are not with the 0-10 .net code per se. In fact 0-10 .net code
is a direct translation of the 0-10 Java code, both of which have
received more review in general than the 0-8 code which predates our
review process.
My concern is with the general approach to the .net client. Both the 0-8
.net client and the 0-10 .net client are simply translated snapshots of
the Java codebase at a particular point in time. I don't believe this
approach is maintainable. The 0-8 .net client is years behind the Java
0-8 client, and it shows in terms of bugs and features that were
fixed/added long ago for Java, but never made it to .net. Similarly the
0-10 .net client is already behind the Java 0-10 code (both in bugs and
features) despite being only a month or so old.
As you say though this is separate from the release discussion.
3. The Java build needs something in the README about Java 1.5 /1.6 or we
need to fix it. It also needs to be updated
with the ant instructions. I also think we should kill maven so people
don't try and fail to build with Maven. (Hiram's
issues trying to build)
I think the issue with the 4? classes should be addressed - I think Martin
is going to raise a JIRA.
There is still the double build issue even if the overrides are removed.
I believe this issue is really what permitted the @Overrides to sneak
in, since it's fairly inconvenient now to use 1.5 as your primary devel
platform, so we don't really check that we compile on 1.5 very often.
Maven can be useful for generating the
IDEA/Eclipse project files so maybe we could just document the build
instructions for trunk ? I'm happy to do that.
I don't think the ability to generate IDEA/Eclipse project files is
worth the confusion of keeping around the pom files. Isn't there some
way it could be done without having broken pom files sitting around?
I am still checking licensing, but that is the punch list I have found so
far on the last spin.
Volunteers welcome to help clean up.
Carl.
I also sent some feedback on the alpha & beta. Be good to get Rafi's view of
what he thinks should be done and we can pitch in.
I think it's too late to be moving around directories at this stage.
IMHO we should focus on testing, getting the READMEs up to date, and
getting JIRA cleaned up. It's always been the case that each sub-project
in qpid has its own private way of doing things, and our releases are a
bit inconsistent as a result. I don't think we're going to solve this
issue for M4, but if we make it a focus for the next devel cycle,
there's a lot we could do to improve things for M5. I think if we were
to do this it would be reasonable to drop the Milestone moniker from the
release at that point.
--Rafael
