incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <>
Subject Re: [VOTE] Release Wave 0.4 based on RC2
Date Tue, 04 Jun 2013 09:22:55 GMT
Responding inline:

On Mon, Jun 3, 2013 at 9:14 PM, Ali Lown <> wrote:
>> - Unusual CHANGES file: I usually see people adding issue numbers our of
>> Jira
> As such, I saw it mentioned in the Common's guide that the use of an
> 'svn log' instead was not strange.
> What do you suggest doing with this instead?

Basically I would have added issue numbers. But actually, this is
totally up to the project and I would not block a release because of
this. It was just a comment from my user perspective. No worries with

>> - server-config.xml, jsongadgets.json, jaas.config no license. Maybe others
>> too? Please utilize: it's a great tool to
>> check our licenses
> Rat looks useful. I will add a note to the release page and on the
> wiki, but I think it will be easiest to run standalone ATM. (Perhaps
> it can be made part of the mavenized process though).

Actually it's very easy to integrate a RAT report with maven. Using it
standalone until maven arrived makes perfect sense to me.

>> - files in /spec - allowed to distribute? No License given, where do these
>> files come from?
> These files are the whitepapers behind the conversation and federation
> protocols that Google wrote. Should I just add the license header to
> them and leave them where they are?

I see in another mail, these files are out from the release. As long
as we do not release these, I believe there is no big deal with having
them as-they-are. When they are included in a release, we need to dig
deeper. I have not found out yet if the donation included this
protocols or not, but it seems they are. If they are donated, we can
easily change the license. If not, we should not touch them. My
suggestion is to leave them out of the release and bring this question
up to a broader audience, namely later.
Its better to have multiple eyes on that.

>> - src folder: we usually use org.apache prefix. Not seen any classes with
>> that
> Heh. You are correct that the org.apache prefix is not used at-all.
> The majority of the code lives under the org.waveprotocol namespace
> (for legacy reasons). Changing to use org.apache is a fairly major
> undertaking, and would serve little purpose if the next release is
> going to be mavenized (with the full codebase relocation that brings).

Makes sense to me. That said, it might be the case others from the
IPMC might see this a bit different. But lets wait for the vote over

>> - thirdparty: allowed to distribute? Check with compatible licenses. Full
>> list whats working what not is here:
> My understanding from the work Angus did is that these are all under
> licenses allowing distribution. We have an ant task (ant
> get-third-party) for the few we are not allowed to distribute.

OK sounds good. I was not knowing if these is checked or not. In any
way it would be good to document this a little.

>> - Wave Logo (/war) seems to miss TM symbol. Please check:
> I assume you are referring to war/static/logo.png. Notably this is a
> different image to the logo used on the incubator website. (Which also
> lacks a TM).
> Which of these should be used? Should they both have a trademark?

What Wave uses is up to the project. Maybe discuss this in a separate
thread. But whatever is used needs the tm symbol.
Actually this might sound a bit nitpickery, but we have had cases in
the past were people are not respecting ASF trademarks and bring a lot
of trouble to the projects. This happens with popular projects
especially. We cannot know - but hope- Wave will be popular again, so
it's better to be straight with the trademark requirements.

>> - Whats the meaning of whitepapers folder?
> This holds the rest of the whitepapers, but these are older than the
> ones in spec/, and are no-longer fully up-to-date wrt. the code.
> Though still often contain useful information explaining why something
> has been done in the way that it has.
> Should I just add the license header and leave them there?
> Alternatively, perhaps spec/ and whitepapers/ would be better licensed
> and moved into doc/?

+1, just take it out of the release (as you have done already)

Cheers + thanks for taking care



View raw message