Kent Fredric posted on Wed, 24 Feb 2016 18:49:06 +1300 as excerpted: > But I'm sure at least one person out there has probably gone looking for > a changelog to see when something got stabilized/keyworded.
<raises hand> In particular, I tend to be looking for this level of "introduced-on ymd to the kde overlay, tho masked as unreleased upstream, unmasked to ~arch in the overlay on ymd after upstream public release, introduced to the main tree on ymd, revision-bumped to get the patch fixing problem to users on ymd, first-arch-stabilized on ymd, x86 stabilized-on ymd, amd64- stabilized on ymd, removed from tree as obsolete on ymd" type detail, when comparing notes with for instance users running LFS and Arch on the fresh end, and users running RHEL/CentOS/Debian-stable on the stale end. Comparing this sort of version and stabilization history across distros, cross-referenced with when particular bugs showed up or disappeared, can be extremely helpful in tracking down whether problematic behavior is version-limited or perhaps doesn't originate with the leaf app in question at all, but instead, with some library that happened to be updated on one distro at the particular time a bug appeared, that either hasn't appeared or has been updated with a fix, on some other distro. And I imagine tracking such ~arch keywording and stable-event dates could be even more critical on less common archs with bugs that don't tend to trigger on the common archs and that thus don't get fixed until someone experiences and reports them on the trigger archs. Tho I understand your point, and have had the same experience when looking at, for instance, upstream kde git-level logs. But to some extent it can be argued that at the distro packaging level as opposed to the upstream code development level, every commit /is/ potentially of interest to users of that package, at least of the arch involved if it's something like keywording/stabilizing, or the commit likely wouldn't be worth making in the first place. Which is one reason it's so frustrating that gentoo's git guidelines recommend /against/ using merges and merge-comments as used with the upstream Linux kernel, for instance. There, if I as an amd64 aka x86_64 user am not interested in say arm commits, they're all sectioned off in big giant merges that I can look for and skip over perhaps hundreds of arm commits once I see that merge is from arm. On gentoo, by contrast, every single arm stabilization commit tends to be its own individual commit to the tree, perhaps pushed as what /would/ be a single merge, but with a recommended rebase, so each one appears individually instead of under a single arm merge with that noted in the merge comment so I can skip them all at once! As a result I have to use a different log tracking strategy on the gentoo git tree compared to to the kernel. Where on the kernel I'll often hit b to go to the bottom and then crawl up the entire update log, checking for merges and drilling down into components I'm interested in, on the kernel I have to do an emerge --update --deep --newuse -ask in one terminal, wait for it to generate its list of updates, then do a git log ORIG_HEAD.. in another terminal, hit b to seek to the bottom and cache it all, hit t to return to the top, and hit / and enter specific package versions I'm interested in to search for. As a result, I don't pick up the general community status information on packages/components I'm not specifically interested in, that I do following the actually far more detailed kernel commit logs, because to keep things manageable I have to search for specific packages of interest instead of being able to exclude entire merge trees with just a high level glance at the main merge comment, where I actually /do/ pick up lots of general status information about kernel subsystems I'm not generally interested in. I guess another way of putting it in the context of changelogs, would be that if gentoo were using git merges correctly, a changelog summary generator could simply take the high-level merge summary comments and turn that into its changelog summary. Instead of ten dozen individual "cat-egory/pkg-x.y.z arm-stable" entries, there'd be one or two "arm- stable various packages in these categories: xxx, yyy, zzz, aaa" entries, and people who don't care about arm could skip the further detail while still getting an overall idea of arm activity, while those who do care about arm and want further information could drill down further as necessary, but would be able to skip the corresponding merge entries for x86 and amd64. With proper git usage, the information would already be there in the git log merge commit comments for people like me who like to read those, but it would also be not only far simpler, but actually /possible/ to automate a summarizer that generates summaries from only those merge entries, that then could be stored in the rsync tree or published to packages.gentoo.org or the gentoo front page, or wherever. -- 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
