On 05/25/2012 09:45 AM, Konstantin Boudnik wrote: > On Wed, May 23, 2012 at 11:32AM, Alan Gates wrote: >> On May 22, 2012, at 10:20 AM, Roman Shaposhnik wrote: >> >>> On Mon, May 21, 2012 at 9:49 PM, Alan Gates <[email protected]> wrote: >>>> I don't know what the rules are for a BOM vote. >>>> It seems close to a release vote, which would indicate a -1 is not a veto >>>> (ie it's a majority vote). >>>> >>>> However, continuing down this path we'll end up with a -1 from Owen when >>>> it comes time to release 0.4. >>>> Releases are majority votes, but the rest of the IPMC is going to take a >>>> long hard look if you have a -1 >>>> from one of your mentors. I think it's in everyone's interest to work >>>> this out now rather than ignore his -1 >>>> only to bump into it again when it's time to release. I realize you feel >>>> his -1 is unjustified. But simply >>>> declaring it to be so and moving on will not make the issue go away. >>> Alan, I think what we're asking our mentors here is whether it would >>> be ok for us to >>> decouple and issue of releasing convenience binary artifacts from the >>> rest of the >>> discussion. IOW, suppose that this vote ONLY applies to the source releases >>> of Bigtop (no binary artifacts involved whatsoever), we're asking Owen >>> whether he >>> would have the same concerns. If he does -- we would like to hear them >>> articulated. >>> >>> That way, Bigtop community can move on working on the *source* of the >>> Bigtop 0.4.0 >>> release and mentors/incubator leadership/ASF board can spend time figuring >>> out >>> an ASF-wide policy for the binary convenience artifacts. >>> >>> Does that makes sense? >> I do not fully understand Owen's concerns and wouldn't presume to speak for >> him. But in thinking about this one concern I have is the following. The >> community votes on and reviews only source releases. I have no problem with >> Bigtop including source code that packages non-Apache owned code. But the >> community does not vote on or approve binary distributions. These are made >> at the discretion of the release manager. I do have concerns with Bigtop >> distributing non-Apache owned artifacts, as I have indicated in previous >> emails. But after I vote for the source release, I have no ability to vote >> against the binary distribution. So I am forced to vote against the source >> release to prevent what I think is a bad binary distribution policy. So I >> don't find it convincing to say this is only about the source release and >> not about the binary distributions until we resolve the question of whether >> or not Bigtop will be doing binary distributions of non-Apache owned >> software. >> >> Alan. > I would like to summarize: > - concerns about the content of BigTop (incubating) release 0.4.0 were > expressed here by Owen and never been resolved, not for the lack of > attempts from BigTop PMC > - Owen rejects to come out on the public list to stand behind his own > concerns > - according to Alan we won't achieve much by simply following Apache's own > voting rules and closing this vote with the statement of +1 and -1, > because > the same (whatever it is) issue will likely to be raised again at the time > of the release > > In the interest of the further community and project's progress which has been > stalled for good two weeks I don't see any other way but to propose: > - let's remove source code for Hue packaging out of the BigTop 0.4.0 BOM > > I hope that most of us here are quite grown-up and professional to understand > why I am offering to make this trade-off. > > Roman, shall we initiate another vote for updated BOM? > > With regards, > Cos >
Could you explain why in your view the project's progress has been stalled for good two weeks? >From my understanding, no one else had any issue with this on the incubator mailing list, this concern has been put to rest in weeks (no reply about questions from the community or activity about it) and the vote has passed. So I am not sure there is any need to revive that thread or for such vote without anyone clearly articulating arguments on why.
