You can find existing repositories and bugs/feature requests without an account. In order to file new bugs or comment, you will need an account and that requires manual intervention by a moderator due to earlier spam problems on that site.
Knowing what is included in an update depends on the level you are interested in. If you use the PureOS store for your updates, tapping on the listed update will show some information about included updates. You could instead use something like "apt changelog " to see change logs. Those are both pretty dependent on the developer including the changes, I think. If you find the repository for the package in which you are interested, you might be able to find the commits included in the release but I’ve sometimes found associating a package version in a package manager with a commit/branch/tag in a repository to be… hit-or-miss.
There is also a staging area for packages in PureOS that you can monitor, but I can’t remember how to get to that right now.
Not sure what that invocation was supposed to achieve. apt changelog linux-image-6.2.0-1-librem5 works fine. All packages contain changelog entries, and they’re being managed in git repositories with their own commit histories. Everything’s out there in the open, you can even build any kind of “nice chronological overview” you wish for by yourself.
Go to the issue page in the corresponding software repository and click New issue in the top right corner of the page. This will take you to a form you can fill out and submit. You enter a subject and a description, and may also be able to tag the issue with certain flags like Bug, UI, etc.
Sometimes Purism developers say outright within these forums what they are actively working on. If you want a more direct view of what contributions are being made at a low-level, you can view the commits that are being performed within each repository. Here are the most recent commits for the calls app, for example.
For a higher-level view that is still within GitLab, view the project milestone page. This project management tool takes extra resources to prepare and isn’t populated within most projects I’ve seen, so please don’t assume one exists. Here are the milestones of the calls app as a basic example.
One common way to suggest a new feature is found in the issue page of each corresponding software repository. First, search to check if anyone else has already made the suggestion, including the closed issues, in case the change was previously rejected. If nothing is found, create a new issue. It is common to find feature request issues with a title such as “Feature Request: feature summary” and/or tagging the issue with e.g. a Feature Request tag, if one exists.
My answer here will be more generic than just a “previous os update” as I feel that topic has been covered by others in this thread.
Release notes are extremely handy to publish, but they are often arduous and time-intensive to create. For these reasons, they are only occasionally found in the wild and typically only on larger, higher-visibility projects or projects for which there are external stakeholders that want to see value-add reports at a glance.
Release notes are often sent to stakeholders directly but, on many open-source projects, they may be listed along with project releases or in the form of a blog post. See the release notes for the calls app for an example of how release notes may be published in conjunction with a formal software release.
This depends greatly on the many unknowns of humans in the loop of the software development cycle. If a project has an exceptionally mature and transparent product release structure and detailed/curated issue tracking, you may find a group of issues staged with a particular issue tag that would indicate that the issue is triaged or undergoing active development. Progression of milestones may also provide an indicator but, again, the mileage will vary between projects, products, developers, and companies.
My personal experience has shown that most teams/developers do not spend the extra time necessary to organize a project so thoroughly, and you’d have to ask them directly through GitLab, forums, IRC, etc, to know what is coming up next. Here is the Mastodon public roadmap as an example of what it looks like for a project to be very forthcoming about upcoming features and product considerations.
Yeah nah. That just means that the top (of the tree) page was modified 9 months ago. Individual pages have been modified much more recently. For instance, you can see that I updated the Tested Accessories 6 days ago, and Tips & Tricks was updated 3 weeks ago. However those pages are maintained by the community i.e. are not official documentation anyway.
I dare say that the official documentation may be a bit sparse. I think the perspective from many has been that effort should be being put towards fixing problems, not documenting them, documenting their fixing, or improving the documentation. However you and many others might disagree.
when we will have v4l2 working with ffmpeg in pureOS?
can you provide a roadmap about what comes next?
a release calendar what was fixed and what will be fixed in-upcoming releases?!
(without git or console gymnastic, a simple list,pls)
up-to pureOS11 pls!
pls file a feature request for me to get video for linux with ffmpeg!