You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aurora.apache.org by Renan DelValle <re...@apache.org> on 2018/05/04 18:38:47 UTC
[DISCUSS] State of the Community
Hello all,
I wanted to bring up a few points for discussion with the community. I'd
really like to hear what the community's thoughts are on these issues and
how can resolve them.
1. Lack of participation. This is due to many members moving on from the
project and becoming dormant. More concerning is the fact that our PMC
roster sits at 21 members [1] of which fewer than half have participated in
the project during the last 6 months.
This inactivity has led the voting process for releases to be held up by
the inability to reach the required minimum 3 votes for releases (both
tar.gz and binary). Our latest binary packaging vote has been going on for
more than a month. [2]
With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly to the
Aurora PMC, we hope to mitigate this issue.
It would be fantastic to see some initiative from long contributing members
to make a case for themselves for being considered for committer and/or PMC
membership.
2. Binary packages. While we have been struggling to get enough votes for
making the release official, the voting process has been marked by a lack
of enthusiasm from the community.
I know that many folks are using these packages (including myself), but we
need to hear feedback when we call votes. It is not enough to stand by
silently if everything works; please let us know about it.
As it stands, the enthusiasm (or lack thereof) for binary packages doesn't
justify the overhead involved in releasing them. Therefore I propose that
we drop official binary packages for the next release. This is up for
discussion and I'd love to hear everyone's opinion on this.
An alternative to ending binary packages would be to automate the process
on tar.gz releases, but that would most likely need to be a community
contribution.
3. Version 1.0. I realize this is a touchy subject. While other projects
that were started around the same time as Aurora, such as Mesos itself,
have gone on to make a 1.0 release (indicating the projects maturity), we
have stuck to our 0.X.0 releases.
Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
wanted to bring up for discussion how everyone felt about making our next
release a 1.0 release to reflect the stability and maturity of the project.
That is all from me, if anyone else has any other concerns regarding the
Aurora community, feel free to bring it up in this thread!
-Renan
[1] https://projects.apache.org/committee.html?aurora
[2] https://lists.apache.org/thread.html/9df9d142408efffd11a1cdc5e4c1e3
67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org%3E
Re: [DISCUSS] State of the Community
Posted by Meghdoot bhattacharya <me...@yahoo.com>.
I would love to see roadmaps, potential new features that would bring fresh energy and excitement rather than a maintenance project kind of feel. I think this project brings a lot that more hyped projects do not but stagnation can hurt.
Thx
> On May 22, 2018, at 4:18 PM, Santhosh Kumar Shanmugham <ss...@twitter.com> wrote:
>
> I would like to see this community become active again. If we can fix the gaps
> with processes that David explained above, I am sure we can revive the community.
>
> As for the timely reviews, I have a couple of requests:
> - Triage - find appropriate reviewers for each patch to assign ownership
> - Expectations - work with the author to set meaningful timelines for review round-trips
>
> -Santhosh
>
>> On Tue, May 22, 2018 at 2:26 PM, Renan DelValle <re...@gmail.com> wrote:
>> Thanks for the feedback David!
>>
>> On Tue, May 22, 2018 at 9:55 AM, David McLaughlin <dm...@apache.org>
>> wrote:
>>
>> > I feel like not getting code reviews is often a symptom of some other
>> > fundamental issue with how change is introduced to a community.
>> >
>> > When I joined the Aurora team at Twitter there were some principals in
>> > place for getting your changes accepted to the community and I still feel
>> > like when you follow them, getting code reviews rarely requires more than a
>> > gentle ping. Maybe none of these have been formally communicated or shared
>> > externally, but some of the principals I've picked up include:
>> >
>> > * Introduce problems before solutions.
>> > * Get buy-in that this is a problem worth solving.
>> > * Work towards abstractions that work for the community and not just for
>> > your specific use case.
>> > * Solicit early feedback on potential solutions.
>> > * Get explicit buy-in for the solution (these +1s would be the people you
>> > add to the reviewers list later). This usually means writing a Design Doc.
>> > * Plan your work carefully to avoid the dreaded code dumps (where
>> > possible). For large efforts work towards multiple, small patches that are
>> > easy to review.
>> > * Follow-up on review feedback quickly to avoid demanding expensive paging
>> > and context-switches from your reviewers later.
>> > * Build trust by thinking through production rollout and rollback
>> > scenarios.
>> >
>>
>> All good points and I think those of us that have been here long enough do
>> strive to follow these principles. For what it's worth,
>> I've always really appreciated the feedback from the folks running at scale
>> when it comes to my contributions. It shows they care
>> about the project and pushes me to write better code.
>>
>> That said, since these are mostly unwritten rules, either we need to write
>> them down or we need to cope with the
>> fact that some folks may not follow them. What would really be unfortunate
>> is to lose potential contributors because
>> they get discouraged after submitting a patch and running into this
>> "invisible" red tape. I can already see this happening
>> such as in https://reviews.apache.org/r/66490/
>>
>> There may not be a solution to that problem (and may be a different problem
>> altogether) but it would at least be
>> nice to have an outline of what procedure is expected from potential
>> contributors.
>>
>> Another thing I'd like to bring up is that our use of JIRA has drastically
>> decreased. There is very little activity going on there.
>> That used to be the starting point of discussion for any contribution. As
>> engagement has dropped, that's pretty much gone away
>> leaving us without much defense in shutting down an idea before it's coded.
>>
>>
>> >
>> > There is obviously more than just this list, but a lot of the patches that
>> > struggle to get reviews (or get hard -1s after a bunch of work is done)
>> > fail on one (or more) of these fundamental ideas.
>> >
>>
>> I agree on this point but what concerns me more than the -1's is the lack
>> of engagement. For example
>> https://reviews.apache.org/r/66537/
>>
>> If we want to engage the community, we gotta give feedback, good or bad.
>> For me, letting review requests rot is one sure fire indicator to
>> potential contributors that sending a contribution is not worth their time
>> or effort (and our process is pretty time consuming given the outline we
>> tend to follow above).
>>
>>
>> We should find a way to keep the core tenets outlined above while
>> streamlining the process. Maybe move away from reviewboard
>> into gitbox so we can do code reviews on github? Not sure if this would
>> help at all, but it may since folks are more familiar with that workflow
>> so it brings down a barrier for contribution.
>>
>>
>> (Side note: maybe it's a good time to propose a cleanup in reviewboard. Right
>> now our group page on reviewboard looks like a graveyard.
>> In my opinion, anything older than a year isn't likely to be committed and
>> should therefore be discarded. I can put this to a vote if the general
>> consensus is
>> positive towards this idea.)
>>
>>
>> > It's also worth calling out that having informal discussions on Slack is
>> > fine, but should also be done on the dev lists, and ideally in the form of
>> > a written document. This is the best way to include those of who feel like
>> > Slack is a massive productivity drain :)
>>
>>
>> Noted, though I will say our slack channel doesn't have much of a pulse
>> these days either (and hasn't for quite some time).
>>
>>
>> >
>> >
>> I guess this is my long-winded way of saying that I'm a -1 on moving to
>> > lazy consensus.
>> >
>> > I wonder if a lot of the concerns can be solved by just improving
>> > communication? Maybe we can revive the weekly developer meeting that we
>> > used to run in IRC.
>> >
>>
>> This would be great but sadly I just don't see the engagement we need to be
>> able to pull this off. We could not even get enough interest to
>> host an Aurora Meetup, so I see this as an uphill battle if we attempt it.
>>
>> I could be wrong though and I would be more than happy to be part of it if
>> we start running it.
>>
>> -Renan
>>
>> >
>> >
>> > On Tue, May 22, 2018 at 8:58 AM, Renan DelValle <re...@apache.org> wrote:
>> >
>> > > Thanks for your input Stephan, very much appreciated! Replies inline:
>> > >
>> > > On Tue, May 22, 2018 at 12:12 AM, Stephan Erb <
>> > stephan.erb@blue-yonder.com
>> > > >
>> > > wrote:
>> > >
>> > > > Hey Renan,
>> > > >
>> > > > thanks again for bringing this up. In my experience, the pain comes
>> > from
>> > > > building, testing & voting rather the packaging scripts themselves. I
>> > > > therefore think we should discontinue building, but continue to
>> > maintain
>> > > > the scripts so that users can build them on their own when necessary.
>> > > >
>> > >
>> > > Fully agree on this. I will even go as far as making unofficial builds
>> > > available for the time being if no one is opposed and if it's not against
>> > > Apache policy to do so.
>> > >
>> > > >
>> > > > We must be careful though with linking the ‘nightly jenkins builds’ on
>> > > the
>> > > > website. We got called out for this once in the past and had to take
>> > the
>> > > > link down.
>> > > >
>> > >
>> > > Noted, thanks for bringing this up!
>> > >
>> > > >
>> > > > We also see a lack of involvement in code reviews. I think we should
>> > > > consider setting up a more formal lazy consensus policy
>> > > > https://www.apache.org/foundation/voting.html#LazyConsensus : For
>> > > > example, patches maybe merged even with a single ‘ship it’ from a
>> > > > committer, if there is neither a ship-it nor a veto from other
>> > committers
>> > > > within 7 days.
>> > > >
>> > >
>> > > I think this is a very valid way forward at this point. How does everyone
>> > > else feel about this?
>> > >
>> > > >
>> > > > Best regards,
>> > > > Stephan
>> > > >
>> > >
>> > >
>> > > -Renan
>> > >
>> > > >
>> > > > From: Santhosh Kumar Shanmugham <ss...@twitter.com>
>> > > > Reply-To: "user@aurora.apache.org" <us...@aurora.apache.org>
>> > > > Date: Thursday, 17. May 2018 at 22:13
>> > > > To: "dev@aurora.apache.org" <de...@aurora.apache.org>
>> > > > Cc: "user@aurora.apache.org" <us...@aurora.apache.org>
>> > > > Subject: Re: [DISCUSS] State of the Community
>> > > >
>> > > > Hello Renan,
>> > > >
>> > > > I understand your frustration.
>> > > >
>> > > > I am a strong +1 for automating the release and voting process. I
>> > > performed
>> > > > a release a while back and the process definitely needs it improve
>> > > > documentation
>> > > > at the least. If one of the members who are more familiar with this
>> > > > process can
>> > > > create a backlog, I will be happy to chip in.
>> > > >
>> > > > -Santhosh
>> > > >
>> > > > On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <renan@apache.org
>> > > <mailto:
>> > > > renan@apache.org>> wrote:
>> > > > All,
>> > > >
>> > > > Discussion has been open for 13 days and only one user has chimed in.
>> > > > Unfortunately it looks like talking point number one will be a serious
>> > > > concern going forward. I will give until tomorrow 12 PM San Francisco
>> > > time
>> > > > for folks to voice their opinion on these issues.
>> > > >
>> > > > After tomorrow I will call a vote to cease distributions of official
>> > > binary
>> > > > packages from versions 0.21.0 onwards until the process is automated
>> > and
>> > > > voting for the voting for the binary packages can be combined with the
>> > > > tar.gz release.
>> > > >
>> > > > Since no feedback was received regarding talking point three, the idea
>> > > will
>> > > > be dropped.
>> > > >
>> > > > -Renan
>> > > >
>> > > >
>> > > > On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <
>> > renanidelvalle@gmail.com
>> > > <
>> > > > mailto:renanidelvalle@gmail.com>>
>> > > > wrote:
>> > > >
>> > > > > In some ways, that's some of the best feedback we can get. Very happy
>> > > to
>> > > > > hear that Aurora is working fo well for Chartbeat.
>> > > > >
>> > > > > I do hope that you guys find some time to help us maintain the
>> > project.
>> > > > > Every little bit counts!
>> > > > >
>> > > > > -Renan
>> > > > >
>> > > > > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <rick@chartbeat.com
>> > > <mailto:
>> > > > rick@chartbeat.com>> wrote:
>> > > > >
>> > > > >> As strong users of aurora but weak contributors, we at Chartbeat
>> > > > >> apologize for our lack of participation. We’re several versions
>> > behind
>> > > > on
>> > > > >> mesos/aurora upgrades and that’s honestly because it works for us :)
>> > > > >>
>> > > > >> Going forward we’re hoping to be able to participate more, at least
>> > > with
>> > > > >> testing new releases.
>> > > > >>
>> > > > >> We thank you though!
>> > > > >>
>> > > > >> Rick and the rest of Chartbeat Engineering
>> > > > >>
>> > > > >>
>> > > > >> > On May 4, 2018, at 2:38 PM, Renan DelValle <renan@apache.org
>> > > <mailto:
>> > > > renan@apache.org>> wrote:
>> > > > >> >
>> > > > >> > Hello all,
>> > > > >> >
>> > > > >> > I wanted to bring up a few points for discussion with the
>> > community.
>> > > > I'd
>> > > > >> > really like to hear what the community's thoughts are on these
>> > > issues
>> > > > >> and
>> > > > >> > how can resolve them.
>> > > > >> >
>> > > > >> > 1. Lack of participation. This is due to many members moving on
>> > from
>> > > > the
>> > > > >> > project and becoming dormant. More concerning is the fact that our
>> > > PMC
>> > > > >> > roster sits at 21 members [1] of which fewer than half have
>> > > > >> participated in
>> > > > >> > the project during the last 6 months.
>> > > > >> >
>> > > > >> > This inactivity has led the voting process for releases to be held
>> > > up
>> > > > by
>> > > > >> > the inability to reach the required minimum 3 votes for releases
>> > > (both
>> > > > >> > tar.gz and binary). Our latest binary packaging vote has been
>> > going
>> > > on
>> > > > >> for
>> > > > >> > more than a month. [2]
>> > > > >> >
>> > > > >> > With the recent additions of Santhosh Kumar Shanmugham and Jordan
>> > Ly
>> > > > to
>> > > > >> the
>> > > > >> > Aurora PMC, we hope to mitigate this issue.
>> > > > >> >
>> > > > >> > It would be fantastic to see some initiative from long
>> > contributing
>> > > > >> members
>> > > > >> > to make a case for themselves for being considered for committer
>> > > > and/or
>> > > > >> PMC
>> > > > >> > membership.
>> > > > >> >
>> > > > >> > 2. Binary packages. While we have been struggling to get enough
>> > > votes
>> > > > >> for
>> > > > >> > making the release official, the voting process has been marked
>> > by a
>> > > > >> lack
>> > > > >> > of enthusiasm from the community.
>> > > > >> >
>> > > > >> > I know that many folks are using these packages (including
>> > myself),
>> > > > but
>> > > > >> we
>> > > > >> > need to hear feedback when we call votes. It is not enough to
>> > stand
>> > > by
>> > > > >> > silently if everything works; please let us know about it.
>> > > > >> >
>> > > > >> > As it stands, the enthusiasm (or lack thereof) for binary packages
>> > > > >> doesn't
>> > > > >> > justify the overhead involved in releasing them. Therefore I
>> > propose
>> > > > >> that
>> > > > >> > we drop official binary packages for the next release. This is up
>> > > for
>> > > > >> > discussion and I'd love to hear everyone's opinion on this.
>> > > > >> >
>> > > > >> > An alternative to ending binary packages would be to automate the
>> > > > >> process
>> > > > >> > on tar.gz releases, but that would most likely need to be a
>> > > community
>> > > > >> > contribution.
>> > > > >> >
>> > > > >> > 3. Version 1.0. I realize this is a touchy subject. While other
>> > > > projects
>> > > > >> > that were started around the same time as Aurora, such as Mesos
>> > > > itself,
>> > > > >> > have gone on to make a 1.0 release (indicating the projects
>> > > maturity),
>> > > > >> we
>> > > > >> > have stuck to our 0.X.0 releases.
>> > > > >> >
>> > > > >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0,
>> > but
>> > > I
>> > > > >> > wanted to bring up for discussion how everyone felt about making
>> > our
>> > > > >> next
>> > > > >> > release a 1.0 release to reflect the stability and maturity of the
>> > > > >> project.
>> > > > >> >
>> > > > >> > That is all from me, if anyone else has any other concerns
>> > regarding
>> > > > the
>> > > > >> > Aurora community, feel free to bring it up in this thread!
>> > > > >> >
>> > > > >> > -Renan
>> > > > >> >
>> > > > >> >
>> > > > >> > [1] https://projects.apache.org/committee.html?aurora
>> > > > >> > [2] https://lists.apache.org/thread.html/
>> > > > 9df9d142408efffd11a1cdc5e4c1e3
>> > > > >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http://
>> > > > 3Cdev.aurora.apache.org>%3E
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > > >
>> > >
>> >
>
Re: [DISCUSS] State of the Community
Posted by Meghdoot bhattacharya <me...@yahoo.com.INVALID>.
I would love to see roadmaps, potential new features that would bring fresh energy and excitement rather than a maintenance project kind of feel. I think this project brings a lot that more hyped projects do not but stagnation can hurt.
Thx
> On May 22, 2018, at 4:18 PM, Santhosh Kumar Shanmugham <ss...@twitter.com> wrote:
>
> I would like to see this community become active again. If we can fix the gaps
> with processes that David explained above, I am sure we can revive the community.
>
> As for the timely reviews, I have a couple of requests:
> - Triage - find appropriate reviewers for each patch to assign ownership
> - Expectations - work with the author to set meaningful timelines for review round-trips
>
> -Santhosh
>
>> On Tue, May 22, 2018 at 2:26 PM, Renan DelValle <re...@gmail.com> wrote:
>> Thanks for the feedback David!
>>
>> On Tue, May 22, 2018 at 9:55 AM, David McLaughlin <dm...@apache.org>
>> wrote:
>>
>> > I feel like not getting code reviews is often a symptom of some other
>> > fundamental issue with how change is introduced to a community.
>> >
>> > When I joined the Aurora team at Twitter there were some principals in
>> > place for getting your changes accepted to the community and I still feel
>> > like when you follow them, getting code reviews rarely requires more than a
>> > gentle ping. Maybe none of these have been formally communicated or shared
>> > externally, but some of the principals I've picked up include:
>> >
>> > * Introduce problems before solutions.
>> > * Get buy-in that this is a problem worth solving.
>> > * Work towards abstractions that work for the community and not just for
>> > your specific use case.
>> > * Solicit early feedback on potential solutions.
>> > * Get explicit buy-in for the solution (these +1s would be the people you
>> > add to the reviewers list later). This usually means writing a Design Doc.
>> > * Plan your work carefully to avoid the dreaded code dumps (where
>> > possible). For large efforts work towards multiple, small patches that are
>> > easy to review.
>> > * Follow-up on review feedback quickly to avoid demanding expensive paging
>> > and context-switches from your reviewers later.
>> > * Build trust by thinking through production rollout and rollback
>> > scenarios.
>> >
>>
>> All good points and I think those of us that have been here long enough do
>> strive to follow these principles. For what it's worth,
>> I've always really appreciated the feedback from the folks running at scale
>> when it comes to my contributions. It shows they care
>> about the project and pushes me to write better code.
>>
>> That said, since these are mostly unwritten rules, either we need to write
>> them down or we need to cope with the
>> fact that some folks may not follow them. What would really be unfortunate
>> is to lose potential contributors because
>> they get discouraged after submitting a patch and running into this
>> "invisible" red tape. I can already see this happening
>> such as in https://reviews.apache.org/r/66490/
>>
>> There may not be a solution to that problem (and may be a different problem
>> altogether) but it would at least be
>> nice to have an outline of what procedure is expected from potential
>> contributors.
>>
>> Another thing I'd like to bring up is that our use of JIRA has drastically
>> decreased. There is very little activity going on there.
>> That used to be the starting point of discussion for any contribution. As
>> engagement has dropped, that's pretty much gone away
>> leaving us without much defense in shutting down an idea before it's coded.
>>
>>
>> >
>> > There is obviously more than just this list, but a lot of the patches that
>> > struggle to get reviews (or get hard -1s after a bunch of work is done)
>> > fail on one (or more) of these fundamental ideas.
>> >
>>
>> I agree on this point but what concerns me more than the -1's is the lack
>> of engagement. For example
>> https://reviews.apache.org/r/66537/
>>
>> If we want to engage the community, we gotta give feedback, good or bad.
>> For me, letting review requests rot is one sure fire indicator to
>> potential contributors that sending a contribution is not worth their time
>> or effort (and our process is pretty time consuming given the outline we
>> tend to follow above).
>>
>>
>> We should find a way to keep the core tenets outlined above while
>> streamlining the process. Maybe move away from reviewboard
>> into gitbox so we can do code reviews on github? Not sure if this would
>> help at all, but it may since folks are more familiar with that workflow
>> so it brings down a barrier for contribution.
>>
>>
>> (Side note: maybe it's a good time to propose a cleanup in reviewboard. Right
>> now our group page on reviewboard looks like a graveyard.
>> In my opinion, anything older than a year isn't likely to be committed and
>> should therefore be discarded. I can put this to a vote if the general
>> consensus is
>> positive towards this idea.)
>>
>>
>> > It's also worth calling out that having informal discussions on Slack is
>> > fine, but should also be done on the dev lists, and ideally in the form of
>> > a written document. This is the best way to include those of who feel like
>> > Slack is a massive productivity drain :)
>>
>>
>> Noted, though I will say our slack channel doesn't have much of a pulse
>> these days either (and hasn't for quite some time).
>>
>>
>> >
>> >
>> I guess this is my long-winded way of saying that I'm a -1 on moving to
>> > lazy consensus.
>> >
>> > I wonder if a lot of the concerns can be solved by just improving
>> > communication? Maybe we can revive the weekly developer meeting that we
>> > used to run in IRC.
>> >
>>
>> This would be great but sadly I just don't see the engagement we need to be
>> able to pull this off. We could not even get enough interest to
>> host an Aurora Meetup, so I see this as an uphill battle if we attempt it.
>>
>> I could be wrong though and I would be more than happy to be part of it if
>> we start running it.
>>
>> -Renan
>>
>> >
>> >
>> > On Tue, May 22, 2018 at 8:58 AM, Renan DelValle <re...@apache.org> wrote:
>> >
>> > > Thanks for your input Stephan, very much appreciated! Replies inline:
>> > >
>> > > On Tue, May 22, 2018 at 12:12 AM, Stephan Erb <
>> > stephan.erb@blue-yonder.com
>> > > >
>> > > wrote:
>> > >
>> > > > Hey Renan,
>> > > >
>> > > > thanks again for bringing this up. In my experience, the pain comes
>> > from
>> > > > building, testing & voting rather the packaging scripts themselves. I
>> > > > therefore think we should discontinue building, but continue to
>> > maintain
>> > > > the scripts so that users can build them on their own when necessary.
>> > > >
>> > >
>> > > Fully agree on this. I will even go as far as making unofficial builds
>> > > available for the time being if no one is opposed and if it's not against
>> > > Apache policy to do so.
>> > >
>> > > >
>> > > > We must be careful though with linking the ‘nightly jenkins builds’ on
>> > > the
>> > > > website. We got called out for this once in the past and had to take
>> > the
>> > > > link down.
>> > > >
>> > >
>> > > Noted, thanks for bringing this up!
>> > >
>> > > >
>> > > > We also see a lack of involvement in code reviews. I think we should
>> > > > consider setting up a more formal lazy consensus policy
>> > > > https://www.apache.org/foundation/voting.html#LazyConsensus : For
>> > > > example, patches maybe merged even with a single ‘ship it’ from a
>> > > > committer, if there is neither a ship-it nor a veto from other
>> > committers
>> > > > within 7 days.
>> > > >
>> > >
>> > > I think this is a very valid way forward at this point. How does everyone
>> > > else feel about this?
>> > >
>> > > >
>> > > > Best regards,
>> > > > Stephan
>> > > >
>> > >
>> > >
>> > > -Renan
>> > >
>> > > >
>> > > > From: Santhosh Kumar Shanmugham <ss...@twitter.com>
>> > > > Reply-To: "user@aurora.apache.org" <us...@aurora.apache.org>
>> > > > Date: Thursday, 17. May 2018 at 22:13
>> > > > To: "dev@aurora.apache.org" <de...@aurora.apache.org>
>> > > > Cc: "user@aurora.apache.org" <us...@aurora.apache.org>
>> > > > Subject: Re: [DISCUSS] State of the Community
>> > > >
>> > > > Hello Renan,
>> > > >
>> > > > I understand your frustration.
>> > > >
>> > > > I am a strong +1 for automating the release and voting process. I
>> > > performed
>> > > > a release a while back and the process definitely needs it improve
>> > > > documentation
>> > > > at the least. If one of the members who are more familiar with this
>> > > > process can
>> > > > create a backlog, I will be happy to chip in.
>> > > >
>> > > > -Santhosh
>> > > >
>> > > > On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <renan@apache.org
>> > > <mailto:
>> > > > renan@apache.org>> wrote:
>> > > > All,
>> > > >
>> > > > Discussion has been open for 13 days and only one user has chimed in.
>> > > > Unfortunately it looks like talking point number one will be a serious
>> > > > concern going forward. I will give until tomorrow 12 PM San Francisco
>> > > time
>> > > > for folks to voice their opinion on these issues.
>> > > >
>> > > > After tomorrow I will call a vote to cease distributions of official
>> > > binary
>> > > > packages from versions 0.21.0 onwards until the process is automated
>> > and
>> > > > voting for the voting for the binary packages can be combined with the
>> > > > tar.gz release.
>> > > >
>> > > > Since no feedback was received regarding talking point three, the idea
>> > > will
>> > > > be dropped.
>> > > >
>> > > > -Renan
>> > > >
>> > > >
>> > > > On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <
>> > renanidelvalle@gmail.com
>> > > <
>> > > > mailto:renanidelvalle@gmail.com>>
>> > > > wrote:
>> > > >
>> > > > > In some ways, that's some of the best feedback we can get. Very happy
>> > > to
>> > > > > hear that Aurora is working fo well for Chartbeat.
>> > > > >
>> > > > > I do hope that you guys find some time to help us maintain the
>> > project.
>> > > > > Every little bit counts!
>> > > > >
>> > > > > -Renan
>> > > > >
>> > > > > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <rick@chartbeat.com
>> > > <mailto:
>> > > > rick@chartbeat.com>> wrote:
>> > > > >
>> > > > >> As strong users of aurora but weak contributors, we at Chartbeat
>> > > > >> apologize for our lack of participation. We’re several versions
>> > behind
>> > > > on
>> > > > >> mesos/aurora upgrades and that’s honestly because it works for us :)
>> > > > >>
>> > > > >> Going forward we’re hoping to be able to participate more, at least
>> > > with
>> > > > >> testing new releases.
>> > > > >>
>> > > > >> We thank you though!
>> > > > >>
>> > > > >> Rick and the rest of Chartbeat Engineering
>> > > > >>
>> > > > >>
>> > > > >> > On May 4, 2018, at 2:38 PM, Renan DelValle <renan@apache.org
>> > > <mailto:
>> > > > renan@apache.org>> wrote:
>> > > > >> >
>> > > > >> > Hello all,
>> > > > >> >
>> > > > >> > I wanted to bring up a few points for discussion with the
>> > community.
>> > > > I'd
>> > > > >> > really like to hear what the community's thoughts are on these
>> > > issues
>> > > > >> and
>> > > > >> > how can resolve them.
>> > > > >> >
>> > > > >> > 1. Lack of participation. This is due to many members moving on
>> > from
>> > > > the
>> > > > >> > project and becoming dormant. More concerning is the fact that our
>> > > PMC
>> > > > >> > roster sits at 21 members [1] of which fewer than half have
>> > > > >> participated in
>> > > > >> > the project during the last 6 months.
>> > > > >> >
>> > > > >> > This inactivity has led the voting process for releases to be held
>> > > up
>> > > > by
>> > > > >> > the inability to reach the required minimum 3 votes for releases
>> > > (both
>> > > > >> > tar.gz and binary). Our latest binary packaging vote has been
>> > going
>> > > on
>> > > > >> for
>> > > > >> > more than a month. [2]
>> > > > >> >
>> > > > >> > With the recent additions of Santhosh Kumar Shanmugham and Jordan
>> > Ly
>> > > > to
>> > > > >> the
>> > > > >> > Aurora PMC, we hope to mitigate this issue.
>> > > > >> >
>> > > > >> > It would be fantastic to see some initiative from long
>> > contributing
>> > > > >> members
>> > > > >> > to make a case for themselves for being considered for committer
>> > > > and/or
>> > > > >> PMC
>> > > > >> > membership.
>> > > > >> >
>> > > > >> > 2. Binary packages. While we have been struggling to get enough
>> > > votes
>> > > > >> for
>> > > > >> > making the release official, the voting process has been marked
>> > by a
>> > > > >> lack
>> > > > >> > of enthusiasm from the community.
>> > > > >> >
>> > > > >> > I know that many folks are using these packages (including
>> > myself),
>> > > > but
>> > > > >> we
>> > > > >> > need to hear feedback when we call votes. It is not enough to
>> > stand
>> > > by
>> > > > >> > silently if everything works; please let us know about it.
>> > > > >> >
>> > > > >> > As it stands, the enthusiasm (or lack thereof) for binary packages
>> > > > >> doesn't
>> > > > >> > justify the overhead involved in releasing them. Therefore I
>> > propose
>> > > > >> that
>> > > > >> > we drop official binary packages for the next release. This is up
>> > > for
>> > > > >> > discussion and I'd love to hear everyone's opinion on this.
>> > > > >> >
>> > > > >> > An alternative to ending binary packages would be to automate the
>> > > > >> process
>> > > > >> > on tar.gz releases, but that would most likely need to be a
>> > > community
>> > > > >> > contribution.
>> > > > >> >
>> > > > >> > 3. Version 1.0. I realize this is a touchy subject. While other
>> > > > projects
>> > > > >> > that were started around the same time as Aurora, such as Mesos
>> > > > itself,
>> > > > >> > have gone on to make a 1.0 release (indicating the projects
>> > > maturity),
>> > > > >> we
>> > > > >> > have stuck to our 0.X.0 releases.
>> > > > >> >
>> > > > >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0,
>> > but
>> > > I
>> > > > >> > wanted to bring up for discussion how everyone felt about making
>> > our
>> > > > >> next
>> > > > >> > release a 1.0 release to reflect the stability and maturity of the
>> > > > >> project.
>> > > > >> >
>> > > > >> > That is all from me, if anyone else has any other concerns
>> > regarding
>> > > > the
>> > > > >> > Aurora community, feel free to bring it up in this thread!
>> > > > >> >
>> > > > >> > -Renan
>> > > > >> >
>> > > > >> >
>> > > > >> > [1] https://projects.apache.org/committee.html?aurora
>> > > > >> > [2] https://lists.apache.org/thread.html/
>> > > > 9df9d142408efffd11a1cdc5e4c1e3
>> > > > >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http://
>> > > > 3Cdev.aurora.apache.org>%3E
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > > >
>> > >
>> >
>
Re: [DISCUSS] State of the Community
Posted by Santhosh Kumar Shanmugham <ss...@twitter.com.INVALID>.
I would like to see this community become active again. If we can fix the
gaps
with processes that David explained above, I am sure we can revive the
community.
As for the timely reviews, I have a couple of requests:
- Triage - find appropriate reviewers for each patch to assign ownership
- Expectations - work with the author to set meaningful timelines for
review round-trips
-Santhosh
On Tue, May 22, 2018 at 2:26 PM, Renan DelValle <re...@gmail.com>
wrote:
> Thanks for the feedback David!
>
> On Tue, May 22, 2018 at 9:55 AM, David McLaughlin <dm...@apache.org>
> wrote:
>
> > I feel like not getting code reviews is often a symptom of some other
> > fundamental issue with how change is introduced to a community.
> >
> > When I joined the Aurora team at Twitter there were some principals in
> > place for getting your changes accepted to the community and I still feel
> > like when you follow them, getting code reviews rarely requires more
> than a
> > gentle ping. Maybe none of these have been formally communicated or
> shared
> > externally, but some of the principals I've picked up include:
> >
> > * Introduce problems before solutions.
> > * Get buy-in that this is a problem worth solving.
> > * Work towards abstractions that work for the community and not just for
> > your specific use case.
> > * Solicit early feedback on potential solutions.
> > * Get explicit buy-in for the solution (these +1s would be the people you
> > add to the reviewers list later). This usually means writing a Design
> Doc.
> > * Plan your work carefully to avoid the dreaded code dumps (where
> > possible). For large efforts work towards multiple, small patches that
> are
> > easy to review.
> > * Follow-up on review feedback quickly to avoid demanding expensive
> paging
> > and context-switches from your reviewers later.
> > * Build trust by thinking through production rollout and rollback
> > scenarios.
> >
>
> All good points and I think those of us that have been here long enough do
> strive to follow these principles. For what it's worth,
> I've always really appreciated the feedback from the folks running at scale
> when it comes to my contributions. It shows they care
> about the project and pushes me to write better code.
>
> That said, since these are mostly unwritten rules, either we need to write
> them down or we need to cope with the
> fact that some folks may not follow them. What would really be unfortunate
> is to lose potential contributors because
> they get discouraged after submitting a patch and running into this
> "invisible" red tape. I can already see this happening
> such as in https://reviews.apache.org/r/66490/
>
> There may not be a solution to that problem (and may be a different problem
> altogether) but it would at least be
> nice to have an outline of what procedure is expected from potential
> contributors.
>
> Another thing I'd like to bring up is that our use of JIRA has drastically
> decreased. There is very little activity going on there.
> That used to be the starting point of discussion for any contribution. As
> engagement has dropped, that's pretty much gone away
> leaving us without much defense in shutting down an idea before it's coded.
>
>
> >
> > There is obviously more than just this list, but a lot of the patches
> that
> > struggle to get reviews (or get hard -1s after a bunch of work is done)
> > fail on one (or more) of these fundamental ideas.
> >
>
> I agree on this point but what concerns me more than the -1's is the lack
> of engagement. For example
> https://reviews.apache.org/r/66537/
>
> If we want to engage the community, we gotta give feedback, good or bad.
> For me, letting review requests rot is one sure fire indicator to
> potential contributors that sending a contribution is not worth their time
> or effort (and our process is pretty time consuming given the outline we
> tend to follow above).
>
>
> We should find a way to keep the core tenets outlined above while
> streamlining the process. Maybe move away from reviewboard
> into gitbox so we can do code reviews on github? Not sure if this would
> help at all, but it may since folks are more familiar with that workflow
> so it brings down a barrier for contribution.
>
>
> (Side note: maybe it's a good time to propose a cleanup in reviewboard.
> Right
> now our group page on reviewboard looks like a graveyard.
> In my opinion, anything older than a year isn't likely to be committed and
> should therefore be discarded. I can put this to a vote if the general
> consensus is
> positive towards this idea.)
>
>
> > It's also worth calling out that having informal discussions on Slack is
> > fine, but should also be done on the dev lists, and ideally in the form
> of
> > a written document. This is the best way to include those of who feel
> like
> > Slack is a massive productivity drain :)
>
>
> Noted, though I will say our slack channel doesn't have much of a pulse
> these days either (and hasn't for quite some time).
>
>
> >
> >
> I guess this is my long-winded way of saying that I'm a -1 on moving to
> > lazy consensus.
> >
> > I wonder if a lot of the concerns can be solved by just improving
> > communication? Maybe we can revive the weekly developer meeting that we
> > used to run in IRC.
> >
>
> This would be great but sadly I just don't see the engagement we need to be
> able to pull this off. We could not even get enough interest to
> host an Aurora Meetup, so I see this as an uphill battle if we attempt it.
>
> I could be wrong though and I would be more than happy to be part of it if
> we start running it.
>
> -Renan
>
> >
> >
> > On Tue, May 22, 2018 at 8:58 AM, Renan DelValle <re...@apache.org>
> wrote:
> >
> > > Thanks for your input Stephan, very much appreciated! Replies inline:
> > >
> > > On Tue, May 22, 2018 at 12:12 AM, Stephan Erb <
> > stephan.erb@blue-yonder.com
> > > >
> > > wrote:
> > >
> > > > Hey Renan,
> > > >
> > > > thanks again for bringing this up. In my experience, the pain comes
> > from
> > > > building, testing & voting rather the packaging scripts themselves. I
> > > > therefore think we should discontinue building, but continue to
> > maintain
> > > > the scripts so that users can build them on their own when necessary.
> > > >
> > >
> > > Fully agree on this. I will even go as far as making unofficial builds
> > > available for the time being if no one is opposed and if it's not
> against
> > > Apache policy to do so.
> > >
> > > >
> > > > We must be careful though with linking the ‘nightly jenkins builds’
> on
> > > the
> > > > website. We got called out for this once in the past and had to take
> > the
> > > > link down.
> > > >
> > >
> > > Noted, thanks for bringing this up!
> > >
> > > >
> > > > We also see a lack of involvement in code reviews. I think we should
> > > > consider setting up a more formal lazy consensus policy
> > > > https://www.apache.org/foundation/voting.html#LazyConsensus : For
> > > > example, patches maybe merged even with a single ‘ship it’ from a
> > > > committer, if there is neither a ship-it nor a veto from other
> > committers
> > > > within 7 days.
> > > >
> > >
> > > I think this is a very valid way forward at this point. How does
> everyone
> > > else feel about this?
> > >
> > > >
> > > > Best regards,
> > > > Stephan
> > > >
> > >
> > >
> > > -Renan
> > >
> > > >
> > > > From: Santhosh Kumar Shanmugham <ss...@twitter.com>
> > > > Reply-To: "user@aurora.apache.org" <us...@aurora.apache.org>
> > > > Date: Thursday, 17. May 2018 at 22:13
> > > > To: "dev@aurora.apache.org" <de...@aurora.apache.org>
> > > > Cc: "user@aurora.apache.org" <us...@aurora.apache.org>
> > > > Subject: Re: [DISCUSS] State of the Community
> > > >
> > > > Hello Renan,
> > > >
> > > > I understand your frustration.
> > > >
> > > > I am a strong +1 for automating the release and voting process. I
> > > performed
> > > > a release a while back and the process definitely needs it improve
> > > > documentation
> > > > at the least. If one of the members who are more familiar with this
> > > > process can
> > > > create a backlog, I will be happy to chip in.
> > > >
> > > > -Santhosh
> > > >
> > > > On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <renan@apache.org
> > > <mailto:
> > > > renan@apache.org>> wrote:
> > > > All,
> > > >
> > > > Discussion has been open for 13 days and only one user has chimed in.
> > > > Unfortunately it looks like talking point number one will be a
> serious
> > > > concern going forward. I will give until tomorrow 12 PM San Francisco
> > > time
> > > > for folks to voice their opinion on these issues.
> > > >
> > > > After tomorrow I will call a vote to cease distributions of official
> > > binary
> > > > packages from versions 0.21.0 onwards until the process is automated
> > and
> > > > voting for the voting for the binary packages can be combined with
> the
> > > > tar.gz release.
> > > >
> > > > Since no feedback was received regarding talking point three, the
> idea
> > > will
> > > > be dropped.
> > > >
> > > > -Renan
> > > >
> > > >
> > > > On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <
> > renanidelvalle@gmail.com
> > > <
> > > > mailto:renanidelvalle@gmail.com>>
> > > > wrote:
> > > >
> > > > > In some ways, that's some of the best feedback we can get. Very
> happy
> > > to
> > > > > hear that Aurora is working fo well for Chartbeat.
> > > > >
> > > > > I do hope that you guys find some time to help us maintain the
> > project.
> > > > > Every little bit counts!
> > > > >
> > > > > -Renan
> > > > >
> > > > > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <rick@chartbeat.com
> > > <mailto:
> > > > rick@chartbeat.com>> wrote:
> > > > >
> > > > >> As strong users of aurora but weak contributors, we at Chartbeat
> > > > >> apologize for our lack of participation. We’re several versions
> > behind
> > > > on
> > > > >> mesos/aurora upgrades and that’s honestly because it works for us
> :)
> > > > >>
> > > > >> Going forward we’re hoping to be able to participate more, at
> least
> > > with
> > > > >> testing new releases.
> > > > >>
> > > > >> We thank you though!
> > > > >>
> > > > >> Rick and the rest of Chartbeat Engineering
> > > > >>
> > > > >>
> > > > >> > On May 4, 2018, at 2:38 PM, Renan DelValle <renan@apache.org
> > > <mailto:
> > > > renan@apache.org>> wrote:
> > > > >> >
> > > > >> > Hello all,
> > > > >> >
> > > > >> > I wanted to bring up a few points for discussion with the
> > community.
> > > > I'd
> > > > >> > really like to hear what the community's thoughts are on these
> > > issues
> > > > >> and
> > > > >> > how can resolve them.
> > > > >> >
> > > > >> > 1. Lack of participation. This is due to many members moving on
> > from
> > > > the
> > > > >> > project and becoming dormant. More concerning is the fact that
> our
> > > PMC
> > > > >> > roster sits at 21 members [1] of which fewer than half have
> > > > >> participated in
> > > > >> > the project during the last 6 months.
> > > > >> >
> > > > >> > This inactivity has led the voting process for releases to be
> held
> > > up
> > > > by
> > > > >> > the inability to reach the required minimum 3 votes for releases
> > > (both
> > > > >> > tar.gz and binary). Our latest binary packaging vote has been
> > going
> > > on
> > > > >> for
> > > > >> > more than a month. [2]
> > > > >> >
> > > > >> > With the recent additions of Santhosh Kumar Shanmugham and
> Jordan
> > Ly
> > > > to
> > > > >> the
> > > > >> > Aurora PMC, we hope to mitigate this issue.
> > > > >> >
> > > > >> > It would be fantastic to see some initiative from long
> > contributing
> > > > >> members
> > > > >> > to make a case for themselves for being considered for committer
> > > > and/or
> > > > >> PMC
> > > > >> > membership.
> > > > >> >
> > > > >> > 2. Binary packages. While we have been struggling to get enough
> > > votes
> > > > >> for
> > > > >> > making the release official, the voting process has been marked
> > by a
> > > > >> lack
> > > > >> > of enthusiasm from the community.
> > > > >> >
> > > > >> > I know that many folks are using these packages (including
> > myself),
> > > > but
> > > > >> we
> > > > >> > need to hear feedback when we call votes. It is not enough to
> > stand
> > > by
> > > > >> > silently if everything works; please let us know about it.
> > > > >> >
> > > > >> > As it stands, the enthusiasm (or lack thereof) for binary
> packages
> > > > >> doesn't
> > > > >> > justify the overhead involved in releasing them. Therefore I
> > propose
> > > > >> that
> > > > >> > we drop official binary packages for the next release. This is
> up
> > > for
> > > > >> > discussion and I'd love to hear everyone's opinion on this.
> > > > >> >
> > > > >> > An alternative to ending binary packages would be to automate
> the
> > > > >> process
> > > > >> > on tar.gz releases, but that would most likely need to be a
> > > community
> > > > >> > contribution.
> > > > >> >
> > > > >> > 3. Version 1.0. I realize this is a touchy subject. While other
> > > > projects
> > > > >> > that were started around the same time as Aurora, such as Mesos
> > > > itself,
> > > > >> > have gone on to make a 1.0 release (indicating the projects
> > > maturity),
> > > > >> we
> > > > >> > have stuck to our 0.X.0 releases.
> > > > >> >
> > > > >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0,
> > but
> > > I
> > > > >> > wanted to bring up for discussion how everyone felt about making
> > our
> > > > >> next
> > > > >> > release a 1.0 release to reflect the stability and maturity of
> the
> > > > >> project.
> > > > >> >
> > > > >> > That is all from me, if anyone else has any other concerns
> > regarding
> > > > the
> > > > >> > Aurora community, feel free to bring it up in this thread!
> > > > >> >
> > > > >> > -Renan
> > > > >> >
> > > > >> >
> > > > >> > [1] https://projects.apache.org/committee.html?aurora
> > > > >> > [2] https://lists.apache.org/thread.html/
> > > > 9df9d142408efffd11a1cdc5e4c1e3
> > > > >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http://
> > > > 3Cdev.aurora.apache.org>%3E
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> >
>
Re: [DISCUSS] State of the Community
Posted by Santhosh Kumar Shanmugham <ss...@twitter.com>.
I would like to see this community become active again. If we can fix the
gaps
with processes that David explained above, I am sure we can revive the
community.
As for the timely reviews, I have a couple of requests:
- Triage - find appropriate reviewers for each patch to assign ownership
- Expectations - work with the author to set meaningful timelines for
review round-trips
-Santhosh
On Tue, May 22, 2018 at 2:26 PM, Renan DelValle <re...@gmail.com>
wrote:
> Thanks for the feedback David!
>
> On Tue, May 22, 2018 at 9:55 AM, David McLaughlin <dm...@apache.org>
> wrote:
>
> > I feel like not getting code reviews is often a symptom of some other
> > fundamental issue with how change is introduced to a community.
> >
> > When I joined the Aurora team at Twitter there were some principals in
> > place for getting your changes accepted to the community and I still feel
> > like when you follow them, getting code reviews rarely requires more
> than a
> > gentle ping. Maybe none of these have been formally communicated or
> shared
> > externally, but some of the principals I've picked up include:
> >
> > * Introduce problems before solutions.
> > * Get buy-in that this is a problem worth solving.
> > * Work towards abstractions that work for the community and not just for
> > your specific use case.
> > * Solicit early feedback on potential solutions.
> > * Get explicit buy-in for the solution (these +1s would be the people you
> > add to the reviewers list later). This usually means writing a Design
> Doc.
> > * Plan your work carefully to avoid the dreaded code dumps (where
> > possible). For large efforts work towards multiple, small patches that
> are
> > easy to review.
> > * Follow-up on review feedback quickly to avoid demanding expensive
> paging
> > and context-switches from your reviewers later.
> > * Build trust by thinking through production rollout and rollback
> > scenarios.
> >
>
> All good points and I think those of us that have been here long enough do
> strive to follow these principles. For what it's worth,
> I've always really appreciated the feedback from the folks running at scale
> when it comes to my contributions. It shows they care
> about the project and pushes me to write better code.
>
> That said, since these are mostly unwritten rules, either we need to write
> them down or we need to cope with the
> fact that some folks may not follow them. What would really be unfortunate
> is to lose potential contributors because
> they get discouraged after submitting a patch and running into this
> "invisible" red tape. I can already see this happening
> such as in https://reviews.apache.org/r/66490/
>
> There may not be a solution to that problem (and may be a different problem
> altogether) but it would at least be
> nice to have an outline of what procedure is expected from potential
> contributors.
>
> Another thing I'd like to bring up is that our use of JIRA has drastically
> decreased. There is very little activity going on there.
> That used to be the starting point of discussion for any contribution. As
> engagement has dropped, that's pretty much gone away
> leaving us without much defense in shutting down an idea before it's coded.
>
>
> >
> > There is obviously more than just this list, but a lot of the patches
> that
> > struggle to get reviews (or get hard -1s after a bunch of work is done)
> > fail on one (or more) of these fundamental ideas.
> >
>
> I agree on this point but what concerns me more than the -1's is the lack
> of engagement. For example
> https://reviews.apache.org/r/66537/
>
> If we want to engage the community, we gotta give feedback, good or bad.
> For me, letting review requests rot is one sure fire indicator to
> potential contributors that sending a contribution is not worth their time
> or effort (and our process is pretty time consuming given the outline we
> tend to follow above).
>
>
> We should find a way to keep the core tenets outlined above while
> streamlining the process. Maybe move away from reviewboard
> into gitbox so we can do code reviews on github? Not sure if this would
> help at all, but it may since folks are more familiar with that workflow
> so it brings down a barrier for contribution.
>
>
> (Side note: maybe it's a good time to propose a cleanup in reviewboard.
> Right
> now our group page on reviewboard looks like a graveyard.
> In my opinion, anything older than a year isn't likely to be committed and
> should therefore be discarded. I can put this to a vote if the general
> consensus is
> positive towards this idea.)
>
>
> > It's also worth calling out that having informal discussions on Slack is
> > fine, but should also be done on the dev lists, and ideally in the form
> of
> > a written document. This is the best way to include those of who feel
> like
> > Slack is a massive productivity drain :)
>
>
> Noted, though I will say our slack channel doesn't have much of a pulse
> these days either (and hasn't for quite some time).
>
>
> >
> >
> I guess this is my long-winded way of saying that I'm a -1 on moving to
> > lazy consensus.
> >
> > I wonder if a lot of the concerns can be solved by just improving
> > communication? Maybe we can revive the weekly developer meeting that we
> > used to run in IRC.
> >
>
> This would be great but sadly I just don't see the engagement we need to be
> able to pull this off. We could not even get enough interest to
> host an Aurora Meetup, so I see this as an uphill battle if we attempt it.
>
> I could be wrong though and I would be more than happy to be part of it if
> we start running it.
>
> -Renan
>
> >
> >
> > On Tue, May 22, 2018 at 8:58 AM, Renan DelValle <re...@apache.org>
> wrote:
> >
> > > Thanks for your input Stephan, very much appreciated! Replies inline:
> > >
> > > On Tue, May 22, 2018 at 12:12 AM, Stephan Erb <
> > stephan.erb@blue-yonder.com
> > > >
> > > wrote:
> > >
> > > > Hey Renan,
> > > >
> > > > thanks again for bringing this up. In my experience, the pain comes
> > from
> > > > building, testing & voting rather the packaging scripts themselves. I
> > > > therefore think we should discontinue building, but continue to
> > maintain
> > > > the scripts so that users can build them on their own when necessary.
> > > >
> > >
> > > Fully agree on this. I will even go as far as making unofficial builds
> > > available for the time being if no one is opposed and if it's not
> against
> > > Apache policy to do so.
> > >
> > > >
> > > > We must be careful though with linking the ‘nightly jenkins builds’
> on
> > > the
> > > > website. We got called out for this once in the past and had to take
> > the
> > > > link down.
> > > >
> > >
> > > Noted, thanks for bringing this up!
> > >
> > > >
> > > > We also see a lack of involvement in code reviews. I think we should
> > > > consider setting up a more formal lazy consensus policy
> > > > https://www.apache.org/foundation/voting.html#LazyConsensus : For
> > > > example, patches maybe merged even with a single ‘ship it’ from a
> > > > committer, if there is neither a ship-it nor a veto from other
> > committers
> > > > within 7 days.
> > > >
> > >
> > > I think this is a very valid way forward at this point. How does
> everyone
> > > else feel about this?
> > >
> > > >
> > > > Best regards,
> > > > Stephan
> > > >
> > >
> > >
> > > -Renan
> > >
> > > >
> > > > From: Santhosh Kumar Shanmugham <ss...@twitter.com>
> > > > Reply-To: "user@aurora.apache.org" <us...@aurora.apache.org>
> > > > Date: Thursday, 17. May 2018 at 22:13
> > > > To: "dev@aurora.apache.org" <de...@aurora.apache.org>
> > > > Cc: "user@aurora.apache.org" <us...@aurora.apache.org>
> > > > Subject: Re: [DISCUSS] State of the Community
> > > >
> > > > Hello Renan,
> > > >
> > > > I understand your frustration.
> > > >
> > > > I am a strong +1 for automating the release and voting process. I
> > > performed
> > > > a release a while back and the process definitely needs it improve
> > > > documentation
> > > > at the least. If one of the members who are more familiar with this
> > > > process can
> > > > create a backlog, I will be happy to chip in.
> > > >
> > > > -Santhosh
> > > >
> > > > On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <renan@apache.org
> > > <mailto:
> > > > renan@apache.org>> wrote:
> > > > All,
> > > >
> > > > Discussion has been open for 13 days and only one user has chimed in.
> > > > Unfortunately it looks like talking point number one will be a
> serious
> > > > concern going forward. I will give until tomorrow 12 PM San Francisco
> > > time
> > > > for folks to voice their opinion on these issues.
> > > >
> > > > After tomorrow I will call a vote to cease distributions of official
> > > binary
> > > > packages from versions 0.21.0 onwards until the process is automated
> > and
> > > > voting for the voting for the binary packages can be combined with
> the
> > > > tar.gz release.
> > > >
> > > > Since no feedback was received regarding talking point three, the
> idea
> > > will
> > > > be dropped.
> > > >
> > > > -Renan
> > > >
> > > >
> > > > On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <
> > renanidelvalle@gmail.com
> > > <
> > > > mailto:renanidelvalle@gmail.com>>
> > > > wrote:
> > > >
> > > > > In some ways, that's some of the best feedback we can get. Very
> happy
> > > to
> > > > > hear that Aurora is working fo well for Chartbeat.
> > > > >
> > > > > I do hope that you guys find some time to help us maintain the
> > project.
> > > > > Every little bit counts!
> > > > >
> > > > > -Renan
> > > > >
> > > > > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <rick@chartbeat.com
> > > <mailto:
> > > > rick@chartbeat.com>> wrote:
> > > > >
> > > > >> As strong users of aurora but weak contributors, we at Chartbeat
> > > > >> apologize for our lack of participation. We’re several versions
> > behind
> > > > on
> > > > >> mesos/aurora upgrades and that’s honestly because it works for us
> :)
> > > > >>
> > > > >> Going forward we’re hoping to be able to participate more, at
> least
> > > with
> > > > >> testing new releases.
> > > > >>
> > > > >> We thank you though!
> > > > >>
> > > > >> Rick and the rest of Chartbeat Engineering
> > > > >>
> > > > >>
> > > > >> > On May 4, 2018, at 2:38 PM, Renan DelValle <renan@apache.org
> > > <mailto:
> > > > renan@apache.org>> wrote:
> > > > >> >
> > > > >> > Hello all,
> > > > >> >
> > > > >> > I wanted to bring up a few points for discussion with the
> > community.
> > > > I'd
> > > > >> > really like to hear what the community's thoughts are on these
> > > issues
> > > > >> and
> > > > >> > how can resolve them.
> > > > >> >
> > > > >> > 1. Lack of participation. This is due to many members moving on
> > from
> > > > the
> > > > >> > project and becoming dormant. More concerning is the fact that
> our
> > > PMC
> > > > >> > roster sits at 21 members [1] of which fewer than half have
> > > > >> participated in
> > > > >> > the project during the last 6 months.
> > > > >> >
> > > > >> > This inactivity has led the voting process for releases to be
> held
> > > up
> > > > by
> > > > >> > the inability to reach the required minimum 3 votes for releases
> > > (both
> > > > >> > tar.gz and binary). Our latest binary packaging vote has been
> > going
> > > on
> > > > >> for
> > > > >> > more than a month. [2]
> > > > >> >
> > > > >> > With the recent additions of Santhosh Kumar Shanmugham and
> Jordan
> > Ly
> > > > to
> > > > >> the
> > > > >> > Aurora PMC, we hope to mitigate this issue.
> > > > >> >
> > > > >> > It would be fantastic to see some initiative from long
> > contributing
> > > > >> members
> > > > >> > to make a case for themselves for being considered for committer
> > > > and/or
> > > > >> PMC
> > > > >> > membership.
> > > > >> >
> > > > >> > 2. Binary packages. While we have been struggling to get enough
> > > votes
> > > > >> for
> > > > >> > making the release official, the voting process has been marked
> > by a
> > > > >> lack
> > > > >> > of enthusiasm from the community.
> > > > >> >
> > > > >> > I know that many folks are using these packages (including
> > myself),
> > > > but
> > > > >> we
> > > > >> > need to hear feedback when we call votes. It is not enough to
> > stand
> > > by
> > > > >> > silently if everything works; please let us know about it.
> > > > >> >
> > > > >> > As it stands, the enthusiasm (or lack thereof) for binary
> packages
> > > > >> doesn't
> > > > >> > justify the overhead involved in releasing them. Therefore I
> > propose
> > > > >> that
> > > > >> > we drop official binary packages for the next release. This is
> up
> > > for
> > > > >> > discussion and I'd love to hear everyone's opinion on this.
> > > > >> >
> > > > >> > An alternative to ending binary packages would be to automate
> the
> > > > >> process
> > > > >> > on tar.gz releases, but that would most likely need to be a
> > > community
> > > > >> > contribution.
> > > > >> >
> > > > >> > 3. Version 1.0. I realize this is a touchy subject. While other
> > > > projects
> > > > >> > that were started around the same time as Aurora, such as Mesos
> > > > itself,
> > > > >> > have gone on to make a 1.0 release (indicating the projects
> > > maturity),
> > > > >> we
> > > > >> > have stuck to our 0.X.0 releases.
> > > > >> >
> > > > >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0,
> > but
> > > I
> > > > >> > wanted to bring up for discussion how everyone felt about making
> > our
> > > > >> next
> > > > >> > release a 1.0 release to reflect the stability and maturity of
> the
> > > > >> project.
> > > > >> >
> > > > >> > That is all from me, if anyone else has any other concerns
> > regarding
> > > > the
> > > > >> > Aurora community, feel free to bring it up in this thread!
> > > > >> >
> > > > >> > -Renan
> > > > >> >
> > > > >> >
> > > > >> > [1] https://projects.apache.org/committee.html?aurora
> > > > >> > [2] https://lists.apache.org/thread.html/
> > > > 9df9d142408efffd11a1cdc5e4c1e3
> > > > >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http://
> > > > 3Cdev.aurora.apache.org>%3E
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> >
>
Re: [DISCUSS] State of the Community
Posted by Renan DelValle <re...@gmail.com>.
Thanks for the feedback David!
On Tue, May 22, 2018 at 9:55 AM, David McLaughlin <dm...@apache.org>
wrote:
> I feel like not getting code reviews is often a symptom of some other
> fundamental issue with how change is introduced to a community.
>
> When I joined the Aurora team at Twitter there were some principals in
> place for getting your changes accepted to the community and I still feel
> like when you follow them, getting code reviews rarely requires more than a
> gentle ping. Maybe none of these have been formally communicated or shared
> externally, but some of the principals I've picked up include:
>
> * Introduce problems before solutions.
> * Get buy-in that this is a problem worth solving.
> * Work towards abstractions that work for the community and not just for
> your specific use case.
> * Solicit early feedback on potential solutions.
> * Get explicit buy-in for the solution (these +1s would be the people you
> add to the reviewers list later). This usually means writing a Design Doc.
> * Plan your work carefully to avoid the dreaded code dumps (where
> possible). For large efforts work towards multiple, small patches that are
> easy to review.
> * Follow-up on review feedback quickly to avoid demanding expensive paging
> and context-switches from your reviewers later.
> * Build trust by thinking through production rollout and rollback
> scenarios.
>
All good points and I think those of us that have been here long enough do
strive to follow these principles. For what it's worth,
I've always really appreciated the feedback from the folks running at scale
when it comes to my contributions. It shows they care
about the project and pushes me to write better code.
That said, since these are mostly unwritten rules, either we need to write
them down or we need to cope with the
fact that some folks may not follow them. What would really be unfortunate
is to lose potential contributors because
they get discouraged after submitting a patch and running into this
"invisible" red tape. I can already see this happening
such as in https://reviews.apache.org/r/66490/
There may not be a solution to that problem (and may be a different problem
altogether) but it would at least be
nice to have an outline of what procedure is expected from potential
contributors.
Another thing I'd like to bring up is that our use of JIRA has drastically
decreased. There is very little activity going on there.
That used to be the starting point of discussion for any contribution. As
engagement has dropped, that's pretty much gone away
leaving us without much defense in shutting down an idea before it's coded.
>
> There is obviously more than just this list, but a lot of the patches that
> struggle to get reviews (or get hard -1s after a bunch of work is done)
> fail on one (or more) of these fundamental ideas.
>
I agree on this point but what concerns me more than the -1's is the lack
of engagement. For example
https://reviews.apache.org/r/66537/
If we want to engage the community, we gotta give feedback, good or bad.
For me, letting review requests rot is one sure fire indicator to
potential contributors that sending a contribution is not worth their time
or effort (and our process is pretty time consuming given the outline we
tend to follow above).
We should find a way to keep the core tenets outlined above while
streamlining the process. Maybe move away from reviewboard
into gitbox so we can do code reviews on github? Not sure if this would
help at all, but it may since folks are more familiar with that workflow
so it brings down a barrier for contribution.
(Side note: maybe it's a good time to propose a cleanup in reviewboard. Right
now our group page on reviewboard looks like a graveyard.
In my opinion, anything older than a year isn't likely to be committed and
should therefore be discarded. I can put this to a vote if the general
consensus is
positive towards this idea.)
> It's also worth calling out that having informal discussions on Slack is
> fine, but should also be done on the dev lists, and ideally in the form of
> a written document. This is the best way to include those of who feel like
> Slack is a massive productivity drain :)
Noted, though I will say our slack channel doesn't have much of a pulse
these days either (and hasn't for quite some time).
>
>
I guess this is my long-winded way of saying that I'm a -1 on moving to
> lazy consensus.
>
> I wonder if a lot of the concerns can be solved by just improving
> communication? Maybe we can revive the weekly developer meeting that we
> used to run in IRC.
>
This would be great but sadly I just don't see the engagement we need to be
able to pull this off. We could not even get enough interest to
host an Aurora Meetup, so I see this as an uphill battle if we attempt it.
I could be wrong though and I would be more than happy to be part of it if
we start running it.
-Renan
>
>
> On Tue, May 22, 2018 at 8:58 AM, Renan DelValle <re...@apache.org> wrote:
>
> > Thanks for your input Stephan, very much appreciated! Replies inline:
> >
> > On Tue, May 22, 2018 at 12:12 AM, Stephan Erb <
> stephan.erb@blue-yonder.com
> > >
> > wrote:
> >
> > > Hey Renan,
> > >
> > > thanks again for bringing this up. In my experience, the pain comes
> from
> > > building, testing & voting rather the packaging scripts themselves. I
> > > therefore think we should discontinue building, but continue to
> maintain
> > > the scripts so that users can build them on their own when necessary.
> > >
> >
> > Fully agree on this. I will even go as far as making unofficial builds
> > available for the time being if no one is opposed and if it's not against
> > Apache policy to do so.
> >
> > >
> > > We must be careful though with linking the ‘nightly jenkins builds’ on
> > the
> > > website. We got called out for this once in the past and had to take
> the
> > > link down.
> > >
> >
> > Noted, thanks for bringing this up!
> >
> > >
> > > We also see a lack of involvement in code reviews. I think we should
> > > consider setting up a more formal lazy consensus policy
> > > https://www.apache.org/foundation/voting.html#LazyConsensus : For
> > > example, patches maybe merged even with a single ‘ship it’ from a
> > > committer, if there is neither a ship-it nor a veto from other
> committers
> > > within 7 days.
> > >
> >
> > I think this is a very valid way forward at this point. How does everyone
> > else feel about this?
> >
> > >
> > > Best regards,
> > > Stephan
> > >
> >
> >
> > -Renan
> >
> > >
> > > From: Santhosh Kumar Shanmugham <ss...@twitter.com>
> > > Reply-To: "user@aurora.apache.org" <us...@aurora.apache.org>
> > > Date: Thursday, 17. May 2018 at 22:13
> > > To: "dev@aurora.apache.org" <de...@aurora.apache.org>
> > > Cc: "user@aurora.apache.org" <us...@aurora.apache.org>
> > > Subject: Re: [DISCUSS] State of the Community
> > >
> > > Hello Renan,
> > >
> > > I understand your frustration.
> > >
> > > I am a strong +1 for automating the release and voting process. I
> > performed
> > > a release a while back and the process definitely needs it improve
> > > documentation
> > > at the least. If one of the members who are more familiar with this
> > > process can
> > > create a backlog, I will be happy to chip in.
> > >
> > > -Santhosh
> > >
> > > On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <renan@apache.org
> > <mailto:
> > > renan@apache.org>> wrote:
> > > All,
> > >
> > > Discussion has been open for 13 days and only one user has chimed in.
> > > Unfortunately it looks like talking point number one will be a serious
> > > concern going forward. I will give until tomorrow 12 PM San Francisco
> > time
> > > for folks to voice their opinion on these issues.
> > >
> > > After tomorrow I will call a vote to cease distributions of official
> > binary
> > > packages from versions 0.21.0 onwards until the process is automated
> and
> > > voting for the voting for the binary packages can be combined with the
> > > tar.gz release.
> > >
> > > Since no feedback was received regarding talking point three, the idea
> > will
> > > be dropped.
> > >
> > > -Renan
> > >
> > >
> > > On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <
> renanidelvalle@gmail.com
> > <
> > > mailto:renanidelvalle@gmail.com>>
> > > wrote:
> > >
> > > > In some ways, that's some of the best feedback we can get. Very happy
> > to
> > > > hear that Aurora is working fo well for Chartbeat.
> > > >
> > > > I do hope that you guys find some time to help us maintain the
> project.
> > > > Every little bit counts!
> > > >
> > > > -Renan
> > > >
> > > > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <rick@chartbeat.com
> > <mailto:
> > > rick@chartbeat.com>> wrote:
> > > >
> > > >> As strong users of aurora but weak contributors, we at Chartbeat
> > > >> apologize for our lack of participation. We’re several versions
> behind
> > > on
> > > >> mesos/aurora upgrades and that’s honestly because it works for us :)
> > > >>
> > > >> Going forward we’re hoping to be able to participate more, at least
> > with
> > > >> testing new releases.
> > > >>
> > > >> We thank you though!
> > > >>
> > > >> Rick and the rest of Chartbeat Engineering
> > > >>
> > > >>
> > > >> > On May 4, 2018, at 2:38 PM, Renan DelValle <renan@apache.org
> > <mailto:
> > > renan@apache.org>> wrote:
> > > >> >
> > > >> > Hello all,
> > > >> >
> > > >> > I wanted to bring up a few points for discussion with the
> community.
> > > I'd
> > > >> > really like to hear what the community's thoughts are on these
> > issues
> > > >> and
> > > >> > how can resolve them.
> > > >> >
> > > >> > 1. Lack of participation. This is due to many members moving on
> from
> > > the
> > > >> > project and becoming dormant. More concerning is the fact that our
> > PMC
> > > >> > roster sits at 21 members [1] of which fewer than half have
> > > >> participated in
> > > >> > the project during the last 6 months.
> > > >> >
> > > >> > This inactivity has led the voting process for releases to be held
> > up
> > > by
> > > >> > the inability to reach the required minimum 3 votes for releases
> > (both
> > > >> > tar.gz and binary). Our latest binary packaging vote has been
> going
> > on
> > > >> for
> > > >> > more than a month. [2]
> > > >> >
> > > >> > With the recent additions of Santhosh Kumar Shanmugham and Jordan
> Ly
> > > to
> > > >> the
> > > >> > Aurora PMC, we hope to mitigate this issue.
> > > >> >
> > > >> > It would be fantastic to see some initiative from long
> contributing
> > > >> members
> > > >> > to make a case for themselves for being considered for committer
> > > and/or
> > > >> PMC
> > > >> > membership.
> > > >> >
> > > >> > 2. Binary packages. While we have been struggling to get enough
> > votes
> > > >> for
> > > >> > making the release official, the voting process has been marked
> by a
> > > >> lack
> > > >> > of enthusiasm from the community.
> > > >> >
> > > >> > I know that many folks are using these packages (including
> myself),
> > > but
> > > >> we
> > > >> > need to hear feedback when we call votes. It is not enough to
> stand
> > by
> > > >> > silently if everything works; please let us know about it.
> > > >> >
> > > >> > As it stands, the enthusiasm (or lack thereof) for binary packages
> > > >> doesn't
> > > >> > justify the overhead involved in releasing them. Therefore I
> propose
> > > >> that
> > > >> > we drop official binary packages for the next release. This is up
> > for
> > > >> > discussion and I'd love to hear everyone's opinion on this.
> > > >> >
> > > >> > An alternative to ending binary packages would be to automate the
> > > >> process
> > > >> > on tar.gz releases, but that would most likely need to be a
> > community
> > > >> > contribution.
> > > >> >
> > > >> > 3. Version 1.0. I realize this is a touchy subject. While other
> > > projects
> > > >> > that were started around the same time as Aurora, such as Mesos
> > > itself,
> > > >> > have gone on to make a 1.0 release (indicating the projects
> > maturity),
> > > >> we
> > > >> > have stuck to our 0.X.0 releases.
> > > >> >
> > > >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0,
> but
> > I
> > > >> > wanted to bring up for discussion how everyone felt about making
> our
> > > >> next
> > > >> > release a 1.0 release to reflect the stability and maturity of the
> > > >> project.
> > > >> >
> > > >> > That is all from me, if anyone else has any other concerns
> regarding
> > > the
> > > >> > Aurora community, feel free to bring it up in this thread!
> > > >> >
> > > >> > -Renan
> > > >> >
> > > >> >
> > > >> > [1] https://projects.apache.org/committee.html?aurora
> > > >> > [2] https://lists.apache.org/thread.html/
> > > 9df9d142408efffd11a1cdc5e4c1e3
> > > >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http://
> > > 3Cdev.aurora.apache.org>%3E
> > > >>
> > > >>
> > > >
> > >
> > >
> >
>
Re: [DISCUSS] State of the Community
Posted by Renan DelValle <re...@gmail.com>.
Thanks for the feedback David!
On Tue, May 22, 2018 at 9:55 AM, David McLaughlin <dm...@apache.org>
wrote:
> I feel like not getting code reviews is often a symptom of some other
> fundamental issue with how change is introduced to a community.
>
> When I joined the Aurora team at Twitter there were some principals in
> place for getting your changes accepted to the community and I still feel
> like when you follow them, getting code reviews rarely requires more than a
> gentle ping. Maybe none of these have been formally communicated or shared
> externally, but some of the principals I've picked up include:
>
> * Introduce problems before solutions.
> * Get buy-in that this is a problem worth solving.
> * Work towards abstractions that work for the community and not just for
> your specific use case.
> * Solicit early feedback on potential solutions.
> * Get explicit buy-in for the solution (these +1s would be the people you
> add to the reviewers list later). This usually means writing a Design Doc.
> * Plan your work carefully to avoid the dreaded code dumps (where
> possible). For large efforts work towards multiple, small patches that are
> easy to review.
> * Follow-up on review feedback quickly to avoid demanding expensive paging
> and context-switches from your reviewers later.
> * Build trust by thinking through production rollout and rollback
> scenarios.
>
All good points and I think those of us that have been here long enough do
strive to follow these principles. For what it's worth,
I've always really appreciated the feedback from the folks running at scale
when it comes to my contributions. It shows they care
about the project and pushes me to write better code.
That said, since these are mostly unwritten rules, either we need to write
them down or we need to cope with the
fact that some folks may not follow them. What would really be unfortunate
is to lose potential contributors because
they get discouraged after submitting a patch and running into this
"invisible" red tape. I can already see this happening
such as in https://reviews.apache.org/r/66490/
There may not be a solution to that problem (and may be a different problem
altogether) but it would at least be
nice to have an outline of what procedure is expected from potential
contributors.
Another thing I'd like to bring up is that our use of JIRA has drastically
decreased. There is very little activity going on there.
That used to be the starting point of discussion for any contribution. As
engagement has dropped, that's pretty much gone away
leaving us without much defense in shutting down an idea before it's coded.
>
> There is obviously more than just this list, but a lot of the patches that
> struggle to get reviews (or get hard -1s after a bunch of work is done)
> fail on one (or more) of these fundamental ideas.
>
I agree on this point but what concerns me more than the -1's is the lack
of engagement. For example
https://reviews.apache.org/r/66537/
If we want to engage the community, we gotta give feedback, good or bad.
For me, letting review requests rot is one sure fire indicator to
potential contributors that sending a contribution is not worth their time
or effort (and our process is pretty time consuming given the outline we
tend to follow above).
We should find a way to keep the core tenets outlined above while
streamlining the process. Maybe move away from reviewboard
into gitbox so we can do code reviews on github? Not sure if this would
help at all, but it may since folks are more familiar with that workflow
so it brings down a barrier for contribution.
(Side note: maybe it's a good time to propose a cleanup in reviewboard. Right
now our group page on reviewboard looks like a graveyard.
In my opinion, anything older than a year isn't likely to be committed and
should therefore be discarded. I can put this to a vote if the general
consensus is
positive towards this idea.)
> It's also worth calling out that having informal discussions on Slack is
> fine, but should also be done on the dev lists, and ideally in the form of
> a written document. This is the best way to include those of who feel like
> Slack is a massive productivity drain :)
Noted, though I will say our slack channel doesn't have much of a pulse
these days either (and hasn't for quite some time).
>
>
I guess this is my long-winded way of saying that I'm a -1 on moving to
> lazy consensus.
>
> I wonder if a lot of the concerns can be solved by just improving
> communication? Maybe we can revive the weekly developer meeting that we
> used to run in IRC.
>
This would be great but sadly I just don't see the engagement we need to be
able to pull this off. We could not even get enough interest to
host an Aurora Meetup, so I see this as an uphill battle if we attempt it.
I could be wrong though and I would be more than happy to be part of it if
we start running it.
-Renan
>
>
> On Tue, May 22, 2018 at 8:58 AM, Renan DelValle <re...@apache.org> wrote:
>
> > Thanks for your input Stephan, very much appreciated! Replies inline:
> >
> > On Tue, May 22, 2018 at 12:12 AM, Stephan Erb <
> stephan.erb@blue-yonder.com
> > >
> > wrote:
> >
> > > Hey Renan,
> > >
> > > thanks again for bringing this up. In my experience, the pain comes
> from
> > > building, testing & voting rather the packaging scripts themselves. I
> > > therefore think we should discontinue building, but continue to
> maintain
> > > the scripts so that users can build them on their own when necessary.
> > >
> >
> > Fully agree on this. I will even go as far as making unofficial builds
> > available for the time being if no one is opposed and if it's not against
> > Apache policy to do so.
> >
> > >
> > > We must be careful though with linking the ‘nightly jenkins builds’ on
> > the
> > > website. We got called out for this once in the past and had to take
> the
> > > link down.
> > >
> >
> > Noted, thanks for bringing this up!
> >
> > >
> > > We also see a lack of involvement in code reviews. I think we should
> > > consider setting up a more formal lazy consensus policy
> > > https://www.apache.org/foundation/voting.html#LazyConsensus : For
> > > example, patches maybe merged even with a single ‘ship it’ from a
> > > committer, if there is neither a ship-it nor a veto from other
> committers
> > > within 7 days.
> > >
> >
> > I think this is a very valid way forward at this point. How does everyone
> > else feel about this?
> >
> > >
> > > Best regards,
> > > Stephan
> > >
> >
> >
> > -Renan
> >
> > >
> > > From: Santhosh Kumar Shanmugham <ss...@twitter.com>
> > > Reply-To: "user@aurora.apache.org" <us...@aurora.apache.org>
> > > Date: Thursday, 17. May 2018 at 22:13
> > > To: "dev@aurora.apache.org" <de...@aurora.apache.org>
> > > Cc: "user@aurora.apache.org" <us...@aurora.apache.org>
> > > Subject: Re: [DISCUSS] State of the Community
> > >
> > > Hello Renan,
> > >
> > > I understand your frustration.
> > >
> > > I am a strong +1 for automating the release and voting process. I
> > performed
> > > a release a while back and the process definitely needs it improve
> > > documentation
> > > at the least. If one of the members who are more familiar with this
> > > process can
> > > create a backlog, I will be happy to chip in.
> > >
> > > -Santhosh
> > >
> > > On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <renan@apache.org
> > <mailto:
> > > renan@apache.org>> wrote:
> > > All,
> > >
> > > Discussion has been open for 13 days and only one user has chimed in.
> > > Unfortunately it looks like talking point number one will be a serious
> > > concern going forward. I will give until tomorrow 12 PM San Francisco
> > time
> > > for folks to voice their opinion on these issues.
> > >
> > > After tomorrow I will call a vote to cease distributions of official
> > binary
> > > packages from versions 0.21.0 onwards until the process is automated
> and
> > > voting for the voting for the binary packages can be combined with the
> > > tar.gz release.
> > >
> > > Since no feedback was received regarding talking point three, the idea
> > will
> > > be dropped.
> > >
> > > -Renan
> > >
> > >
> > > On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <
> renanidelvalle@gmail.com
> > <
> > > mailto:renanidelvalle@gmail.com>>
> > > wrote:
> > >
> > > > In some ways, that's some of the best feedback we can get. Very happy
> > to
> > > > hear that Aurora is working fo well for Chartbeat.
> > > >
> > > > I do hope that you guys find some time to help us maintain the
> project.
> > > > Every little bit counts!
> > > >
> > > > -Renan
> > > >
> > > > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <rick@chartbeat.com
> > <mailto:
> > > rick@chartbeat.com>> wrote:
> > > >
> > > >> As strong users of aurora but weak contributors, we at Chartbeat
> > > >> apologize for our lack of participation. We’re several versions
> behind
> > > on
> > > >> mesos/aurora upgrades and that’s honestly because it works for us :)
> > > >>
> > > >> Going forward we’re hoping to be able to participate more, at least
> > with
> > > >> testing new releases.
> > > >>
> > > >> We thank you though!
> > > >>
> > > >> Rick and the rest of Chartbeat Engineering
> > > >>
> > > >>
> > > >> > On May 4, 2018, at 2:38 PM, Renan DelValle <renan@apache.org
> > <mailto:
> > > renan@apache.org>> wrote:
> > > >> >
> > > >> > Hello all,
> > > >> >
> > > >> > I wanted to bring up a few points for discussion with the
> community.
> > > I'd
> > > >> > really like to hear what the community's thoughts are on these
> > issues
> > > >> and
> > > >> > how can resolve them.
> > > >> >
> > > >> > 1. Lack of participation. This is due to many members moving on
> from
> > > the
> > > >> > project and becoming dormant. More concerning is the fact that our
> > PMC
> > > >> > roster sits at 21 members [1] of which fewer than half have
> > > >> participated in
> > > >> > the project during the last 6 months.
> > > >> >
> > > >> > This inactivity has led the voting process for releases to be held
> > up
> > > by
> > > >> > the inability to reach the required minimum 3 votes for releases
> > (both
> > > >> > tar.gz and binary). Our latest binary packaging vote has been
> going
> > on
> > > >> for
> > > >> > more than a month. [2]
> > > >> >
> > > >> > With the recent additions of Santhosh Kumar Shanmugham and Jordan
> Ly
> > > to
> > > >> the
> > > >> > Aurora PMC, we hope to mitigate this issue.
> > > >> >
> > > >> > It would be fantastic to see some initiative from long
> contributing
> > > >> members
> > > >> > to make a case for themselves for being considered for committer
> > > and/or
> > > >> PMC
> > > >> > membership.
> > > >> >
> > > >> > 2. Binary packages. While we have been struggling to get enough
> > votes
> > > >> for
> > > >> > making the release official, the voting process has been marked
> by a
> > > >> lack
> > > >> > of enthusiasm from the community.
> > > >> >
> > > >> > I know that many folks are using these packages (including
> myself),
> > > but
> > > >> we
> > > >> > need to hear feedback when we call votes. It is not enough to
> stand
> > by
> > > >> > silently if everything works; please let us know about it.
> > > >> >
> > > >> > As it stands, the enthusiasm (or lack thereof) for binary packages
> > > >> doesn't
> > > >> > justify the overhead involved in releasing them. Therefore I
> propose
> > > >> that
> > > >> > we drop official binary packages for the next release. This is up
> > for
> > > >> > discussion and I'd love to hear everyone's opinion on this.
> > > >> >
> > > >> > An alternative to ending binary packages would be to automate the
> > > >> process
> > > >> > on tar.gz releases, but that would most likely need to be a
> > community
> > > >> > contribution.
> > > >> >
> > > >> > 3. Version 1.0. I realize this is a touchy subject. While other
> > > projects
> > > >> > that were started around the same time as Aurora, such as Mesos
> > > itself,
> > > >> > have gone on to make a 1.0 release (indicating the projects
> > maturity),
> > > >> we
> > > >> > have stuck to our 0.X.0 releases.
> > > >> >
> > > >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0,
> but
> > I
> > > >> > wanted to bring up for discussion how everyone felt about making
> our
> > > >> next
> > > >> > release a 1.0 release to reflect the stability and maturity of the
> > > >> project.
> > > >> >
> > > >> > That is all from me, if anyone else has any other concerns
> regarding
> > > the
> > > >> > Aurora community, feel free to bring it up in this thread!
> > > >> >
> > > >> > -Renan
> > > >> >
> > > >> >
> > > >> > [1] https://projects.apache.org/committee.html?aurora
> > > >> > [2] https://lists.apache.org/thread.html/
> > > 9df9d142408efffd11a1cdc5e4c1e3
> > > >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http://
> > > 3Cdev.aurora.apache.org>%3E
> > > >>
> > > >>
> > > >
> > >
> > >
> >
>
Re: [DISCUSS] State of the Community
Posted by David McLaughlin <dm...@apache.org>.
I feel like not getting code reviews is often a symptom of some other
fundamental issue with how change is introduced to a community.
When I joined the Aurora team at Twitter there were some principals in
place for getting your changes accepted to the community and I still feel
like when you follow them, getting code reviews rarely requires more than a
gentle ping. Maybe none of these have been formally communicated or shared
externally, but some of the principals I've picked up include:
* Introduce problems before solutions.
* Get buy-in that this is a problem worth solving.
* Work towards abstractions that work for the community and not just for
your specific use case.
* Solicit early feedback on potential solutions.
* Get explicit buy-in for the solution (these +1s would be the people you
add to the reviewers list later). This usually means writing a Design Doc.
* Plan your work carefully to avoid the dreaded code dumps (where
possible). For large efforts work towards multiple, small patches that are
easy to review.
* Follow-up on review feedback quickly to avoid demanding expensive paging
and context-switches from your reviewers later.
* Build trust by thinking through production rollout and rollback
scenarios.
There is obviously more than just this list, but a lot of the patches that
struggle to get reviews (or get hard -1s after a bunch of work is done)
fail on one (or more) of these fundamental ideas.
It's also worth calling out that having informal discussions on Slack is
fine, but should also be done on the dev lists, and ideally in the form of
a written document. This is the best way to include those of who feel like
Slack is a massive productivity drain :)
I guess this is my long-winded way of saying that I'm a -1 on moving to
lazy consensus.
I wonder if a lot of the concerns can be solved by just improving
communication? Maybe we can revive the weekly developer meeting that we
used to run in IRC.
On Tue, May 22, 2018 at 8:58 AM, Renan DelValle <re...@apache.org> wrote:
> Thanks for your input Stephan, very much appreciated! Replies inline:
>
> On Tue, May 22, 2018 at 12:12 AM, Stephan Erb <stephan.erb@blue-yonder.com
> >
> wrote:
>
> > Hey Renan,
> >
> > thanks again for bringing this up. In my experience, the pain comes from
> > building, testing & voting rather the packaging scripts themselves. I
> > therefore think we should discontinue building, but continue to maintain
> > the scripts so that users can build them on their own when necessary.
> >
>
> Fully agree on this. I will even go as far as making unofficial builds
> available for the time being if no one is opposed and if it's not against
> Apache policy to do so.
>
> >
> > We must be careful though with linking the ‘nightly jenkins builds’ on
> the
> > website. We got called out for this once in the past and had to take the
> > link down.
> >
>
> Noted, thanks for bringing this up!
>
> >
> > We also see a lack of involvement in code reviews. I think we should
> > consider setting up a more formal lazy consensus policy
> > https://www.apache.org/foundation/voting.html#LazyConsensus : For
> > example, patches maybe merged even with a single ‘ship it’ from a
> > committer, if there is neither a ship-it nor a veto from other committers
> > within 7 days.
> >
>
> I think this is a very valid way forward at this point. How does everyone
> else feel about this?
>
> >
> > Best regards,
> > Stephan
> >
>
>
> -Renan
>
> >
> > From: Santhosh Kumar Shanmugham <ss...@twitter.com>
> > Reply-To: "user@aurora.apache.org" <us...@aurora.apache.org>
> > Date: Thursday, 17. May 2018 at 22:13
> > To: "dev@aurora.apache.org" <de...@aurora.apache.org>
> > Cc: "user@aurora.apache.org" <us...@aurora.apache.org>
> > Subject: Re: [DISCUSS] State of the Community
> >
> > Hello Renan,
> >
> > I understand your frustration.
> >
> > I am a strong +1 for automating the release and voting process. I
> performed
> > a release a while back and the process definitely needs it improve
> > documentation
> > at the least. If one of the members who are more familiar with this
> > process can
> > create a backlog, I will be happy to chip in.
> >
> > -Santhosh
> >
> > On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <renan@apache.org
> <mailto:
> > renan@apache.org>> wrote:
> > All,
> >
> > Discussion has been open for 13 days and only one user has chimed in.
> > Unfortunately it looks like talking point number one will be a serious
> > concern going forward. I will give until tomorrow 12 PM San Francisco
> time
> > for folks to voice their opinion on these issues.
> >
> > After tomorrow I will call a vote to cease distributions of official
> binary
> > packages from versions 0.21.0 onwards until the process is automated and
> > voting for the voting for the binary packages can be combined with the
> > tar.gz release.
> >
> > Since no feedback was received regarding talking point three, the idea
> will
> > be dropped.
> >
> > -Renan
> >
> >
> > On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <renanidelvalle@gmail.com
> <
> > mailto:renanidelvalle@gmail.com>>
> > wrote:
> >
> > > In some ways, that's some of the best feedback we can get. Very happy
> to
> > > hear that Aurora is working fo well for Chartbeat.
> > >
> > > I do hope that you guys find some time to help us maintain the project.
> > > Every little bit counts!
> > >
> > > -Renan
> > >
> > > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <rick@chartbeat.com
> <mailto:
> > rick@chartbeat.com>> wrote:
> > >
> > >> As strong users of aurora but weak contributors, we at Chartbeat
> > >> apologize for our lack of participation. We’re several versions behind
> > on
> > >> mesos/aurora upgrades and that’s honestly because it works for us :)
> > >>
> > >> Going forward we’re hoping to be able to participate more, at least
> with
> > >> testing new releases.
> > >>
> > >> We thank you though!
> > >>
> > >> Rick and the rest of Chartbeat Engineering
> > >>
> > >>
> > >> > On May 4, 2018, at 2:38 PM, Renan DelValle <renan@apache.org
> <mailto:
> > renan@apache.org>> wrote:
> > >> >
> > >> > Hello all,
> > >> >
> > >> > I wanted to bring up a few points for discussion with the community.
> > I'd
> > >> > really like to hear what the community's thoughts are on these
> issues
> > >> and
> > >> > how can resolve them.
> > >> >
> > >> > 1. Lack of participation. This is due to many members moving on from
> > the
> > >> > project and becoming dormant. More concerning is the fact that our
> PMC
> > >> > roster sits at 21 members [1] of which fewer than half have
> > >> participated in
> > >> > the project during the last 6 months.
> > >> >
> > >> > This inactivity has led the voting process for releases to be held
> up
> > by
> > >> > the inability to reach the required minimum 3 votes for releases
> (both
> > >> > tar.gz and binary). Our latest binary packaging vote has been going
> on
> > >> for
> > >> > more than a month. [2]
> > >> >
> > >> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly
> > to
> > >> the
> > >> > Aurora PMC, we hope to mitigate this issue.
> > >> >
> > >> > It would be fantastic to see some initiative from long contributing
> > >> members
> > >> > to make a case for themselves for being considered for committer
> > and/or
> > >> PMC
> > >> > membership.
> > >> >
> > >> > 2. Binary packages. While we have been struggling to get enough
> votes
> > >> for
> > >> > making the release official, the voting process has been marked by a
> > >> lack
> > >> > of enthusiasm from the community.
> > >> >
> > >> > I know that many folks are using these packages (including myself),
> > but
> > >> we
> > >> > need to hear feedback when we call votes. It is not enough to stand
> by
> > >> > silently if everything works; please let us know about it.
> > >> >
> > >> > As it stands, the enthusiasm (or lack thereof) for binary packages
> > >> doesn't
> > >> > justify the overhead involved in releasing them. Therefore I propose
> > >> that
> > >> > we drop official binary packages for the next release. This is up
> for
> > >> > discussion and I'd love to hear everyone's opinion on this.
> > >> >
> > >> > An alternative to ending binary packages would be to automate the
> > >> process
> > >> > on tar.gz releases, but that would most likely need to be a
> community
> > >> > contribution.
> > >> >
> > >> > 3. Version 1.0. I realize this is a touchy subject. While other
> > projects
> > >> > that were started around the same time as Aurora, such as Mesos
> > itself,
> > >> > have gone on to make a 1.0 release (indicating the projects
> maturity),
> > >> we
> > >> > have stuck to our 0.X.0 releases.
> > >> >
> > >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but
> I
> > >> > wanted to bring up for discussion how everyone felt about making our
> > >> next
> > >> > release a 1.0 release to reflect the stability and maturity of the
> > >> project.
> > >> >
> > >> > That is all from me, if anyone else has any other concerns regarding
> > the
> > >> > Aurora community, feel free to bring it up in this thread!
> > >> >
> > >> > -Renan
> > >> >
> > >> >
> > >> > [1] https://projects.apache.org/committee.html?aurora
> > >> > [2] https://lists.apache.org/thread.html/
> > 9df9d142408efffd11a1cdc5e4c1e3
> > >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http://
> > 3Cdev.aurora.apache.org>%3E
> > >>
> > >>
> > >
> >
> >
>
Re: [DISCUSS] State of the Community
Posted by David McLaughlin <dm...@apache.org>.
I feel like not getting code reviews is often a symptom of some other
fundamental issue with how change is introduced to a community.
When I joined the Aurora team at Twitter there were some principals in
place for getting your changes accepted to the community and I still feel
like when you follow them, getting code reviews rarely requires more than a
gentle ping. Maybe none of these have been formally communicated or shared
externally, but some of the principals I've picked up include:
* Introduce problems before solutions.
* Get buy-in that this is a problem worth solving.
* Work towards abstractions that work for the community and not just for
your specific use case.
* Solicit early feedback on potential solutions.
* Get explicit buy-in for the solution (these +1s would be the people you
add to the reviewers list later). This usually means writing a Design Doc.
* Plan your work carefully to avoid the dreaded code dumps (where
possible). For large efforts work towards multiple, small patches that are
easy to review.
* Follow-up on review feedback quickly to avoid demanding expensive paging
and context-switches from your reviewers later.
* Build trust by thinking through production rollout and rollback
scenarios.
There is obviously more than just this list, but a lot of the patches that
struggle to get reviews (or get hard -1s after a bunch of work is done)
fail on one (or more) of these fundamental ideas.
It's also worth calling out that having informal discussions on Slack is
fine, but should also be done on the dev lists, and ideally in the form of
a written document. This is the best way to include those of who feel like
Slack is a massive productivity drain :)
I guess this is my long-winded way of saying that I'm a -1 on moving to
lazy consensus.
I wonder if a lot of the concerns can be solved by just improving
communication? Maybe we can revive the weekly developer meeting that we
used to run in IRC.
On Tue, May 22, 2018 at 8:58 AM, Renan DelValle <re...@apache.org> wrote:
> Thanks for your input Stephan, very much appreciated! Replies inline:
>
> On Tue, May 22, 2018 at 12:12 AM, Stephan Erb <stephan.erb@blue-yonder.com
> >
> wrote:
>
> > Hey Renan,
> >
> > thanks again for bringing this up. In my experience, the pain comes from
> > building, testing & voting rather the packaging scripts themselves. I
> > therefore think we should discontinue building, but continue to maintain
> > the scripts so that users can build them on their own when necessary.
> >
>
> Fully agree on this. I will even go as far as making unofficial builds
> available for the time being if no one is opposed and if it's not against
> Apache policy to do so.
>
> >
> > We must be careful though with linking the ‘nightly jenkins builds’ on
> the
> > website. We got called out for this once in the past and had to take the
> > link down.
> >
>
> Noted, thanks for bringing this up!
>
> >
> > We also see a lack of involvement in code reviews. I think we should
> > consider setting up a more formal lazy consensus policy
> > https://www.apache.org/foundation/voting.html#LazyConsensus : For
> > example, patches maybe merged even with a single ‘ship it’ from a
> > committer, if there is neither a ship-it nor a veto from other committers
> > within 7 days.
> >
>
> I think this is a very valid way forward at this point. How does everyone
> else feel about this?
>
> >
> > Best regards,
> > Stephan
> >
>
>
> -Renan
>
> >
> > From: Santhosh Kumar Shanmugham <ss...@twitter.com>
> > Reply-To: "user@aurora.apache.org" <us...@aurora.apache.org>
> > Date: Thursday, 17. May 2018 at 22:13
> > To: "dev@aurora.apache.org" <de...@aurora.apache.org>
> > Cc: "user@aurora.apache.org" <us...@aurora.apache.org>
> > Subject: Re: [DISCUSS] State of the Community
> >
> > Hello Renan,
> >
> > I understand your frustration.
> >
> > I am a strong +1 for automating the release and voting process. I
> performed
> > a release a while back and the process definitely needs it improve
> > documentation
> > at the least. If one of the members who are more familiar with this
> > process can
> > create a backlog, I will be happy to chip in.
> >
> > -Santhosh
> >
> > On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <renan@apache.org
> <mailto:
> > renan@apache.org>> wrote:
> > All,
> >
> > Discussion has been open for 13 days and only one user has chimed in.
> > Unfortunately it looks like talking point number one will be a serious
> > concern going forward. I will give until tomorrow 12 PM San Francisco
> time
> > for folks to voice their opinion on these issues.
> >
> > After tomorrow I will call a vote to cease distributions of official
> binary
> > packages from versions 0.21.0 onwards until the process is automated and
> > voting for the voting for the binary packages can be combined with the
> > tar.gz release.
> >
> > Since no feedback was received regarding talking point three, the idea
> will
> > be dropped.
> >
> > -Renan
> >
> >
> > On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <renanidelvalle@gmail.com
> <
> > mailto:renanidelvalle@gmail.com>>
> > wrote:
> >
> > > In some ways, that's some of the best feedback we can get. Very happy
> to
> > > hear that Aurora is working fo well for Chartbeat.
> > >
> > > I do hope that you guys find some time to help us maintain the project.
> > > Every little bit counts!
> > >
> > > -Renan
> > >
> > > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <rick@chartbeat.com
> <mailto:
> > rick@chartbeat.com>> wrote:
> > >
> > >> As strong users of aurora but weak contributors, we at Chartbeat
> > >> apologize for our lack of participation. We’re several versions behind
> > on
> > >> mesos/aurora upgrades and that’s honestly because it works for us :)
> > >>
> > >> Going forward we’re hoping to be able to participate more, at least
> with
> > >> testing new releases.
> > >>
> > >> We thank you though!
> > >>
> > >> Rick and the rest of Chartbeat Engineering
> > >>
> > >>
> > >> > On May 4, 2018, at 2:38 PM, Renan DelValle <renan@apache.org
> <mailto:
> > renan@apache.org>> wrote:
> > >> >
> > >> > Hello all,
> > >> >
> > >> > I wanted to bring up a few points for discussion with the community.
> > I'd
> > >> > really like to hear what the community's thoughts are on these
> issues
> > >> and
> > >> > how can resolve them.
> > >> >
> > >> > 1. Lack of participation. This is due to many members moving on from
> > the
> > >> > project and becoming dormant. More concerning is the fact that our
> PMC
> > >> > roster sits at 21 members [1] of which fewer than half have
> > >> participated in
> > >> > the project during the last 6 months.
> > >> >
> > >> > This inactivity has led the voting process for releases to be held
> up
> > by
> > >> > the inability to reach the required minimum 3 votes for releases
> (both
> > >> > tar.gz and binary). Our latest binary packaging vote has been going
> on
> > >> for
> > >> > more than a month. [2]
> > >> >
> > >> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly
> > to
> > >> the
> > >> > Aurora PMC, we hope to mitigate this issue.
> > >> >
> > >> > It would be fantastic to see some initiative from long contributing
> > >> members
> > >> > to make a case for themselves for being considered for committer
> > and/or
> > >> PMC
> > >> > membership.
> > >> >
> > >> > 2. Binary packages. While we have been struggling to get enough
> votes
> > >> for
> > >> > making the release official, the voting process has been marked by a
> > >> lack
> > >> > of enthusiasm from the community.
> > >> >
> > >> > I know that many folks are using these packages (including myself),
> > but
> > >> we
> > >> > need to hear feedback when we call votes. It is not enough to stand
> by
> > >> > silently if everything works; please let us know about it.
> > >> >
> > >> > As it stands, the enthusiasm (or lack thereof) for binary packages
> > >> doesn't
> > >> > justify the overhead involved in releasing them. Therefore I propose
> > >> that
> > >> > we drop official binary packages for the next release. This is up
> for
> > >> > discussion and I'd love to hear everyone's opinion on this.
> > >> >
> > >> > An alternative to ending binary packages would be to automate the
> > >> process
> > >> > on tar.gz releases, but that would most likely need to be a
> community
> > >> > contribution.
> > >> >
> > >> > 3. Version 1.0. I realize this is a touchy subject. While other
> > projects
> > >> > that were started around the same time as Aurora, such as Mesos
> > itself,
> > >> > have gone on to make a 1.0 release (indicating the projects
> maturity),
> > >> we
> > >> > have stuck to our 0.X.0 releases.
> > >> >
> > >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but
> I
> > >> > wanted to bring up for discussion how everyone felt about making our
> > >> next
> > >> > release a 1.0 release to reflect the stability and maturity of the
> > >> project.
> > >> >
> > >> > That is all from me, if anyone else has any other concerns regarding
> > the
> > >> > Aurora community, feel free to bring it up in this thread!
> > >> >
> > >> > -Renan
> > >> >
> > >> >
> > >> > [1] https://projects.apache.org/committee.html?aurora
> > >> > [2] https://lists.apache.org/thread.html/
> > 9df9d142408efffd11a1cdc5e4c1e3
> > >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http://
> > 3Cdev.aurora.apache.org>%3E
> > >>
> > >>
> > >
> >
> >
>
Re: [DISCUSS] State of the Community
Posted by Renan DelValle <re...@apache.org>.
Thanks for your input Stephan, very much appreciated! Replies inline:
On Tue, May 22, 2018 at 12:12 AM, Stephan Erb <st...@blue-yonder.com>
wrote:
> Hey Renan,
>
> thanks again for bringing this up. In my experience, the pain comes from
> building, testing & voting rather the packaging scripts themselves. I
> therefore think we should discontinue building, but continue to maintain
> the scripts so that users can build them on their own when necessary.
>
Fully agree on this. I will even go as far as making unofficial builds
available for the time being if no one is opposed and if it's not against
Apache policy to do so.
>
> We must be careful though with linking the ‘nightly jenkins builds’ on the
> website. We got called out for this once in the past and had to take the
> link down.
>
Noted, thanks for bringing this up!
>
> We also see a lack of involvement in code reviews. I think we should
> consider setting up a more formal lazy consensus policy
> https://www.apache.org/foundation/voting.html#LazyConsensus : For
> example, patches maybe merged even with a single ‘ship it’ from a
> committer, if there is neither a ship-it nor a veto from other committers
> within 7 days.
>
I think this is a very valid way forward at this point. How does everyone
else feel about this?
>
> Best regards,
> Stephan
>
-Renan
>
> From: Santhosh Kumar Shanmugham <ss...@twitter.com>
> Reply-To: "user@aurora.apache.org" <us...@aurora.apache.org>
> Date: Thursday, 17. May 2018 at 22:13
> To: "dev@aurora.apache.org" <de...@aurora.apache.org>
> Cc: "user@aurora.apache.org" <us...@aurora.apache.org>
> Subject: Re: [DISCUSS] State of the Community
>
> Hello Renan,
>
> I understand your frustration.
>
> I am a strong +1 for automating the release and voting process. I performed
> a release a while back and the process definitely needs it improve
> documentation
> at the least. If one of the members who are more familiar with this
> process can
> create a backlog, I will be happy to chip in.
>
> -Santhosh
>
> On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <renan@apache.org<mailto:
> renan@apache.org>> wrote:
> All,
>
> Discussion has been open for 13 days and only one user has chimed in.
> Unfortunately it looks like talking point number one will be a serious
> concern going forward. I will give until tomorrow 12 PM San Francisco time
> for folks to voice their opinion on these issues.
>
> After tomorrow I will call a vote to cease distributions of official binary
> packages from versions 0.21.0 onwards until the process is automated and
> voting for the voting for the binary packages can be combined with the
> tar.gz release.
>
> Since no feedback was received regarding talking point three, the idea will
> be dropped.
>
> -Renan
>
>
> On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <renanidelvalle@gmail.com<
> mailto:renanidelvalle@gmail.com>>
> wrote:
>
> > In some ways, that's some of the best feedback we can get. Very happy to
> > hear that Aurora is working fo well for Chartbeat.
> >
> > I do hope that you guys find some time to help us maintain the project.
> > Every little bit counts!
> >
> > -Renan
> >
> > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <rick@chartbeat.com<mailto:
> rick@chartbeat.com>> wrote:
> >
> >> As strong users of aurora but weak contributors, we at Chartbeat
> >> apologize for our lack of participation. We’re several versions behind
> on
> >> mesos/aurora upgrades and that’s honestly because it works for us :)
> >>
> >> Going forward we’re hoping to be able to participate more, at least with
> >> testing new releases.
> >>
> >> We thank you though!
> >>
> >> Rick and the rest of Chartbeat Engineering
> >>
> >>
> >> > On May 4, 2018, at 2:38 PM, Renan DelValle <renan@apache.org<mailto:
> renan@apache.org>> wrote:
> >> >
> >> > Hello all,
> >> >
> >> > I wanted to bring up a few points for discussion with the community.
> I'd
> >> > really like to hear what the community's thoughts are on these issues
> >> and
> >> > how can resolve them.
> >> >
> >> > 1. Lack of participation. This is due to many members moving on from
> the
> >> > project and becoming dormant. More concerning is the fact that our PMC
> >> > roster sits at 21 members [1] of which fewer than half have
> >> participated in
> >> > the project during the last 6 months.
> >> >
> >> > This inactivity has led the voting process for releases to be held up
> by
> >> > the inability to reach the required minimum 3 votes for releases (both
> >> > tar.gz and binary). Our latest binary packaging vote has been going on
> >> for
> >> > more than a month. [2]
> >> >
> >> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly
> to
> >> the
> >> > Aurora PMC, we hope to mitigate this issue.
> >> >
> >> > It would be fantastic to see some initiative from long contributing
> >> members
> >> > to make a case for themselves for being considered for committer
> and/or
> >> PMC
> >> > membership.
> >> >
> >> > 2. Binary packages. While we have been struggling to get enough votes
> >> for
> >> > making the release official, the voting process has been marked by a
> >> lack
> >> > of enthusiasm from the community.
> >> >
> >> > I know that many folks are using these packages (including myself),
> but
> >> we
> >> > need to hear feedback when we call votes. It is not enough to stand by
> >> > silently if everything works; please let us know about it.
> >> >
> >> > As it stands, the enthusiasm (or lack thereof) for binary packages
> >> doesn't
> >> > justify the overhead involved in releasing them. Therefore I propose
> >> that
> >> > we drop official binary packages for the next release. This is up for
> >> > discussion and I'd love to hear everyone's opinion on this.
> >> >
> >> > An alternative to ending binary packages would be to automate the
> >> process
> >> > on tar.gz releases, but that would most likely need to be a community
> >> > contribution.
> >> >
> >> > 3. Version 1.0. I realize this is a touchy subject. While other
> projects
> >> > that were started around the same time as Aurora, such as Mesos
> itself,
> >> > have gone on to make a 1.0 release (indicating the projects maturity),
> >> we
> >> > have stuck to our 0.X.0 releases.
> >> >
> >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
> >> > wanted to bring up for discussion how everyone felt about making our
> >> next
> >> > release a 1.0 release to reflect the stability and maturity of the
> >> project.
> >> >
> >> > That is all from me, if anyone else has any other concerns regarding
> the
> >> > Aurora community, feel free to bring it up in this thread!
> >> >
> >> > -Renan
> >> >
> >> >
> >> > [1] https://projects.apache.org/committee.html?aurora
> >> > [2] https://lists.apache.org/thread.html/
> 9df9d142408efffd11a1cdc5e4c1e3
> >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http://
> 3Cdev.aurora.apache.org>%3E
> >>
> >>
> >
>
>
Re: [DISCUSS] State of the Community
Posted by Renan DelValle <re...@apache.org>.
Thanks for your input Stephan, very much appreciated! Replies inline:
On Tue, May 22, 2018 at 12:12 AM, Stephan Erb <st...@blue-yonder.com>
wrote:
> Hey Renan,
>
> thanks again for bringing this up. In my experience, the pain comes from
> building, testing & voting rather the packaging scripts themselves. I
> therefore think we should discontinue building, but continue to maintain
> the scripts so that users can build them on their own when necessary.
>
Fully agree on this. I will even go as far as making unofficial builds
available for the time being if no one is opposed and if it's not against
Apache policy to do so.
>
> We must be careful though with linking the ‘nightly jenkins builds’ on the
> website. We got called out for this once in the past and had to take the
> link down.
>
Noted, thanks for bringing this up!
>
> We also see a lack of involvement in code reviews. I think we should
> consider setting up a more formal lazy consensus policy
> https://www.apache.org/foundation/voting.html#LazyConsensus : For
> example, patches maybe merged even with a single ‘ship it’ from a
> committer, if there is neither a ship-it nor a veto from other committers
> within 7 days.
>
I think this is a very valid way forward at this point. How does everyone
else feel about this?
>
> Best regards,
> Stephan
>
-Renan
>
> From: Santhosh Kumar Shanmugham <ss...@twitter.com>
> Reply-To: "user@aurora.apache.org" <us...@aurora.apache.org>
> Date: Thursday, 17. May 2018 at 22:13
> To: "dev@aurora.apache.org" <de...@aurora.apache.org>
> Cc: "user@aurora.apache.org" <us...@aurora.apache.org>
> Subject: Re: [DISCUSS] State of the Community
>
> Hello Renan,
>
> I understand your frustration.
>
> I am a strong +1 for automating the release and voting process. I performed
> a release a while back and the process definitely needs it improve
> documentation
> at the least. If one of the members who are more familiar with this
> process can
> create a backlog, I will be happy to chip in.
>
> -Santhosh
>
> On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <renan@apache.org<mailto:
> renan@apache.org>> wrote:
> All,
>
> Discussion has been open for 13 days and only one user has chimed in.
> Unfortunately it looks like talking point number one will be a serious
> concern going forward. I will give until tomorrow 12 PM San Francisco time
> for folks to voice their opinion on these issues.
>
> After tomorrow I will call a vote to cease distributions of official binary
> packages from versions 0.21.0 onwards until the process is automated and
> voting for the voting for the binary packages can be combined with the
> tar.gz release.
>
> Since no feedback was received regarding talking point three, the idea will
> be dropped.
>
> -Renan
>
>
> On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <renanidelvalle@gmail.com<
> mailto:renanidelvalle@gmail.com>>
> wrote:
>
> > In some ways, that's some of the best feedback we can get. Very happy to
> > hear that Aurora is working fo well for Chartbeat.
> >
> > I do hope that you guys find some time to help us maintain the project.
> > Every little bit counts!
> >
> > -Renan
> >
> > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <rick@chartbeat.com<mailto:
> rick@chartbeat.com>> wrote:
> >
> >> As strong users of aurora but weak contributors, we at Chartbeat
> >> apologize for our lack of participation. We’re several versions behind
> on
> >> mesos/aurora upgrades and that’s honestly because it works for us :)
> >>
> >> Going forward we’re hoping to be able to participate more, at least with
> >> testing new releases.
> >>
> >> We thank you though!
> >>
> >> Rick and the rest of Chartbeat Engineering
> >>
> >>
> >> > On May 4, 2018, at 2:38 PM, Renan DelValle <renan@apache.org<mailto:
> renan@apache.org>> wrote:
> >> >
> >> > Hello all,
> >> >
> >> > I wanted to bring up a few points for discussion with the community.
> I'd
> >> > really like to hear what the community's thoughts are on these issues
> >> and
> >> > how can resolve them.
> >> >
> >> > 1. Lack of participation. This is due to many members moving on from
> the
> >> > project and becoming dormant. More concerning is the fact that our PMC
> >> > roster sits at 21 members [1] of which fewer than half have
> >> participated in
> >> > the project during the last 6 months.
> >> >
> >> > This inactivity has led the voting process for releases to be held up
> by
> >> > the inability to reach the required minimum 3 votes for releases (both
> >> > tar.gz and binary). Our latest binary packaging vote has been going on
> >> for
> >> > more than a month. [2]
> >> >
> >> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly
> to
> >> the
> >> > Aurora PMC, we hope to mitigate this issue.
> >> >
> >> > It would be fantastic to see some initiative from long contributing
> >> members
> >> > to make a case for themselves for being considered for committer
> and/or
> >> PMC
> >> > membership.
> >> >
> >> > 2. Binary packages. While we have been struggling to get enough votes
> >> for
> >> > making the release official, the voting process has been marked by a
> >> lack
> >> > of enthusiasm from the community.
> >> >
> >> > I know that many folks are using these packages (including myself),
> but
> >> we
> >> > need to hear feedback when we call votes. It is not enough to stand by
> >> > silently if everything works; please let us know about it.
> >> >
> >> > As it stands, the enthusiasm (or lack thereof) for binary packages
> >> doesn't
> >> > justify the overhead involved in releasing them. Therefore I propose
> >> that
> >> > we drop official binary packages for the next release. This is up for
> >> > discussion and I'd love to hear everyone's opinion on this.
> >> >
> >> > An alternative to ending binary packages would be to automate the
> >> process
> >> > on tar.gz releases, but that would most likely need to be a community
> >> > contribution.
> >> >
> >> > 3. Version 1.0. I realize this is a touchy subject. While other
> projects
> >> > that were started around the same time as Aurora, such as Mesos
> itself,
> >> > have gone on to make a 1.0 release (indicating the projects maturity),
> >> we
> >> > have stuck to our 0.X.0 releases.
> >> >
> >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
> >> > wanted to bring up for discussion how everyone felt about making our
> >> next
> >> > release a 1.0 release to reflect the stability and maturity of the
> >> project.
> >> >
> >> > That is all from me, if anyone else has any other concerns regarding
> the
> >> > Aurora community, feel free to bring it up in this thread!
> >> >
> >> > -Renan
> >> >
> >> >
> >> > [1] https://projects.apache.org/committee.html?aurora
> >> > [2] https://lists.apache.org/thread.html/
> 9df9d142408efffd11a1cdc5e4c1e3
> >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http://
> 3Cdev.aurora.apache.org>%3E
> >>
> >>
> >
>
>
Re: [DISCUSS] State of the Community
Posted by Stephan Erb <st...@blue-yonder.com>.
Hey Renan,
thanks again for bringing this up. In my experience, the pain comes from building, testing & voting rather the packaging scripts themselves. I therefore think we should discontinue building, but continue to maintain the scripts so that users can build them on their own when necessary.
We must be careful though with linking the ‘nightly jenkins builds’ on the website. We got called out for this once in the past and had to take the link down.
We also see a lack of involvement in code reviews. I think we should consider setting up a more formal lazy consensus policy https://www.apache.org/foundation/voting.html#LazyConsensus : For example, patches maybe merged even with a single ‘ship it’ from a committer, if there is neither a ship-it nor a veto from other committers within 7 days.
Best regards,
Stephan
From: Santhosh Kumar Shanmugham <ss...@twitter.com>
Reply-To: "user@aurora.apache.org" <us...@aurora.apache.org>
Date: Thursday, 17. May 2018 at 22:13
To: "dev@aurora.apache.org" <de...@aurora.apache.org>
Cc: "user@aurora.apache.org" <us...@aurora.apache.org>
Subject: Re: [DISCUSS] State of the Community
Hello Renan,
I understand your frustration.
I am a strong +1 for automating the release and voting process. I performed
a release a while back and the process definitely needs it improve documentation
at the least. If one of the members who are more familiar with this process can
create a backlog, I will be happy to chip in.
-Santhosh
On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <re...@apache.org>> wrote:
All,
Discussion has been open for 13 days and only one user has chimed in.
Unfortunately it looks like talking point number one will be a serious
concern going forward. I will give until tomorrow 12 PM San Francisco time
for folks to voice their opinion on these issues.
After tomorrow I will call a vote to cease distributions of official binary
packages from versions 0.21.0 onwards until the process is automated and
voting for the voting for the binary packages can be combined with the
tar.gz release.
Since no feedback was received regarding talking point three, the idea will
be dropped.
-Renan
On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <re...@gmail.com>>
wrote:
> In some ways, that's some of the best feedback we can get. Very happy to
> hear that Aurora is working fo well for Chartbeat.
>
> I do hope that you guys find some time to help us maintain the project.
> Every little bit counts!
>
> -Renan
>
> On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <ri...@chartbeat.com>> wrote:
>
>> As strong users of aurora but weak contributors, we at Chartbeat
>> apologize for our lack of participation. We’re several versions behind on
>> mesos/aurora upgrades and that’s honestly because it works for us :)
>>
>> Going forward we’re hoping to be able to participate more, at least with
>> testing new releases.
>>
>> We thank you though!
>>
>> Rick and the rest of Chartbeat Engineering
>>
>>
>> > On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org>> wrote:
>> >
>> > Hello all,
>> >
>> > I wanted to bring up a few points for discussion with the community. I'd
>> > really like to hear what the community's thoughts are on these issues
>> and
>> > how can resolve them.
>> >
>> > 1. Lack of participation. This is due to many members moving on from the
>> > project and becoming dormant. More concerning is the fact that our PMC
>> > roster sits at 21 members [1] of which fewer than half have
>> participated in
>> > the project during the last 6 months.
>> >
>> > This inactivity has led the voting process for releases to be held up by
>> > the inability to reach the required minimum 3 votes for releases (both
>> > tar.gz and binary). Our latest binary packaging vote has been going on
>> for
>> > more than a month. [2]
>> >
>> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly to
>> the
>> > Aurora PMC, we hope to mitigate this issue.
>> >
>> > It would be fantastic to see some initiative from long contributing
>> members
>> > to make a case for themselves for being considered for committer and/or
>> PMC
>> > membership.
>> >
>> > 2. Binary packages. While we have been struggling to get enough votes
>> for
>> > making the release official, the voting process has been marked by a
>> lack
>> > of enthusiasm from the community.
>> >
>> > I know that many folks are using these packages (including myself), but
>> we
>> > need to hear feedback when we call votes. It is not enough to stand by
>> > silently if everything works; please let us know about it.
>> >
>> > As it stands, the enthusiasm (or lack thereof) for binary packages
>> doesn't
>> > justify the overhead involved in releasing them. Therefore I propose
>> that
>> > we drop official binary packages for the next release. This is up for
>> > discussion and I'd love to hear everyone's opinion on this.
>> >
>> > An alternative to ending binary packages would be to automate the
>> process
>> > on tar.gz releases, but that would most likely need to be a community
>> > contribution.
>> >
>> > 3. Version 1.0. I realize this is a touchy subject. While other projects
>> > that were started around the same time as Aurora, such as Mesos itself,
>> > have gone on to make a 1.0 release (indicating the projects maturity),
>> we
>> > have stuck to our 0.X.0 releases.
>> >
>> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
>> > wanted to bring up for discussion how everyone felt about making our
>> next
>> > release a 1.0 release to reflect the stability and maturity of the
>> project.
>> >
>> > That is all from me, if anyone else has any other concerns regarding the
>> > Aurora community, feel free to bring it up in this thread!
>> >
>> > -Renan
>> >
>> >
>> > [1] https://projects.apache.org/committee.html?aurora
>> > [2] https://lists.apache.org/thread.html/9df9d142408efffd11a1cdc5e4c1e3
>> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http://3Cdev.aurora.apache.org>%3E
>>
>>
>
Re: [DISCUSS] State of the Community
Posted by Stephan Erb <st...@blue-yonder.com>.
Hey Renan,
thanks again for bringing this up. In my experience, the pain comes from building, testing & voting rather the packaging scripts themselves. I therefore think we should discontinue building, but continue to maintain the scripts so that users can build them on their own when necessary.
We must be careful though with linking the ‘nightly jenkins builds’ on the website. We got called out for this once in the past and had to take the link down.
We also see a lack of involvement in code reviews. I think we should consider setting up a more formal lazy consensus policy https://www.apache.org/foundation/voting.html#LazyConsensus : For example, patches maybe merged even with a single ‘ship it’ from a committer, if there is neither a ship-it nor a veto from other committers within 7 days.
Best regards,
Stephan
From: Santhosh Kumar Shanmugham <ss...@twitter.com>
Reply-To: "user@aurora.apache.org" <us...@aurora.apache.org>
Date: Thursday, 17. May 2018 at 22:13
To: "dev@aurora.apache.org" <de...@aurora.apache.org>
Cc: "user@aurora.apache.org" <us...@aurora.apache.org>
Subject: Re: [DISCUSS] State of the Community
Hello Renan,
I understand your frustration.
I am a strong +1 for automating the release and voting process. I performed
a release a while back and the process definitely needs it improve documentation
at the least. If one of the members who are more familiar with this process can
create a backlog, I will be happy to chip in.
-Santhosh
On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <re...@apache.org>> wrote:
All,
Discussion has been open for 13 days and only one user has chimed in.
Unfortunately it looks like talking point number one will be a serious
concern going forward. I will give until tomorrow 12 PM San Francisco time
for folks to voice their opinion on these issues.
After tomorrow I will call a vote to cease distributions of official binary
packages from versions 0.21.0 onwards until the process is automated and
voting for the voting for the binary packages can be combined with the
tar.gz release.
Since no feedback was received regarding talking point three, the idea will
be dropped.
-Renan
On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <re...@gmail.com>>
wrote:
> In some ways, that's some of the best feedback we can get. Very happy to
> hear that Aurora is working fo well for Chartbeat.
>
> I do hope that you guys find some time to help us maintain the project.
> Every little bit counts!
>
> -Renan
>
> On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <ri...@chartbeat.com>> wrote:
>
>> As strong users of aurora but weak contributors, we at Chartbeat
>> apologize for our lack of participation. We’re several versions behind on
>> mesos/aurora upgrades and that’s honestly because it works for us :)
>>
>> Going forward we’re hoping to be able to participate more, at least with
>> testing new releases.
>>
>> We thank you though!
>>
>> Rick and the rest of Chartbeat Engineering
>>
>>
>> > On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org>> wrote:
>> >
>> > Hello all,
>> >
>> > I wanted to bring up a few points for discussion with the community. I'd
>> > really like to hear what the community's thoughts are on these issues
>> and
>> > how can resolve them.
>> >
>> > 1. Lack of participation. This is due to many members moving on from the
>> > project and becoming dormant. More concerning is the fact that our PMC
>> > roster sits at 21 members [1] of which fewer than half have
>> participated in
>> > the project during the last 6 months.
>> >
>> > This inactivity has led the voting process for releases to be held up by
>> > the inability to reach the required minimum 3 votes for releases (both
>> > tar.gz and binary). Our latest binary packaging vote has been going on
>> for
>> > more than a month. [2]
>> >
>> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly to
>> the
>> > Aurora PMC, we hope to mitigate this issue.
>> >
>> > It would be fantastic to see some initiative from long contributing
>> members
>> > to make a case for themselves for being considered for committer and/or
>> PMC
>> > membership.
>> >
>> > 2. Binary packages. While we have been struggling to get enough votes
>> for
>> > making the release official, the voting process has been marked by a
>> lack
>> > of enthusiasm from the community.
>> >
>> > I know that many folks are using these packages (including myself), but
>> we
>> > need to hear feedback when we call votes. It is not enough to stand by
>> > silently if everything works; please let us know about it.
>> >
>> > As it stands, the enthusiasm (or lack thereof) for binary packages
>> doesn't
>> > justify the overhead involved in releasing them. Therefore I propose
>> that
>> > we drop official binary packages for the next release. This is up for
>> > discussion and I'd love to hear everyone's opinion on this.
>> >
>> > An alternative to ending binary packages would be to automate the
>> process
>> > on tar.gz releases, but that would most likely need to be a community
>> > contribution.
>> >
>> > 3. Version 1.0. I realize this is a touchy subject. While other projects
>> > that were started around the same time as Aurora, such as Mesos itself,
>> > have gone on to make a 1.0 release (indicating the projects maturity),
>> we
>> > have stuck to our 0.X.0 releases.
>> >
>> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
>> > wanted to bring up for discussion how everyone felt about making our
>> next
>> > release a 1.0 release to reflect the stability and maturity of the
>> project.
>> >
>> > That is all from me, if anyone else has any other concerns regarding the
>> > Aurora community, feel free to bring it up in this thread!
>> >
>> > -Renan
>> >
>> >
>> > [1] https://projects.apache.org/committee.html?aurora
>> > [2] https://lists.apache.org/thread.html/9df9d142408efffd11a1cdc5e4c1e3
>> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org<http://3Cdev.aurora.apache.org>%3E
>>
>>
>
Re: [DISCUSS] State of the Community
Posted by Santhosh Kumar Shanmugham <ss...@twitter.com>.
Hello Renan,
I understand your frustration.
I am a strong +1 for automating the release and voting process. I performed
a release a while back and the process definitely needs it improve
documentation
at the least. If one of the members who are more familiar with this process
can
create a backlog, I will be happy to chip in.
-Santhosh
On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <re...@apache.org> wrote:
> All,
>
> Discussion has been open for 13 days and only one user has chimed in.
> Unfortunately it looks like talking point number one will be a serious
> concern going forward. I will give until tomorrow 12 PM San Francisco time
> for folks to voice their opinion on these issues.
>
> After tomorrow I will call a vote to cease distributions of official binary
> packages from versions 0.21.0 onwards until the process is automated and
> voting for the voting for the binary packages can be combined with the
> tar.gz release.
>
> Since no feedback was received regarding talking point three, the idea will
> be dropped.
>
> -Renan
>
>
> On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <re...@gmail.com>
> wrote:
>
> > In some ways, that's some of the best feedback we can get. Very happy to
> > hear that Aurora is working fo well for Chartbeat.
> >
> > I do hope that you guys find some time to help us maintain the project.
> > Every little bit counts!
> >
> > -Renan
> >
> > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <ri...@chartbeat.com> wrote:
> >
> >> As strong users of aurora but weak contributors, we at Chartbeat
> >> apologize for our lack of participation. We’re several versions behind
> on
> >> mesos/aurora upgrades and that’s honestly because it works for us :)
> >>
> >> Going forward we’re hoping to be able to participate more, at least with
> >> testing new releases.
> >>
> >> We thank you though!
> >>
> >> Rick and the rest of Chartbeat Engineering
> >>
> >>
> >> > On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org> wrote:
> >> >
> >> > Hello all,
> >> >
> >> > I wanted to bring up a few points for discussion with the community.
> I'd
> >> > really like to hear what the community's thoughts are on these issues
> >> and
> >> > how can resolve them.
> >> >
> >> > 1. Lack of participation. This is due to many members moving on from
> the
> >> > project and becoming dormant. More concerning is the fact that our PMC
> >> > roster sits at 21 members [1] of which fewer than half have
> >> participated in
> >> > the project during the last 6 months.
> >> >
> >> > This inactivity has led the voting process for releases to be held up
> by
> >> > the inability to reach the required minimum 3 votes for releases (both
> >> > tar.gz and binary). Our latest binary packaging vote has been going on
> >> for
> >> > more than a month. [2]
> >> >
> >> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly
> to
> >> the
> >> > Aurora PMC, we hope to mitigate this issue.
> >> >
> >> > It would be fantastic to see some initiative from long contributing
> >> members
> >> > to make a case for themselves for being considered for committer
> and/or
> >> PMC
> >> > membership.
> >> >
> >> > 2. Binary packages. While we have been struggling to get enough votes
> >> for
> >> > making the release official, the voting process has been marked by a
> >> lack
> >> > of enthusiasm from the community.
> >> >
> >> > I know that many folks are using these packages (including myself),
> but
> >> we
> >> > need to hear feedback when we call votes. It is not enough to stand by
> >> > silently if everything works; please let us know about it.
> >> >
> >> > As it stands, the enthusiasm (or lack thereof) for binary packages
> >> doesn't
> >> > justify the overhead involved in releasing them. Therefore I propose
> >> that
> >> > we drop official binary packages for the next release. This is up for
> >> > discussion and I'd love to hear everyone's opinion on this.
> >> >
> >> > An alternative to ending binary packages would be to automate the
> >> process
> >> > on tar.gz releases, but that would most likely need to be a community
> >> > contribution.
> >> >
> >> > 3. Version 1.0. I realize this is a touchy subject. While other
> projects
> >> > that were started around the same time as Aurora, such as Mesos
> itself,
> >> > have gone on to make a 1.0 release (indicating the projects maturity),
> >> we
> >> > have stuck to our 0.X.0 releases.
> >> >
> >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
> >> > wanted to bring up for discussion how everyone felt about making our
> >> next
> >> > release a 1.0 release to reflect the stability and maturity of the
> >> project.
> >> >
> >> > That is all from me, if anyone else has any other concerns regarding
> the
> >> > Aurora community, feel free to bring it up in this thread!
> >> >
> >> > -Renan
> >> >
> >> >
> >> > [1] https://projects.apache.org/committee.html?aurora
> >> > [2] https://lists.apache.org/thread.html/
> 9df9d142408efffd11a1cdc5e4c1e3
> >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org%3E
> >>
> >>
> >
>
Re: [DISCUSS] State of the Community
Posted by Santhosh Kumar Shanmugham <ss...@twitter.com.INVALID>.
Hello Renan,
I understand your frustration.
I am a strong +1 for automating the release and voting process. I performed
a release a while back and the process definitely needs it improve
documentation
at the least. If one of the members who are more familiar with this process
can
create a backlog, I will be happy to chip in.
-Santhosh
On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <re...@apache.org> wrote:
> All,
>
> Discussion has been open for 13 days and only one user has chimed in.
> Unfortunately it looks like talking point number one will be a serious
> concern going forward. I will give until tomorrow 12 PM San Francisco time
> for folks to voice their opinion on these issues.
>
> After tomorrow I will call a vote to cease distributions of official binary
> packages from versions 0.21.0 onwards until the process is automated and
> voting for the voting for the binary packages can be combined with the
> tar.gz release.
>
> Since no feedback was received regarding talking point three, the idea will
> be dropped.
>
> -Renan
>
>
> On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <re...@gmail.com>
> wrote:
>
> > In some ways, that's some of the best feedback we can get. Very happy to
> > hear that Aurora is working fo well for Chartbeat.
> >
> > I do hope that you guys find some time to help us maintain the project.
> > Every little bit counts!
> >
> > -Renan
> >
> > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <ri...@chartbeat.com> wrote:
> >
> >> As strong users of aurora but weak contributors, we at Chartbeat
> >> apologize for our lack of participation. We’re several versions behind
> on
> >> mesos/aurora upgrades and that’s honestly because it works for us :)
> >>
> >> Going forward we’re hoping to be able to participate more, at least with
> >> testing new releases.
> >>
> >> We thank you though!
> >>
> >> Rick and the rest of Chartbeat Engineering
> >>
> >>
> >> > On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org> wrote:
> >> >
> >> > Hello all,
> >> >
> >> > I wanted to bring up a few points for discussion with the community.
> I'd
> >> > really like to hear what the community's thoughts are on these issues
> >> and
> >> > how can resolve them.
> >> >
> >> > 1. Lack of participation. This is due to many members moving on from
> the
> >> > project and becoming dormant. More concerning is the fact that our PMC
> >> > roster sits at 21 members [1] of which fewer than half have
> >> participated in
> >> > the project during the last 6 months.
> >> >
> >> > This inactivity has led the voting process for releases to be held up
> by
> >> > the inability to reach the required minimum 3 votes for releases (both
> >> > tar.gz and binary). Our latest binary packaging vote has been going on
> >> for
> >> > more than a month. [2]
> >> >
> >> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly
> to
> >> the
> >> > Aurora PMC, we hope to mitigate this issue.
> >> >
> >> > It would be fantastic to see some initiative from long contributing
> >> members
> >> > to make a case for themselves for being considered for committer
> and/or
> >> PMC
> >> > membership.
> >> >
> >> > 2. Binary packages. While we have been struggling to get enough votes
> >> for
> >> > making the release official, the voting process has been marked by a
> >> lack
> >> > of enthusiasm from the community.
> >> >
> >> > I know that many folks are using these packages (including myself),
> but
> >> we
> >> > need to hear feedback when we call votes. It is not enough to stand by
> >> > silently if everything works; please let us know about it.
> >> >
> >> > As it stands, the enthusiasm (or lack thereof) for binary packages
> >> doesn't
> >> > justify the overhead involved in releasing them. Therefore I propose
> >> that
> >> > we drop official binary packages for the next release. This is up for
> >> > discussion and I'd love to hear everyone's opinion on this.
> >> >
> >> > An alternative to ending binary packages would be to automate the
> >> process
> >> > on tar.gz releases, but that would most likely need to be a community
> >> > contribution.
> >> >
> >> > 3. Version 1.0. I realize this is a touchy subject. While other
> projects
> >> > that were started around the same time as Aurora, such as Mesos
> itself,
> >> > have gone on to make a 1.0 release (indicating the projects maturity),
> >> we
> >> > have stuck to our 0.X.0 releases.
> >> >
> >> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
> >> > wanted to bring up for discussion how everyone felt about making our
> >> next
> >> > release a 1.0 release to reflect the stability and maturity of the
> >> project.
> >> >
> >> > That is all from me, if anyone else has any other concerns regarding
> the
> >> > Aurora community, feel free to bring it up in this thread!
> >> >
> >> > -Renan
> >> >
> >> >
> >> > [1] https://projects.apache.org/committee.html?aurora
> >> > [2] https://lists.apache.org/thread.html/
> 9df9d142408efffd11a1cdc5e4c1e3
> >> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org%3E
> >>
> >>
> >
>
Re: [DISCUSS] State of the Community
Posted by Renan DelValle <re...@apache.org>.
All,
Discussion has been open for 13 days and only one user has chimed in.
Unfortunately it looks like talking point number one will be a serious
concern going forward. I will give until tomorrow 12 PM San Francisco time
for folks to voice their opinion on these issues.
After tomorrow I will call a vote to cease distributions of official binary
packages from versions 0.21.0 onwards until the process is automated and
voting for the voting for the binary packages can be combined with the
tar.gz release.
Since no feedback was received regarding talking point three, the idea will
be dropped.
-Renan
On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <re...@gmail.com>
wrote:
> In some ways, that's some of the best feedback we can get. Very happy to
> hear that Aurora is working fo well for Chartbeat.
>
> I do hope that you guys find some time to help us maintain the project.
> Every little bit counts!
>
> -Renan
>
> On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <ri...@chartbeat.com> wrote:
>
>> As strong users of aurora but weak contributors, we at Chartbeat
>> apologize for our lack of participation. We’re several versions behind on
>> mesos/aurora upgrades and that’s honestly because it works for us :)
>>
>> Going forward we’re hoping to be able to participate more, at least with
>> testing new releases.
>>
>> We thank you though!
>>
>> Rick and the rest of Chartbeat Engineering
>>
>>
>> > On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org> wrote:
>> >
>> > Hello all,
>> >
>> > I wanted to bring up a few points for discussion with the community. I'd
>> > really like to hear what the community's thoughts are on these issues
>> and
>> > how can resolve them.
>> >
>> > 1. Lack of participation. This is due to many members moving on from the
>> > project and becoming dormant. More concerning is the fact that our PMC
>> > roster sits at 21 members [1] of which fewer than half have
>> participated in
>> > the project during the last 6 months.
>> >
>> > This inactivity has led the voting process for releases to be held up by
>> > the inability to reach the required minimum 3 votes for releases (both
>> > tar.gz and binary). Our latest binary packaging vote has been going on
>> for
>> > more than a month. [2]
>> >
>> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly to
>> the
>> > Aurora PMC, we hope to mitigate this issue.
>> >
>> > It would be fantastic to see some initiative from long contributing
>> members
>> > to make a case for themselves for being considered for committer and/or
>> PMC
>> > membership.
>> >
>> > 2. Binary packages. While we have been struggling to get enough votes
>> for
>> > making the release official, the voting process has been marked by a
>> lack
>> > of enthusiasm from the community.
>> >
>> > I know that many folks are using these packages (including myself), but
>> we
>> > need to hear feedback when we call votes. It is not enough to stand by
>> > silently if everything works; please let us know about it.
>> >
>> > As it stands, the enthusiasm (or lack thereof) for binary packages
>> doesn't
>> > justify the overhead involved in releasing them. Therefore I propose
>> that
>> > we drop official binary packages for the next release. This is up for
>> > discussion and I'd love to hear everyone's opinion on this.
>> >
>> > An alternative to ending binary packages would be to automate the
>> process
>> > on tar.gz releases, but that would most likely need to be a community
>> > contribution.
>> >
>> > 3. Version 1.0. I realize this is a touchy subject. While other projects
>> > that were started around the same time as Aurora, such as Mesos itself,
>> > have gone on to make a 1.0 release (indicating the projects maturity),
>> we
>> > have stuck to our 0.X.0 releases.
>> >
>> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
>> > wanted to bring up for discussion how everyone felt about making our
>> next
>> > release a 1.0 release to reflect the stability and maturity of the
>> project.
>> >
>> > That is all from me, if anyone else has any other concerns regarding the
>> > Aurora community, feel free to bring it up in this thread!
>> >
>> > -Renan
>> >
>> >
>> > [1] https://projects.apache.org/committee.html?aurora
>> > [2] https://lists.apache.org/thread.html/9df9d142408efffd11a1cdc5e4c1e3
>> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org%3E
>>
>>
>
Re: [DISCUSS] State of the Community
Posted by Renan DelValle <re...@apache.org>.
All,
Discussion has been open for 13 days and only one user has chimed in.
Unfortunately it looks like talking point number one will be a serious
concern going forward. I will give until tomorrow 12 PM San Francisco time
for folks to voice their opinion on these issues.
After tomorrow I will call a vote to cease distributions of official binary
packages from versions 0.21.0 onwards until the process is automated and
voting for the voting for the binary packages can be combined with the
tar.gz release.
Since no feedback was received regarding talking point three, the idea will
be dropped.
-Renan
On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <re...@gmail.com>
wrote:
> In some ways, that's some of the best feedback we can get. Very happy to
> hear that Aurora is working fo well for Chartbeat.
>
> I do hope that you guys find some time to help us maintain the project.
> Every little bit counts!
>
> -Renan
>
> On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <ri...@chartbeat.com> wrote:
>
>> As strong users of aurora but weak contributors, we at Chartbeat
>> apologize for our lack of participation. We’re several versions behind on
>> mesos/aurora upgrades and that’s honestly because it works for us :)
>>
>> Going forward we’re hoping to be able to participate more, at least with
>> testing new releases.
>>
>> We thank you though!
>>
>> Rick and the rest of Chartbeat Engineering
>>
>>
>> > On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org> wrote:
>> >
>> > Hello all,
>> >
>> > I wanted to bring up a few points for discussion with the community. I'd
>> > really like to hear what the community's thoughts are on these issues
>> and
>> > how can resolve them.
>> >
>> > 1. Lack of participation. This is due to many members moving on from the
>> > project and becoming dormant. More concerning is the fact that our PMC
>> > roster sits at 21 members [1] of which fewer than half have
>> participated in
>> > the project during the last 6 months.
>> >
>> > This inactivity has led the voting process for releases to be held up by
>> > the inability to reach the required minimum 3 votes for releases (both
>> > tar.gz and binary). Our latest binary packaging vote has been going on
>> for
>> > more than a month. [2]
>> >
>> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly to
>> the
>> > Aurora PMC, we hope to mitigate this issue.
>> >
>> > It would be fantastic to see some initiative from long contributing
>> members
>> > to make a case for themselves for being considered for committer and/or
>> PMC
>> > membership.
>> >
>> > 2. Binary packages. While we have been struggling to get enough votes
>> for
>> > making the release official, the voting process has been marked by a
>> lack
>> > of enthusiasm from the community.
>> >
>> > I know that many folks are using these packages (including myself), but
>> we
>> > need to hear feedback when we call votes. It is not enough to stand by
>> > silently if everything works; please let us know about it.
>> >
>> > As it stands, the enthusiasm (or lack thereof) for binary packages
>> doesn't
>> > justify the overhead involved in releasing them. Therefore I propose
>> that
>> > we drop official binary packages for the next release. This is up for
>> > discussion and I'd love to hear everyone's opinion on this.
>> >
>> > An alternative to ending binary packages would be to automate the
>> process
>> > on tar.gz releases, but that would most likely need to be a community
>> > contribution.
>> >
>> > 3. Version 1.0. I realize this is a touchy subject. While other projects
>> > that were started around the same time as Aurora, such as Mesos itself,
>> > have gone on to make a 1.0 release (indicating the projects maturity),
>> we
>> > have stuck to our 0.X.0 releases.
>> >
>> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
>> > wanted to bring up for discussion how everyone felt about making our
>> next
>> > release a 1.0 release to reflect the stability and maturity of the
>> project.
>> >
>> > That is all from me, if anyone else has any other concerns regarding the
>> > Aurora community, feel free to bring it up in this thread!
>> >
>> > -Renan
>> >
>> >
>> > [1] https://projects.apache.org/committee.html?aurora
>> > [2] https://lists.apache.org/thread.html/9df9d142408efffd11a1cdc5e4c1e3
>> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org%3E
>>
>>
>
Re: [DISCUSS] State of the Community
Posted by Renan DelValle <re...@gmail.com>.
In some ways, that's some of the best feedback we can get. Very happy to
hear that Aurora is working fo well for Chartbeat.
I do hope that you guys find some time to help us maintain the project.
Every little bit counts!
-Renan
On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <ri...@chartbeat.com> wrote:
> As strong users of aurora but weak contributors, we at Chartbeat apologize
> for our lack of participation. We’re several versions behind on
> mesos/aurora upgrades and that’s honestly because it works for us :)
>
> Going forward we’re hoping to be able to participate more, at least with
> testing new releases.
>
> We thank you though!
>
> Rick and the rest of Chartbeat Engineering
>
>
> > On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org> wrote:
> >
> > Hello all,
> >
> > I wanted to bring up a few points for discussion with the community. I'd
> > really like to hear what the community's thoughts are on these issues and
> > how can resolve them.
> >
> > 1. Lack of participation. This is due to many members moving on from the
> > project and becoming dormant. More concerning is the fact that our PMC
> > roster sits at 21 members [1] of which fewer than half have participated
> in
> > the project during the last 6 months.
> >
> > This inactivity has led the voting process for releases to be held up by
> > the inability to reach the required minimum 3 votes for releases (both
> > tar.gz and binary). Our latest binary packaging vote has been going on
> for
> > more than a month. [2]
> >
> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly to
> the
> > Aurora PMC, we hope to mitigate this issue.
> >
> > It would be fantastic to see some initiative from long contributing
> members
> > to make a case for themselves for being considered for committer and/or
> PMC
> > membership.
> >
> > 2. Binary packages. While we have been struggling to get enough votes for
> > making the release official, the voting process has been marked by a lack
> > of enthusiasm from the community.
> >
> > I know that many folks are using these packages (including myself), but
> we
> > need to hear feedback when we call votes. It is not enough to stand by
> > silently if everything works; please let us know about it.
> >
> > As it stands, the enthusiasm (or lack thereof) for binary packages
> doesn't
> > justify the overhead involved in releasing them. Therefore I propose that
> > we drop official binary packages for the next release. This is up for
> > discussion and I'd love to hear everyone's opinion on this.
> >
> > An alternative to ending binary packages would be to automate the process
> > on tar.gz releases, but that would most likely need to be a community
> > contribution.
> >
> > 3. Version 1.0. I realize this is a touchy subject. While other projects
> > that were started around the same time as Aurora, such as Mesos itself,
> > have gone on to make a 1.0 release (indicating the projects maturity), we
> > have stuck to our 0.X.0 releases.
> >
> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
> > wanted to bring up for discussion how everyone felt about making our next
> > release a 1.0 release to reflect the stability and maturity of the
> project.
> >
> > That is all from me, if anyone else has any other concerns regarding the
> > Aurora community, feel free to bring it up in this thread!
> >
> > -Renan
> >
> >
> > [1] https://projects.apache.org/committee.html?aurora
> > [2] https://lists.apache.org/thread.html/9df9d142408efffd11a1cdc5e4c1e3
> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org%3E
>
>
Re: [DISCUSS] State of the Community
Posted by Renan DelValle <re...@gmail.com>.
In some ways, that's some of the best feedback we can get. Very happy to
hear that Aurora is working fo well for Chartbeat.
I do hope that you guys find some time to help us maintain the project.
Every little bit counts!
-Renan
On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <ri...@chartbeat.com> wrote:
> As strong users of aurora but weak contributors, we at Chartbeat apologize
> for our lack of participation. We’re several versions behind on
> mesos/aurora upgrades and that’s honestly because it works for us :)
>
> Going forward we’re hoping to be able to participate more, at least with
> testing new releases.
>
> We thank you though!
>
> Rick and the rest of Chartbeat Engineering
>
>
> > On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org> wrote:
> >
> > Hello all,
> >
> > I wanted to bring up a few points for discussion with the community. I'd
> > really like to hear what the community's thoughts are on these issues and
> > how can resolve them.
> >
> > 1. Lack of participation. This is due to many members moving on from the
> > project and becoming dormant. More concerning is the fact that our PMC
> > roster sits at 21 members [1] of which fewer than half have participated
> in
> > the project during the last 6 months.
> >
> > This inactivity has led the voting process for releases to be held up by
> > the inability to reach the required minimum 3 votes for releases (both
> > tar.gz and binary). Our latest binary packaging vote has been going on
> for
> > more than a month. [2]
> >
> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly to
> the
> > Aurora PMC, we hope to mitigate this issue.
> >
> > It would be fantastic to see some initiative from long contributing
> members
> > to make a case for themselves for being considered for committer and/or
> PMC
> > membership.
> >
> > 2. Binary packages. While we have been struggling to get enough votes for
> > making the release official, the voting process has been marked by a lack
> > of enthusiasm from the community.
> >
> > I know that many folks are using these packages (including myself), but
> we
> > need to hear feedback when we call votes. It is not enough to stand by
> > silently if everything works; please let us know about it.
> >
> > As it stands, the enthusiasm (or lack thereof) for binary packages
> doesn't
> > justify the overhead involved in releasing them. Therefore I propose that
> > we drop official binary packages for the next release. This is up for
> > discussion and I'd love to hear everyone's opinion on this.
> >
> > An alternative to ending binary packages would be to automate the process
> > on tar.gz releases, but that would most likely need to be a community
> > contribution.
> >
> > 3. Version 1.0. I realize this is a touchy subject. While other projects
> > that were started around the same time as Aurora, such as Mesos itself,
> > have gone on to make a 1.0 release (indicating the projects maturity), we
> > have stuck to our 0.X.0 releases.
> >
> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
> > wanted to bring up for discussion how everyone felt about making our next
> > release a 1.0 release to reflect the stability and maturity of the
> project.
> >
> > That is all from me, if anyone else has any other concerns regarding the
> > Aurora community, feel free to bring it up in this thread!
> >
> > -Renan
> >
> >
> > [1] https://projects.apache.org/committee.html?aurora
> > [2] https://lists.apache.org/thread.html/9df9d142408efffd11a1cdc5e4c1e3
> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org%3E
>
>
Re: [DISCUSS] State of the Community
Posted by Rick Mangi <ri...@chartbeat.com>.
As strong users of aurora but weak contributors, we at Chartbeat apologize for our lack of participation. We’re several versions behind on mesos/aurora upgrades and that’s honestly because it works for us :)
Going forward we’re hoping to be able to participate more, at least with testing new releases.
We thank you though!
Rick and the rest of Chartbeat Engineering
> On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org> wrote:
>
> Hello all,
>
> I wanted to bring up a few points for discussion with the community. I'd
> really like to hear what the community's thoughts are on these issues and
> how can resolve them.
>
> 1. Lack of participation. This is due to many members moving on from the
> project and becoming dormant. More concerning is the fact that our PMC
> roster sits at 21 members [1] of which fewer than half have participated in
> the project during the last 6 months.
>
> This inactivity has led the voting process for releases to be held up by
> the inability to reach the required minimum 3 votes for releases (both
> tar.gz and binary). Our latest binary packaging vote has been going on for
> more than a month. [2]
>
> With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly to the
> Aurora PMC, we hope to mitigate this issue.
>
> It would be fantastic to see some initiative from long contributing members
> to make a case for themselves for being considered for committer and/or PMC
> membership.
>
> 2. Binary packages. While we have been struggling to get enough votes for
> making the release official, the voting process has been marked by a lack
> of enthusiasm from the community.
>
> I know that many folks are using these packages (including myself), but we
> need to hear feedback when we call votes. It is not enough to stand by
> silently if everything works; please let us know about it.
>
> As it stands, the enthusiasm (or lack thereof) for binary packages doesn't
> justify the overhead involved in releasing them. Therefore I propose that
> we drop official binary packages for the next release. This is up for
> discussion and I'd love to hear everyone's opinion on this.
>
> An alternative to ending binary packages would be to automate the process
> on tar.gz releases, but that would most likely need to be a community
> contribution.
>
> 3. Version 1.0. I realize this is a touchy subject. While other projects
> that were started around the same time as Aurora, such as Mesos itself,
> have gone on to make a 1.0 release (indicating the projects maturity), we
> have stuck to our 0.X.0 releases.
>
> Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
> wanted to bring up for discussion how everyone felt about making our next
> release a 1.0 release to reflect the stability and maturity of the project.
>
> That is all from me, if anyone else has any other concerns regarding the
> Aurora community, feel free to bring it up in this thread!
>
> -Renan
>
>
> [1] https://projects.apache.org/committee.html?aurora
> [2] https://lists.apache.org/thread.html/9df9d142408efffd11a1cdc5e4c1e3
> 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org%3E
Re: [DISCUSS] State of the Community
Posted by Rick Mangi <ri...@chartbeat.com>.
As strong users of aurora but weak contributors, we at Chartbeat apologize for our lack of participation. We’re several versions behind on mesos/aurora upgrades and that’s honestly because it works for us :)
Going forward we’re hoping to be able to participate more, at least with testing new releases.
We thank you though!
Rick and the rest of Chartbeat Engineering
> On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org> wrote:
>
> Hello all,
>
> I wanted to bring up a few points for discussion with the community. I'd
> really like to hear what the community's thoughts are on these issues and
> how can resolve them.
>
> 1. Lack of participation. This is due to many members moving on from the
> project and becoming dormant. More concerning is the fact that our PMC
> roster sits at 21 members [1] of which fewer than half have participated in
> the project during the last 6 months.
>
> This inactivity has led the voting process for releases to be held up by
> the inability to reach the required minimum 3 votes for releases (both
> tar.gz and binary). Our latest binary packaging vote has been going on for
> more than a month. [2]
>
> With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly to the
> Aurora PMC, we hope to mitigate this issue.
>
> It would be fantastic to see some initiative from long contributing members
> to make a case for themselves for being considered for committer and/or PMC
> membership.
>
> 2. Binary packages. While we have been struggling to get enough votes for
> making the release official, the voting process has been marked by a lack
> of enthusiasm from the community.
>
> I know that many folks are using these packages (including myself), but we
> need to hear feedback when we call votes. It is not enough to stand by
> silently if everything works; please let us know about it.
>
> As it stands, the enthusiasm (or lack thereof) for binary packages doesn't
> justify the overhead involved in releasing them. Therefore I propose that
> we drop official binary packages for the next release. This is up for
> discussion and I'd love to hear everyone's opinion on this.
>
> An alternative to ending binary packages would be to automate the process
> on tar.gz releases, but that would most likely need to be a community
> contribution.
>
> 3. Version 1.0. I realize this is a touchy subject. While other projects
> that were started around the same time as Aurora, such as Mesos itself,
> have gone on to make a 1.0 release (indicating the projects maturity), we
> have stuck to our 0.X.0 releases.
>
> Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
> wanted to bring up for discussion how everyone felt about making our next
> release a 1.0 release to reflect the stability and maturity of the project.
>
> That is all from me, if anyone else has any other concerns regarding the
> Aurora community, feel free to bring it up in this thread!
>
> -Renan
>
>
> [1] https://projects.apache.org/committee.html?aurora
> [2] https://lists.apache.org/thread.html/9df9d142408efffd11a1cdc5e4c1e3
> 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org%3E