[gentoo-dev] Re: Bug #565566: Why is it still not fixed?

[Duncan]

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