Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
On 27.05.20 01:10, Julien Pivotto wrote: > On 27 May 00:54, Bjoern Rabenstein wrote: > > > > Thus, if we wanted to introduce rough consensus in our governance, we > > would have to use it instead of the majority vote, not the lazy > > consensus. Replacing the lazy consensus with rough consensus would > > actually be against the spirit of RFC7282 because RFC7282 still > > prefers a "smooth"/"good" consensus over a rough consensus, but > > Richi's proposed change explicitly states that rough consensus is the > > "default decision making mechanism". > > I think that the proposal is more to default to "rfc7282" not "rough > consensus". Yes, that would make sense, but it's different from what's written in Richi's commit. And it would still mean that votes about technical decisions wouldn't happen anymore (so that that part of the governance needed to be deleted, or in other words: still a way more invasive change than suggested in the commit). > Quoting: > > Although most of the examples in this document talk about working group > chairs, these principles apply to any person who is trying to lead a > group to rough consensus, whether a chair, a design team leader, a > document editor, an area director, or any community member who is > facilitating a discussion or trying to assess consensus. > > I think that could then e.g. fallback to MAINTAINERS.md. One could indeed see Prometheus repos as the equivalent of work groups and their maintainers as the chairs. However, several concerns: - (minor) In case of multiple maintainers, we needed to pick the "real" chair. - (a bit more relevant) The whole prometheus-team is smaller than one work group of the IETF. Do we really want to create the fine-granular hierarchy of an organization with thousands of participants for the 20 people in prometheus-team? (counterpoint: discussions involve more than just prometheus-team, so we arguably have hundreds of potential participants) - (actually very relevant) Most of the controversial choking points in PRs were happening because at least one side of the controversy believed that the change has relevance for the whole project. In which case we are back to square one: Who is actually the person authorized to call the rough consensus? Similarly, we would still not have a chair for all the decisions that are naturally not bound to a particular repository. > Yes that joins what I said just before. However it might be difficult > to give one person so much "power". At least the "parliament" (i.e. prometheus-team) could just elect another chair if the current one goes wild. > I think that we miss a way to achieve consensus _within the scope of a > PR/issue_. See the third of my concerns above. IIRC in the rare cases that the decision of a maintainer of a repo was challenged, one of the justifications was that the implications of the PR/issue in question was believed to reach beyond just that repo. -- Björn Rabenstein [PGP-ID] 0x851C3DA17D748D03 [email] bjo...@rabenste.in -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200526235134.GV2326%40jahnn.
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
On 27 May 00:54, Bjoern Rabenstein wrote: > tl;dr: Oh my... > > I think we have an interesting discussion here, and a lot of valid and > good points were brought up. > > However, I have a concern with Richi's suggestions on a much more > fundamental level. > > I (re-)read https://tools.ietf.org/html/rfc7282 very carefully, and > it's indeed a very insightful document. (If you haven't read it > already, I strongly recommend to do so.) > > I do not see any substantial contradiction between CouchDB-style lazy > consensus and RFC7282, though. Please note that lazy consensus > describes the "happy path", pretty much what RFC7282 sees as the > prefered variety of consensus. Rough consensus, however, kicks in if > no "regular" consensus can be reached. It is dealing with a case where > lazy consensus has already disappeared. In all its essence, it's a > _replacement_ for voting. > > Thus, if we wanted to introduce rough consensus in our governance, we > would have to use it instead of the majority vote, not the lazy > consensus. Replacing the lazy consensus with rough consensus would > actually be against the spirit of RFC7282 because RFC7282 still > prefers a "smooth"/"good" consensus over a rough consensus, but > Richi's proposed change explicitly states that rough consensus is the > "default decision making mechanism". I think that the proposal is more to default to "rfc7282" not "rough consensus". > To analyze the premise of RFC7282 a bit more: > > Two relevant properties of the IETF are: > > 1. They do not vote. (They don't want to, but they also cannot.) > 2. They have chairs. > > Obviously, RFC7282 expresses a lot of reasons why votes are > problematic in general, but it also states that the IETF doesn't even > have the formal requirements for votes as their is no definition of > voting right. > > For Prometheus, the situation is pretty much the oppsite: > > 1. We do vote. (We don't want to, but we can if need be.) > 2. We have no chairs. Quoting: Although most of the examples in this document talk about working group chairs, these principles apply to any person who is trying to lead a group to rough consensus, whether a chair, a design team leader, a document editor, an area director, or any community member who is facilitating a discussion or trying to assess consensus. I think that could then e.g. fallback to MAINTAINERS.md. > I want to emphasize that we do not _like_ votes. They are a last > resort. That's clearly stated in the governance. We probably all agree > with the problems of voting described in RFC7282, but as long as votes > don't happen often, those problems are not very relevant. As also > stated in RFC7282, the IETF has to revert to rough consensus quite > often. If we had to revert to votes very often, I'd agree that we have > a problem. The IETF has work groups with hundreds of people (and many > work groups), while the whole Prometheus team consists of 20 > people. The much larger organization size makes it more likely that no > "smooth" consensus can be found. On the other hand, the larger size > goes along with some hierarchical structures, so there are work groups > with chairs, and the existence of chairs enables rough consensus. With > voting as the last resort, they would devolve into constant votes with > all its problems. So rough consensus is the better way out for them. It is not easy to call a vote. When lazy consensus does not work and we speak about niche feature or single line changes, it is embarrassing to go in public and call a vote for "just" that. > I have to disagree with Richi that rough consensus would work without > chairs. On the contrary, I believe that qualified chairs are the most > critical part of making rough consensus work. (As said by others in > the thread already: Who would otherwise make the binding call when the > rough consensus is reached.) See my previous comment about MAINTAINERS.md. > Or in other words: Rough consensus would solve a problem that we don't > have with means that we don't have, either. > > Having said all that, the mail thread so far shows that there is a > fair amount of dissatisfaction with our decision-making performance so > far. In general, I believe we need to understand and discuss the the > underlying problems better to find a good solution for it. However, > here is my speculation why rough consensus appears appealing to some > of us: Precisely because we all know and feel that frequent voting > would be a problem, we avoid votes, and because we do that, we > compromise on the quality of our consensus, e.g. we shy away from > decisions where a consensus seems hard to find, or some of us > "capitulate" (as fittingly described in RFC7282), or the notion of > "veto power" spreads, and probably more... If that's true, the > problems of voting would indirectly have an effect even if actual > votes are rare. In that case, rough consensus might be a solution, but > note what I pointed out above: It would
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
tl;dr: Oh my... I think we have an interesting discussion here, and a lot of valid and good points were brought up. However, I have a concern with Richi's suggestions on a much more fundamental level. I (re-)read https://tools.ietf.org/html/rfc7282 very carefully, and it's indeed a very insightful document. (If you haven't read it already, I strongly recommend to do so.) I do not see any substantial contradiction between CouchDB-style lazy consensus and RFC7282, though. Please note that lazy consensus describes the "happy path", pretty much what RFC7282 sees as the prefered variety of consensus. Rough consensus, however, kicks in if no "regular" consensus can be reached. It is dealing with a case where lazy consensus has already disappeared. In all its essence, it's a _replacement_ for voting. Thus, if we wanted to introduce rough consensus in our governance, we would have to use it instead of the majority vote, not the lazy consensus. Replacing the lazy consensus with rough consensus would actually be against the spirit of RFC7282 because RFC7282 still prefers a "smooth"/"good" consensus over a rough consensus, but Richi's proposed change explicitly states that rough consensus is the "default decision making mechanism". To analyze the premise of RFC7282 a bit more: Two relevant properties of the IETF are: 1. They do not vote. (They don't want to, but they also cannot.) 2. They have chairs. Obviously, RFC7282 expresses a lot of reasons why votes are problematic in general, but it also states that the IETF doesn't even have the formal requirements for votes as their is no definition of voting right. For Prometheus, the situation is pretty much the oppsite: 1. We do vote. (We don't want to, but we can if need be.) 2. We have no chairs. I want to emphasize that we do not _like_ votes. They are a last resort. That's clearly stated in the governance. We probably all agree with the problems of voting described in RFC7282, but as long as votes don't happen often, those problems are not very relevant. As also stated in RFC7282, the IETF has to revert to rough consensus quite often. If we had to revert to votes very often, I'd agree that we have a problem. The IETF has work groups with hundreds of people (and many work groups), while the whole Prometheus team consists of 20 people. The much larger organization size makes it more likely that no "smooth" consensus can be found. On the other hand, the larger size goes along with some hierarchical structures, so there are work groups with chairs, and the existence of chairs enables rough consensus. With voting as the last resort, they would devolve into constant votes with all its problems. So rough consensus is the better way out for them. I have to disagree with Richi that rough consensus would work without chairs. On the contrary, I believe that qualified chairs are the most critical part of making rough consensus work. (As said by others in the thread already: Who would otherwise make the binding call when the rough consensus is reached.) Or in other words: Rough consensus would solve a problem that we don't have with means that we don't have, either. Having said all that, the mail thread so far shows that there is a fair amount of dissatisfaction with our decision-making performance so far. In general, I believe we need to understand and discuss the the underlying problems better to find a good solution for it. However, here is my speculation why rough consensus appears appealing to some of us: Precisely because we all know and feel that frequent voting would be a problem, we avoid votes, and because we do that, we compromise on the quality of our consensus, e.g. we shy away from decisions where a consensus seems hard to find, or some of us "capitulate" (as fittingly described in RFC7282), or the notion of "veto power" spreads, and probably more... If that's true, the problems of voting would indirectly have an effect even if actual votes are rare. In that case, rough consensus might be a solution, but note what I pointed out above: It would replace the voting, not the lazy consensus part AKA we would still first try to find a "smooth" consenus before we go "rough". And yes, it would require chairs. In case of the small size of the Prometheus team, one chair would probably be enough. Prometheus-team would then be the voting body to elect the chair. But here is the point where I stop my speculation. Summary of my points (all meant as IMHO, even if stated as facts here): - The changes as suggested in https://github.com/prometheus/docs/commit/f7ee6ac5a9b841be6be25d92e2c403de15949491 are _not_ following the spirit of RFC7282. - To truly adopt rough consensus, we need to introduce a chair and get rid of decision finding by voting (with change of governance, admitting and removing team members, and electing the chair as notable exceptions). But that would be a very invasive change of the governance. - Before we do that, I would prefer to
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
On 26 May 21:16, Bartłomiej Płotka wrote: > Hi > > On a separate note, while I believe in maintaining high project quality for > everything we ship, I think we should be way more open into the > experimenting bit more in Prometheus. Having some experimental features > under a flag is something that gives quicker feedback if the API, feature, > or given logic makes sense for a wider user base. For majority of cases we > always reject those because "it's support burden", "this does not help much > for Prometheus only Cortex/Thanos/XYZ", "this overlap with older, less > efficient API", "we don't like those extra dependencies (e.g gRPC)", > "people will not use it". This might be off-topic here, but I feel like > this is another thing which could improve the velocity of Prometheus and > usability of the project itself (: I agree with that statement. I think that we could and should not have taboos; we should be able to rethink some decisions and not be afraid to accept more new features. Maybe we should also be less concerned about pointing our users in the "correct" direction and let them do more with their data. > > Kind Regards, > Bartek > > On Mon, 25 May 2020 at 20:53, Julien Pivotto > wrote: > > > On 25 May 19:41, Richard Hartmann wrote: > > > On Mon, May 25, 2020 at 7:08 PM Julius Volz > > wrote: > > > > > > > I would also want to understand a bit more specifically how this would > > work in practice though. E.g. when there are three people arguing one way > > on an issue, and one person against, and all views have been considered and > > arguments are turning in circles, can the majority (with respect to that > > discussion) just go ahead and decide / merge things? I guess in the worst > > case, when someone feels unheard, they can still call for a team-wide vote, > > but the cost of calling for that vote would then be carried by the > > minority, not the majority? So things would be more biased towards action. > > > > > > That's one possible mode of operation, yes. > > > > > > Hopefully, there would be fewer lockups by shifting from default-deny > > > to default-majority-ish. > > > > > > If it does not work out to our shared satisfaction, we can always > > > refine the governance further, e.g. introduce a Chair system though, > > > again, I would like to avoid that. > > > > > > > > > Best, > > > Richard > > > > I would vote :+1: on changing to rough consensus. > > > > -- > > Julien Pivotto > > @roidelapluie > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Prometheus Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to prometheus-developers+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/prometheus-developers/20200525195320.GA983523%40oxygen > > . > > > > -- > You received this message because you are subscribed to the Google Groups > "Prometheus Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to prometheus-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/CAMssQwZ3apTKpmUGuTJRs0ipDF7TQcypPOiXh_uX9%2B%3D2zVrFqg%40mail.gmail.com. -- Julien Pivotto @roidelapluie -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200526202441.GB1213027%40oxygen.
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
On 26 May 22:55, Julius Volz wrote: > On Tue, May 26, 2020 at 10:17 PM Bartłomiej Płotka > wrote: > > > Hi > > > > I support 100% of what Julius said: > > > > *> In general, +10 for a change in this direction, since currently, the > > balance is too much in favor of inaction - it's really easy to veto > > something, but really hard to unblock it because team-wide votes are > > high-overhead.* > > *> I would also want to understand a bit more specifically how this would > > work in practice though. * > > > > +1 on moving to a rough consensus as I think it's stepping into a good > > direction. > > > > Overall, I feel that our team is not a children's playground, we are team > > of professionals. This means that we trust each other, so no one in > > Prometheus will decide something totally against someone else's strong > > opposite vote. > > > > If we don't want to go totally against someone's strong opposing vote, then > I think we could just leave the governance as it is. I thought the point > was to make it possible to go against someone's strong opposing vote, just > as long as it's considered. And if they are still against something, they > can still call for a vote, but now that burden would be on the minority > blocker party. Yes that is what I think too. Note that rough consensus means that sometimes the minority wins too. > > > > On a separate note, while I believe in maintaining high project quality > > for everything we ship, I think we should be way more open into the > > experimenting bit more in Prometheus. Having some experimental features > > under a flag is something that gives quicker feedback if the API, feature, > > or given logic makes sense for a wider user base. For majority of cases we > > always reject those because "it's support burden", "this does not help much > > for Prometheus only Cortex/Thanos/XYZ", "this overlap with older, less > > efficient API", "we don't like those extra dependencies (e.g gRPC)", > > "people will not use it". This might be off-topic here, but I feel like > > this is another thing which could improve the velocity of Prometheus and > > usability of the project itself (: > > > > Kind Regards, > > Bartek > > > > On Mon, 25 May 2020 at 20:53, Julien Pivotto > > wrote: > > > >> On 25 May 19:41, Richard Hartmann wrote: > >> > On Mon, May 25, 2020 at 7:08 PM Julius Volz > >> wrote: > >> > > >> > > I would also want to understand a bit more specifically how this > >> would work in practice though. E.g. when there are three people arguing one > >> way on an issue, and one person against, and all views have been considered > >> and arguments are turning in circles, can the majority (with respect to > >> that discussion) just go ahead and decide / merge things? I guess in the > >> worst case, when someone feels unheard, they can still call for a team-wide > >> vote, but the cost of calling for that vote would then be carried by the > >> minority, not the majority? So things would be more biased towards action. > >> > > >> > That's one possible mode of operation, yes. > >> > > >> > Hopefully, there would be fewer lockups by shifting from default-deny > >> > to default-majority-ish. > >> > > >> > If it does not work out to our shared satisfaction, we can always > >> > refine the governance further, e.g. introduce a Chair system though, > >> > again, I would like to avoid that. > >> > > >> > > >> > Best, > >> > Richard > >> > >> I would vote :+1: on changing to rough consensus. > >> > >> -- > >> Julien Pivotto > >> @roidelapluie > >> > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Prometheus Developers" group. > >> To unsubscribe from this group and stop receiving emails from it, send an > >> email to prometheus-developers+unsubscr...@googlegroups.com. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msgid/prometheus-developers/20200525195320.GA983523%40oxygen > >> . > >> > > > > -- > You received this message because you are subscribed to the Google Groups > "Prometheus Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to prometheus-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoxDKMgf%2BEmyWG3%3D1KMW_Z99-Ky8kmFo12VgmejKRS%2Bk4w%40mail.gmail.com. -- Julien Pivotto @roidelapluie -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200526205710.GA1264710%40oxygen.
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
On 26 May 22:31, Brian Brazil wrote: > On Tue, 26 May 2020 at 22:08, Julius Volz wrote: > > > On Tue, May 26, 2020 at 10:57 PM Julien Pivotto < > > roidelapl...@prometheus.io> wrote: > > > >> On 26 May 22:55, Julius Volz wrote: > >> > On Tue, May 26, 2020 at 10:17 PM Bartłomiej Płotka > >> > wrote: > >> > > >> > > Hi > >> > > > >> > > I support 100% of what Julius said: > >> > > > >> > > *> In general, +10 for a change in this direction, since currently, > >> the > >> > > balance is too much in favor of inaction - it's really easy to veto > >> > > something, but really hard to unblock it because team-wide votes are > >> > > high-overhead.* > >> > > *> I would also want to understand a bit more specifically how this > >> would > >> > > work in practice though. * > >> > > > >> > > +1 on moving to a rough consensus as I think it's stepping into a good > >> > > direction. > >> > > > >> > > Overall, I feel that our team is not a children's playground, we are > >> team > >> > > of professionals. This means that we trust each other, so no one in > >> > > Prometheus will decide something totally against someone else's strong > >> > > opposite vote. > >> > > > >> > > >> > If we don't want to go totally against someone's strong opposing vote, > >> then > >> > I think we could just leave the governance as it is. I thought the point > >> > was to make it possible to go against someone's strong opposing vote, > >> just > >> > as long as it's considered. And if they are still against something, > >> they > >> > can still call for a vote, but now that burden would be on the minority > >> > blocker party. > >> > >> > >> Yes that is what I think too. Note that rough consensus means that > >> sometimes the minority wins too. > >> > > > > Even if there's already an outspoken (relative) majority against that > > minority? How would that be rough consensus then? > > > > The doc Richi linked covers it in some depth. Rough concensus can cover > both a minority "winning" over a majority, and a majority being in favour > not being sufficient for rough concensus. It's all about if objections are > sufficiently considered. > The doc is more aspirational/philosophical rather than a formal policy, so > I think it doesn't work as a governance in those terms as it's kinda vague. I have to say that it will be fun to address 'the PromQL evaluation model doesn't allow looking into the future.' kind of arguments. Unless it falls under the "unappealing" kind of concerns and can be dismissed by a real "rough" consensus call: Conversely, the working group might convince the objector that the concerns can be addressed, or that the choice is simply unappealing (i.e., something the objector can "live with") and not a show-stopper. > > Brian > > > > > > > >> > > >> > > >> > > On a separate note, while I believe in maintaining high project > >> quality > >> > > for everything we ship, I think we should be way more open into the > >> > > experimenting bit more in Prometheus. Having some experimental > >> features > >> > > under a flag is something that gives quicker feedback if the API, > >> feature, > >> > > or given logic makes sense for a wider user base. For majority of > >> cases we > >> > > always reject those because "it's support burden", "this does not > >> help much > >> > > for Prometheus only Cortex/Thanos/XYZ", "this overlap with older, less > >> > > efficient API", "we don't like those extra dependencies (e.g gRPC)", > >> > > "people will not use it". This might be off-topic here, but I feel > >> like > >> > > this is another thing which could improve the velocity of Prometheus > >> and > >> > > usability of the project itself (: > >> > > > >> > > Kind Regards, > >> > > Bartek > >> > > > >> > > On Mon, 25 May 2020 at 20:53, Julien Pivotto < > >> roidelapl...@prometheus.io> > >> > > wrote: > >> > > > >> > >> On 25 May 19:41, Richard Hartmann wrote: > >> > >> > On Mon, May 25, 2020 at 7:08 PM Julius Volz >> > > >> > >> wrote: > >> > >> > > >> > >> > > I would also want to understand a bit more specifically how this > >> > >> would work in practice though. E.g. when there are three people > >> arguing one > >> > >> way on an issue, and one person against, and all views have been > >> considered > >> > >> and arguments are turning in circles, can the majority (with respect > >> to > >> > >> that discussion) just go ahead and decide / merge things? I guess in > >> the > >> > >> worst case, when someone feels unheard, they can still call for a > >> team-wide > >> > >> vote, but the cost of calling for that vote would then be carried by > >> the > >> > >> minority, not the majority? So things would be more biased towards > >> action. > >> > >> > > >> > >> > That's one possible mode of operation, yes. > >> > >> > > >> > >> > Hopefully, there would be fewer lockups by shifting from > >> default-deny > >> > >> > to default-majority-ish. > >> > >> > > >> > >> > If it does not work out to our shared satisfaction, we can always >
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
On Tue, 26 May 2020 at 22:08, Julius Volz wrote: > On Tue, May 26, 2020 at 10:57 PM Julien Pivotto < > roidelapl...@prometheus.io> wrote: > >> On 26 May 22:55, Julius Volz wrote: >> > On Tue, May 26, 2020 at 10:17 PM Bartłomiej Płotka >> > wrote: >> > >> > > Hi >> > > >> > > I support 100% of what Julius said: >> > > >> > > *> In general, +10 for a change in this direction, since currently, >> the >> > > balance is too much in favor of inaction - it's really easy to veto >> > > something, but really hard to unblock it because team-wide votes are >> > > high-overhead.* >> > > *> I would also want to understand a bit more specifically how this >> would >> > > work in practice though. * >> > > >> > > +1 on moving to a rough consensus as I think it's stepping into a good >> > > direction. >> > > >> > > Overall, I feel that our team is not a children's playground, we are >> team >> > > of professionals. This means that we trust each other, so no one in >> > > Prometheus will decide something totally against someone else's strong >> > > opposite vote. >> > > >> > >> > If we don't want to go totally against someone's strong opposing vote, >> then >> > I think we could just leave the governance as it is. I thought the point >> > was to make it possible to go against someone's strong opposing vote, >> just >> > as long as it's considered. And if they are still against something, >> they >> > can still call for a vote, but now that burden would be on the minority >> > blocker party. >> >> >> Yes that is what I think too. Note that rough consensus means that >> sometimes the minority wins too. >> > > Even if there's already an outspoken (relative) majority against that > minority? How would that be rough consensus then? > The doc Richi linked covers it in some depth. Rough concensus can cover both a minority "winning" over a majority, and a majority being in favour not being sufficient for rough concensus. It's all about if objections are sufficiently considered. The doc is more aspirational/philosophical rather than a formal policy, so I think it doesn't work as a governance in those terms as it's kinda vague. Brian > > >> > >> > >> > > On a separate note, while I believe in maintaining high project >> quality >> > > for everything we ship, I think we should be way more open into the >> > > experimenting bit more in Prometheus. Having some experimental >> features >> > > under a flag is something that gives quicker feedback if the API, >> feature, >> > > or given logic makes sense for a wider user base. For majority of >> cases we >> > > always reject those because "it's support burden", "this does not >> help much >> > > for Prometheus only Cortex/Thanos/XYZ", "this overlap with older, less >> > > efficient API", "we don't like those extra dependencies (e.g gRPC)", >> > > "people will not use it". This might be off-topic here, but I feel >> like >> > > this is another thing which could improve the velocity of Prometheus >> and >> > > usability of the project itself (: >> > > >> > > Kind Regards, >> > > Bartek >> > > >> > > On Mon, 25 May 2020 at 20:53, Julien Pivotto < >> roidelapl...@prometheus.io> >> > > wrote: >> > > >> > >> On 25 May 19:41, Richard Hartmann wrote: >> > >> > On Mon, May 25, 2020 at 7:08 PM Julius Volz > > >> > >> wrote: >> > >> > >> > >> > > I would also want to understand a bit more specifically how this >> > >> would work in practice though. E.g. when there are three people >> arguing one >> > >> way on an issue, and one person against, and all views have been >> considered >> > >> and arguments are turning in circles, can the majority (with respect >> to >> > >> that discussion) just go ahead and decide / merge things? I guess in >> the >> > >> worst case, when someone feels unheard, they can still call for a >> team-wide >> > >> vote, but the cost of calling for that vote would then be carried by >> the >> > >> minority, not the majority? So things would be more biased towards >> action. >> > >> > >> > >> > That's one possible mode of operation, yes. >> > >> > >> > >> > Hopefully, there would be fewer lockups by shifting from >> default-deny >> > >> > to default-majority-ish. >> > >> > >> > >> > If it does not work out to our shared satisfaction, we can always >> > >> > refine the governance further, e.g. introduce a Chair system >> though, >> > >> > again, I would like to avoid that. >> > >> > >> > >> > >> > >> > Best, >> > >> > Richard >> > >> >> > >> I would vote :+1: on changing to rough consensus. >> > >> >> > >> -- >> > >> Julien Pivotto >> > >> @roidelapluie >> > >> >> > >> -- >> > >> You received this message because you are subscribed to the Google >> Groups >> > >> "Prometheus Developers" group. >> > >> To unsubscribe from this group and stop receiving emails from it, >> send an >> > >> email to prometheus-developers+unsubscr...@googlegroups.com. >> > >> To view this discussion on the web visit >> > >> >>
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
On Tue, May 26, 2020 at 11:22 PM Bartłomiej Płotka wrote: > > >> >> Overall, I feel that our team is not a children's playground, we are team >> of professionals. This means that we trust each other, so no one in >> Prometheus will decide something totally against someone else's strong >> opposite vote. >> > > > If we don't want to go totally against someone's strong opposing vote, > then I think we could just leave the governance as it is. I thought the > point was to make it possible to go against someone's strong opposing vote, > just as long as it's considered. And if they are still against something, > they can still call for a vote, but now that burden would be on the > minority blocker party. > > I think I was misunderstood. It's opposite:* It is exactly to make it > possible to go against someone's strong opposite vote.* But it does not > mean that if anyone disagrees we immediately ignore one person's opinion. > It's more *about stronger motivation to find consensus *between everyone > as there is an open, legal path for the project to move forward despite one > person being strongly opposed. > Yep, agreed. > Let's think about this in the opposite way: If we *trust* each other, why > having a rough consensus would be a problem? We will definitely try to > address our concerns and items asked by the opposed party, right? *It's > the same with open source*. Our license (Apache 2) allows almost > anything. Free distribution, modification, forking etc. This ensures that > there is always an open path if there will be a major blocker or conflict > etc. It does not mean that forks are often. > > Kind Regards, > Bartek > > > On Tue, 26 May 2020 at 22:08, Julius Volz wrote: > >> On Tue, May 26, 2020 at 10:57 PM Julien Pivotto < >> roidelapl...@prometheus.io> wrote: >> >>> On 26 May 22:55, Julius Volz wrote: >>> > On Tue, May 26, 2020 at 10:17 PM Bartłomiej Płotka >> > >>> > wrote: >>> > >>> > > Hi >>> > > >>> > > I support 100% of what Julius said: >>> > > >>> > > *> In general, +10 for a change in this direction, since currently, >>> the >>> > > balance is too much in favor of inaction - it's really easy to veto >>> > > something, but really hard to unblock it because team-wide votes are >>> > > high-overhead.* >>> > > *> I would also want to understand a bit more specifically how this >>> would >>> > > work in practice though. * >>> > > >>> > > +1 on moving to a rough consensus as I think it's stepping into a >>> good >>> > > direction. >>> > > >>> > > Overall, I feel that our team is not a children's playground, we are >>> team >>> > > of professionals. This means that we trust each other, so no one in >>> > > Prometheus will decide something totally against someone else's >>> strong >>> > > opposite vote. >>> > > >>> > >>> > If we don't want to go totally against someone's strong opposing vote, >>> then >>> > I think we could just leave the governance as it is. I thought the >>> point >>> > was to make it possible to go against someone's strong opposing vote, >>> just >>> > as long as it's considered. And if they are still against something, >>> they >>> > can still call for a vote, but now that burden would be on the minority >>> > blocker party. >>> >>> >>> Yes that is what I think too. Note that rough consensus means that >>> sometimes the minority wins too. >>> >> >> Even if there's already an outspoken (relative) majority against that >> minority? How would that be rough consensus then? >> >> >>> > >>> > >>> > > On a separate note, while I believe in maintaining high project >>> quality >>> > > for everything we ship, I think we should be way more open into the >>> > > experimenting bit more in Prometheus. Having some experimental >>> features >>> > > under a flag is something that gives quicker feedback if the API, >>> feature, >>> > > or given logic makes sense for a wider user base. For majority of >>> cases we >>> > > always reject those because "it's support burden", "this does not >>> help much >>> > > for Prometheus only Cortex/Thanos/XYZ", "this overlap with older, >>> less >>> > > efficient API", "we don't like those extra dependencies (e.g gRPC)", >>> > > "people will not use it". This might be off-topic here, but I feel >>> like >>> > > this is another thing which could improve the velocity of Prometheus >>> and >>> > > usability of the project itself (: >>> > > >>> > > Kind Regards, >>> > > Bartek >>> > > >>> > > On Mon, 25 May 2020 at 20:53, Julien Pivotto < >>> roidelapl...@prometheus.io> >>> > > wrote: >>> > > >>> > >> On 25 May 19:41, Richard Hartmann wrote: >>> > >> > On Mon, May 25, 2020 at 7:08 PM Julius Volz < >>> julius.v...@gmail.com> >>> > >> wrote: >>> > >> > >>> > >> > > I would also want to understand a bit more specifically how this >>> > >> would work in practice though. E.g. when there are three people >>> arguing one >>> > >> way on an issue, and one person against, and all views have been >>> considered >>> > >> and arguments are turning in circles, can the
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
On 26 May 23:08, Julius Volz wrote: > On Tue, May 26, 2020 at 10:57 PM Julien Pivotto > wrote: > > > On 26 May 22:55, Julius Volz wrote: > > > On Tue, May 26, 2020 at 10:17 PM Bartłomiej Płotka > > > wrote: > > > > > > > Hi > > > > > > > > I support 100% of what Julius said: > > > > > > > > *> In general, +10 for a change in this direction, since currently, > > the > > > > balance is too much in favor of inaction - it's really easy to veto > > > > something, but really hard to unblock it because team-wide votes are > > > > high-overhead.* > > > > *> I would also want to understand a bit more specifically how this > > would > > > > work in practice though. * > > > > > > > > +1 on moving to a rough consensus as I think it's stepping into a good > > > > direction. > > > > > > > > Overall, I feel that our team is not a children's playground, we are > > team > > > > of professionals. This means that we trust each other, so no one in > > > > Prometheus will decide something totally against someone else's strong > > > > opposite vote. > > > > > > > > > > If we don't want to go totally against someone's strong opposing vote, > > then > > > I think we could just leave the governance as it is. I thought the point > > > was to make it possible to go against someone's strong opposing vote, > > just > > > as long as it's considered. And if they are still against something, they > > > can still call for a vote, but now that burden would be on the minority > > > blocker party. > > > > > > Yes that is what I think too. Note that rough consensus means that > > sometimes the minority wins too. > > > > Even if there's already an outspoken (relative) majority against that > minority? How would that be rough consensus then? Rough consensus is NOT about being PRO's or CON's. It is about raisin issues that must be considered. Ideally we reach an agreement of everyone. That should be the majority. But if someone says no, we must take their arguments into consideration and resolve the issue. When it is addressed/considered, either everyone agrees or the chair can then call a 'rough' consensus. 7. Five people for and one hundred people against might still be rough consensus https://tools.ietf.org/html/rfc7282 > > > > > > > > > > > > On a separate note, while I believe in maintaining high project quality > > > > for everything we ship, I think we should be way more open into the > > > > experimenting bit more in Prometheus. Having some experimental features > > > > under a flag is something that gives quicker feedback if the API, > > feature, > > > > or given logic makes sense for a wider user base. For majority of > > cases we > > > > always reject those because "it's support burden", "this does not help > > much > > > > for Prometheus only Cortex/Thanos/XYZ", "this overlap with older, less > > > > efficient API", "we don't like those extra dependencies (e.g gRPC)", > > > > "people will not use it". This might be off-topic here, but I feel like > > > > this is another thing which could improve the velocity of Prometheus > > and > > > > usability of the project itself (: > > > > > > > > Kind Regards, > > > > Bartek > > > > > > > > On Mon, 25 May 2020 at 20:53, Julien Pivotto < > > roidelapl...@prometheus.io> > > > > wrote: > > > > > > > >> On 25 May 19:41, Richard Hartmann wrote: > > > >> > On Mon, May 25, 2020 at 7:08 PM Julius Volz > > > >> wrote: > > > >> > > > > >> > > I would also want to understand a bit more specifically how this > > > >> would work in practice though. E.g. when there are three people > > arguing one > > > >> way on an issue, and one person against, and all views have been > > considered > > > >> and arguments are turning in circles, can the majority (with respect > > to > > > >> that discussion) just go ahead and decide / merge things? I guess in > > the > > > >> worst case, when someone feels unheard, they can still call for a > > team-wide > > > >> vote, but the cost of calling for that vote would then be carried by > > the > > > >> minority, not the majority? So things would be more biased towards > > action. > > > >> > > > > >> > That's one possible mode of operation, yes. > > > >> > > > > >> > Hopefully, there would be fewer lockups by shifting from > > default-deny > > > >> > to default-majority-ish. > > > >> > > > > >> > If it does not work out to our shared satisfaction, we can always > > > >> > refine the governance further, e.g. introduce a Chair system though, > > > >> > again, I would like to avoid that. > > > >> > > > > >> > > > > >> > Best, > > > >> > Richard > > > >> > > > >> I would vote :+1: on changing to rough consensus. > > > >> > > > >> -- > > > >> Julien Pivotto > > > >> @roidelapluie > > > >> > > > >> -- > > > >> You received this message because you are subscribed to the Google > > Groups > > > >> "Prometheus Developers" group. > > > >> To unsubscribe from this group and stop receiving emails from it, > > send an > > > >> email to
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
> > > Overall, I feel that our team is not a children's playground, we are team > of professionals. This means that we trust each other, so no one in > Prometheus will decide something totally against someone else's strong > opposite vote. > > If we don't want to go totally against someone's strong opposing vote, then I think we could just leave the governance as it is. I thought the point was to make it possible to go against someone's strong opposing vote, just as long as it's considered. And if they are still against something, they can still call for a vote, but now that burden would be on the minority blocker party. I think I was misunderstood. It's opposite:* It is exactly to make it possible to go against someone's strong opposite vote.* But it does not mean that if anyone disagrees we immediately ignore one person's opinion. It's more *about stronger motivation to find consensus *between everyone as there is an open, legal path for the project to move forward despite one person being strongly opposed. Let's think about this in the opposite way: If we *trust* each other, why having a rough consensus would be a problem? We will definitely try to address our concerns and items asked by the opposed party, right? *It's the same with open source*. Our license (Apache 2) allows almost anything. Free distribution, modification, forking etc. This ensures that there is always an open path if there will be a major blocker or conflict etc. It does not mean that forks are often. Kind Regards, Bartek On Tue, 26 May 2020 at 22:08, Julius Volz wrote: > On Tue, May 26, 2020 at 10:57 PM Julien Pivotto < > roidelapl...@prometheus.io> wrote: > >> On 26 May 22:55, Julius Volz wrote: >> > On Tue, May 26, 2020 at 10:17 PM Bartłomiej Płotka >> > wrote: >> > >> > > Hi >> > > >> > > I support 100% of what Julius said: >> > > >> > > *> In general, +10 for a change in this direction, since currently, >> the >> > > balance is too much in favor of inaction - it's really easy to veto >> > > something, but really hard to unblock it because team-wide votes are >> > > high-overhead.* >> > > *> I would also want to understand a bit more specifically how this >> would >> > > work in practice though. * >> > > >> > > +1 on moving to a rough consensus as I think it's stepping into a good >> > > direction. >> > > >> > > Overall, I feel that our team is not a children's playground, we are >> team >> > > of professionals. This means that we trust each other, so no one in >> > > Prometheus will decide something totally against someone else's strong >> > > opposite vote. >> > > >> > >> > If we don't want to go totally against someone's strong opposing vote, >> then >> > I think we could just leave the governance as it is. I thought the point >> > was to make it possible to go against someone's strong opposing vote, >> just >> > as long as it's considered. And if they are still against something, >> they >> > can still call for a vote, but now that burden would be on the minority >> > blocker party. >> >> >> Yes that is what I think too. Note that rough consensus means that >> sometimes the minority wins too. >> > > Even if there's already an outspoken (relative) majority against that > minority? How would that be rough consensus then? > > >> > >> > >> > > On a separate note, while I believe in maintaining high project >> quality >> > > for everything we ship, I think we should be way more open into the >> > > experimenting bit more in Prometheus. Having some experimental >> features >> > > under a flag is something that gives quicker feedback if the API, >> feature, >> > > or given logic makes sense for a wider user base. For majority of >> cases we >> > > always reject those because "it's support burden", "this does not >> help much >> > > for Prometheus only Cortex/Thanos/XYZ", "this overlap with older, less >> > > efficient API", "we don't like those extra dependencies (e.g gRPC)", >> > > "people will not use it". This might be off-topic here, but I feel >> like >> > > this is another thing which could improve the velocity of Prometheus >> and >> > > usability of the project itself (: >> > > >> > > Kind Regards, >> > > Bartek >> > > >> > > On Mon, 25 May 2020 at 20:53, Julien Pivotto < >> roidelapl...@prometheus.io> >> > > wrote: >> > > >> > >> On 25 May 19:41, Richard Hartmann wrote: >> > >> > On Mon, May 25, 2020 at 7:08 PM Julius Volz > > >> > >> wrote: >> > >> > >> > >> > > I would also want to understand a bit more specifically how this >> > >> would work in practice though. E.g. when there are three people >> arguing one >> > >> way on an issue, and one person against, and all views have been >> considered >> > >> and arguments are turning in circles, can the majority (with respect >> to >> > >> that discussion) just go ahead and decide / merge things? I guess in >> the >> > >> worst case, when someone feels unheard, they can still call for a >> team-wide >> > >> vote, but the cost of calling for that vote would then be
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
On Tue, May 26, 2020 at 10:57 PM Julien Pivotto wrote: > On 26 May 22:55, Julius Volz wrote: > > On Tue, May 26, 2020 at 10:17 PM Bartłomiej Płotka > > wrote: > > > > > Hi > > > > > > I support 100% of what Julius said: > > > > > > *> In general, +10 for a change in this direction, since currently, > the > > > balance is too much in favor of inaction - it's really easy to veto > > > something, but really hard to unblock it because team-wide votes are > > > high-overhead.* > > > *> I would also want to understand a bit more specifically how this > would > > > work in practice though. * > > > > > > +1 on moving to a rough consensus as I think it's stepping into a good > > > direction. > > > > > > Overall, I feel that our team is not a children's playground, we are > team > > > of professionals. This means that we trust each other, so no one in > > > Prometheus will decide something totally against someone else's strong > > > opposite vote. > > > > > > > If we don't want to go totally against someone's strong opposing vote, > then > > I think we could just leave the governance as it is. I thought the point > > was to make it possible to go against someone's strong opposing vote, > just > > as long as it's considered. And if they are still against something, they > > can still call for a vote, but now that burden would be on the minority > > blocker party. > > > Yes that is what I think too. Note that rough consensus means that > sometimes the minority wins too. > Even if there's already an outspoken (relative) majority against that minority? How would that be rough consensus then? > > > > > > > On a separate note, while I believe in maintaining high project quality > > > for everything we ship, I think we should be way more open into the > > > experimenting bit more in Prometheus. Having some experimental features > > > under a flag is something that gives quicker feedback if the API, > feature, > > > or given logic makes sense for a wider user base. For majority of > cases we > > > always reject those because "it's support burden", "this does not help > much > > > for Prometheus only Cortex/Thanos/XYZ", "this overlap with older, less > > > efficient API", "we don't like those extra dependencies (e.g gRPC)", > > > "people will not use it". This might be off-topic here, but I feel like > > > this is another thing which could improve the velocity of Prometheus > and > > > usability of the project itself (: > > > > > > Kind Regards, > > > Bartek > > > > > > On Mon, 25 May 2020 at 20:53, Julien Pivotto < > roidelapl...@prometheus.io> > > > wrote: > > > > > >> On 25 May 19:41, Richard Hartmann wrote: > > >> > On Mon, May 25, 2020 at 7:08 PM Julius Volz > > >> wrote: > > >> > > > >> > > I would also want to understand a bit more specifically how this > > >> would work in practice though. E.g. when there are three people > arguing one > > >> way on an issue, and one person against, and all views have been > considered > > >> and arguments are turning in circles, can the majority (with respect > to > > >> that discussion) just go ahead and decide / merge things? I guess in > the > > >> worst case, when someone feels unheard, they can still call for a > team-wide > > >> vote, but the cost of calling for that vote would then be carried by > the > > >> minority, not the majority? So things would be more biased towards > action. > > >> > > > >> > That's one possible mode of operation, yes. > > >> > > > >> > Hopefully, there would be fewer lockups by shifting from > default-deny > > >> > to default-majority-ish. > > >> > > > >> > If it does not work out to our shared satisfaction, we can always > > >> > refine the governance further, e.g. introduce a Chair system though, > > >> > again, I would like to avoid that. > > >> > > > >> > > > >> > Best, > > >> > Richard > > >> > > >> I would vote :+1: on changing to rough consensus. > > >> > > >> -- > > >> Julien Pivotto > > >> @roidelapluie > > >> > > >> -- > > >> You received this message because you are subscribed to the Google > Groups > > >> "Prometheus Developers" group. > > >> To unsubscribe from this group and stop receiving emails from it, > send an > > >> email to prometheus-developers+unsubscr...@googlegroups.com. > > >> To view this discussion on the web visit > > >> > https://groups.google.com/d/msgid/prometheus-developers/20200525195320.GA983523%40oxygen > > >> . > > >> > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "Prometheus Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to prometheus-developers+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoxDKMgf%2BEmyWG3%3D1KMW_Z99-Ky8kmFo12VgmejKRS%2Bk4w%40mail.gmail.com > . > > -- > Julien Pivotto > @roidelapluie > -- You received this message because you are subscribed to the Google Groups "Prometheus
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
On Tue, May 26, 2020 at 10:17 PM Bartłomiej Płotka wrote: > Hi > > I support 100% of what Julius said: > > *> In general, +10 for a change in this direction, since currently, the > balance is too much in favor of inaction - it's really easy to veto > something, but really hard to unblock it because team-wide votes are > high-overhead.* > *> I would also want to understand a bit more specifically how this would > work in practice though. * > > +1 on moving to a rough consensus as I think it's stepping into a good > direction. > > Overall, I feel that our team is not a children's playground, we are team > of professionals. This means that we trust each other, so no one in > Prometheus will decide something totally against someone else's strong > opposite vote. > If we don't want to go totally against someone's strong opposing vote, then I think we could just leave the governance as it is. I thought the point was to make it possible to go against someone's strong opposing vote, just as long as it's considered. And if they are still against something, they can still call for a vote, but now that burden would be on the minority blocker party. > On a separate note, while I believe in maintaining high project quality > for everything we ship, I think we should be way more open into the > experimenting bit more in Prometheus. Having some experimental features > under a flag is something that gives quicker feedback if the API, feature, > or given logic makes sense for a wider user base. For majority of cases we > always reject those because "it's support burden", "this does not help much > for Prometheus only Cortex/Thanos/XYZ", "this overlap with older, less > efficient API", "we don't like those extra dependencies (e.g gRPC)", > "people will not use it". This might be off-topic here, but I feel like > this is another thing which could improve the velocity of Prometheus and > usability of the project itself (: > > Kind Regards, > Bartek > > On Mon, 25 May 2020 at 20:53, Julien Pivotto > wrote: > >> On 25 May 19:41, Richard Hartmann wrote: >> > On Mon, May 25, 2020 at 7:08 PM Julius Volz >> wrote: >> > >> > > I would also want to understand a bit more specifically how this >> would work in practice though. E.g. when there are three people arguing one >> way on an issue, and one person against, and all views have been considered >> and arguments are turning in circles, can the majority (with respect to >> that discussion) just go ahead and decide / merge things? I guess in the >> worst case, when someone feels unheard, they can still call for a team-wide >> vote, but the cost of calling for that vote would then be carried by the >> minority, not the majority? So things would be more biased towards action. >> > >> > That's one possible mode of operation, yes. >> > >> > Hopefully, there would be fewer lockups by shifting from default-deny >> > to default-majority-ish. >> > >> > If it does not work out to our shared satisfaction, we can always >> > refine the governance further, e.g. introduce a Chair system though, >> > again, I would like to avoid that. >> > >> > >> > Best, >> > Richard >> >> I would vote :+1: on changing to rough consensus. >> >> -- >> Julien Pivotto >> @roidelapluie >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Prometheus Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to prometheus-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/prometheus-developers/20200525195320.GA983523%40oxygen >> . >> > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoxDKMgf%2BEmyWG3%3D1KMW_Z99-Ky8kmFo12VgmejKRS%2Bk4w%40mail.gmail.com.
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
On Tue, May 26, 2020 at 10:24 PM Julien Pivotto wrote: > On 26 May 21:16, Bartłomiej Płotka wrote: > > Hi > > > > On a separate note, while I believe in maintaining high project quality > for > > everything we ship, I think we should be way more open into the > > experimenting bit more in Prometheus. Having some experimental features > > under a flag is something that gives quicker feedback if the API, > feature, > > or given logic makes sense for a wider user base. For majority of cases > we > > always reject those because "it's support burden", "this does not help > much > > for Prometheus only Cortex/Thanos/XYZ", "this overlap with older, less > > efficient API", "we don't like those extra dependencies (e.g gRPC)", > > "people will not use it". This might be off-topic here, but I feel like > > this is another thing which could improve the velocity of Prometheus and > > usability of the project itself (: > > I agree with that statement. I think that we could and should not have > taboos; we should be able to rethink some decisions and not be afraid to > accept more new features. > > Maybe we should also be less concerned about pointing our users in the > "correct" direction and let them do more with their data. > Coming tomorrow to Prometheus: logs, tracing, deep analytics, and push ;) In seriousness though, I agree. Maybe not to go that far, but to be open and evolve a bit with the times. There is certainly value to Prometheus having a core scope and not growing into a solution that tries to be everything for everyone, but I also think we can still do more and still be Prometheus. > > > > Kind Regards, > > Bartek > > > > On Mon, 25 May 2020 at 20:53, Julien Pivotto > > > wrote: > > > > > On 25 May 19:41, Richard Hartmann wrote: > > > > On Mon, May 25, 2020 at 7:08 PM Julius Volz > > > wrote: > > > > > > > > > I would also want to understand a bit more specifically how this > would > > > work in practice though. E.g. when there are three people arguing one > way > > > on an issue, and one person against, and all views have been > considered and > > > arguments are turning in circles, can the majority (with respect to > that > > > discussion) just go ahead and decide / merge things? I guess in the > worst > > > case, when someone feels unheard, they can still call for a team-wide > vote, > > > but the cost of calling for that vote would then be carried by the > > > minority, not the majority? So things would be more biased towards > action. > > > > > > > > That's one possible mode of operation, yes. > > > > > > > > Hopefully, there would be fewer lockups by shifting from default-deny > > > > to default-majority-ish. > > > > > > > > If it does not work out to our shared satisfaction, we can always > > > > refine the governance further, e.g. introduce a Chair system though, > > > > again, I would like to avoid that. > > > > > > > > > > > > Best, > > > > Richard > > > > > > I would vote :+1: on changing to rough consensus. > > > > > > -- > > > Julien Pivotto > > > @roidelapluie > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Prometheus Developers" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an > > > email to prometheus-developers+unsubscr...@googlegroups.com. > > > To view this discussion on the web visit > > > > https://groups.google.com/d/msgid/prometheus-developers/20200525195320.GA983523%40oxygen > > > . > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "Prometheus Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to prometheus-developers+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/CAMssQwZ3apTKpmUGuTJRs0ipDF7TQcypPOiXh_uX9%2B%3D2zVrFqg%40mail.gmail.com > . > > -- > Julien Pivotto > @roidelapluie > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YozHcACUDAaZVCNyJKjuKq_n2y-Ez4c2prw0m8nxXNHwbA%40mail.gmail.com.
Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?
Hi I support 100% of what Julius said: *> In general, +10 for a change in this direction, since currently, the balance is too much in favor of inaction - it's really easy to veto something, but really hard to unblock it because team-wide votes are high-overhead.* *> I would also want to understand a bit more specifically how this would work in practice though. * +1 on moving to a rough consensus as I think it's stepping into a good direction. Overall, I feel that our team is not a children's playground, we are team of professionals. This means that we trust each other, so no one in Prometheus will decide something totally against someone else's strong opposite vote. I would see it as rather a message to the community that we no longer accept blocking decisions for so long as we used to. If anyone has strong objections on a certain topic, they *have *to suggest alternatives or actionable items that have to be addressed first. This is what I would see as a practical form of such consensus which also hopefully avoids "*concern tends to be ignored rather than addressed*" problem that Brian's mentioned. On a separate note, while I believe in maintaining high project quality for everything we ship, I think we should be way more open into the experimenting bit more in Prometheus. Having some experimental features under a flag is something that gives quicker feedback if the API, feature, or given logic makes sense for a wider user base. For majority of cases we always reject those because "it's support burden", "this does not help much for Prometheus only Cortex/Thanos/XYZ", "this overlap with older, less efficient API", "we don't like those extra dependencies (e.g gRPC)", "people will not use it". This might be off-topic here, but I feel like this is another thing which could improve the velocity of Prometheus and usability of the project itself (: Kind Regards, Bartek On Mon, 25 May 2020 at 20:53, Julien Pivotto wrote: > On 25 May 19:41, Richard Hartmann wrote: > > On Mon, May 25, 2020 at 7:08 PM Julius Volz > wrote: > > > > > I would also want to understand a bit more specifically how this would > work in practice though. E.g. when there are three people arguing one way > on an issue, and one person against, and all views have been considered and > arguments are turning in circles, can the majority (with respect to that > discussion) just go ahead and decide / merge things? I guess in the worst > case, when someone feels unheard, they can still call for a team-wide vote, > but the cost of calling for that vote would then be carried by the > minority, not the majority? So things would be more biased towards action. > > > > That's one possible mode of operation, yes. > > > > Hopefully, there would be fewer lockups by shifting from default-deny > > to default-majority-ish. > > > > If it does not work out to our shared satisfaction, we can always > > refine the governance further, e.g. introduce a Chair system though, > > again, I would like to avoid that. > > > > > > Best, > > Richard > > I would vote :+1: on changing to rough consensus. > > -- > Julien Pivotto > @roidelapluie > > -- > You received this message because you are subscribed to the Google Groups > "Prometheus Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to prometheus-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/20200525195320.GA983523%40oxygen > . > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMssQwZ3apTKpmUGuTJRs0ipDF7TQcypPOiXh_uX9%2B%3D2zVrFqg%40mail.gmail.com.
Re: [prometheus-developers] move https/ package to client_golang
On 24.05.20 21:17, Julien Pivotto wrote: > > I think that for the benefit of the whole community, it might be better > to move it to our "public code" repository, > github.com/prometheus/client_golang. I don't think that github.com/prometheus/client_golang is our "public code" repository. It's the Go instrumentation client, which happens to share its repository with the experimental and not properly maintained HTTP API client. The latter is essentially an accident, a result of a habit of certain core contributors back then to "just do" things without discussing them in depth with their peers. Go Modules weren't a thing back then, otherwise I would have resisted more strongly. With Go Modules in the game, we should either avoid putting multiple more or less independent libraries into the same repo, or we need to embrace multi-module repos after all. I haven't developed an educated opinion about the latter yet. I just noticed a number of fairly strong statements that multi-module repos are supposed to be very painful. Having said all that, github.com/prometheus/common is of course just as problematic as a location. It contains many independent libraries in the same repo. It would essentially be impossible to have meaningful post-1.0 semver in that repo without turning it into a multi-module repo. Plus, the common repo is (by now) explicitly marked as an internal one. The most straight forward solution right now is to create a new repo "github.com/prometheus/tls" or similar. (And I would then advocate to move the HTTP API client out of client_golang into its own repo, should we ever see that it is steering towards a v1.0 release.) If people feel strongly about the proliferation of repos in the Prometheus GH org, I'm willing to educate myself about multi-module repositories so that I can say if I will support or resist a move to a multi-module client_golang repo (if that's possible in a non-breaking fashion at all - if not, we should probably plan to make the common repo multi-module). -- Björn Rabenstein [PGP-ID] 0x851C3DA17D748D03 [email] bjo...@rabenste.in -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200526191532.GQ2326%40jahnn.
[prometheus-developers] Restricting Prometheus to a particular Namespace
Hi All, Currently Prometheus needs ClusterRole and ClusterRoleBinding for scrapping the metrics on Kubernetes. We want to restrict the prometheus to a particular namespace. So we changed RBAC to using Role and RoleBinding and in the Prometheus configuration we added namespaces to kubernetes_sd_configs section. we see that we are able to scrape metrics from the configured namespace, but continuously seeing the errors saying access forbidden to *v1.Pod etc. Currently my cluster is down. will share the exact error once it is available. Following is the Prometheus configuration: - job_name: 'kubernetes-apiservers' kubernetes_sd_configs: - role: endpoints namespaces: names: ['admin'] Please let me know whether we can do with Role and RoleBinding? Thanks n Regards, Chalapathi. -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CABXnQPvSq3-45%2B-2%2BWUctibx6UZKJK%2Bdwfj31zMeGCU%2BcX-vhA%40mail.gmail.com. <>
