1 |
Mark Knecht posted on Thu, 05 Jun 2014 11:59:23 -0700 as excerpted: |
2 |
|
3 |
> Yeah, this was likely the issue. One comment in the -user thread on this |
4 |
> subject was that at least one -dev-type thinks users should be reading |
5 |
> change logs to figure this stuff out. I no longer remember how long I've |
6 |
> run Gentoo but it's well beyond a decade at this point. Daniel Robbins |
7 |
> was certainly participating. I was working at a company from mid-1999 to |
8 |
> 2004 when I started. I can only say that I've never read a change log in |
9 |
> that whole time. |
10 |
|
11 |
Wow. I read 'em routinely. There are actually four different types of |
12 |
"changelogs" I read, more or less often and closely, depending on the |
13 |
package and how closely I'm following it. |
14 |
|
15 |
1) The gentoo package changelogs (as found in the gentoo tree) don't |
16 |
normally contain a lot of information about the upstream package or |
17 |
changes between versions, so I don't read them all the time, but I *DO* |
18 |
read the gentoo package changelog much of the time when I see a -rX bump |
19 |
for something I already have installed at the same upstream version |
20 |
number, because in that case I normally want to know what the gentoo |
21 |
package maintainer considered important enough for a revision bump and |
22 |
the resulting rebuild trigger for users with that same upstream version |
23 |
already installed, instead of simply fixing it in the ebuild without a |
24 |
revision bump. These can be security bumps, for instance, and if so I |
25 |
want to know how bad it was and what my risk was before the update. |
26 |
Another common reason is config changes or patches that might affect me |
27 |
in other ways, that as an admin responsible for the wellbeing of my gentoo |
28 |
system (a responsibility I take very seriously), I want to know about. |
29 |
|
30 |
Additionally, the gentoo package changelogs contain dates for version |
31 |
introduction into the tree as well as stabilization on the various archs, |
32 |
and eventually, for removal from the tree. Most of the time when I'm |
33 |
checking on these, it's to help someone on some other list figure out a |
34 |
dependency on their non-gentoo distro, or figure out how far behind my |
35 |
~amd64 installation their version is and how outdated, etc. Other times |
36 |
it can be basically the same stuff, but for another gentooer on stable |
37 |
instead of my ~amd64 plus selected live-packages system. |
38 |
|
39 |
At least back when Zac was portage dev lead, because gentoo /is/ upstream |
40 |
for portage and because portage changes are critical to a gentoo system's |
41 |
wellbeing, the portage package changelog was far more detailed than most |
42 |
others, including bug report numbers and mentioning big feature changes. |
43 |
I followed the portage changelog very closely and looked up every bug |
44 |
number mentioned to see what sort of changes were being made and why. |
45 |
|
46 |
2) While not technically "changelog" files, git logs are in fact |
47 |
generally much more detailed changelogs, and for stuff like kde, where I |
48 |
run live-git-branch packages from the gentoo/kde project overlay, every |
49 |
time I do a sync (of both the main gentoo tree and the few overlays I |
50 |
run), I FAITHFULLY run git log on the overlay trees to see what updated |
51 |
since I last synced, and how. For the overlays, I follow *EVERY* |
52 |
*SINGLE* *CHANGE*, at minimum reading the git-log entry which lists the |
53 |
files involved as well, and if there's patches introduced that interest |
54 |
me, I'll use git show to pull up the full git diffs and see what actually |
55 |
changed, line by line in the source code. |
56 |
|
57 |
3) Similarly, for various upstream packages I follow upstream's changelog |
58 |
or news files as well, not /too/ closely for most packages, but for a lot |
59 |
of packages, closely enough to at least be aware of major feature |
60 |
updates, both so I can make use of those features, and because they might |
61 |
affect config files that I'll be etc-updating in short order, after the |
62 |
package upgrade. |
63 |
|
64 |
4) For a lot of packages that I run the live-git version of, I'll use the |
65 |
smart-live-rebuild output to get the upstream git commit IDs, and will |
66 |
then do a git log with those IDs to see what changed there, as well. For |
67 |
a few packages, I have a different script that I run that does an |
68 |
individual git pull for the package, and I git log it if there are |
69 |
changes, before I even run smart-live-rebuild to catch the others at all. |
70 |
|
71 |
Until I recently switched to systemd, I was one of the few non-dev users |
72 |
actually running openrc-9999, precisely so I COULD follow individual git |
73 |
commit updates, and I found and filed a number of bugs that then got |
74 |
fixed before a release version ever made them generally available even to |
75 |
~arch users. Similarly, I've been involved with upstream pan (the news |
76 |
client I follow this list with, among other things) for over a decade |
77 |
now, helping out on its mailing list and now filling the local |
78 |
application historian role as well, tho I'm not a dev, and I follow its |
79 |
git logs *VERY* closely. Lately I've been active both as a btrfs user |
80 |
and on the btrfs list, and follow the btrfs-progs git commit log closely |
81 |
as well. |
82 |
|
83 |
For kde, where I'm on the kde4 development branch, I don't follow the git |
84 |
logs /quite/ that closely, but I do keep an eye on them, particularly for |
85 |
kdelibs, kde-baseapps and kde-workspace. |
86 |
|
87 |
I have my own scripts that I use for updating the kernel so I don't use |
88 |
gentoo's kernel packages at all, but there too I run (mainline Linus) |
89 |
kernel git, and while I don't follow individual commits especially during |
90 |
the merge window, I often follow the mainline merge-commits, and follow |
91 |
things more closely as commits slow down later in the cycle. As with |
92 |
openrc, I've bisected, filed and gotten fixed a number of bugs in pre- |
93 |
releases over the years before they hit full releases. |
94 |
|
95 |
So I must confess it's a bit hard to imagine someone who hasn't read a |
96 |
single changelog in at least the decade I've been on gentoo, particularly |
97 |
since following them to at least /some/ extent is IMO part of the |
98 |
responsibility of being a good sysadmin, responsible for at least their |
99 |
own system if no others, is all about. While I certainly don't expect |
100 |
people to follow changes as closely as I do, not viewing even /one/ |
101 |
changelog over the course of at least a decade... let's put it this way, |
102 |
it's not something /I'd/ be proud to admit in public. |
103 |
|
104 |
OTOH, that you've gone this long without it and are still here discussing |
105 |
and running gentoo definitely *IS* a testament to how good the gentoo |
106 |
devs (and tester-users like me filing bugs to be fixed before things hit |
107 |
stable, and sometimes before they hit a release or the ~arch tree at all) |
108 |
actually are in general at keeping things actually working for people, a |
109 |
bit of hiccup now and again for a few days, but basically nothing that's |
110 |
not fixed in a few days, and nothing that tends to actually eat systems |
111 |
to the point that you're not here, a decade later. |
112 |
|
113 |
That's SAYING something! =:^) |
114 |
|
115 |
> This stuff does happen once in awhile. I'm surprised it doesn't happen |
116 |
> more often actually so for the most part the release process is pretty |
117 |
> good. |
118 |
|
119 |
=:^) |
120 |
|
121 |
> WRT to systemd, my real problem with this latest issue is the systemd |
122 |
> profile issue, and beyond that there doesn't seem to be a systemd |
123 |
> oriented new machine install document. In my study getting ready to |
124 |
> build a new RAID (probably will be 2-drive 3TB RAID1) I wondered of I |
125 |
> should give in to this portage pressure and go systemd. When I start |
126 |
> looking there all I find are documents that seem to assume a pretty high |
127 |
> understanding of systemd which doesn't represent my current education or |
128 |
> abilities. Seems to me if the gentoo-devs interested in seeing systemd |
129 |
> gain traction were serious this would be a high priority job. All we get |
130 |
> today is |
131 |
> |
132 |
> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml? |
133 |
full=1#book_part1_chap12 |
134 |
> |
135 |
> which to me says it's not what Gentoo developers want Gentoo users to |
136 |
> use. |
137 |
> Of course, that's just me. |
138 |
|
139 |
You're actually correct. Mainline gentoo remains openrc, and that's |
140 |
likely to remain the case for some time. Systemd is certainly available |
141 |
as an option, and more and more people are switching to it, but even |
142 |
after it's well documented in the handbook, openrc will continue to be an |
143 |
option for the foreseeable future, with several devs having stated quite |
144 |
specifically that they use gentoo and depend on openrc in their jobs, so |
145 |
whatever /else/ may happen to gentoo, openrc is *NOT* about to become |
146 |
unsupported, as I said for the foreseeable future (which in practice |
147 |
means at LEAST two years out as it'd take that long to switch over -- |
148 |
remember how long it took to stabilize baselayout-2, and more likely at |
149 |
least five years, even if they voted that as a goal right now!). |
150 |
|
151 |
OTOH, individual packages and specific desktop projects can change |
152 |
dependencies based on what upstream supports, and gentoo/gnome is only |
153 |
supporting systemd for some elements now. |
154 |
|
155 |
Luckily for gentoo/kdeers, upstream kde has committed to maintaining more |
156 |
systemd independence than has gnome, including with kde 5 frameworks. |
157 |
And the modularization of kde-frameworks should make that much easier |
158 |
too, over time, altho individual kde packages may eventually require |
159 |
systemd. OTOH, gentooers have it better than most in that they have more |
160 |
choice about actually installing individual packages, as well as keeping |
161 |
upstream-optional dependencies actually optional. |
162 |
|
163 |
We did almost lose the ability to opt-out of semantic-desktop, but |
164 |
fortunately saner heads prevailed, and had they not done so in gentoo/kde, |
165 |
a number of us users were making plans for a user-supported overlay |
166 |
similar to the user-supported kde-sunset for kde3 users, to maintain |
167 |
semantic-desktop-less kde4 at least until kde5/frameworks, at which point |
168 |
we hoped upstream policies would bring back the option due to its |
169 |
modularity. But while I actually had to maintain the semantic-desktop- |
170 |
less ebuild patches locally for awhile in ordered to continue following |
171 |
kde-live-branch, and I guess ~arch users faced the problem for a shorter |
172 |
time, the policy thankfully reverted before stable users had to make that |
173 |
painful choice. |
174 |
|
175 |
But various devs have made it VERY clear, gentoo as a whole isn't going |
176 |
to get anywhere /close/ to losing the openrc option, as I said, for the |
177 |
foreseeable future. |
178 |
|
179 |
And well before that were to happen, or even if gentoo really expected |
180 |
stable users to switch to systemd in quantity, there'd be MUCH better |
181 |
documentation, just as that was a prerequisite to the stable-side |
182 |
baselayout-2, one of the big reasons it took years. Again, that's |
183 |
exactly the reason users worried about gentoo suddenly switching to |
184 |
systemd as it /looked/ like it might be doing here, have nothing to worry |
185 |
about for at **LEAST** two years. A ship as big as gentoo simply doesn't |
186 |
turn on a dime, nor can it be forced to, and even were the council to |
187 |
suddenly get a brain transplant and vote that it should be the goal |
188 |
today, it'd take years to actually implement, including for many gentoo |
189 |
devs *AND* their employers. |
190 |
|
191 |
-- |
192 |
Duncan - List replies preferred. No HTML msgs. |
193 |
"Every nonfree program has a lord, a master -- |
194 |
and if you use the program, he is your master." Richard Stallman |