Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
Date: Sun, 01 Jun 2014 13:13:16
Message-Id: 1401628384.790.28.camel@belkin5
In Reply to: Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention by Markos Chandras
1 El dom, 01-06-2014 a las 13:59 +0100, Markos Chandras escribió:
2 > On 06/01/2014 01:07 PM, Pacho Ramos wrote:
3 > > El dom, 01-06-2014 a las 13:00 +0100, Markos Chandras escribió:
4 > >> On 06/01/2014 12:33 PM, Pacho Ramos wrote:
5 > >>> El dom, 01-06-2014 a las 14:18 +0300, Samuli Suominen escribió:
6 > >>>> http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking
7 > >>>> stabilizing the new virtuals, and thus, converting the tree, and
8 > >>>> also blocking stabilization of the already converted packages
9 > >>>> (gnome seems to have some) pending for 3 months already
10 > >>>>
11 > >>>> thanks, samuli
12 > >>>>
13 > >>>
14 > >>> This makes me wonder about the real status of some of this arches.
15 > >>> I know that now we will probably see how Agostino goes ahead and
16 > >>> does all the work (that is nice and I really welcome his work
17 > >>> trying to keep this arches in shape), but also makes me thing if
18 > >>> makes sense to keep this agostino-dependency for this arches more
19 > >>> and more time. What will occur if he is not around sometime? :/
20 > >>>
21 > >>>
22 > >>
23 > >> We have been through the same discussion not so long ago and the
24 > >> result was to start dropping the ~m68k, s390 and sh to ~testing[1]. In
25 > >> the thread that started it all[2] there has been no resistance about
26 > >> dropping the keywords of these arches on $subject and here we are
27 > >> again discussing the problem. Here[3] you can see council's decision.
28 > >> I quote here just for fyi:
29 > >>
30 > >> "In summary:
31 > >> - m68k, s390, sh: will be dropped to unstable keywords globally.
32 > >> - alpha, ia64: Maintainers can remove older stable versions according
33 > >> to the "package-by-package" proposal.
34 > >> - sparc: No action.
35 > >> "
36 > >> So unless I make a mistake, you are free to start dropping alpha, ia64
37 > >> to ~arch. For ppc,ppc64 and sparc it's probably best to resurrect the
38 > >> old thread and possible have add it to the agenda for the next meeting.
39 > >>
40 > >> [1] http://permalink.gmane.org/gmane.linux.gentoo.devel/88183
41 > >> [2] http://www.gossamer-threads.com/lists/gentoo/dev/277054
42 > >> [3]
43 > >> http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt
44 > >>
45 > >
46 > > The problem arrives when even core components like udev takes so long to
47 > > be handled :/ (and situation would be much worse if Agostino doesn't
48 > > have time to make his mass stabilizations... well, each time I report a
49 > > stabilization bug that affects me I cross my fingers expecting ago has
50 > > enough time to handle them ;))
51 > >
52 > >
53 >
54 > Relying on a single developer handling all architectures clearly does
55 > not scale and it is dangerous. We really need to be realistic and
56 > consider how many stable alpha/sparc/ia64/ppc* users are out there. In
57 > my mind the number is rather small, so does it really worth the effort
58 > trying to keep them stable hurting the remaining stable architectures
59 > and causing significant delays in publishing GLSAs?
60 > The reason I suggested to move the discussion back to the old thread is
61 > that some of these things have already been discussed in the past so I
62 > would like to avoid restarting the discussion from scratch.
63 >
64
65 Yes, I agree. What I am trying to say is that this discussions usually
66 ends when some people reports that "statistically" they don't take so
67 long to stabilize and don't have so many opened bugs... but that
68 statistics depends on ago being able to do the work recently and, then,
69 it's a chicken-egg problem: we want and need him to stabilize on that
70 arches... but that makes other think the arches are ok in that area
71 while they are really relying on one man work :(