On 15 jul 2011, at 18.59em, Emmanuel Lecharny wrote:
> Hi guys,
>
> I know it's frustrating to wait for something that could be done in a matter
> of minutes, but in the mean time, I would suggest you start some discussions
> about some important aspects of the project, before it starts to grow by
> adding ne committers :
No worries. It's almost like JIRA auto commit the patches attached to issues ;)
(I like that feature)
>
> 1) discuss about the file formatting options :
> - space vs tabs : usually, almost everyone ins using spaces, no tabs in all
> the files.(4 spaces). This is not your case. It would be interesting to
> states what's is to be used explicitly.
My vote goes for spaces. (I guess its some sed-fu or IDE magic to sort that
out(?)).
> - Classes headers : @author can be added, it's up to you to decide what to
> put into it
I'm fine without @author tag
> - formater : would you keep the default Java formatting, or do you have some
> desires to modify it ?
So, regarding the formatting (prepare for bikeshedding..)
Some of you might have noticed some non conventional code formatting. I'll try
to explain to reason for this (please take your time to read the "manifesto"
below).
Some of the APIs (AsynchronousSocket, AsynchronousHttpClient, Timeout,
PeriodicCallback etc) are truly asynchronous
(the return type of the method is void and the result is simply returned in a
callback (AsyncCallback or AsyncResult) that you supplied).
Eg. the readUntil(String, AsyncResult) method in the AsynchronousSocket.
So the pseudo code for some client code for this api would look like:
socket.readnUtil("\r\n\r\n", onHeaders) // where onHeaderes is a
surrounding method (the callback) to be invoked when the result is ready
To accomplish this in Java, using "standard" coding conventions you will end up
with something like this:
socket.readUntil("\r\n\r\n", new AsyncResult() {
public void onSuccess(String headers) {
onHeaders(headers);
}
});
Thats 7(!) lines.
So, to "solve" this cps (continuation passing style) in a more flexible way in
Java the current code base use the following conventions:
socket.readUntil(
"\r\n\r\n",
new AsyncResult() { public void onSuccess(String headers) {
onHeaders(headers); }}
);
Each argument on its own row (easy to distinguish) and the callback (the
anonymous instance of the AsyncResult in this case) is simply on a single line.
What we want to achieve is to simulate that the onHeaders method is the actual
callback (too fuzzy?)
Beside this I think we are (to some extent) following the standard java
conventions (though we are using 120 column width (80 is legazy :) ))
</manifesto>
>
> As a rule of thumb, most of the ASF projects are using spaces/no tabs,
> default Java format and @author only contains a ref to The ASF. This is *not*
> mandatory...
>
> 2) DEFT Web site
> - it would be a good idea to start thinking about a dedicated web-site
I agree. I like the standard look of other Apache incubation project's web
sites.
> - should it be Confluence backed, or whatever the ASF is now using (don't
> remember exactly what it is, Niklas ?)
> - structure for this web-site (doco, downloads, tutorials, how to become a
> committer, etc)
+1
>
> 3) IP cleareance
IP is short for?
> I think it should be quite fast. The first step would be to clearly list the
> initial committers, and to identify those who contributed to each part of the
> code, getting an ICLA for them
Basically iterate the entire github history and contact each one of them (~5
people besides the initial committers)
> - listing the dependencies, and their license
We have a NOTICE.txt, enough?
> - if some code has been copied from third party projects, I would seriously
> suggest that they should be replaced, unless it's Apache code (you never know
> how tainted it was before you copied it...)
I dont think so.
> - Pick a Logo and add the TM to it (this is mandated by The ASF : the Logo
> will be own by The ASF)
>
> Looking at the code size, all those tasks should not take a long time, and
> it's better to do it while the project is in its infancy at the ASF.
>
> One last thing : I'm a Javadoc crazy freak. Most of the projects I see around
> are just dry code without Javadoc, and Javadoc is the easiest way to help new
> comers to get a grip about the code. I know it's a major burden, like tests
> are, but, well, it just help. This is not really a part of being a mentor, I
> just like beautiful code with good tests and great Javadoc... Excuse me for
> that :)
> Have fun this week-end !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
// Roger
