[gentoo-amd64] Re: amd64 list, still useful? Was: btrfs

[Duncan <1i5t5.duncan@cox.net>]

Mark Knecht posted on Thu, 05 Jun 2014 11:59:23 -0700 as excerpted:

> Yeah, this was likely the issue. One comment in the -user thread on this
> subject was that at least one -dev-type thinks users should be reading
> change logs to figure this stuff out. I no longer remember how long I've
> run Gentoo but it's well beyond a decade at this point. Daniel Robbins
> was certainly participating. I was working at a company from mid-1999 to
> 2004 when I started. I can only say that I've never read a change log in
> that whole time.

Wow.  I read 'em routinely.  There are actually four different types of 
"changelogs" I read, more or less often and closely, depending on the 
package and how closely I'm following it.

1) The gentoo package changelogs (as found in the gentoo tree) don't 
normally contain a lot of information about the upstream package or 
changes between versions, so I don't read them all the time, but I *DO* 
read the gentoo package changelog much of the time when I see a -rX bump 
for something I already have installed at the same upstream version 
number, because in that case I normally want to know what the gentoo 
package maintainer considered important enough for a revision bump and 
the resulting rebuild trigger for users with that same upstream version 
already installed, instead of simply fixing it in the ebuild without a 
revision bump.  These can be security bumps, for instance, and if so I 
want to know how bad it was and what my risk was before the update.  
Another common reason is config changes or patches that might affect me 
in other ways, that as an admin responsible for the wellbeing of my gentoo 
system (a responsibility I take very seriously), I want to know about.

Additionally, the gentoo package changelogs contain dates for version 
introduction into the tree as well as stabilization on the various archs, 
and eventually, for removal from the tree.  Most of the time when I'm 
checking on these, it's to help someone on some other list figure out a 
dependency on their non-gentoo distro, or figure out how far behind my 
~amd64 installation their version is and how outdated, etc.  Other times 
it can be basically the same stuff, but for another gentooer on stable 
instead of my ~amd64 plus selected live-packages system.

At least back when Zac was portage dev lead, because gentoo /is/ upstream 
for portage and because portage changes are critical to a gentoo system's 
wellbeing, the portage package changelog was far more detailed than most 
others, including bug report numbers and mentioning big feature changes.  
I followed the portage changelog very closely and looked up every bug 
number mentioned to see what sort of changes were being made and why.

2) While not technically "changelog" files, git logs are in fact 
generally much more detailed changelogs, and for stuff like kde, where I 
run live-git-branch packages from the gentoo/kde project overlay, every 
time I do a sync (of both the main gentoo tree and the few overlays I 
run), I FAITHFULLY run git log on the overlay trees to see what updated 
since I last synced, and how.  For the overlays, I follow *EVERY* 
*SINGLE* *CHANGE*, at minimum reading the git-log entry which lists the 
files involved as well, and if there's patches introduced that interest 
me, I'll use git show to pull up the full git diffs and see what actually 
changed, line by line in the source code.

3) Similarly, for various upstream packages I follow upstream's changelog 
or news files as well, not /too/ closely for most packages, but for a lot 
of packages, closely enough to at least be aware of major feature 
updates, both so I can make use of those features, and because they might 
affect config files that I'll be etc-updating in short order, after the 
package upgrade.

4) For a lot of packages that I run the live-git version of, I'll use the 
smart-live-rebuild output to get the upstream git commit IDs, and will 
then do a git log with those IDs to see what changed there, as well.  For 
a few packages, I have a different script that I run that does an 
individual git pull for the package, and I git log it if there are 
changes, before I even run smart-live-rebuild to catch the others at all.

Until I recently switched to systemd, I was one of the few non-dev users 
actually running openrc-9999, precisely so I COULD follow individual git 
commit updates, and I found and filed a number of bugs that then got 
fixed before a release version ever made them generally available even to 
~arch users.  Similarly, I've been involved with upstream pan (the news 
client I follow this list with, among other things) for over a decade 
now, helping out on its mailing list and now filling the local 
application historian role as well, tho I'm not a dev, and I follow its 
git logs *VERY* closely.  Lately I've been active both as a btrfs user 
and on the btrfs list, and follow the btrfs-progs git commit log closely 
as well.

For kde, where I'm on the kde4 development branch, I don't follow the git 
logs /quite/ that closely, but I do keep an eye on them, particularly for 
kdelibs, kde-baseapps and kde-workspace.

I have my own scripts that I use for updating the kernel so I don't use 
gentoo's kernel packages at all, but there too I run (mainline Linus) 
kernel git, and while I don't follow individual commits especially during 
the merge window, I often follow the mainline merge-commits, and follow 
things more closely as commits slow down later in the cycle.  As with 
openrc, I've bisected, filed and gotten fixed a number of bugs in pre-
releases over the years before they hit full releases.

So I must confess it's a bit hard to imagine someone who hasn't read a 
single changelog in at least the decade I've been on gentoo, particularly 
since following them to at least /some/ extent is IMO part of the 
responsibility of being a good sysadmin, responsible for at least their 
own system if no others, is all about.  While I certainly don't expect 
people to follow changes as closely as I do, not viewing even /one/ 
changelog over the course of at least a decade... let's put it this way, 
it's not something /I'd/ be proud to admit in public.

OTOH, that you've gone this long without it and are still here discussing 
and running gentoo definitely *IS* a testament to how good the gentoo 
devs (and tester-users like me filing bugs to be fixed before things hit 
stable, and sometimes before they hit a release or the ~arch tree at all) 
actually are in general at keeping things actually working for people, a 
bit of hiccup now and again for a few days, but basically nothing that's 
not fixed in a few days, and nothing that tends to actually eat systems 
to the point that you're not here, a decade later.

That's SAYING something! =:^)

> This stuff does happen once in awhile. I'm surprised it doesn't happen
> more often actually so for the most part the release process is pretty
> good.

=:^)

> WRT to systemd, my real problem with this latest issue is the systemd
> profile issue, and beyond that there doesn't seem to be a systemd
> oriented new machine install document. In my study getting ready to
> build a new RAID (probably will be 2-drive 3TB RAID1) I wondered of I
> should give in to this portage pressure and go systemd. When I start
> looking there all I find are documents that seem to assume a pretty high
> understanding of systemd which doesn't represent my current education or
> abilities. Seems to me if the gentoo-devs interested in seeing systemd
> gain traction were serious this would be a high priority job. All we get
> today is
> 
> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?
full=1#book_part1_chap12
> 
> which to me says it's not what Gentoo developers want Gentoo users to
> use.
> Of course, that's just me.

You're actually correct.  Mainline gentoo remains openrc, and that's 
likely to remain the case for some time.  Systemd is certainly available 
as an option, and more and more people are switching to it, but even 
after it's well documented in the handbook, openrc will continue to be an 
option for the foreseeable future, with several devs having stated quite 
specifically that they use gentoo and depend on openrc in their jobs, so 
whatever /else/ may happen to gentoo, openrc is *NOT* about to become 
unsupported, as I said for the foreseeable future (which in practice 
means at LEAST two years out as it'd take that long to switch over -- 
remember how long it took to stabilize baselayout-2, and more likely at 
least five years, even if they voted that as a goal right now!).

OTOH, individual packages and specific desktop projects can change 
dependencies based on what upstream supports, and gentoo/gnome is only 
supporting systemd for some elements now.

Luckily for gentoo/kdeers, upstream kde has committed to maintaining more 
systemd independence than has gnome, including with kde 5 frameworks.  
And the modularization of kde-frameworks should make that much easier 
too, over time, altho individual kde packages may eventually require 
systemd.  OTOH, gentooers have it better than most in that they have more 
choice about actually installing individual packages, as well as keeping 
upstream-optional dependencies actually optional.

We did almost lose the ability to opt-out of semantic-desktop, but 
fortunately saner heads prevailed, and had they not done so in gentoo/kde, 
a number of us users were making plans for a user-supported overlay 
similar to the user-supported kde-sunset for kde3 users, to maintain 
semantic-desktop-less kde4 at least until kde5/frameworks, at which point 
we hoped upstream policies would bring back the option due to its 
modularity.  But while I actually had to maintain the semantic-desktop-
less ebuild patches locally for awhile in ordered to continue following 
kde-live-branch, and I guess ~arch users faced the problem for a shorter 
time, the policy thankfully reverted before stable users had to make that 
painful choice.

But various devs have made it VERY clear, gentoo as a whole isn't going 
to get anywhere /close/ to losing the openrc option, as I said, for the 
foreseeable future.

And well before that were to happen, or even if gentoo really expected 
stable users to switch to systemd in quantity, there'd be MUCH better 
documentation, just as that was a prerequisite to the stable-side 
baselayout-2, one of the big reasons it took years.  Again, that's 
exactly the reason users worried about gentoo suddenly switching to 
systemd as it /looked/ like it might be doing here, have nothing to worry 
about for at **LEAST** two years.  A ship as big as gentoo simply doesn't 
turn on a dime, nor can it be forced to, and even were the council to 
suddenly get a brain transplant and vote that it should be the goal 
today, it'd take years to actually implement, including for many gentoo 
devs *AND* their employers.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman