But what if the community wants Apache to have such a rapid cadence? By forcing the community to decamp to GitHub, then what are we saying to that community? Sorry we may value community over code, but we value procedure over both?
If that is the answer, then so be it, let's change our mantra from "community over code" to "policies and procedures over community over code"... But that is not the foundation I thought I was joining There are only some hard and fast rules at the ASF... 72h for a vote is not a hard and fast rule (you just need a good reason for why you are going shorter and from what I have seen, the board would probably be ok as long as protections are put in place to safeguard the community) So the only hard rule per se, is that the PMC must do their IP diligence... What I don't want to see is a PMC taking the "easy" way out and pretending that thy download an check the source bundle for IP... I suspect there are enough binding votes cast having skimped on that criteria... So we need to make it easier for the PMC members to do their responsibility and verify the IP... Sure we can live in the dark and say that moving faster is not "the Apache way"... But how does that protect the foundation... Faster release cadence is about raising the bar in general too... Not just about helping some projects "dodge" release vote requirements - Stephen On Saturday, 8 February 2014, Henri Yandell <he...@yandell.org> wrote: > If you want to have a faster release cadence, then I think the answer is > for _you_ (not Apache) to have a faster release cadence. It seems easy to > look at Apache rules for releases and Linux rules for releases (as an > underpinning for the features found in Git) and treat them as incompatible, > but I don't think they should be. > > * 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. > > We have some issues to 'defend' against: > > * Trademark understanding so that a project's releases on GitHub do not > appear as being from Apache. > * Making sure the system is not used for exclusionary reasons (though > they'll often identify community problems as a root cause anyway). > > It's no different than what commercial companies are doing already, either > by having internal forks or an 'upsell' public version; with both cases > taking time for patches to work their way back in. Why not have subsets of > the PMC doing the same? > > This takes the legal arguments out and gets us more focused on the 'but a > singleton community is the apache way' gut unhappiness. > > Hen > -- Sent from my phone
