Re: GitHub write access
On Wed, Jun 25, 2014 at 7:52 AM, Lisa Seacat DeLuca wrote: > Ah, okay. I was hoping I'd be able to use the simple GitHub UX to quickly > push a button to merge in my changes. Background: The reason that we don't do this is that Apache needs the push records to establish code provenance definitively. In a DCVS local commit content and metadata can be forged, but pushes to ASF Git repositories are authenticated and the record of which ASF committer pushed what commits gets captured to our email archives. Were we to sync from a Github repo, the push record information would be held solely by Github and we would have subpoena them to obtain it in the event of a dispute -- assuming that Github keeps such information indefinitely and that they stay in business forever. For further explanation, see this thread: http://markmail.org/message/rigrcro5jgzfj7ul http://s.apache.org/zxn Marvin Humphrey
Re: Hangout
On Tue, Jun 10, 2014 at 7:13 PM, Michal Mocny wrote: > Curious to test if you can have multiple "owners" of the event to hit the > broadcast button that way, and if the final youtube videos are labeled in a > way that makes sense. Good points -- I don't know the answers to either of those questions. I've used that technique to create a permanent channel, but we don't broadcast or save archives. Marvin Humphrey
Re: Hangout
On Tue, Jun 10, 2014 at 1:07 PM, Michal Mocny wrote: > Link for joining coming in 1 sec. We'll figure this out one day, promise. It's possible to set up a permanent Google hangout so that the link never changes. The essential technique is to create a Google+ event whose location is a hangout and whose date is far in the future. The details are fiddly; try a web search for "google hangout permalink" for various recipes. Marvin Humphrey
Re: minor bump to cordova-lib
On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux wrote: > /me slow clap Brian, I realize that you are deeply opposed to voting on releases, and I understand and respect your arguments. Were Cordova an independent project, I would not come to the community proposing that release voting be adopted. However, Cordova is at Apache and the policies are what they are. You're welcome to make the case that the org should change, but to be honest I doubt such a change is achievable in the near term. The policy has deep roots -- a good chunk of the Foundation's legal structure is built in its service. And so I would argue that avoiding quixotic conflicts with the Board is in the best interest of most Cordova stakeholders. In the meantime, the question is how to make the best of things within existing constraints. For the record, there's nothing stopping Cordova from releasing on a fixed cadence. Marvin Humphrey
Re: minor bump to cordova-lib
On Mon, Jun 9, 2014 at 1:35 PM, Brian LeRoux wrote: > My understanding is that a VOTE was for ./dist and that anything npm is the > domain of the person publishing. Here's the policy: http://www.apache.org/dev/release#what What Is A Release? Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. [...] So it's not that packages published to npm (or any other downstream distribution channel) don't require a VOTE, it's that npm packages should also be published to dist (and require a VOTE). Marvin Humphrey
Re: ApacheCon session recording: Releasing Apache Software
On Wed, Jun 4, 2014 at 12:36 PM, Brian LeRoux wrote: > I think I might be soon (I accepted) though I'm not sure how it works > behind the curtain. Have you sent in the Membership application form to secretary@apache and received an acknowledgment? Please make sure that the paperwork gets taken care of well before the deadline of 30 days after the Members meeting (which took place on May 27 this year). If the 30-day window expires, we can't bring you on until the next Members meeting, probably a year from now. Marvin Humphrey
Re: ApacheCon session recording: Releasing Apache Software
On Thu, Jun 5, 2014 at 10:59 AM, Joe Bowser wrote: > The only thing that SHOULD be private on the lists is the selection of > PMC members and security issues, and a part of me doesn't even like > the latter very much when things are already public elsewhere (i.e. in > BugTraq). Well, at the project level there are occasionally legal issues which are best handled in private -- for instance, trademark violations, many of which can be resolved with a polite note to the offending party. > There's also the fact that people use > private lists to say things that they wouldn't dare say in public. Your experience matches my own. > I'll happily be rude to someone in public to their face, because to do > otherwise is dishonest. Hmm. I generally prefer discretion and diplomacy, which need not require dishonesty. FWIW, many communities have found success with the approach of criticizing ideas while avoiding ad hominem attacks. Lots of good stuff here: http://producingoss.com/en/setting-tone.html >> Ideally, only subjects which truly require discretion such as personnel >> issues, security, trademarks and so on get discussed on private lists. >> In practice, things are messy and sometimes conscious effort is required >> to move conversations public, but the diversity of the ASF Membership >> guards against subterfuge at the org level just as the diversity of the >> Cordova PMC guards against it at the project level. > > What sort of subterfuge are you referring to? Primarily excessive commercial influence. Apache has a reputation as a place where competing companies can collaborate on a common codebase. However, even with our governance institutions, such collaboration can become unstable when the interests of the various companies who employ a project's PMC members are not aligned either with each other or aligned with the interests of the Foundation. The ASF Board of Directors is tasked with overseeing all Apache projects, which includes enforcement of rules on project independence. This starts with ensuring that projects are operating according to the rules of meritocracy and that new PMC members are being added and granted a full role in governance, but in extreme circumstances it can extend to reconstituting PMCs and terminating projects (both of which have happened, though not lately). At the Foundation level, the ASF Membership[1] (effectively its shareholders) is far too diverse for any one commercial entity to hold sway. The Cordova PMC[2] is likewise quite diverse -- but that's not true for all PMCs. > It isn't related to this thread on legal, is it? > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201406.mbox/browser [See http://s.apache.org/6N3 for the correct permalink.] Heh. It seems that Ross got his addresses mixed up and inadvertently sent a message to legal-discuss@apache (public) that was meant for members@apache (private). To put that message in context, we're talking about how to streamline the annual Members meeting while maintaining the safeguards provided by our current bylaws. I suppose that subject matter is indirectly related to the "subterfuge" I had in mind. Our bylaws are carefully drafted to ensure that the Foundation cannot be legally hijacked by an illegitimate minority. There's a *lot* of money to be made in Apache software and conceivably some entity might be motivated to pull a fast one if we don't watch out. Marvin Humphrey [1] http://www.apache.org/foundation/how-it-works.html#asf-members [2] http://www.apache.org/foundation/how-it-works.html#management
Re: ApacheCon session recording: Releasing Apache Software
On Thu, Jun 5, 2014 at 10:52 AM, Brian LeRoux wrote: > Pls elaborate on how we can be more efficient? OK, the following suggestions are offered with no expectations and from humility as a Cordova noob. * Avoid "retagging" during the release process. Having the same version tag mean different RCs at different times destroys history and causes all sorts of confusion when testing, discussing, voting or performing post-mortem analysis. * Be more rigorous with the term "release candidate". Don't call something a "release candidate" unless it's *immutable* and there's going to be a *vote* on it. * Utilize RC numbers to differentiate release candidates. Each time a new one is created, add a new Git tag in the format `X.Y.Z-rcN`. * When in doubt, increment the RC number. Skipping RC numbers is minimally confusing because it is safe to assume that any earlier RC has been withdrawn and is superseded by the later one. * Incorporate RC identifiers into VOTE thread subject lines. For instance: `[VOTE] cordova-firefoxos 4.0.0-rc2` * Since votes for each platform are held independently, consider isolating release candidates within your dist/dev area using directory names incorporating the RC identifier such as `/dev/cordova/CB-/cordova-firefoxos-4.0.0-rc2` (which would hold the files `cordova-firefoxos-4.0.0.zip`, `cordova-firefoxos-4.0.0.zip.asc`, etc.). The idea is that each RC directory corresponds to one and only one VOTE thread. * Only add the final `X.Y.Z` tag when the VOTE passes. I recognize that implementing these suggestions would require both changes to Coho and unlearning of ingrained habits. But it seems to me that one reason the Cordova community finds the release process so taxing is that you're burdened by a mental model where "release candidates" are mutable. HTH, Marvin Humphrey
Re: ApacheCon session recording: Releasing Apache Software
On Wed, Jun 4, 2014 at 12:50 PM, Joe Bowser wrote: > I'm asking because of this: > https://twitter.com/TheASF/status/472089851693891584 > > So, another criticism of the ASF is the fact that as committers we > have zero say on the process because committers aren't members, and > only members can really cause any change. I question the > effectiveness of this given that the board for the most part hasn't > changed in years. > > Furthermore, as a project of the ASF, we have no idea what's going on > with the project that holds the copyright for our code. The same situation exists with Cordova's project-specific private list from the perspective of Cordova users who are not PMC members, no? Ideally, only subjects which truly require discretion such as personnel issues, security, trademarks and so on get discussed on private lists. In practice, things are messy and sometimes conscious effort is required to move conversations public, but the diversity of the ASF Membership guards against subterfuge at the org level just as the diversity of the Cordova PMC guards against it at the project level. On a separate note, the notion that the ASF "holds the copyright for our code" is not correct. When you contribute code to an ASF project, you maintain ownership but grant a copyright license under terms spelled out in the ALv2 and the ICLA. This is different from, say, the FSF, which requires copyright assignment in order to ensure it will have "standing" to sue for copyright violation and enforce the GPL. The ASF does not have the same priorities and has deliberately chosen not to require copyright assignment. > The fact that we hardly ever ship anymore > thanks to "The Apache Way" and the cognitive dissonance that it's > caused in its wake really hasn't helped matters. My impression as someone with a deep understanding of Apache and an admittedly superficial understanding of Cordova, is that Cordova's release process is not very efficient in the way it goes about satisfying Apache's requirements. For what it's worth there have been a few times I've thought about delurking to contribute specific suggestions, but I have been concerned that they might not be taken well. Instead, I've just tried to make myself available as a resource to Cordova contributors trying to make the best of things, and to continue with more general initiatives (policy clarification, the ApacheCon talk) which may help Cordova indirectly. Marvin Humphrey
Re: ApacheCon session recording: Releasing Apache Software
On Wed, Jun 4, 2014 at 12:47 PM, Brian LeRoux wrote: > I'd also like to point out that some of the perceptions of the release > process are currently being refined as they are not clear, and are not in > place for legal reasons though sometimes characterized as such. (So take > that presentation with a hefty grain of salt.) As the person who is driving the clarification initiative, I'm confident that the material in that presentation remains accurate and relevant. (In retrospect, the only thing I would revise is to incorporate disposable build servers into the presentation, which go some distance towards addressing the security issues surrounding org-certified binaries.) Marvin Humphrey
Re: ApacheCon session recording: Releasing Apache Software
On Wed, Jun 4, 2014 at 11:19 AM, Marcel Kinard wrote: > The Denver ApacheCon session had an good session on the Apache perspective > on doing a release. I found it very informative, especially with the threads > on this topic over the last few months. Hi Marcel... I'm gratified that you found it worthwhile, and I enjoyed meeting you and other Cordova people in Denver. Some of the presentation material was tailored with Cordova in mind after I attended one of your hangouts a couple months ago. If there are questions, I'm lurking on this list, and might show up at another hangout sometime. Marvin Humphrey
Re: [DISCUSS] Automate signed icla to git commits
On Mon, Apr 28, 2014 at 9:20 AM, Andrew Grieve wrote: > Interesting! Going by this description, it sounds like we wound't need > ICLAs for the majority of pull requests since pull requests details get > forwarded to the mailing-list. Legally, the party making the pull request implicitly asserts that they have the right to contribute the commits under the ALv2 section 5. However, if a release with infringing material escapes out into the wild, having somebody to blame will be cold comfort. Should the original copyright owner request that we cease distributing the offending release, Cordova's users are going to be in a bad situation regardless. > New proposal: don't worry about CLAs at release time. The key here is that the Cordova PMC needs to be vigilant with every pull request from somebody who has not signed a CLA or is otherwise well-known to be submitting clean IP. The Cordova committer who accepts the pull request and pushes to the ASF repo is the first line of defense. However, the rest of the PMC is also collectively responsible for reviewing all commits. So the question is, how confident are you in the existing review process? If it's working as intended, then there's indeed no need to perform an additional audit at release time. On the other hand if it's porous, then building in more checks might be wise. Marvin Humphrey
Re: [DISCUSS] Automate signed icla to git commits
On Fri, Apr 25, 2014 at 12:42 PM, Jesse wrote: > We can accept trivial commits without an ICLA, so the commit hook would > need a firm definition of 'trivial'. Section 5 of the ALv2 covers contributions: http://www.apache.org/licenses/LICENSE-2.0.html#contributions 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. [...] Technically, Apache doesn't require an ICLA or software grant for submissions, no matter what the size. What we need is documentation of the contributor's intent to contribute, captured within Apache-archived communication channels (mailing list, bug tracker, etc.). If we have that, then the ALv2 section 5 covers us legally. The ASF requires an ICLA for all *committers* to cover submissions which are committed directly into an Apache repo, but that's different. Nevertheless, it's considered best practice to obtain additional documentation from the contributor for large contributions, where "large" is not precisely defined. That documentation typically takes the form of a CLA or a software grant. So by establishing a hard requirement for an ICLA for *all* non-trivial contributions, Cordova would actually be going further than is required by Apache. That might be a sound policy considering how active Cordova is, and it's SOP at other places like the Eclipse Foundation. What we definitely would like to avoid is integrating important contributions from somebody clueless submitting stuff they don't own or somebody whose identity is not known. Requiring an ICLA up front would guard against that, at the cost of raising the barrier to entry. HTH, Marvin Humphrey
Re: What should it mean to +1 a release
On Fri, Apr 25, 2014 at 11:34 AM, Joe Bowser wrote: > Well, there's a reason we do cadence. Of course, Apache seems to > despise cadence and the release early, release often thing. There is no Apache policy stopping Cordova from scheduling release votes on a fixed cadence. CouchDB does it now -- here's Dave Cottlehuber singing its praises: http://s.apache.org/aV7 I agree; in the CouchDB community we had a similar experience. Addressing it has been positive both for our brand and for our community. It's also been a triumph of Apache values of community over code, demonstrating that the incubator process, as well as addressing legal concerns via due diligence, is also capable of sustaining communities who can survive the acrimonious departure of the founder. Moving to a time-driven release has helped us enormously. Marvin Humphrey
Re: What should it mean to +1 a release
On Fri, Apr 25, 2014 at 10:55 AM, Andrew Grieve wrote: > Had some discussions about this at ApacheCon, and I think it would be > good to formalize this in a release-process doc within coho/docs. I'd like to help with this. ASF release policy is an area of expertise for me, and I look forward in particular to suggesting mechanisms which reduce overhead while keeping Cordova and the ASF in sync. Marvin Humphrey
Re: Nomination for a new chair for Apache Cordova
On Wed, Apr 23, 2014 at 11:17 AM, Joe Bowser wrote: > That's actually insane that you can't quit until the meeting. You can > normally resign a post by writing a resignation letter in most places. > Why is this? Brian could resign, but that would leave a vacancy until the Board passes a resolution appointing a new Chair. It's possible for the Board to act outside of the monthly meeting, it's just a pain. (See below for gory details excerpted from the Foundation's bylaws.) I speculate that making it non-trivial for the Board to change project VPs was done by design, but I don't know that for sure. Marvin Humphrey http://www.apache.org/foundation/bylaws#5.12 Section 5.12. Action Without a Meeting. Any action required or permitted to be taken at a meeting of the Board of Directors or of any committee thereof may be taken without a meeting if all the members of the board or committee, as the case may be, consent thereto in writing, and such writing is filed with the minutes of the proceedings of the board or committee. Such consent shall have the same effect as a unanimous vote. http://www.apache.org/foundation/bylaws#6.4 Section 6.4. Election and Term. The officers of the corporation and the members of each existing Project Management Committee shall be appointed by the Board of Directors or appointed by an officer empowered by the Board to make such appointment. Such appointment by the Board of Directors may be made at any regular or special meeting of the Board...
[VOTE][DISCUSS] Cordova 3.1.0
On Wed, Feb 26, 2014 at 9:27 AM, Ian Clelland wrote: > I'm not sure about the lack of a NOTICE file; it otherwise indicates > "This product includes software developed by > Google Code Prettify (http://code.google.com/p/google-code-prettify)" > which isn't covered by the cordova-3.1.0/NOTIFY file Comparing the contents of 3.0.0 to 3.1.0, it seems that prettify is in one of the directories that happened to be stripped (cordova-docs/template/docs/default/prettify). Since those bits aren't bundled, there's no need to mention anything in LICENSE/NOTICE. So there's no problem here that would affect the 3.1.0 release. Actually, looking at google-code-prettify's licensing, both the bundled version and the current upstream, they don't include a NOTICE file -- so mentioning them in cordova-docs/NOTICE is actually a minor licensing documentation bug. (NOTICE should only include stuff that's absolutely necessary, so that it's easier for downstream users to consume.) I'd suggest applying the patch below to cordova-docs. Cheers, Marvin Humphrey --- NOTICE.orig 2014-02-26 10:12:04.0 -0800 +++ NOTICE 2014-02-26 10:12:13.0 -0800 @@ -4,5 +4,3 @@ This product includes software developed by The Apache Software Foundation (http://www.apache.org) -This product includes software developed by -Google Code Prettify (http://code.google.com/p/google-code-prettify)
