Could I suggest a focus on making the release process easier? That will benefit everybody, and serve as a platform for ongoing discussion about releases and cadences.
It seems to me that we could make voters' jobs easier. This would help get releases approved _in 72 hours_, to start with. We ask voters to participate in a business decision by; 1. being aware of the ongoing work of the community 2. checking the signature 3. building and running enough tests to be willing to endorse that release as a product of the community At the start of this thread, someone asked: "If a trusted machine validated the signature, built the package, and ran the tests, could a responsible PMC member vote +1 on the basis of trusting the machine?" After all, all many voters do is to run the tests in the package, and if a someone has committed changes to denature them, the voter might well not notice. All of this should sit on the platform of my first point above: I submit that a person who has been paying no attention to commits and discussions has no business swooping in and voting on a package based on the other two steps. On Tue, Feb 11, 2014 at 11:19 AM, Shane Curcuru <a...@shanecurcuru.org> wrote: > On 2/9/14 2:03 PM, Doug Cutting wrote: >> >> On Sat, Feb 8, 2014 at 2:44 PM, Henri Yandell <he...@yandell.org> wrote: >>> >>> * Go and fork the project code on GitHub. >>> * Put your changes in there and PR them up into the Apache codebase. >>> * If others want to, they can PR the code to you, and then you can PR the >>> code up to the codebase (or the group of you could work as a community >>> preparing PRs). >>> * The one pushing into the Apache codebase needs to be confident that the >>> code is covered by CLAs. >>> * You can release in GitHub whenever you want. >>> * The Apache release happens less often and follows the rules. >> >> >> Keep in mind that if this is in any way a PMC activity then it is part >> of Apache trying to circumvent the rest of Apache, i.e., not advised. >> A distinct legal entity may indeed fork, re-brand, alter and release >> any Apache project using policies it prefers, but this must be clearly >> separate from any Apache project. A subset of a PMC acting as >> individuals would be murky territory if they share no common legal >> entity outside Apache. >> >> Doug > > > The key point is: who is the "we" that the world perceives doing this? This > whole discussion really underscores the importance of trademarks and the > Apache brand. > > We're quite happy for anyone to take our code and ship it just about however > they like. But they can't call it an Apache project: only a PMC here at > Apache can do that. While the original reason for most ASF release, > branding, legal, etc. policies is to ensure our legal safety, the very real > effect of these policies and their consistent application in PMCs is that > our projects following these policies are *seen by the rest of the world* as > being "Apache projects". > > - Shane
