I will echo Thejas's concern w.r.t RC voting. Usually it takes 2-3 rounds
of RC and folks generally tend to vote towards end of cycle. So, if we
increase it to 7 days, we are looking at 21 days (in worst case) to get a
release out, which may not be what we want. So, for RC vote my suggestion
will
Will do.
Thanks.
Carl
On Wed, Jan 15, 2014 at 3:33 PM, Thejas Nair wrote:
> Adding another sentence to clarify that with a -1, the patch can be
> reverted "If the code has been committed before the -1, the code can
> be reverted until the vote is over."
>
> Approval : Code Change : The code
Adding another sentence to clarify that with a -1, the patch can be
reverted "If the code has been committed before the -1, the code can
be reverted until the vote is over."
Approval : Code Change : The code can be committed after the first
+1. Committers should wait for reasonable time after pat
This wording seems fine. You could add "a" here: "Committers should wait
for [a] reasonable time"
The guidance is good.
+1
-- Lefty
On Tue, Jan 14, 2014 at 7:53 PM, Thejas Nair wrote:
> I guess the silence from others on the changing the '24 hours from +1'
> to a guidance of '24 hours
I guess the silence from others on the changing the '24 hours from +1'
to a guidance of '24 hours from patch available', implies they are OK
with this change.
Proposed general guidance for commits for committers: Wait for 24
hours from the time a patch is made 'patch available' before doing a
"+1
I think there is value in having some changes committed in less than 24
hours. Particularly for minor changes. Also reverting of patches makes
sense. Although it could be cumbersome, it is not much worse than what
would happen now incase of a bad commit. Anyway we wait for the unit tests
to complet
> ... to nudge committers to review patches sooner ...
I'm of two minds about this, so I'd like to hear more opinions.
In theory, picking up the pace seems like a good idea. But in practice,
everybody has other tasks to juggle so reviewing patches doesn't always
find a place in the daily schedu
More thoughts on the 24 hour wait : Changing the by-law to a 24 hr
wait from first time patch is marked as available (or making this a
guidance instead of by-law), is likely to nudge committers to review
patches sooner. Right now, the clock starts ticking for a commit when
another committer has +1'
After thinking some more about it, I am not sure if we need to have a
hard and fast rule of 24 hours before commit. I think we should let
committers make a call on if this is a trivial, safe and non
controversial change and commit it in less than 24 hours in such
cases. In case of larger changes, w
One other benefit in rotating chairs is that it exposes more of Hive’s PMC
members to the board and other Apache old timers. This is helpful in getting
better integrated into Apache and becoming a candidate for Apache membership.
It is also an excellent education in the Apache Way for those wh
Okay, I'm convinced that one-year terms for the chair are reasonable.
Thanks for the reassurance, Edward and Thejas.
Is 24h rule is needed at all? In other projects, I've seen patches simply
> reverted by author (or someone else). It's a rare occurrence, and it should
> be possible to revert a pa
On Sun, Dec 29, 2013 at 12:06 AM, Lefty Leverenz
wrote:
> Let's discuss annual rotation of the PMC chair a bit more. Although I
> agree with the points made in favor, I wonder about frequent loss of
> expertise and needing to establish new relationships. What's the ramp-up
> time?
The ramp up t
"Also something similar to this was said in the thread, "my +1 issue was
never committed for N days". Will new bylaws solve this problem? What is
the root of the problem?"
For the record, I will suggest the root of this problems is that there are
too many people working in "silos", and as the proj
I think the terms is good. We do not want to have a lame duck scenario.
Strictly the chair is only responsible for this:
http://www.apache.org/dev/pmc.html#chair
In many of the other ASF projects the chair is a more active organizer of
the committers. I have seen chairs suggest road maps, hang ou
Let's discuss annual rotation of the PMC chair a bit more. Although I
agree with the points made in favor, I wonder about frequent loss of
expertise and needing to establish new relationships. What's the ramp-up
time?
Could a current chair be chosen for another consecutive term? Could two
chair
This is what Thejas has also suggested earlier in thread. Sounds good to me.
On Fri, Dec 27, 2013 at 5:43 PM, Edward Capriolo wrote:
> " I propose to modify
> > that one such that there must be 24 hour duration between creation of
> jira
> > and patch commit, that will ensure that there is suffi
" I propose to modify
> that one such that there must be 24 hour duration between creation of jira
> and patch commit, that will ensure that there is sufficient time for folks
> to see changes which are happening on trunk."
One thing. Many of the jira's have little detail. So someone could file a
I actually have a patch out on a jira that says it will be committed in 24
hours from long ago ;)
Is 24h rule is needed at all? In other projects, I've seen patches simply
reverted by author (or someone else). It's a rare occurrence, and it should
be possible to revert a patch if someone -1s it af
I agree with Ashutosh that the 24 hour waiting period after +1 is
cumbersome, I have also forgotten to commit patches after +1,
resulting in patches going stale.
But I think 24 hours wait between creation of jira and patch commit is
not very useful, as the thing to be examined is the patch and not
Proposed changes look good to me, both suggested by Carl and Thejas.
Another one I would like to add for consideration is: 24 hour rule between
+1 and commit. Since this exists only in Hive (no other apache project
which I am aware of) this surprises new contributors. More importantly, I
have seen
The changes look good to me.
Only concern I have is with the 7 days for release candidate voting.
Based on my experience with releases, it often takes few cycles to get
the candidate out, and people tend to vote closer to the end of the
voting period. This can mean that it takes several weeks to ge
I like the changes. I believe rotating the PMC chair will keep the project
fresh. Work and life events come in spurts, and it's hard to step down when
your at the top (
http://disinfo.com/2013/02/ratzinger-resigns-first-pope-to-quit-since-1415/
:) .
On Thu, Dec 26, 2013 at 10:08 PM, Carl Steinbac
I think we should make several changes to the Apache Hive Project Bylaws.
The proposed changes are available for review here:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=38568856
Most of the changes were directly inspired by provisions found in the
Apache Hadoop Project Bylaw
23 matches
Mail list logo
