Olaf, Yuqi was guided by me: https://github.com/apache/bigtop/pull/555#issuecomment-634819743
Usually we'll put up a DISCUSS first and the a VOTE. So -1 and its reason will be there in DISCUSS most of the time. If the discussion is positive, then indeed there's no need to vote as we pretty much reach the consensus already. In other case that everyone has expressed there're though but still no consensus reached. We can only put in into a majority vote and move forward based on the vote result. I agree with those items you listed as priorities. Kengo as RM is driving the 1.5 release and we should polish those things. > Really? MPack is a amabari only technology, that seems not to even be defined properly. How could this ever end in more contributions to Bigtop ? We should take more user feedback on this because anyhow it solve user's problems. And if we have contributors who's willing to maintain it. It should be something we can adopt. The question we should ask here is are you willing to be the maintainer going forward? Best, Evans Olaf Flebbe <[email protected]> 於 2020年6月8日 週一 上午12:07寫道： > Hi, > > Sorry, I am super lost about the implications of that vote. > > Why do we need a vote in the first place? > I am familiar with votes for additional committers, PMC additions and > releases. For these votes we have the concept of binding votes by PMC > members. > > Why should I care about this ? > Does it have legal implications? > > Who will maintain this ? > I am a bit surprised that we do anything with ambari, since we not even > have a maintainer for it > grep ambari MAINTAINERS.txt -> nothing > > What problem/case is this additional component trying to solve? > If you are asking for a vote I would like to have a more elaborate > explanation. I looked at the linked ticket: Sorry I am totally lost about > what is this about. If you would have simply done it, I wouldn’t have cared. > > As I understand it should somehow enable more contributions. > Really? MPack is a amabari only technology, that seems not to even be > defined properly. How could this ever end in more contributions to Bigtop ? > > What will happen if someone is -1 on this vote ? > > If a contributor cares about adopting Bigtop to new business cases, that’s > very fine to me. Please go ahead. But please don’t ask for a vote. All > committers still have the chance to reject patches. > > Generally I am concerned that we care about an (from Bigtop side) > unmaintained project while neglecting our core infrastructure and packages > at the same time. > 1) The ci.bigtop.apache.org certificate expired again > 2) The bigtop-trunk-packages do not reflect the architectures we ought to > support (ubuntu-18.04 for instance) > 3) Trunk-packages for amd64 looks like garbage > 4) Still no-one working on Hadoop3 > 5) CI needs to be redone (with pipeline jobs) . > IMO we might have wrong priorities. > > Best, > Olaf > > > > > > Am 04.06.2020 um 19:04 schrieb Ganesh Raju <[email protected]>: > > > > +1 > > > > On Thu, Jun 4, 2020 at 12:01 PM Matt Andruff <[email protected]> > > wrote: > > > >> +1 > >> > >> On Thu., Jun. 4, 2020, 02:35 Yuqi Gu, <[email protected]> wrote: > >> > >>> Hi folks, > >>> > >>> As the discussion with Evans Ye, Jun He, and Matt Andruff (from Ambari) > >> on > >>> https://github.com/apache/bigtop/pull/555#issuecomment-635228180: > >>> > >>> For users / Bigtopers could easily modify Mapck and make contributions > to > >>> it like bugfix and adding more services, > >>> How about to decouple Mpack from Ambari and put Mpack as a standalone > >>> component in Bigtop, like *bigtop-packages/src/common/bigtop-mpack*? > >>> If so, it's convenient for users to get and install Mpack rpm/deb > >> packages > >>> in their own Ambari cluster. > >>> > >>> The VOTE: > >>> [ ] +1, Agree to put Mpack as a standalone component. > >>> [ ] +0, I don't care either way. > >>> [ ] -1, do *not * Agree. > >>> > >>> Look forward to your comments and feedback, thanks. > >>> > >>> BRs, > >>> Yuqi > >>> > >> > > > > > > -- > > IRC: ganeshraju@#linaro on irc.freenode.ne <http://irc.freenode.net/>t > >
