I don't get a vote here, but I definitely do not like comments like

It works fine within cinnamon, sorry I don't give a damn if it doesn't in gnome.
I don't care if nemo doesn't function in Gnome.
I'm done with your crappy demanding attitude, take it to fesco.

. The best action for you would be probably to get to upstream bugtracker (in order to get a fix).

I personally think that a maintainer has a right to not care about something, yet it is not a reason to 1) close bugs as NOTABUG, 2) be rude.

As for the first thing, currently there is no "rule" that a maintainer needs to be reasonable. It's a common sense thing. I'm not sure what can or should be done on FESCo level about such cases, but IMHO a more collaborative effort in package maintenance should prevent individual maintainers to block things like this.

For this specific case, I'd suggest working with upstream to fix the bug, submitting a PR (or asking somebody to do that for you) and if that doesn't help, ask a proven packager with domain knowledge about the problem to review and push the changes.

For the second part, if you feel that the maintainer went to far, go trough the Code of Conduct and file (a private) Council issue if you feel the need.

Let me just mention that to me the conversation feels very unfriendly from both sides, yet I can empathize with you being told that the maintainer doesn't give a damn. However you attitude really seems a bit demanding.

On the technical side, I think FESCo should assert that the bug should not be closed as NOTABUG. Maintainers should keep their packages compatible with other packages in the distro, as far as reasonable. Gnome is our default desktop, so I expect a bigger effort here, and certainly not closing the issue immediately.

a more collaborative effort in package maintenance should prevent individual maintainers to block things like this.

I don't think a collaborative effort here is the answer. Co-maintainers help when there is too much stuff to do, but here the maintainer refuses to consider the issue at all.

On the technical side, I think FESCo should assert that the bug should not be closed as NOTABUG. Maintainers should keep their packages compatible with other packages in the distro, as far as reasonable. Gnome is our default desktop, so I expect a bigger effort here, and certainly not closing the issue immediately.

I think the point though is that "nemo" in particular is a cinnamon-specific package that is expected only to work for that desktop environment. We have no expectation in Fedora that (for example), KWallet must be a fully-functional replacement for GNOME Keyring if you're running GNOME. Nemo is the same, in my opinion.

I think Leigh absolutely should have communicated this better, but Nemo on GNOME is not a supportable configuration.

a more collaborative effort in package maintenance should prevent individual maintainers to block things like this.

I don't think a collaborative effort here is the answer. Co-maintainers help when there is too much stuff to do, but here the maintainer refuses to consider the issue at all.

Then what are dependencies for?
Then why does it mostly work?
Then what is a user to do when a desktop OS removes the desktop behaviour from the GUI with no real alternative?
This is the workaround until a plugin works well enough to reinstate the desktop display behaviour.
See e.g. https://gitlab.gnome.org/GNOME/nautilus/issues/158#alternative-solution.

Then what are dependencies for?
This question doesn't seem relevant.

Then why does it mostly work?
Mostly by luck, because Nemo happens to be a fork from a very old version of nautilus for GNOME.

Then what is a user to do when a desktop OS removes the desktop behaviour from the GUI with no real alternative?

Have a discussion with the upstream for that project and explain your concerns to the people with the ability to do something about it. Express yourself in a positive way, such as "I have this use-case: [description] and a recent change meant that I can't do this anymore. Can you restore this functionality or help me figure out a new way to accomplish my task?"

Running to FESCo and demanding that we order around our contributors is counter-productive.

This is the workaround until a plugin works well enough to reinstate the desktop display behaviour.
See e.g. https://gitlab.gnome.org/GNOME/nautilus/issues/158#alternative-solution.

What you are citing is someone's blog who asserted that a year ago, Nemo happened to be capable of doing what you are asking for. It was not by any stretch of the imagination a supported response from the GNOME developers.

The supported (and supportable) solution is to use the GNOME extension at https://extensions.gnome.org/extension/1465/desktop-icons/ for this. Which, I note, was mentioned in the issue you linked to.

Proposal: close this ticket as there isn't any proposal for FESCo to act upon.

Again Fesco is inclined to do nothing.
The proposed extension is not very stable if you read the responses at https://extensions.gnome.org/extension/1465/desktop-icons/.
The stuff at https://gitlab.gnome.org/GNOME/nautilus/issues/158#alternative-solution does not appear as a blog as it deals with individual gnome issues. Not a per date story about whatever in someones life.

Comments about the shape of things in my communication are the cheapest escape there is:
I do not claim to be able to write perfect english, so the subtleties that you might expect might not be present in my output.
Please be so professional and try to discern the core issue.

We see at least three different situations:
One where support for a certain package is claimed to be given yet nothing really happens. (see my former frontpage and the history of that if that is still to be found)
One where support for a certain package is claimed not to be given and nothing really happens except deprecation. (network-scripts)
One where support for a certain package is claimed to be given yet nothing really happens due to the feelings (!) of the support person. (nemo)

The latter case is due to a graphical desktop environment dropping support for displaying the desktop items (!) without first providing a viable alternative.
So now we know that the nemo workaround works but has at least one issue, root cause unknown.
The extension solution has more than one issue, root causes to be fixed.
So what is a user to do if there is no actual product and no actual support?

If you want support you can buy some product with support. You cannot really demand support for Fedora packages, as Fedora is created and maintained by volunteers.

Why then is a perceived lack of support reason to deprecate a package?
The perceived lack can be caused by lack of support personnel but also due to inactivity of support personnel.

I n this case I do perceive a lack of support for a solution advertised upstream so I'd say: deprecate the package! That will learn them!

I did not demand support I merely pointed out weird behaviour of a set of packages that should satisfy a valid environment for nemo. Said support person did not investigate at all but solely on whatever reason refused to do anything, even refused to explain why they did not explain their graphical environment would be better.
If all this is accepted, why then balk at a package without support?

So, the end goal you have here is to have icons on your desktop, right?

The default Fedora Workstation doesn't 'support' this anymore, and is not likely to.
So, you used a workaround with nemo as filemanager, but this has stopped working.
It would be very difficult to support a component like nemo that was written to work in a specific desktop in all other desktops for something as difficult as managing your desktop icons, so I don't blame the maintainer there, although I agree with everyone else that he should have been able to communicate this in a better way.

Some other ideas to reach your goal:

• Try gnome-classic ? This is gnome 3, but using extensions to behave more like older gnome. I think it uses an extension to show icons on the desktop.
• Try Xfce? There's a pref in xfdesktop to show icons on the desktop.
• File a upstream bug or talk to upstream nemo developers and convince them your use case is something they should support.
• As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1662302#c5 try using nemo but disabling the 'Organize desktop by name'

In any case I don't think there is anything FESCo can do for you here.

Nemo did not stop working. It simply has a 'small' issue that support does want to look at.
I.e.: I get no support.
In such case I say 'deprecate' as Fesco does with networking-scripts in case of no support.
Same for gnome-shell (I get no support) and many others.

Why change the whole gui thing when a simple feature is fumbled with?
A graphical desktop environment shows a desktop-like screen. look at competing products.
For Gnome dropping this without providing a real (working, supported, blessed, etc) alternative is bad acting.
It is very uncarefull.
Gnome simply acts like years ago: gvfs features are way more important than egtting basic GUI features working right.
I.e.: they do not understand proper priorities.
They do not understand that life is not always fun and games.

And if Fesco cannot even signal about that, then what?
All is routed back to the user, not to a bigger entity.

On Fri, 2019-01-11 at 05:55 +0000, Udo van den Heuvel wrote:

Nemo did not stop working. It simply has a 'small' issue that
support does want to look at.
I.e.: I get no support.

Support is a bit of a loaded term. The way you are using the term
implies that you expect people to do work at your direction. If you
want that kind of support, you should use a paid distribution with a
contract. Fedora is maintained by a community of volunteers, and the
only things that are "supported" are the things those volunteers choose
to spend their time on.

Interpretation is a personal thing.
What I mean by support is that after filing the bug with a reasonable amount of info someone shows interest in the bug and asks for additional logs/output/etc within a reasonable time.
Yes, I know it is al volunteer etc, but what is the point of 'having' support if it does not perform even close to actually bringing the experience of being supported to the user?
I did not state any term for a solution or even finding a root cause.

See my bug history and see how many bugs passed without any support reply within say six months (yes, they got married, went on a looong honeymoon and is now encumbered by divorce proceedings, I can understand that) which looks very reasonable to me.
That would say enough about deprecating or deciding to keep the package but without support.
(wiser as fairly core packages suffer from this)

Attitude, support, freedom of choice, etc can be found in this bug https://bugzilla.redhat.com/show_bug.cgi?id=1379070

I say: deprecate as we do not see support, not even a workaround.
The situation is at odds with https://pagure.io/packaging-committee/pull-request/844, perhaps the original text even.

Manually moving the items mentioned to their locations causes very similar behaviour later on.
Also we see double/single size (4K-related) issue. Small icons, bigger icons depending on when one looks. (different issue, but where? xorg shows a small arrow cursor at first but once one logs in the cursor doubles in size as intended)

All fesco terms (' Support is a bit of a loaded term.') were about the shape.
Not so much about the actual content ( 'help') kind of things.
The fedora person associated with the bug did not provide any help, not even towards his own taste of GUI when asked about that.
In such case, when supposed helper is not even able to be enthusiastic about the native gui that their tools are from then I see that person as unfit for their supposed task.
To close an issue about such situation as 'invalid' means that something else is invalid/unfit/etc.

Same issue is for the bug at https://bugzilla.redhat.com/show_bug.cgi?id=1379070
Extremely basic guidelines for developers lack.
Support then lacks.
Support about support then lacks.
Then what is a user to think after these happenings?
That all that happens is by accident and that there's no positive influence possible via these channels?

See the comments for the PR at https://pagure.io/packaging-committee/pull-request/844.