Tom Wijsman: > On Tue, 01 Apr 2014 20:21:23 +0300 > Samuli Suominen <ssuomi...@gentoo.org> wrote: > >> On 01/04/14 19:38, Tom Wijsman wrote: >> >>> can serve as a reminder how people can respond to such a QA action, >>> that is to talk to the 1) QA person, 2) QA team and then 3) Council. >> >> That is what was done, with the members online at #gentoo-qa, where >> some of the members did not exactly agree with the act of masking >> at the stage we were in. > > Which were only ~2 people at the time the mask happened, I was only > contacted by WilliamH whom changed mind; a mail to the alias works much > better, as you reach everyone and it is not lost in a too long backlog. > >> Still, I see many points where this could have been handled >> differently, better, and I certainly see how you could interpret that >> bulletin point of the GLEP differently. > > Which points? How? The GLEP can be updated to avoid misinterpretations. > >>>> This is an individual, albeit a QA member, disagreeing with a >>>> design model. >>> How can we disagree with a design model we didn't know about yet? >> >> I get your point, however, I still believe the related people were >> involved by other communication channels. >> If use of those other communication channels is so unpreferred over >> the mailing list, I believe the QA/council/comrel >> whoever is in charge of the policy dictating gentoo-dev being a >> optional ML, > > It "should" be [1]; it acts as a recommendation, which is stronger than > "optional". While on its own this sentence doesn't mean much and you can > ignore it; it should be noted that quite some changes pass by there, as > well as some decisions on a lower level. In which case people "should" > be aware that if they aren't subscribed that they might miss out on it. > > [1] Gentoo Developer Handbook > > https://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=3#doc_chap8 > >> should review that policy and make it a mandatory one, if it really >> is. It would have certainly made me see things differently right from >> the start, that is, what some seem to be after here? > > The thing we need to do is get more changes and decisions, even if it's > just a digest of the last week, pass by gentoo-dev-announce; earlier in > #gentoo-qa I've mentioned something like that, in which we can summarize > that and additionally highlight eclass, virtual, profiles changes, > meeting decisions, the list goes on... > >> I believe by that, we would have avoided our (you, and me) earlier >> "problem" (you know what I'm talking about, no need >> to refresh it here.) > > Well, I've asked you several times to bring this up to the general > public; and even in absence of those, also the Gentoo Council. This is > a similar "appeal to ..." approach. The other part of our "problem" is > based on that the "do not touch other maintainer's packages" doesn't > cover how this policy takes into account reverse dependencies changes. > > Currently I make an exception for those three packages that were > mentioned; because well, I don't want such a "problem", but rather > have it constructively discussed somewhere in the near or far future. > >>>> If joining QA team means you get to dictate, alone, how others do >>>> their work, even when they are not breaking anything while doing >>>> so, >>> That is also a part of quality assurance. >> >> I suspect we have a slight language barrier here. If you mean if QA >> should be monitoring every commit that goes in to the tree and >> monitor the tree as whole, then you would be right. That's what I do >> daily basis, and I suspect many others do as well -- being subscribed >> to the gentoo-commits ML and informing others of possible mishaps. >> You don't need to be part of the QA team for that. > > +1 > >> However, that's not what I meant, by 'dictate how others do their >> work', I meant that one literally, let me demostrate with completely >> made-up example from the on-going multilib thread on the ML where >> yngwin doesn't agree with the multilib design model, if he were a QA >> member and wanted to revert the tree to a state it was before the >> conversions, he'd have powers to do that alone. > > Let's assume that leads to disagreement, his power would stop there; > and if he would revert that large part of a tree, it might have other > consequences for not discussing such large scale changes in advance. > >> Note, I do not leverage the use of subslots in tree to the multilib >> issue, at all, and I realize the example wasn't perfect, but it was >> the best I could come up with such short notice. > > My above answer translated to the virtual subslots would only apply if > you were to change reverse dependencies (note, our "problem" above) > yourself without discussion and it would lead to breakage; regressions > like these, were people are unaware, aren't well received. > > Okay, but this isn't what happened yet; because your plan was to send > out a mail after stabilization for everyone to adapt the reverse > dependencies, and I predict that that in its own would have lead to a > discussion. At which point I think a discussion in advance would be > better than one when you've already started the migration; otherwise, > you might meet resistance halfway in the migration. An unintended > delay; and who knows, perhaps more than that in the form of breakage. > >>>> without the rest of the team, we'd be setting a bad precedence. >>> Per the GLEP; when there is disagreement, the rest can vote on it; >>> beyond that, there's also the Council. >> >> I suspect we agree, but have different understanding of 'disagreement' > > (Dis)agreement that is based on reasoning and not on "that way". > >>>> The QA membership is not a large trout you get to bash others with >>>> when you feel like it. >>> Of course; but this isn't what is happening, is it? >> >> Maybe not anymore, but that's certainly what it looked to be earlier. >> >>>> Otherwise everyone would be lining up the QA team membership just >>>> to protect their work from others. >>> Projects like the Council, ComRel and QA are there to protect >>> Gentoo; and yes, people are (or should be) lining up to protect >>> Gentoo. >>> >> >> You are right, but that's not what I said. > > Examples of how things would be in reality are brought up to demonstrate > that what you speak of is hypothetical; in other words, "bashing when > we feel like it" or "protecting our work" hasn't taken place, as it is > done to protect Gentoo. But as said earlier, maybe it is a bit too fast. > > That said, I agree with your points in the general way; I just don't see > them as having happened intentionally here, or reflecting what happened. > > Anyhow, the later part of this conversation is for ComRel to decide on; > so, let's not go back-and-forth. In response to hasufell, I just wanted > to make clear how relevant parts of QA and appealing work as well as > why things were done the way they are. Apart from its speed... >
Tom... I am not sure if you know that, but your posts are difficult to read. You split up posts horribly and I am often unable to follow what you mean... at all. If I am the only one, then it's probably my fault.
