I hope you can help me better understand the flow of changelogs.
Today we have again a small update for manjaro and it is a single package:
hopefull I ran pacman -Qc powerdevil to get the changelog. But as so often it did not show any.
So first question: Is there a general way to get to the changelog? Or is this an individual hunt for each package? I would even be willing to consider a code diff a changelog in this case.
Second question: If this is not possible. Which I fear is the case.
How is the process. Where does the change log get lost. I assume that there always is one initially set by the developers. I don’t want to play the blame game. I want to know if maybe I can put some effort into developing a tool to automate getting this. I think this would be a worthwhile improvement.
I am still relatively new to Linux so my understanding of the workings behind the curtain is still very limited.
No doubt. I installed right away. This is also not about being “selective” as I don’t think it is wise to leave the default path more than absolutely necessary under Linux.
It is about being curious what cool features I got, or which quirks might finally be gone.
Thank you for the link. It shows that there is a change log, as I assumed. So normally I would expect
pacman -Qc powerdevil to return at least
“Fix crash (FS#61926)”
running pacman -Qc returns a changelog for only 1 in a hundred packages. So obviously this feature is not really delt with at all. Can’t this be automated somehow, to get the changelogs, when providing the updates?
I love reading changelogs and I wish I could have a list of them to read before any major update. I know 98% of users don’t care about them (I even hear some users actually update without looking at the package list ).
Maybe someone will come up with something that generates a easy readable changelog for all packages (1 or 100) marked for update.
I found out about the change by reading @sueridgepipe’s post in the Plasma discussion thread. I didn’t know it was even broken because I’d not noticed it fail on either of my systems, both of which have batteries to monitor. One a notebook and the other has a UPS hooked up to the USB port.
You do realise Manjaro is not a commercially backed distribution with paid employees developing and supporting it?
The Manjaro folk can be counted on fingers and do any work in their freetime as most are still in full-time employment or have other real life commitments. It started out as a hobby and quite frankly is still technically albeit done to an exceptionally high standard.
If you or anyone else with the coding skills can help out and develop an automated way to achieve such collation it would be fantastic and much appreciated I am sure. I’m too rusty these days to even go there myself, I haven’t had the time to keep up with language developments either. Rust (the language) is something that interests me though. My last really active days were in the late 90s to early 00s when I didn’t have a Wife and kids to look out for. These days I am dealing mainly with hardware and network infrastructure on a day-to-day basis. I sub-contract a lot of coding and software support work as their aren’t enough hours in the day and I prefer the building and testing work.
Ofc, and I would never expect a manual solution. Else I would have requested a changelog like this:
Yes, I am a developer and also wrote countless automation scripts in bash nowadays. And would offer my assistance if this is feasible/wanted. But as I said, I have no idea of the process a maintainer has to go through yet.
I guess most, if not all packages are maintained in one of the major VCS like CVS, svn or git.
So it should be feasible to automate a generic changelog from the commit messages. While certainly not perfect, better than nothing. Ofc if the package is not in version control it will still have no change log. Or if the commit messages are empty/cryptic, it will not help much. But GIT changed the playing field somewhat. With its twitter like one line summary encouragement per commit as well as its staging mechanism that makes it easy to commit in small dosages of descriptive changes. Commit histories have become far more reflective of a real change log.
Also if this would be implemented, one could also somewhat better judge the quality of a project/package by seing if such a commit log is available/clean or not.