Gentoo Archives: gentoo-project

From: Markos Chandras <hwoarang@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Council discuss: overlapping council terms of two years
Date: Sat, 06 Aug 2011 10:01:07
In Reply to: Re: [gentoo-project] Council discuss: overlapping council terms of two years by "Jorge Manuel B. S. Vicetto"
Hash: SHA512

On 08/06/2011 04:11 AM, Jorge Manuel B. S. Vicetto wrote:
> On 05-08-2011 18:43, Markos Chandras wrote: >> On 08/05/2011 07:36 PM, Matt Turner wrote: >>> On Fri, Aug 5, 2011 at 12:32 PM, Patrick Lauer >>> <patrick@g.o> wrote: >>>> So if you think slacking arches are a problem ... aquire a >>>> Mips or Sparc or whatever machine and get cracking. > >>> Thank you. Yes, please do this. > >>> I don't mean to go off topic, but every time I see a complaint >>> about "slacking arches" I wonder if the person realized that >>> almost all of the "slacking arch" teams are run almost entirely >>> by a single person, armin76. > >>> Take a look at the number of commits that he has and then >>> complain about slacking. > >> What are you talking about? Did I ever blame Armin76? Do you think >> that having a single person doing all the commits can justify your >> argument? A single person doing commits 24/7 is not a proof that >> an arch is in a good state. You have totally missed the point >> here. > > Markos, > > I'm sorry, but in my view, you and others have completely missed the > point when you ignore the issue with man power and resources to do > arch work or the relevance of it and focus only on "punishing" > "slacking arches". Having Raúl as the single or the de-facto single > maintainer for an arch is something that should worry us, but not to > call such an arch "slacking" or, worse, "dead".
Oh come on Jorge. You know what I mean by slacking arches. I am not talking about punishing them. Maybe drop stable keywords or drop keyword from X package and shrink their tree so they can keep up with the load.
> One of the issues with the "slacking arches" topic is that people > tend to associate it with mips, alpha, sparc or some of the other > "exotic" arches. However, in one of the iterations about this topic, > someone put forth numbers that showed that amd64 was at the time one > of the worst "slacking arches".
I did that but things got slightly better since then.
> This should be the arch more developers use daily and is likely the > one with more members (herd count). Also, one should remember the > time it takes to compile, test or debug an issue in a recent amd64 > system or an old / slow box with an "exotic arch" varies > substantially. Not to mention that the amount of testing done on > "exotic arches" varies substantially between projects.
I am aware of the problems and this is way I want a solution.
> > In the last council, I've took the job of promoting some email > threads between arch teams, the council, trustees and infra to see > what we could do about it. Some of the issues were then opened on the > project ml. You are correct that there wasn't a "quick", "final" or > even "conclusive" decision, but I'll argue that we needed more debate > - including more interest and participation from the community. I do > think we had a good discussion.
Yes, we discussed what was needed etc but I don't really think that anything changed since them. If not, then I apologize
> If the argument in the end boils down to how many arches Gentoo > supports and about leaving support for some arches or killing it so > that maintainers aren't "bogged down" by arches, I'll support arches > over maintainers. >
I never said to completely drop these arches. When did I say that? I just want a more realistic approach on how well an arch is supported. Why you people are afraid to admit that we have problems? Having an arch with constantly >200 stabilization bugs open clearly proves that the manpower cannot handle the situation. ps: ++ to Raúl for his work. I hope he wont fed up with that in the future :) - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOPRCwAAoJEPqDWhW0r/LCKIgP/A1ZAUKuUDA7yT0VVdpd/Dc3 7KeN5IJF+JV1Zg3f31DwdpWpARe4Vy4znRyvWXJVDjdSVzFZWpuSZbgcVr5fn/fp 0xIo/5W8nQBhCC70fVy3XhhCgvFOumLNJj5L6isM/95UlDPPKa5FMzfqcvfFO3b9 p2HxEr+MaptebdeijwSGD/pYGD0ct0t0v/nmBiwzT5m+iC1cPL9JL3mtVle2E+RL 7Cyx+PJylORC9xbNp4E0OGHGwjkv12OlhnHjXA7tLZk3teDg22W2IMDyRaXTwL6p sdEoDx1kq1AkEiJls70yO9nh5AGLrOpMgYr9LPo/aKauRy68aIR1tHHw+Dq0YDp6 IveAzXCGtWTCebWMfB7gInYkQ82sJr4nLViUP//EedkFIn624GtxjhkL+VXAwMME qbYq+n48f65E35FarDvV4sOTHrXvkO6/iVIRbmspQrw8Tje3V/2w9zBnRCP2DNKM LueiPAon9I3Z/Vs2AeBdtOtI2rqsAUdFffGbq9calk22u2+l3AJEoUUqdp2UISVs bsk2rNy9cO3+5xZnWWEeAebGhPYkMtFAgbmoxTp9Q6nhLBbgoAbWGZ+kEnYf6A6e oeMKX9z00nUIaA11FY+GpwVnFSCTD0g8K37MzfloFyMV/coOUJgLMa8aLOIQhmSM VN9pyMOwrmHZyE91Qv9Y =7xTL -----END PGP SIGNATURE-----