1 |
Well, to steal a German phrase, here's my own mustard in the mix: |
2 |
|
3 |
Am Freitag, 14. Februar 2020, 23:52:32 CET schrieb Mark Knecht: |
4 |
> On Fri, Feb 14, 2020 at 12:21 PM Kai Peter <kp@×××××××××××××××.org> wrote: |
5 |
> > On 2020-02-11 00:06, Rich Freeman wrote: |
6 |
> > >> Nevertheless, thank you for discussing it with me |
7 |
> > > |
8 |
> > > You're welcome. You're hardly the first person to disagree with me. |
9 |
> > > |
10 |
> > > :) |
11 |
> > > |
12 |
> > > I'm also not in any particular position of power when it comes to how |
13 |
> > > bugs are handled. You can always make a proposal to automatically |
14 |
> > > close old bugs. I'd probably start with the Bug Wranglers, though you |
15 |
> > > could always bring an issue to the Council if you don't feel you're |
16 |
> > > getting the desired response there. They've certainly been known to |
17 |
> > > disagree with me at times too. :) |
18 |
> > |
19 |
> > Interesting discussion. To bad that it's over. Not so much from the |
20 |
> > technical site, but the different POV's. Michael tries to improve |
21 |
> > things, make things better. Rich stays with the common 'it is like it is |
22 |
> |
23 |
> > and it is good'. An example to the big view: |
24 |
> https://web.archive.org/web/20080331092730/http://www.linux.com/articles/601 |
25 |
> 24 |
26 |
> > Even if I tend to Michael's side, I don't say Rich is wrong. To me the |
27 |
> > truth is in the middle, always. |
28 |
|
29 |
Personally, for me all those open bugs seem like a symptom of bad bug hygiene. |
30 |
Maybe it's not really, and those are just bugs that were left behind in |
31 |
turbulence, so-to-say (e.g., devs retiring, packages becoming obsolete, |
32 |
whatever), but personally, I care about closing bugs that are done with or |
33 |
can't be acted upon. Perhaps its a matter of workflow, because I treat bugs |
34 |
as a sort of TODO list, but that's my take on it. I honestly think it would |
35 |
be best to close bugs that are just not applicable anymore, e.g., for ebuilds |
36 |
or versions of packages that have not been in the tree for a looong time, |
37 |
like, say, HAL: https://bugs.gentoo.org/401257. |
38 |
|
39 |
But like I say below: that's *work*, even closing bugs that are 10 years old |
40 |
might clean up stuff that's more of a task than an actual bug (i.e., something |
41 |
somebody wants to work on at some point), so you'd have to go over them, at |
42 |
least superficially. Also: Rich does have a point in the bugs being open not |
43 |
necessarily mattering much in practice. But for me, I *do* occasionally look |
44 |
at all bugs assigned to or authored by me in case I forgot about something, |
45 |
and having ancient open bugs would be infuriating to me, so I wonder what |
46 |
workflow projects like "freedesktop" have that it's not a problem for them (or |
47 |
maybe it's a defunct project and nobody is even looking). |
48 |
|
49 |
> Well, ok, a view from the very distant other side. Don't take anything I |
50 |
> say as anything other than my opinion which at this point is woefully out |
51 |
> of date about Gentoo I'm sure. |
52 |
> |
53 |
> 1) I started running Gentoo mid-2001, or possibly 2002. I had been running |
54 |
> Redhat, a friend who was a real sys admin type vs me, nothin' but a 'user', |
55 |
> said it was great and I should check it out. It wasn't overly difficult to |
56 |
> get started but I certainly had my issues, like one time removing my C |
57 |
> compiler. Real newbie stuff. However once I got my first machine up and |
58 |
> running I was really happy with both the machine and most of all this |
59 |
> community which is second to none. In those days getting my first machine |
60 |
> really buttoned down was like a 2-3 week event. |
61 |
> |
62 |
> 2) For many years my machines ran really well and admin wasn't a big deal. |
63 |
> Yes, hours upon hours upon hours of building programs - the Gentoo way - |
64 |
> but they usually built. I was always a 'mostly stable' guy, only adding |
65 |
> ~arch when I had to. There wasn't a lot of that, at least in the beginning. |
66 |
> I remember this being how I ran until about 2016. There were some difficult |
67 |
> months, but devs got things fixed pretty fast and I could, for the most |
68 |
> part depend that if I had to install an ~arch package that within a month I |
69 |
> could probably get back to stable. |
70 |
|
71 |
Ah, I still run my machines that way: packages where I want new versions |
72 |
because of a bug fix or feature that's important to me will get unmasked, and |
73 |
I'll try to keep track of if/when they go stable. However... |
74 |
|
75 |
> 3) From my perspective this lasted until 2015/16/17-ish. However somewhere |
76 |
> in there I consistently found two things: |
77 |
> 1) Getting an arch package back to stable in a timely manner pretty much |
78 |
> didn't work anymore. I suspect this is really the other thread here about |
79 |
> long term bugs not getting fixed. Why? I don't know. I suspected devs were |
80 |
> leaving the distro, but I had no info. |
81 |
> 2) This is just my opinion but I came to think there was no real |
82 |
> __interest__ from the devs still here in purely stable anymore. I remember |
83 |
> trying to set up a Virtualbox VM running Gentoo and it almost didn't work. |
84 |
> I had to add so many use flags. At that point it just wasn't fun anymore. |
85 |
> Throw in that I had 3 machines to deal with at home and it was too much for |
86 |
> user type who wasn't having fun. |
87 |
|
88 |
... I totally see this, too. When I started with Gentoo (2007ish) I based my |
89 |
install on Sabayon, but quickly reverted to vanilla Gentoo for simplicity's |
90 |
sake. The Sabayon install set ACCEPT_KEYWORDS="~amd64", but I was able to |
91 |
change that to "amd64", downgrade various packages, and unmask whatever had to |
92 |
stay at ~arch (e.g., glibc) and wait until it upgraded to stable. That took |
93 |
about 2-3 months, as I recall. The vast majority was done within 1-2 months. |
94 |
Today I've been living with most of my current unmask entries for months or |
95 |
years. Although, half of those are in overlays or games (which are "banned" |
96 |
from stable), but the other half are packages with either really old stable |
97 |
version or none at all (they upgrade, but then older versions are removed |
98 |
instead of being stabilized). |
99 |
|
100 |
However, two points here: |
101 |
|
102 |
1.) Lots of important software *does* receive regular stable upgrades (e.g., |
103 |
KDE, all core system packages such as gentoo-sources and glibc, Gnome). |
104 |
AFAICT, for me it's pretty much only "niche" software that doesn't get stable |
105 |
versions. |
106 |
|
107 |
2.) I understand that there just isn't enough man power to go around, so I |
108 |
don't see any point in complaining and just try to manage as best I can. If |
109 |
Gentoo manages to recover from its lack of manpower (and I hope it does), I |
110 |
expect that the set of packages receiving stabilizations will grow again. |
111 |
|
112 |
> 4) I tried out a few other distros and pretty quickly focused in on |
113 |
> Kubuntu. I've been running it for a couple of years now. Frankly, I can |
114 |
> hardly tell the difference from Gentoo when I'm just using the machine. |
115 |
> It's fast, it's KDE, it's all I need. I don't know much more than a couple |
116 |
> of apt commands to install packages. No update in the 2-3 years I've been |
117 |
> using Kubuntu hasn't booted. I don't have any trouble installing the |
118 |
> packages I need that in the Gentoo world would have caused me ~arch |
119 |
> problems. (Mixbus32C, makemkv, handbrake and other pro-audio type packages) |
120 |
> Updates to my machines are on the order of LITERALLY minutes per week, and |
121 |
> distribution upgrades, once a year-ish, are on the order of an hour. The |
122 |
> machines all seem fast. It's simple. |
123 |
|
124 |
My laptop has openSUSE Tumbleweed, because, well, I want a rolling release |
125 |
distro and for some reason didn't want to try Arch Linux (although I probably |
126 |
will at some point). Oh, and I just felt like trying something different, |
127 |
hence why I didn't stick with Gentoo [0] (my desktop and two home servers |
128 |
remain on Gentoo, though). Although, now that I think about it, openSUSE has |
129 |
one leg up against Arch: it's the only mainstream distro that supports BTRFS, |
130 |
my main file system of choice (SUSE even employs several of its developers). |
131 |
|
132 |
> I love this list and the people on it. For the most part everyone here has |
133 |
> been really great to me over the years and there's no place I'd rather go |
134 |
> looking for technical answers. Stack Overflow does tend to be the Ubuntu |
135 |
> way these days so lots of little things I need to know I find there. I |
136 |
> suspect many Gentoo-ers do also. |
137 |
> |
138 |
> Anyway, it's just an opinion of one guy not representing what state the |
139 |
> distribution is in today. |
140 |
|
141 |
FWIW, I'm not so sure about the community *overall*, especially when it comes |
142 |
to the typical inflammatory topics (e.g., systemd, pulseaudio); that is, when |
143 |
things heat up, they can get *really* hot. Though perhaps its just a few bad |
144 |
experiences that manage to color my overall perception, or I'm just seeing |
145 |
things overly negative right now, because there are certainly also plenty of |
146 |
good people here, and I'm with you in that I prefer to ask technical questions |
147 |
(even not directly relating to Gentoo) in this community as well (although my |
148 |
first step is always to research things myself, meaning I almost never have to |
149 |
ask for help here in the first place). |
150 |
|
151 |
> Mark |
152 |
|
153 |
[0] A VM doesn't cut it for me in this case, I feel one needs to use a system |
154 |
in everyday practice to really get a feel for it. I already get that for |
155 |
Ubuntu at work and University, and can confidently say it's not for me. |
156 |
|
157 |
Greetings |
158 |
-- |
159 |
Marc Joliet |
160 |
-- |
161 |
"People who think they know everything really annoy those of us who know we |
162 |
don't" - Bjarne Stroustrup |