-----BEGIN PGP SIGNED MESSAGE-----
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
>>> <firstname.lastname@example.org> 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
> 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
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
-----END PGP SIGNATURE-----