Hello,
> The Apache motto is "community over code". This means that Apache is all
> about building community and trusting that the community will build the
> code. If you don't have the community, then the code doesn't much matter.
We have a community of users and vendors that leverage our software and push us
to get our releases out in a timely manner. As such, we are working for our
community, we just can't seem to get our artifacts through in a timely manner
within the Apache Incubation process. Our PMC reviews and votes go smoothly at
dev@, but then we hit the general@-wall and we twiddle our thumbs "hoping"
someone will VOTE. And as a great man once told me: "Hope is not a strategy."
> There may be issues with the incubator, the voting systems and such, but it
> isn't a bug that humans are involved and need care and feeding to get them
> motivated. That is a feature.
I comment on this below.
> I think that Marvin's question to you was pretty cogent. Would you be
> willing to spend an hour or so each on 5 different projects you aren't
> involved in before getting to put your own project up for a release? Would
> it change your willingness if most of the community behind some of those
> projects not only aren't willing to review your project, but they aren't
> even willing to review their own project carefully and cast a vote?
I use Apache, I am not Apache. I don't expect the users of TinkerPop to have to
write my code, they are there to use it. If they find a bug, I ask that they
submit a bug report (or better yet, a pull request). I map that to here:
"voting is inefficient and human biased" => bug report
"why not use a voting queue" => pull request
If I'm not delivering software in a timely manner, then I'm not doing my job.
If I'm going to wear the TinkerPop hat, then I better deliver on TinkerPop or
take off that hat. Likewise for Apache Incubation (though perhaps I'm naive in
my assumptions) -- if you are a mentor, move the artifacts through in a timely
manner and don't wait for the project leaders to ping "Hey, can we get a
VOTE?…please…pretty please….hello?"
> Your answers will likely say a lot about the dynamics of getting people to
> help each other. It is hard to do and a human touch goes further than
> setting hurdles.
This is where I lose you guys. Why are humans involved in a process that should
be automated.
1. MD5, SHA1, PGP can be automatically checked.
2. Unzip and see if the data is corrupted can be done automatically.
3. LICENSE verification is difficult, but I suspect with some markup
language for LICENSE and pom.xml analysis, this can be done automatically.
4. mvn clean install (BUILD SUCCESS can be verified automatically).
5. ...
As I see it, get the human out of the loop so we can move some software. Next,
I suspect you guys are getting tired of my banter. What better way to get rid
of me than to get this process automated so there isn't a sense of "dude, this
Marko guy bugs. I'm not wasting my time helping him." Once people start
thinking like that then its not about software, its about politics….marketing.
Politics aren't processing rippin' the algorithms, software is.
Thanks guys,
Marko.
http://markorodriguez.com
>
>
>
>
>
>
>
> On Mon, Sep 14, 2015 at 12:45 PM, Marvin Humphrey <mar...@rectangular.com>
> wrote:
>
>> Hi Marko,
>>
>> Have you ever considered reviewing other podlings' incubating release
>> candidates and cast non-binding votes yourself? If podling contributors
>> like
>> you would all help each other by performing thorough inspections of each
>> others release candidates (and by learning enough to perform those thorough
>> inspections), it would make things easier for everyone!
>>
>> I'm sure that some people reading this list are chortling with contempt at
>> my
>> naivete. ("Why not? Because there's nothing in it for ME, dummy!") But
>> helping out with other people's projects was part of what got me elected
>> onto
>> the IPMC while Lucy (the main project I contribute to) was still
>> incubating.
>> So then I was able to cast binding votes -- and our podling was largely
>> insulated from the problem that so vexes you now.
>>
>> Participating in wider Apache activities is also its own reward. The
>> Apache
>> Software Foundation is a worthy institution contributing great value to the
>> world at large. Helping out the Incubator, now or later, is both
>> personally
>> enriching and more meaningful than what a lot of people get to do at their
>> software day jobs.
>>
>> On Mon, Sep 14, 2015 at 9:26 AM, Marko Rodriguez <okramma...@gmail.com>
>> wrote:
>>
>>> For instance, Groovy received (out of my foggy memory) some 20+ VOTEs
>> when
>>> only 3 were were needed and other project VOTEs were sitting around
>> hoping
>>> for an Apache member to spend time on their project.
>>
>> Groovy got 4 +1 votes and 2 -1 votes. If you aren't reading these threads
>> closely, you should. The Groovy release vote thread would have been
>> extremely
>> educational -- contended votes are rare, and thread touched on not just
>> legal
>> issues but the fundamental reasons behind release policy.
>>
>>> Second, if no Apache member really cares about the project's VOTE,
>>> then the project committee is left "hoping" that someone will care ---
>>> pinging around to their mentors (no reply), to the list ("please")… like
>>> beggars in the street.
>>
>> I sympathize. This problem used to be WAY worse than it is now. And we
>> did
>> something about it, back in late 2013.
>>
>> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
>>
>> 2013 Alternate Release Voting Process
>>
>> Select podlings pre-cleared by a majority vote of the IPMC MAY
>> participate
>> in an alternate release voting process:
>>
>> Should a Podling decide it wishes to perform a release, the Podling
>> SHALL
>> hold a vote on the Podling's dev list and create a permanently archived
>> Release Manifest as described in the Experimental Release Guide. At
>> least
>> three +1 votes from PPMC members are required (see the Apache Voting
>> Process page). If the majority of PPMC votes is positive, then the
>> Podling
>> SHALL send a summary of that vote to the Incubator's general list and
>> formally request the Incubator PMC approve such a release. Formal
>> approval
>> requires three binding +1 votes and more positive than negative votes.
>> Votes cast by members of the Incubator PMC are always binding. For all
>> releases after the first, votes cast by members of the PPMC are
>> binding if
>> a Mentor approves the Release Manifest.
>>
>> So it's actually possible to get by with a single Mentor vote, if the
>> podling
>> contributors are willing to do some extra work. Are you?
>>
>> Ironically, that provision, which was so difficult to get consensus for,
>> has
>> only been used once -- because these days we make better use of the limited
>> IPMC capacity for freelance (i.e. non-Mentor) votes.
>>
>> But to drill down to the immediate issue... The specific TinkerPop VOTE
>> thread
>> you're concerned about is here, right?
>>
>> http://s.apache.org/VPv
>>
>> One thing that's confusing is that it mentions having 4 binding votes
>> already.
>>
>> Result summary: +1 (4 binding, 2 non-binding), 0 (0), -1 (0)
>>
>> I recommend supplying "IPMC", "PPMC", and "community" subtotals rather than
>> only the ambiguous "binding"/"non-binding". It looks like the TinkerPop
>> dev
>> list VOTE produced one Mentor/IPMC vote (Daniel Gruno's). Writing that the
>> release candidate has "1 IPMC vote" communicates that 2 more are needed in
>> a
>> way that "4 binding" does not.
>>
>> Regardless, pinging general@incubator asking for IPMC votes usually works
>> these days and it will probably work for this specific TinkerPop release
>> candidate as well. I see that you've already gotten one more IPMC vote
>> today.
>>
>> Marvin Humphrey
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
