conflicts and losses with community upstream

[apprehensions]

These following packages exist in kiss community upstream, but do not depend on X, which brings no reason to belong here as well:

• libslirp
• tiff

These following packages do not exist in kiss community upstream, but do not depend on X, which brings no reason to belong here, and should belong in community:

• babl
• bdfedit
• cgal
• coin
• doxygen
• dragon-git
• eigen
• emacs-git
• exiv2
• farbfeld
• fmt
• fontforge
• gegl
• gexiv2
• gftp
• glew
• glfw
• glib-networking
• glmark2
• glu
• gnumeric
• gnuplot
• gobject-introspection
• goffice
• graphene
• gst-plugins-base
• gstreamer
• gtk-gnutella
• harfbuzz-icu
• jsoncpp
• kicad
• libfixposix
• libgsf
• libmedc
• libmypaint
• libnghttp2
• libnotify
• librsvg
• libsass
• libsecret
• libsigc++
• libsoup
• libsoup3
• libspectre
• libtorrent-rasterbar
• luakit
• lxappearance
• mypaint-brushes
• neon
• netcdf
• netsurf-gtk3
• nsxiv
• nyxt
• openal-soft
• opencascade
• opencsg
• otf2bdf
• perl-netsurf
• qbittorrent
• qpwgraph
• qscintilla-qt5
• qt5-multimedia
• qt5-x11extras
• qt5-xmlpatterns
• raylib
• sasm
• sassc
• scons
• shared-mime-info
• shiboken2-pyside2
• slop
• solvespace
• spice-protocol
• srain
• stalonetray
• stumpwm
• surf
• swig
• sylpheed
• tcl
• tiramisu
• tkdiff
• vimb-git
• vimb
• vtk
• winetricks
• wv
• wyeb
• xerces-c
• yaml-cpp
• ymuse
• zircon

The reason i am making this issue is to make the segregation between kiss-xorg community and kiss community smaller, there is no good reason to have kiss-xorg users exclusively have these packages other than maintainership.

while some of the packages listed above may or may not be related to X, some of them still belong in kiss community.

[echawk]

I personally have no interest in maintaining them in upstream community, because it will become a much bigger maintenance burden on myself (not being able to use esources, having to submit patches via irc, etc). If you would like to come back to this issue and ask for things to be dropped as other community members push those packages up to community, I'd be happy to point them that way. Otherwise, this is WONTFIX.

[apprehensions]

I will see if i can take the time to move some of these to community if possible, for example: raylib and farbfeld.

Some packages will have to be dropped, such as tiff and libslirp, while others such as libnotify have to be dropped too because they're used in dbus applications, which can be put in the kiss-dbus repository.

[apprehensions]

Just to mention, i think it would be a great idea for you, as the maintainer for these packages, to simply drop ones that you only maintain just to maintain it. Upstream KISS will drop packages in which they no longer have interest, such as a loss of a maintainer. I understand that you wish to maintain these yourself, but i think it would be better overall to provide what you need, and let others maintain what they need as well.

[apprehensions]

Any response on that previous comment?

[apprehensions]

Looking at this again, i still see no reason for kiss-xorg to serve as a personal repository. This repository is for Xorg packages and it's overrides, not for having packages that aren't specific to X (such as glu, which i can benefit from greatly)

Please make a change.

You are already going through the effort of updating these packages. Just drop the packages that you don't use, and let others maintain the packages they need.

[echawk]

Please make a change.

I've already stated my stance on this - if YOU (or others) want to go through the work of upstreaming them to community, then please, be my guest, and I will happily drop them from this repo. Unfortunately, there has been a lot of talk, and not a lot of walk.

[apprehensions]

Your analogy is correct, but in the end you are still choosing to maintain these packages, regardless if any packages use them, or depend on X. what I've been trying to ask is for a personal purge of packages that are unused, and that you don't use.

[nakoeppen]

I think it's useful to have access to the packages in this repo, and I think it's ridiculous to just delete these because they are 'supposed' to be on upstream community.

In any event, I am sure echawk would love to make the time to move these over to community if it means that much to you. Just pay the poor guy for his time (or do it yourself, as he suggested).

[apprehensions]

It doesn't make any sense to have them here if the maintainer isnt upstreaming them, why else is it here in the first place? Why have a package that has nothing to do with X in a repository made for supporting X? Why maintain these packages in the first place?

[nakoeppen]

At the end of the day, echawk is volunteering his time to maintain these packages. Why he works on them, I do not know. However, he has ported over packages for KISS (likely, for the large majority of them, done so for his own use) and graciously shared his solutions on a GitHub repository for others to benefit from. I seriously do not see any point in being nit-picky on how a repository that is not directly sponsored by KISS is ran.

Furthermore, I do not see any reason why perfectly functioning packages need to be wiped off the Earth and all that work be re-done by some other maintainer, simply because echawk does not have the time to go through the process to get them properly verified for the upstream community repo. I am sure if someone else wanted to carry the torch, echawk would pass it on (as he has implied above). I encourage you to be that person if echawk can't, if this bothers you to this extent. For what it is worth, I agree its place should be in the upstream community repo. It just depends on who can and who cares enough to put them there.

[apprehensions]

This makes a lot of sense, but doesn't quite answer one of my questions: why is he putting random libraries in a repository for X that aren't for X? If you said that they are for his own use, then they belong in his own repository. The fact is that he is sharing them for others to use, but in the wrong place.

Only just now I realized I have no position to start nitpicking and demanding these things, because ultimately it is not my repository, but I would have like to seen it be simpler.

Maintaining hundreds of packages seems to be easy for him but why would he maintain these packages if he isnt the one using them? For example chromium was ruthlessly dropped in community due to communication issues by ioraff, since he hadn't gone to anyone who he knows is actively using the package, such as myself who made a PR.

If anything, anyone can simply revert the commit of dropping a package, and start adopting it.

I have his repository cloned myself and find myself using some or maybe forking his packages onto my repository.