From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 65B301387FD for ; Fri, 6 Jun 2014 12:11:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BD9ADE0A6F; Fri, 6 Jun 2014 12:11:35 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C9877E0A5C for ; Fri, 6 Jun 2014 12:11:34 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Wsszc-0002St-L1 for gentoo-amd64@lists.gentoo.org; Fri, 06 Jun 2014 14:11:32 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jun 2014 14:11:32 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jun 2014 14:11:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: amd64 list, still useful? Was: btrfs Date: Fri, 6 Jun 2014 12:11:18 +0000 (UTC) Message-ID: References: <20140527223938.GA3701@sgi.com> <53859043.2050303@thegeezer.net> <20140528223247.66fff7d5@marcec> <20140529195707.3fddb0a0@marcec> <20140529170526.2e35807f7959d11f45f2de1c@comcast.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 2ae6aff /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: b6cd4a33-40fa-4745-9435-a58bcc39c1e2 X-Archives-Hash: caf139834331392134e4201c726decb5 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