Not sure if it's a mischaracterization. I have the same understanding as
Benson that that many comments on git threads reflected the perception
that git/github are incompatible with ASF. Not the point however.
What I see again is, for the most part, violent agreement that turns
into lengthy threads that have a ddos effect (at least on me). What I
get is that:
* votes are important, no vote no release (little to debate on that,
given the current bylaws)
* the community *must* be included, hence the rationale for 72 hours
votes guideline
* the board is ok with shorter vote windows, provided the release
requirements are met *and* community is included
* the cordova community is willing to adapt to a process that satisfies
the ASF guidelines, but they would like to preserve their current style
of 'cadence releases'
What I don't get is this:
* say a community reaches a consensus to provide weekly releases (or
daily, whatever cadence)
* say that they all know that the voting window is 12 hours (or 1 hour)
starting *always* on Wed as 12 am UTC.
Then how can one justify a claim that a release was pushed by the
'people in the room'? Cadence release is not unheard of. There are
communities who release at a cadence of 4 years and the voting window is
24 hours, the Tue after the first Mon in Nov [1].
* nobody could claim they are excluded, as the voting window is well
known in advance
* people (pmc or not) can decide in advance if they have bandwidth to
participate in testing the release and hence voting
* people can volunteer/announce in advance if they can/will participate
in testing the release, which is what the RM does in any project
* what goes in the release is dictated by the commits and the community
has plenty of ways to decide how to accomplish that
* changes are incremental (i.e. whatever changes since last week), so
the volume of work and expectations are known and manageable
* people can decide what the fate of failed releases is (redo, skip, etc).
* a project could even go as far as allowing such 'short' vote cycles
only via a unanimous and time bound (say quarterly) vote in the PMC.
This way a rogue group would only have a limited time to push their
interests. A disenfranchised PMC member could easily -1 short releases
for the next quarter. If the community cares about candence releases, it
creates an incentive for people to play nicely in the community. And
there are other ways, smarter people already suggested.
It is not my place to judge nor my desire to advocate for or against
cadence releases. I saw a bunch of excellent comments and proposals in
these thread(s). Some volunteered to experiment too. What is the problem
with such an elusive solution, really? What is the perceived risk?
My $0.02,
Hadrian
[1] http://en.wikipedia.org/wiki/Election_Day_%28United_States%29
On 02/13/2014 08:40 AM, Joseph Schaefer wrote:
That is a mischaracterization of the git story which was always about being
able to support multiple version control tools. Yes people were concerned
about the social side but we wouldn't be Apache without that debate.
Same here. All you are seeing is some natural skepticism about the claims
being made. The door is open though to a well considered proposal that this
exercise should help refine.
Sent from my iPhone
On Feb 13, 2014, at 7:58 AM, Benson Margulies <bimargul...@gmail.com> wrote:
This conversation goes in a circle. I see two positions:
1: Cadence releases are inevitably incompatible with Apache community values.
2: Cadence releases are not inevitably incompatible with Apache
community values.
People who take the first position see this desire to use cadence as
weakening of values and the brand. People who take the second position
are frustrated.
Note the phrase, 'not inevitably'. No one here is claiming, in the
absence of an experiment, that this idea will inevitably lead to a
perfectly healthy expression of Apache Community values.
This conversation reminds me of the early days of the git discussion.
At that time, some folks were convinced that 'git === fork culture'.
Since 'fork culture' is pretty clearly incompatible with Apache
community values, it took a very long time for us to decide to perform
an _experiment_ in git usage to see what would happen. OK, here we
are, the git experiment has been deemed a success.
The following is utterly non-rhetorical. Something happened over the
course of long discussion to move from 'git is evil, go away' to
'infra is willing to put effort into the infrastructure to support an
experiment.' What was it, and is there any hope of following that
path?
On Thu, Feb 13, 2014 at 12:02 AM, Phil Steitz <phil.ste...@gmail.com> wrote:
On 2/12/14, 7:23 PM, Marvin Humphrey wrote:
On Wed, Feb 12, 2014 at 10:46 AM, Phil Steitz <phil.ste...@gmail.com> wrote:
I know this looks old-fashioned, even downright anachronistic to
"push-hourly-from-CI" people; but deciding *what* to release *as a
community* is an important responsibility of ASF PMCs. Putting
things on a rigid schedule basically skips this step, which, IMHO is
a core part of our common culture and values.
Should projects who wish to release on a regular schedule avoid Apache?
I agree with Joe that that is the wrong question to ask. The right
question is what are the basic principles and values that
*communities* should buy into when deciding to join Apache. I
proposed a couple of them above. How releases happen, how policy
compliance is assured are secondary - the main thing communities
need to ask themselves when deciding to join the ASF is do they want
to do open, community-based development the way it is done here. If
cutting releases on a predetermined schedule is somehow a
"requirement" for them, the first question to ask is "why" and if
there is a good answer to that question then the second question is
how do you do that in a way that is consistent our principles.
Phil
Marvin Humphrey
.
