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... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
