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 <ganesh.r...@linaro.org>:
> 
> +1
> 
> On Thu, Jun 4, 2020 at 12:01 PM Matt Andruff <m...@andruffsolutions.com>
> wrote:
> 
>> +1
>> 
>> On Thu., Jun. 4, 2020, 02:35 Yuqi Gu, <yuqi...@linaro.org> 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

Reply via email to