Tracker for regressions, improvements and backports

[stefan11111]

Describe the task

We have a lot of regressions (either inherited from Xorg, or from Xlibre) and improvements with issues and pr's open for them.

I'd like for the most important regressions and improvements to all be linked to in one place, so that we can easily keep track of them and not forget any.

I'd also like for us to keep track of what gets fixed in master and what gets fixed in maint, so we don't forget to backport a bugfix from master into maint.

@callmetango @metux @artist4xlibre @b-aaz @HaplessIdiot @jonhermansen @josephcrowell @mikedld @probonopd @steven-vd Thoughts?

It should be done because

.

Additional Information

.

Extra fields

• I have checked the existing issues
• I have read the Contributing Guidelines
• I'd like to work on this issue

[callmetango]

I really like the idea and think it should be discussed at X11Libre 2 Rfcs Of The Core Team · Discussions · GitHub 😉 so I'm moving it there. We can then create issues or other good things once it is refined.

[callmetango]

I'd like for the most important regressions and improvements to all be linked to in one place, so that we can easily keep track of them and not forget any.

I'd also like for us to keep track of what gets fixed in master and what gets fixed in maint, so we don't forget to backport a bugfix from master into maint.

Very good! My idea was to make use of About Projects - GitHub Docs and About milestones - GitHub Docs as already stated in the README.md: add mission statement and many more · X11Libre/xserver@4839966.

Github Projects integrate very well with GitHub Issues documentation - GitHub Docs and fulfills many of the "wishes" you made. In Github Projects it is e.g. possible to link in issues from different repositories so we can get a clear and global picture of what needs to be done where. Adding metadata - About Projects - GitHub Docs is possible as well. The relations of issues to projects and vice versa will be established by Github when assigning issues to projects so it is easily possible to see the context of an issue and to navigate it.

For the first steps my simplest idea was to create a "bug board" of all bugs reported in all of the repositories. This should give a clear focus on what to work on (first). Another one was to create a "feature board" with the prioritization of the feature requests we already received and will receive.

Using the Github Milesstones feature in finer granularity we would able to differentiate what needs to be done next and what is for later. We could create for example a 25.0.0.6 milestone and attach all very high priority bugs to it. So again we know what goes where and when.

Github Projects is really very powerful like one can see here GitHub Project Management - Create GitHub Project Board & Automations 2024 - YouTube and here Learn how to use Project Roadmaps - GitHub Checkout - YouTube.

If there's not too much drama in the project, I'll check out the Github Projects feature this week.

[callmetango]

I'd also like for us to keep track of what gets fixed in master and what gets fixed in maint, so we don't forget to backport a bugfix from master into maint.

Yes, me too! This has to be aligned with our strategy of how to backport and "upmerge" bug fixes from the release branches and possibly master. In https://github.com/orgs/X11Libre/discussions/243#discussioncomment-13882031 I said that I will draft a Git workflow and this is what I begin with this week as well.

The at least two questions to me in this context are:

• Why fix bugs in master first hand and not in the lowest versioned release branch they occured in. So why backporting at all?
• How to "upmerge" these bugfixes to master?

There is also another yet unanswered question of mine in https://github.com/orgs/X11Libre/discussions/243#discussioncomment-13882052. But this will hopefully be answered over there.

[metux]

Maybe it's better to always fix bugs in the oldest maintenance branch (we'll be having more when new releases coming) and then move (rebase) forward step by step ?

[callmetango]

Yes, I would prefer the "fix it in the oldest affected branch/version" way. What do you mean by "rebase"? Wouldn't that be a merge from e.g. release/25.0 to release/25.1 (assuming semantic versioning)?

[stefan11111]

It would also be nice for someone to track upstream commits that apply to Xlibre and list them somewhere.
Or perhaps something automated, so we don't miss improvements from Xorg.

[metux]

not git merge but git rebase.
or in simple cases git cherry-pick

[callmetango]

I played around with the GitHub Projects feature a bit and created an organization-wide project called “Bug Tracking.”. Still private at the moment. After creating it I manually imported all bugs from all relevant repositories into the project and roughly assigned them their respective statuses. Here's what the result looks like:

[callmetango]

There are also many more possibilities. So: What more could one want?

[callmetango]

Oh, did I mention that Github Projects work for pull requests 1 too? So one could plan them. Not that I would recommend to mix bug reports and pull requests, but pull requests could live in their own project if need be. Organization-wide or in their respective repositories. We can also have a project for feature requests to plan them and other projects for other issue types as well. And maybe automated tracking of the X.org Server and XWayland commits could also be possible by listening to push - Events that trigger workflows - GitHub Docs. I'm thinking of automated issue or pull request creation on such events.

[stefan11111]

Is there also a way to set priority?

[callmetango]

For sure!

But I would advise caution here: priorities can quickly become subjective and change within a matter of days. An example: the mouse pointer is distorted. A user would say: fatal. A developer: glitch. Priorities are particularly difficult when new “events” occur and require reprioritization.

My suggestion is that we look together at what we want to use the priorities for. In my experience, bugs can be prioritized very well using severity. See Bug Severity Levels: From High-Impact Showstoppers to Minor Annoyances and Bug Severity: How & Why to Measure + Levels Guide.

It might also be useful to model the effects and then attach them to the bugs in the form of tags. Like say "System crashes", "Log distorted", "Compilation error", ...

Apart from that, the order of the issues in the backlog of the “Bug Fixing” project can be changed and is also always saved, so it remains intact.

[callmetango]

The bug tracking project part was resolved by resolving Create an organization-wide tracker for regressions · Issue #314 · X11Libre/misc. Every bug wrangler can now assign the "Bug Tracking" project to any issue in any XLibre repository as shown in the screenshots above. You can also work directly with the board to change the status, order and contents of the bug reports.

[probonopd]

Right now I find it a bit hard to track which changes are being made for what reason.

Probably that's obvious to the respective developer, but not necessarily to others. I am getting the impression that some changes are just being made "to improve things" without a concrete bug being fixed or feature being implemented. Personally I see such changes as a risk. Sure, they may improve the overall code quality, but they also introduce the risk that something might break. So for me it would be extremely helpful if every pull request/commit would state in the first sentence which concrete bug or feature this solves.

While this is not a direct response to your question, it's an impression I wanted to share in the hope that it may be helpful. If not, then please disregard.

[jonhermansen]

I wholeheartedly agree. X11 covers a lot of use cases, it's a lot of code, and how much variance do you think there is in each setup? The combinatorics are insane. We're talking about:

• Maintaining multiple branches (multiply your testing X the numer of branches)
• Supporting 25? or so X11 drivers (some will probably get less attention)
• Those 25 drivers can interact with any number of kernel versions (with distro-specific patches)
• Some GPUs require proprietary drivers that have their own update cycles
• Potentially thousands of use cases multiplied by all the variables above

We should do our best to reduce the problem space as much as possible. I think we should ruthlessly prioritize what is in the issue tracker. We should clearly define what is supported and not supported. And we should do our best not to overextend ourselves.

Probably a lot of clean up was overdue, but I think it should be gated or phased and done in a controlled manner with a good feedback loop. If we make a lot of big changes and expect users to figure out which one broke their system, it's a bad experience for them. I think we can do much better.

[stefan11111]

I agree we should be more careful about breakages and prioritize fixing issues over code cleanups and new features.

[callmetango]

I wholeheartedly agree. X11 covers a lot of use cases, it's a lot of code, and how much variance do you think there is in each setup? The combinatorics are insane. We're talking about:

Thank you for the analysis, and definitely! However, there is more: the number of platforms that the X.Org server once supported. Brief list: alpha amd64 arm arm64 hppa loong m68k mips ppc ppc64 riscv s390 sparc x86 (source). That will be, um, interesting when it comes to multiplication with the other factors...

[stefan11111]

@callmetango Does your solution also support tracking different issues on different branches, including needed backports?

[callmetango]

The bug fixing Github project: no. But I would suggest to split the "backports" aspect out of this idea into a new one. Not out of contempt, but because I think it's a different level with different priorities.

We currently also talk to the Redot devs about their workflow · Issue #286 · X11Libre/misc.