On 11 February 2014 17:01, Benson Margulies <bimargul...@gmail.com> wrote: > 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
+ hashes > 3. building and running enough tests to be willing to endorse that > release as a product of the community 4. Checking that the NOTICE & LICENSE files are appropriate to the release artifacts that contain them. 5. Checking that the contents of the source release agree with the SCM tag (there should be nothing in the source release that is not in SCM - or perhaps directly derived therefrom, but that is unusual) > 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. I agree if the vote is +1 However, I don't think one should disallow reports of packaging bugs or test failures - these can be picked up by anyone. Also note that whatever is used to check the packaging and release should be entirely independent of the packaging mechanism. This is necessary to avoid common-mode failures (if that is the correct term). > > 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
