On Tue, 28 Jan 2014 12:37:40 +0000 "Steven J. Long" <[email protected]> wrote:
> Please set your client not to embed people's email addresses in your > responses: it's spambait in web archives. Thanks. It's as much a spambait as it is listed in the From: header on the web archives; in other words, it are the web archives that need to fix this. Unless you want to keep spamming this sentence to everyone you talk to; and/or besides that, wasting your time on changing the quote lines. > Tom Wijsman wrote: > "moves us closer to bleeding-edge" is completely useless; It might be for you; depends, but not completely useless in general. > there are already an immense amount of ways to run more up to date > software, or you wouldn't have users already doing it. That doesn't > detract from the merits of the stabilisation process, which you > apparently don't get despite trumpeting your QA membership. > > The latter leaves me rather worried, to be frank. For there to be a stabilization process there need to be people; and thus, other solutions need to be explored. And thus some of those other solutions are detracting from the merits of the stabilization process. > > > > > I don't think that's what was being proposed, though. The > > > > > question was really the old complaint about slow > > > > > architectures; the "-* arch" solution sounds like the most > > > > > reasonable definition of "dropping" keywords, in the absence > > > > > of AT communication otherwise. > > > > > > > > Dropping keywords and specifying -* are a world apart of each > > > > other. > > > > > > That's why it's in quotes. > > > > Why is there at all if you intend it to be irrelevant to this > > thread? > > What? OFC it's relevant; it's just not dropping keywords, it's > dropping the ebuild from most archs, and leaving it in-place for > those which haven't stabilised a newer version. Dropping a keyword or ebuild means removing it; -* is a step further than that, and thus beyond the scope of this thread. It is there to indicate the package does not work on that particular architecture, it is a world apart from just dropping the keyword; hence it is irrelevant. > > > > The former means that it is not ready for wide stable or testing > > > > users, the latter means that it has been tested to not work at > > > > all; furthermore, we need to explicitly specify which arches in > > > > that case. > > > > > > You're missing the point, again. The question was what does > > > "dropping keywords" mean, when the maintainer has stabilised a > > > newer version on the arch/s s/he has available, but feels that > > > slower archs are holding up that process. > > > > Where is that question? > > *sigh* Are you really saying you don't understand the point of this > thread? It's yaf "slow archs are slow and i don't want them" > complaint, which recur every year or so, going back at least 10, > though we haven't had this for the last couple of years that I > recall; Gentoo has moved pretty quickly. > > It comes up more from openrc, imo, since the upstream maintainer is > also a Gentoo dev, who doesn't release testing (= hard-masked) ebuilds > for a core system package. That's an old argument, though, and his > call. I mention it simply because the QA process for that package is > squashed, in comparison to its importance within the framework. Git > ebuilds are not the same as distribution stabilisation. > > No, I'm not expecting it to change. I'm just pointing out that it's > very different to the other packages in the tree (being in-house it > hasn't gone through any upstream testing at all, since Gentoo is > effectively the upstream), and a case could be made that in fact its > QA needs better handling, rather than changing policy to the detriment > of archs across the board in response to this complaint. So, where is that question? > > > I'm slightly at a loss as to why it's such a big deal to just > > > leave the old ebuild as-is, given that anyone on a stabled arch > > > should upgrade automatically. > > > > It is when you are running the arch that only has the old version. > > FGS that's up the AT and their users to collaborate on them with. It's > not up to some external "developer" to tell the AT which ebuilds are > stable for their arch: that's their *job*. The ebuild dev only gets to > request testing, just like users only get to request a version bump. Sometimes users get to put it in their overlay because their version bump, or even a new package request, yields no succes; in the same way, sometimes there are no people that fill in the *job*, hence we come to the point of this thread to look into options to change it. > > > But given that the maintainer feels they don't want that old > > > ebuild around, and that the arch in question has not got round to > > > testing the new one, for whatever reason (it's their call, after > > > all, as to how their arch progresses), instead of simply removing > > > that ebuild, or bumping it to unstable (which makes zero sense), > > > just leave it stable on the slow arch/s in question, and remove > > > the others. > > > > There are situations (security, stability, incompatibility) where > > keeping it in place becomes a much harder task; at which point, > > removal is bound to happen. At that point, such action is required. > > > > It becomes faster than you think; if you depend on a library, and > > the compatible range of that library gets wiped by a security bug, > > your package will suddenly depend on an incompatible newer > > stabilized version of the library at which point you are up for > > either a lot of hard work or plain out starting the progress of > > masking and removing it. > > Security bugs have a separate process, as you know, It affects the visibility of the package or its ebuilds. > and reverse dep checking is a standard thing. On new stabilizations, yes; those that were around for a long time, no. > No-one said maintaining the tree is easy: that's why there's so many > of you collaborating on it, rather than a team of 5. Nor that you > can't mask ever: just that the standard stabilisation cycle should > not involve you removing the prior stable ebuild on an arch before a > newer version is stabilised. > > The latter becomes an issue when someone wants to remove the ebuild, > for whatever reason. If you do find yourself wanting to remove the > ebuild, and it's still not stable, then just remove the keywords on > all archs except the specific slow ones. There must be a bug for > stabilisation already, so note it there, and get on with your life > without whinging. It's not your problem, it's the AT's: let them get > on with it without you messing up their arch with no warning. An AT problem can quickly become a problem on the distribution level; if it weren't a problem, we'd not even get bothered or care. For example, it causes bugs that depend on the stabilization bug to get blocked; delaying progress of bugs that depend on it. There might be other reasons listed in the previous thread regarding the minor arches. > > > This seems like a rarity, but when it's an issue, people get > > > annoyed on either side. The solution proposed by the ARM team, > > > > Where is this solution? > > What? Pay attention: "-* arch" It's irrelevant to this thread. So, maybe "arch" was meant instead? > > > seems like a simple way round, and indicates clearly to anyone > > > perusing the ebuild, that a newer version needs stabling on the > > > "slow" archs. > > > > Masking works fine for that too; what this does is make clear to the > > user that (1) the current stable version has breakage for a specific > > reason, (2) a newer stable version is not yet available and (3) > > that the user can choose to keep the breakage or upgrade to an > > unstable version. > > It's more work, and there's no reason for it: "-* arch" is a lot > quicker, simple to do and blindingly obvious as to its intent. But also plain wrong, see above; maybe "arch" is thus meant, but we are already doing that today. The problem here isn't the other listed arches, but rather the arch itself; as it blocks progress, see above. > Note we are not talking about "breakage" for security (a separate > process and team are in place for that.) It affects the visibility, as I mentioned before. > It indicates 1) The arch is lagging on this ebuild and 2) there is a > newer ebuild which the maintainer has stabilised on other archs, so > work on that if you want a newer version, and *know that the work > will be much welcomed*, and 3) the user can unmask a newer ebuild > should they wish to (and thus feedback for stabilisation.) 3) The newer ebuild is unmasked, this means accepting the keyword? > It's much better metadata, easily detectable via script, in the right > place: the ebuild, not a profile mask file somewhere in the stack. If > we agree on it as a mechanism (and I still have not seen why not, for > the case that started this thread and other standard cases) then it's > trivial for portage/pkgcore to flag it in output, leading to better > user feedback and the chance of quicker stabilisation. That stack can very well be the profile directory of the arch team, which is a rather good place for this metadata. > > > By all means, raise technical objections; just not a philosophical > > > one. > > > > Where are these philosophical objections? > > All over the shop. "Where is this solution" If I tell you to "check out my solution"; then which one would that be? I've given several through-out the thread; if you were to pick one, that would merely be an assumption. Thus this is an actual question, rather than something philosophical; it makes the discussion harder if you refer to matters using generic keywords instead of being specific. > "Please point out X" instead of simply reading what is in front of > you Where did I use this exact wording? It's probably for a good reason to get something clarified; clarifications are natural in a discussion, you can't expect other individuals to fully understand each other. > along with digression about the nature of software, the > development process and how things could be considered, but very > little practical insight, IMO, resulting in frustrated responses, as > usual. What are you talking about? IMO, this misses reference, as usual. > Again, what is so wrong with removing keywords for all archs except > the ones which have not caught up and stabilised, instead of removing > the ebuild? (Or indeed forcing people through the whole mask cycle > without good cause.) Nothing, it is just irrelevant to this thread; it is something we already do, it doesn't address with the problem put forward in this thread as well as that it forms no actual solution to the problem here. > = > I concur that "QA should be focusing on making stable, actually > stable, not more bleeding edge." That's not a "performance" issue as > you put it, except in management nuspeek. It's the whole bloody point > of the distro, in overarching terms: to test and stabilise robust > ebuilds. That process is what leads to better software, not staying > at the "bleeding-edge" and forgetting about robustness since "a new > version is out." A process needs people to fulfill it. > There's plenty of ways to stay on the bleeding-edge; throwing out the > baby with the bathwater will only tip you over it, and bork the distro > for the rest of us, and everyone down the line. Why do we have the baby in the first place? > I'm slightly worried as to the composition of the QA team now, where I > wasn't before. "QA comes in to reorganize our efforts as well as > policy" is over-reaching afaic. Consider starting a new thread about the role and/or composition of the QA team if that is a concern. > But a QA team only interested in the bleeding-edge, Where is there an implication that we are /only/ interested in that? > or even /thinking/ that losing the stable tree will improve either > quality or the distro? *shudder* Where is there an implication where we think we /should/ lose it? > I thought QA was a hard team to get onto, and not because it's a > clique, but because it's central to the mission. Oh well. s/QA/an arch team/ -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : [email protected] GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
