What does he mean there ? Is this problem fixed or not ? Is tasks-list dropped ? That kind of answer do not help understanding and sharing. If it’s dropped just say it. If it’s still broken just say it, that happens.
I hope you guys who « develop » things around UbuntuBudgie have better and more constructive conversations with the upstream team.
That problem still exists by the way in 20.04, just put any applet « too big » on left or center of panel, it will push other applets out on the right… ( it’s easy to trigger this behavior with pixel-saver and number of letters for title ).
Well sorry for bitterness here, I don’t expect any profound answer here, I just hope things get better with time for all.
I share your thoughts here - either keep & fix or drop. In this case its “fixed in budgie 11”. So fair enough.
At the end of the day end users (I’m an end user as well remember!) need to understand what is meant by “upstream” - what they do and how they conduct matters.
The TL;DR; - I’ll be blunt here - your rights are to use the software … and that’s it. What you are doing when raising issues is looking to improve software.
An “upstream” is a project that maintains and develops a piece of software/hardware/both. Any linux distro is the combined efforts of hundreds & thousands of upstream projects - both big and small.
Each upstream has its own way of doing things - thats the most frustrating part of reporting issues. In general you’ll find most projects has its own target distro & distro-version that they develop with and target.
Users do have an obligation here when dealing with upstreams - to do as much research into an issue as they can - making sure its reproducible on at least the projects target distro - sometimes looking at the very latest version of software. That can mean compiling software themselves - that can be quite hard for most users who consume software by just what their preferred distro provides.
The reason for the obligation is simple - maintainers have a finite amount of time. It is very frustrating for maintainers who see issues raised when they know its been fixed … but the distro doesn’t carry that software update.
Every project has its own way of dealing with issues raised. Most again deal with issues as a “work order” - evaluating what is needed to do and often (if its a team) discussing openly how to implement.
As such - github/gitlab issues are NOT for “that affects me to” or “what about if you do this” or “has it been done yet” type comments. You have the option to subscribe to an issue - but that’s mostly all the rights you have as an end-user.
The TL;DR; this is why I personally always advise for end-users to come here to discuss first. Your first port-of-call should never be an upstream project.
This is called triaging. You’ll notice most of the time I will say for non-budgie related stuff either “can you test this version/distro version” and/or
This is needed so that the maintainers on launchpad are aware of your issue. Many projects though do not have dedicated launchpad maintainers - at this point the advice will be to raise to upstream projects.
Once you are potentially in the realms of upstream queries that’s where the effort on your side ramps up before you hit the “create and submit” buttons.
With that bit of essay - please do not feel downhearted etc. At the end of the day we all want to see improvements. There are many ways to improve matters. The simplest is raising issue - you won’t be surprised that many issues are never raised - people grumble but never to the right location/people