On Tue, Jun 14, 2011 at 09:35:05PM -0500, Richard Frovarp wrote:
>> There should be archived VOTE threads on the droids-private list, which were
>> cc'd to private@incubator.a.o. Hopefully they were for PPMC membership. If
>> not, there will be some cleanup work to do.
>
> The votes were handled on the droids-dev list (like they should) and
> were committer votes. So Bertil and I aren't on the PPMC.
OK... In my opinion, the intent of the community to make this release is
perfectly clear. None of the people who are officially on the PPMC objected
to it, nor did anyone raise any concerns about the validity of votes from
Committers who aren't on the PPMC.
Furthermore, the three +1 votes come from the three top podling committers by
commit volume:
http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fincubator%2Fdroids
The community is small and some people are MIA, but it seems like those who are
active are exhibiting exactly what the Incubator wants to see: responsible
self-governance by stakeholders. The fact that two votes come from people who
were elected as Committers but not PPMC members is a technical oversight.
The Incubation Policy page sets out clear rules for how a release happens, and
I don't see a way to overlook or overrule the "SHALL" and "SHALL NOT" portions
of the text without a formal IPMC vote:
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
...
Podlings in Incubation SHALL NOT perform any releases of software without
the explicit approval of the Incubator PMC. Such approval SHALL be given
only after the Incubator PMC has followed the process detailed in these
guidelines, and SHALL NOT occur until all source has been legally
transferred to the ASF.
Therefore, should a Podling decide it wishes to perform a release, the
Podling SHALL hold a vote on the Podling's public -dev list. At least
three +1 votes are required (see the Apache Voting Process page). If the
majority of all votes is positive, then the Podling SHALL send a summary
of that vote to the Incubator's general list and formally request the
Incubator PMC approve such a release. Three +1 Incubator PMC votes are
required. Below is an example showing how an incubating project managed
this process:
The by-the-book remedy is for the existing Droids PPMC members to vote in the
people who are obviously driving this project forward, and for a new release
vote to be taken. I'm pained by the delays that will introduce, and if
there's anything I can do to expedite the process I'd like to help, but as a
newcomer to the IPMC I don't see it as being my place to suggest alternative
approaches.
> No, there is no JIRA ticket.
OK, no problem -- this thread will suffice.
> There are no category-X defined dependencies.
Check!
> The notice file includes notices for all the category B
> defined dependencies: JUnit and javax.servlet. Those are fairly common
> in Apache projects and the requirements were met. See below.
>
> Attached is the dependency hierarchy. All of the Apache projects are
> full projects, so they are all good. That leaves:
>
> NekoHTML - AL2
> SLF4J - MIT
> mockito - MIT
> Google Guava - AL2
> Spring - AL2
> JUnit - CPL v1 - Category B, binary only, appropriately labeled in the
> NOTICE.txt file
> javax.servlet - Included in the Jetty notice, which states it is CDDLv1
> and copyright Sun Microsystems and ASF. Notice text copied from Solr
> Jetty 6 - AL2, but requires notice (in place)
> CGLib - AL2
OK, excellent -- no fundamental problems, so it's just a matter of dotting our
i's and crossing our t's.
I see that the Droids LICENSE.txt only contains the ALv2, yet Droids has
dependencies on non-ALv2 libraries.
http://www.apache.org/dev/release.html#distributing-code-under-several-licenses
However, it looks as though Droids isn't *bundling* either JUnit or
javax.servlet, in either in source or binary form -- you're expecting Maven to
resolve and install the dependency. Therefore, I don't believe it's required
to include the license texts which apply to those components.
I'm not even sure whether you even need attributions in NOTICE.txt for
components you aren't bundling. As best I can tell, the Droids distro archive
does not contain either source or binary materials belonging to or derived
from either JUnit or javax.servlet IP.
In summary, unless someone corrects my interpretation, LICENSE.txt is fine and
NOTICE.txt has some info which is arguably superfluous, but the presence of
that extra info does not block the release. I consider the matter
provisionally resolved.
(If Droids ever *starts* bundling JUnit or javax.servlet, I'm pretty sure
you'll need *both* the notice and the license texts.)
> That's Maven. LICENSE.txt and NOTICE.txt are the two in svn. We may need
> to rename them to be without the .txt so Maven doesn't do its own thing
> there. While without txt is preferred, it is allowable to use the .txt
> file names.
OK. In my rush, I hadn't noticed that the Maven-generated NOTICE file was just
a stub rather than a substantially different version of NOTICE.txt. It's still
inaccurate because it's incomplete, though:
Droids
Copyright 2007-2011 The Apache Software Foundation
This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
It's not clear to me whether the presence of an inaccurate NOTICE file is
rendered moot by the presence of an accurate NOTICE.txt file. In the absence
of further commentary by those more expert than myself, I think I have to
consider the inaccurate file a blocker.
>> I'm not sure what the DEPENDENCIES file is supposed to tell us, but it
>> contains
>> minimal information. Presumably it's some Maven thing I just don't grok.
>
> That was Maven generated and I don't understand it either. I used the
> defined method of releasing via Apache Maven, including using the latest
> parent pom.
It's misleading because it's named "DEPENDENCIES" yet it does not list any of
the project's existing dependencies. I don't like it, and if it is consumed
by anything downstream, it could lead to miscommunications. However, I don't
know of a reason it should block.
>> Lastly, I think it's worth commenting on the contents of README.TXT, which
>> starts off like so:
>>
>> A p a c h e D r o i d s
>> --------------------------
>>
>> by Thorsten Scherler<thorsten at apache.org>
>>
>> That credit is obviously inaccurate and seems quite unusual for an Apache
>> project. I know that other projects have gone out of their way to delete all
>> @author tags. Perhaps Droids might consider doing likewise.
>
> Yes, that file needs to be cleaned up. I do see there are two source
> files with @author in them. I've fixed them in trunk. I don't think
> either of these two things are a blocker.
Good resolution, agree that it's not a blocker FWIW.
>> I also intend to run a RAT report, and to pore over LICENSE and NOTICE more
>> thoroughly, but I'm out of time for today and wanted to get you this feedback
>> sooner rather than later.
>>
>
> Thanks for the feedback. I poured over the LICENSE.txt and NOTICE.txt
> files quite carefully. The RAT report was ran until it came back clean
> twice. Those should be good.
Yep. I double checked and RAT only flags that silly DEPENDENCIES file.
License headers look good!
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
