[opensuse-factory] Compilation of summarized Group arguments/statements and timeline
MAY OF 2018. [1.0] TC: too strict requirements on group JE: let's give ourselves some time to come up with better options [1.0] TC: only yast and rpm display the group value, let's remove it JE: there are other programs that can display or use it in some fashion [1.0] TC: it does not really make sense to install packages based groups JE: the Group field's purpose is not for installation, but browsing [1.3] WR: annoyed by wrong or inconsistent groups. JE: I'm on it, fixing it. (To date, around 350 edits could be found from my side alone to that end. In other cases, no edit was needed, or the package has not yet crossed my field of sight.) [1.4] WR: trying to figure out the single-category group is hard. (JE: agreement; go for tags) [1.5] MC: recurring packager questions like "What is the Group field for?", "which to choose?" (JE: agreement; go for tags, that seems to work out well for freshcode.club and stackexchange.com) [1.6] MC: (basically Fedora failed to get a grip on Groups, so the world should remove it) (JE: openSUSE has a grip, so "keep" and/or do tags) CONCLUSION OF MAY 2018. Supporters of having some value for "Group": Jan Engelhardt [1.3] "The grouping made yast something of a "Things to Explore" guide to the packages it had." Scott Bahling @SUSE [1.9] "I'm using the rpm Group tag as a way to index software in Package Hub" Wolfgang Rosenauer @SUSE [1.4] "I use the group index to find software I might be interested in." Adam Majer @SUSE [1.7] "Debian has been using package tags[1] for a number of years in addition to groups." Stefan Behlert @SUSE [1.8] "I personally like the groups. They give you a good hint what a package is for." Opponents of "Group": Tomas Chvatal. Apart from the initial message, has not made any reply in that thread to the counter arguments (maybe they were too convincing). Matěj Cepl Michal Kubecek The supporters have made their case and commitment to work it. Technically, being a meritocracy, this decided that the Group tag is to stay for the time being, and be enhanced as we go. JUNE OF 2019. [2.0] IG: Fedora guy here, I missed the previous discussion on groups, so I am proposing the removal again. JE: Link to the previous discussion. [2.1] NG: "I'm actually not a fan of the fact Fedora doesn't use the Group tag. ... I'd rather re-introduce a better formulated Group tag" [2.2] TC: "We are already in process of abandoning it." -> in violation of the May resolution [2.3] TK: single-value group is useless currently -> the idea of tags is just floating [2.3] TK: "many Group entries are wrong, useless or something similar" JE: "Most Group entries are actually right", I'm doing the dang reviews where all the spec files pass my eagle eyes. CONCLUSION OF JUNE 2019. (New) supporters of having some value for "Group": Neil Gompa (New) opponents: Maurizio Galli (MauG) AUGUST 2019. [3.0] TC: "As there was no major pushback", ignores the May result, ignores the June discussion even after being pointed to previous threads. [3.1] TC: "Your lonely complain is not a major pushback..." JE: This overview is proof of the contrary. [3.2] SK: "should eliminate *the need* to have a group line." JE: agreement [3.3] HPJ: "OTOH, I cannot see a good reason to *actively* *eliminate* the Group line" [3.4] BV: Concern that removing Group is extra work. CONCLUSION OF AUGUST 2019. * new .spec files can come without a group line; groups/tags can be added later by those who care * keep Group lines * A tag browser software is on display to showcase that even the old groups _work reasonably well_ as tags for the purpose of software browsing and discovery. * rpmlint was amended in late September not to warn on wrong group lines anymore * Group: can thus be freeform, allowing for a tag system (whitespace-separated words) (New) supporters of having some value for "Group": Hans-Peter Jansen OCTOBER 2019. [] Opponents: maintainers are gods over their own packages [4.0] JE: I'm trying to run a distro-wide endeavor here, there should be limits as to what maintainers can and cannot oppose. [4.2] TK: repeats his prior statement that groups are useless JE: repeats his prior statement that they are in good shape [4.3] TK: wiki has not corresponded to what the tooling does [4.4] JE: disproves TK and explains the circumstances [4.5] HPJ gets annoyed by Opponents' removal of Group lines in his package. OVERALL. Opponents start killing off Group tag even though that goes directly against the goal of the Group/Tags subproject and its Supporters. Bad. Opponents claim "it was decided", but this decision was at best unilateral and there is anything _but_ consensus about the removal. In doing so, they also overstep other maintainers [SR 738421]. Very bad. The wiki has a strange position in all this. Many regard it as an authoritative manual, but only where it is convenient and matches practice. Right now it says "Group: only package groups listed in the package group guidelines should be used." [5.0] and "New groups can be created by just starting to make use of them in .spec files." [5.1], so I will hold it to that. MAIL REFERENCES (webview). [1.0] https://lists.opensuse.org/opensuse-factory/2018-05/msg00460.html [1.3] https://lists.opensuse.org/opensuse-factory/2018-05/msg00507.html [1.4] https://lists.opensuse.org/opensuse-factory/2018-05/msg00511.html [1.5] https://lists.opensuse.org/opensuse-factory/2018-05/msg00517.html [1.6] https://lists.opensuse.org/opensuse-factory/2018-05/msg00517.html [1.7] https://lists.opensuse.org/opensuse-factory/2018-06/msg00004.html [1.8] https://lists.opensuse.org/opensuse-factory/2018-06/msg00131.html [1.9] https://lists.opensuse.org/opensuse-factory/2018-05/msg00503.html [2.0] https://lists.opensuse.org/opensuse-factory/2019-06/msg00054.html [2.1] https://lists.opensuse.org/opensuse-factory/2019-06/msg00056.html [2.2] https://lists.opensuse.org/opensuse-factory/2019-06/msg00058.html [2.3] https://lists.opensuse.org/opensuse-factory/2019-06/msg00059.html [3.0] https://lists.opensuse.org/opensuse-factory/2019-08/msg00253.html [3.1] https://lists.opensuse.org/opensuse-factory/2019-08/msg00257.html [3.2] https://lists.opensuse.org/opensuse-factory/2019-08/msg00262.html [3.3] https://lists.opensuse.org/opensuse-factory/2019-08/msg00268.html [3.4] https://lists.opensuse.org/opensuse-factory/2019-09/msg00034.html [4.0] https://lists.opensuse.org/opensuse-factory/2019-10/msg00039.html [4.2] https://lists.opensuse.org/opensuse-factory/2019-10/msg00046.html [4.3] https://lists.opensuse.org/opensuse-factory/2019-10/msg00048.html [4.4] https://lists.opensuse.org/opensuse-factory/2019-10/msg00051.html [5.0] https://en.opensuse.org/openSUSE:Specfile_guidelines [5.1] https://en.opensuse.org/openSUSE:Package_group_guidelines -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-10-16 21:56, Jan Engelhardt wrote:
OVERALL.
great summary, thanks.
Opponents start killing off Group tag even though that goes directly against the goal of the Group/Tags subproject and its Supporters. Bad.
Opponents claim "it was decided", but this decision was at best unilateral and there is anything _but_ consensus about the removal. In doing so, they also overstep other maintainers [SR 738421]. Very bad.
Although I'm far away from the center of decisions in the openSUSE project, I also have the gut feeling that a) this topic has not been discussed until the end, and b) no agreed decision has ever been made (or published). So maybe some of us all have already started with the seemingly easy and tempting task to remove the Group tags - I for myself almost fell in that same mood/trap (but refrained from sending a SR because I wanted to wait for the "official decision", and then removed my branches again). I personally like Groups. For sure, re-assigning some packages to other Groups may be necessary now and also in future - still I see it's the best categorization we currently have. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/17/19 6:26 AM, Jan Engelhardt wrote:
MAY OF 2018.
[1.0] TC: too strict requirements on group JE: let's give ourselves some time to come up with better options
[1.0] TC: only yast and rpm display the group value, let's remove it JE: there are other programs that can display or use it in some fashion
[1.0] TC: it does not really make sense to install packages based groups JE: the Group field's purpose is not for installation, but browsing
[1.3] WR: annoyed by wrong or inconsistent groups. JE: I'm on it, fixing it. (To date, around 350 edits could be found from my side alone to that end. In other cases, no edit was needed, or the package has not yet crossed my field of sight.)
[1.4] WR: trying to figure out the single-category group is hard. (JE: agreement; go for tags)
[1.5] MC: recurring packager questions like "What is the Group field for?", "which to choose?" (JE: agreement; go for tags, that seems to work out well for freshcode.club and stackexchange.com)
[1.6] MC: (basically Fedora failed to get a grip on Groups, so the world should remove it) (JE: openSUSE has a grip, so "keep" and/or do tags)
CONCLUSION OF MAY 2018.
Supporters of having some value for "Group":
Jan Engelhardt [1.3] "The grouping made yast something of a "Things to Explore" guide to the packages it had." Scott Bahling @SUSE [1.9] "I'm using the rpm Group tag as a way to index software in Package Hub" Wolfgang Rosenauer @SUSE [1.4] "I use the group index to find software I might be interested in." Adam Majer @SUSE
It should be pointed out that before the removal became possible both yast and packagehub have been migrated to use alternate mechanisms so i'm not sure how much weight these arguments have. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2019-10-17 01:03, Simon Lees wrote:
[1.3] "The grouping made yast something of a "Things to Explore" guide to the packages it had." [1.9] "I'm using the rpm Group tag as a way to index software in Package Hub" [1.4] "I use the group index to find software I might be interested in."
It should be pointed out that before the removal became possible both yast and packagehub have been migrated to use alternate mechanisms so i'm not sure how much weight these arguments have.
It should also be pointed out that * I believe yast does not use any "alternate mechanism", because the browse-by-group feature was killed off there. * packagehub looks like a SLE-specific thing, meaning the SLE guys sometimes do things different, but me I am interested in the openSUSE ways. * Coincidentally, packagehub uses the same approach as rpm-catalog for turning classic groups into tags. * Moreover, packagehub also has a "Unspecified" category with already 16 packages in it. This strongly suggests it also relies on the RPM Group line. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/17/19 10:25 AM, Jan Engelhardt wrote:
On Thursday 2019-10-17 01:03, Simon Lees wrote:
[1.3] "The grouping made yast something of a "Things to Explore" guide to the packages it had." [1.9] "I'm using the rpm Group tag as a way to index software in Package Hub" [1.4] "I use the group index to find software I might be interested in."
It should be pointed out that before the removal became possible both yast and packagehub have been migrated to use alternate mechanisms so i'm not sure how much weight these arguments have.
It should also be pointed out that
* I believe yast does not use any "alternate mechanism", because the browse-by-group feature was killed off there.
It still has a "Package-Group" view that is doing something atleast on my tumbleweed install maybe that's a bug.
* packagehub looks like a SLE-specific thing, meaning the SLE guys sometimes do things different, but me I am interested in the openSUSE ways.
* Coincidentally, packagehub uses the same approach as rpm-catalog for turning classic groups into tags.
* Moreover, packagehub also has a "Unspecified" category with already 16 packages in it. This strongly suggests it also relies on the RPM Group line.
Either way those that want to see groups removed have been working with the yast and package hub teams to do so -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/17/19 6:26 AM, Jan Engelhardt wrote:
MAY OF 2018.
[4.0] JE: I'm trying to run a distro-wide endeavor here, there should be limits as to what maintainers can and cannot oppose.
This wasn't the way you worded it in your original email. If this is what your thinking it seems you are trying to run a "distro-wide endeavor" without the buy in of most of the distro. It seems while some other people think "tags" might be useful, No one else agrees that the current system is useful, the fact that the info has been removed from openSUSE's tools, maybe the only place the current groups could be really useful is to convert to a new "tag" system if there comes to a consensus on that. If you would like to work on this as a distro wide project then you really need consensus from a significant part of the distro. Part of this would be proposing what the tags would look like so that we can as a community decide they are useful and have the right level of granularity right now I have no idea what your tag system would look like so I have no idea if I think it would be useful and would support it. Maybe a wiki page with a proposal of tags would be a good starting point here. I think you also need to get buy in from the Yast team, Yast is openSUSE's package manager and if it is never going to support using tags in a meaningful way then personally I don't really see a whole lot of point in maintaining them.
OVERALL.
Opponents start killing off Group tag even though that goes directly against the goal of the Group/Tags subproject and its Supporters. Bad.
Opponents claim "it was decided", but this decision was at best unilateral and there is anything _but_ consensus about the removal. In doing so, they also overstep other maintainers [SR 738421]. Very bad.
The wiki has a strange position in all this. Many regard it as an authoritative manual, but only where it is convenient and matches practice. It is not that uncommon for parts of the wiki to end up out of date
until someone realises and updates it. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Simon Lees
On 10/17/19 10:25 AM, Jan Engelhardt wrote:
On Thursday 2019-10-17 01:03, Simon Lees wrote:
[1.3] "The grouping made yast something of a "Things to Explore" guide to the packages it had." [1.9] "I'm using the rpm Group tag as a way to index software in Package Hub" [1.4] "I use the group index to find software I might be interested in."
It should be pointed out that before the removal became possible both yast and packagehub have been migrated to use alternate mechanisms so i'm not sure how much weight these arguments have.
It should also be pointed out that
* I believe yast does not use any "alternate mechanism", because the browse-by-group feature was killed off there.
It still has a "Package-Group" view that is doing something atleast on my tumbleweed install maybe that's a bug.
* packagehub looks like a SLE-specific thing, meaning the SLE guys sometimes do things different, but me I am interested in the openSUSE ways.
* Coincidentally, packagehub uses the same approach as rpm-catalog for turning classic groups into tags.
* Moreover, packagehub also has a "Unspecified" category with already 16 packages in it. This strongly suggests it also relies on the RPM Group line.
Either way those that want to see groups removed have been working with the yast and package hub teams to do so
so they took it upon themselves to invoke a unilateral action. somehow that flies in the face of a cooperative effort. have we been taken over, a coup perhaps. maybe a solution to leadership by committee. continuation down this path will definitely solve the problem of selecting a name for the coming (or not) foundation. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/17/19 1:04 PM, Patrick Shanahan wrote:
* Simon Lees
[10-16-19 20:03]: On 10/17/19 10:25 AM, Jan Engelhardt wrote:
On Thursday 2019-10-17 01:03, Simon Lees wrote:
[1.3] "The grouping made yast something of a "Things to Explore" guide to the packages it had." [1.9] "I'm using the rpm Group tag as a way to index software in Package Hub" [1.4] "I use the group index to find software I might be interested in."
It should be pointed out that before the removal became possible both yast and packagehub have been migrated to use alternate mechanisms so i'm not sure how much weight these arguments have.
It should also be pointed out that
* I believe yast does not use any "alternate mechanism", because the browse-by-group feature was killed off there.
It still has a "Package-Group" view that is doing something atleast on my tumbleweed install maybe that's a bug.
* packagehub looks like a SLE-specific thing, meaning the SLE guys sometimes do things different, but me I am interested in the openSUSE ways.
* Coincidentally, packagehub uses the same approach as rpm-catalog for turning classic groups into tags.
* Moreover, packagehub also has a "Unspecified" category with already 16 packages in it. This strongly suggests it also relies on the RPM Group line.
Either way those that want to see groups removed have been working with the yast and package hub teams to do so
so they took it upon themselves to invoke a unilateral action. somehow that flies in the face of a cooperative effort.
have we been taken over, a coup perhaps. maybe a solution to leadership by committee.
continuation down this path will definitely solve the problem of selecting a name for the coming (or not) foundation.
Well as can be read from some of the previous threads on this topic here they rightly or wrongly believed they had a general consensus of developers in the project with the exception of Jan. It does raise a question of whether a consensus should be all developers which is really hard, most developers or just a majority of developers. If someone proposes a change and only 2-3 out of nearly 500 developers (going off aprox member numbers) object at the same time we should encourage anyone to be able to work on whatever they want which is easy to do in isolated components but much harder to do when its something that spreads right across the distro. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Simon Lees
On 10/17/19 1:04 PM, Patrick Shanahan wrote:
* Simon Lees
[10-16-19 20:03]: On 10/17/19 10:25 AM, Jan Engelhardt wrote:
On Thursday 2019-10-17 01:03, Simon Lees wrote:
[1.3] "The grouping made yast something of a "Things to Explore" guide to the packages it had." [1.9] "I'm using the rpm Group tag as a way to index software in Package Hub" [1.4] "I use the group index to find software I might be interested in."
It should be pointed out that before the removal became possible both yast and packagehub have been migrated to use alternate mechanisms so i'm not sure how much weight these arguments have.
It should also be pointed out that
* I believe yast does not use any "alternate mechanism", because the browse-by-group feature was killed off there.
It still has a "Package-Group" view that is doing something atleast on my tumbleweed install maybe that's a bug.
* packagehub looks like a SLE-specific thing, meaning the SLE guys sometimes do things different, but me I am interested in the openSUSE ways.
* Coincidentally, packagehub uses the same approach as rpm-catalog for turning classic groups into tags.
* Moreover, packagehub also has a "Unspecified" category with already 16 packages in it. This strongly suggests it also relies on the RPM Group line.
Either way those that want to see groups removed have been working with the yast and package hub teams to do so
so they took it upon themselves to invoke a unilateral action. somehow that flies in the face of a cooperative effort.
have we been taken over, a coup perhaps. maybe a solution to leadership by committee.
continuation down this path will definitely solve the problem of selecting a name for the coming (or not) foundation.
Well as can be read from some of the previous threads on this topic here they rightly or wrongly believed they had a general consensus of developers in the project with the exception of Jan.
It does raise a question of whether a consensus should be all developers which is really hard, most developers or just a majority of developers. If someone proposes a change and only 2-3 out of nearly 500 developers (going off aprox member numbers) object at the same time we should encourage anyone to be able to work on whatever they want which is easy to do in isolated components but much harder to do when its something that spreads right across the distro.
and most of the dev's are concerned with a very small sub-set of packages rather than object which define the openSUSE distro and you are correct that they deserver a certain ownership/freedom, but changes with far reaching affect, no so much. I believe I read almost an even break on the subject. I cannot believe defining it a consensus is possible. in fact, I do not understand posing the question if the action was aready determined, as it appears. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2019-10-17 02:02, Simon Lees wrote:
* I believe yast does not use any "alternate mechanism", because the browse-by-group feature was killed off there.
It still has a "Package-Group" view that is doing something atleast on my tumbleweed install maybe that's a bug.
I am not sure what "Package-Group" is supposed to refer to, graphically. Here are my screenshots, there is clearly a "RPM Group" view (within the Search feature) in 42.1, but not in TW. https://paste.opensuse.org/88172756 my tumbleweed https://paste.opensuse.org/59490542 42.1 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 17.10.19 um 02:15 schrieb Simon Lees:
This wasn't the way you worded it in your original email. If this is what your thinking it seems you are trying to run a "distro-wide endeavor" without the buy in of most of the distro. It seems while some other people think "tags" might be useful, No one else agrees that the current system is useful, the fact that the info has been removed from openSUSE's tools, maybe the only place the current groups could be really useful is to convert to a new "tag" system if there comes to a consensus on that.
I agreed a few times with Jan that I find the groups helpful. That was up to 15.0 or 15.1 my primary source to browse available software based on categories. And yes, it was not always accurate but better than anything else we had and now have. At least within YaST there is no useful way for me to search for software where I don't know the name for. Tags might be a better thing but they do not exist. So what are people using to find certain packages available in the repos if you you look for a category? Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2019-10-17 02:15, Simon Lees wrote:
On 10/17/19 6:26 AM, Jan Engelhardt wrote:
MAY OF 2018.
[4.0] JE: I'm trying to run a distro-wide endeavor here, there should be limits as to what maintainers can and cannot oppose.
This wasn't the way you worded it in your original email.
Perhaps https://lists.opensuse.org/opensuse-factory/2019-10/msg00044.html . Well I was _hoping_ that people would be smart enough to recognize that two discussions and plenty of SRs mean something. And if it's still not clear, let's say it out loud again: - THE GROUP FIELD IS FOR CATEGORIZATION. - CATEGORIZATION IS USEFUL WHEN THERE ARE PLENTY OF DIFFERENT PACKAGES. - A DISTRO IS THE PLACE WHERE DIFFERENT PACKAGES COME TOGETHER. - THEREFORE, THE GROUP FIELD IS A DISTRO-WIDE THING. - SOMETIMES, IT REACHES CROSS-DISTRO NIVEAU.
If this is what your thinking it seems you are trying to run a "distro-wide endeavor" without the buy in of most of the distro. It seems while some other people think "tags" might be useful,
No one else agrees that the current system is useful
PackageHub and rpm-catalog are counterexample of this opinion.
the fact that the info has been removed from openSUSE's tools
It has been removed from one tool (yast), others never had it (zypper), and there are other things that evaluate the field (PH, rc).
maybe the only place the current groups could be really useful is to convert to a new "tag" system if there comes to a consensus on that.
Hard to speak about consensus at this point, but as my overview tried to outline, I think there are more proponents for "group or tag (but in any case, keep)" than "remove".
If you would like to work on this as a distro wide project then you really need consensus from a significant part of the distro.
I had hoped I had the consensus, giving SRs were accepted so far to shift classic groups (which has later been shown to be a usable tag source too) to the right value.
Part of this would be proposing what the tags would look like
This was already proposed. By suggesting it should be proposed, you reaffirm my impression that you and others have not followed the discussion truly. Tags made an appearance here [1.6] https://lists.opensuse.org/opensuse-factory/2018-05/msg00518.html [] https://lists.opensuse.org/opensuse-factory/2019-09/msg00031.html and, repeating myself again, because people, by this point in the mail, will have already forgotten again that classico groups turned out to also work as tags. (see PackageHub) I hope you can now understand my frustration with all the SUSE people that make or participate in the threads whose subject aptly includes "Group" and then pretend afterwards they did not see any replies, counterarguments, counterproposals and even proof of concept.
so that we can as a community decide they are useful and have the
As there is no formal (e.g. Debian-style) "voting process" in matters, discussion responses in essence get evaluated decentrally, and usually it is clear that there is a majority for one particular outcome or another. Based upon this established process and my recollection of the prior responses, I have come to the conclusion that my position has a larger share of supporters. This is presented in the overview.
right level of granularity right now I have no idea what your tag system would look like so I have no idea if I think it would be useful and would support it. Maybe a wiki page with a proposal of tags would be a good starting point here.
A section was added just yesterday at https://en.opensuse.org/openSUSE:Package_group_guidelines Four packages have been submitted in the direction of Factory very recently X11:Wayland/vulkan-*, more are to follow over time.
I think you also need to get buy in from the Yast team, Yast is openSUSE's package manager and if it is never going to support using tags in a meaningful way then personally I don't really see a whole lot of point in maintaining them.
Again, PackageHub, and (this was before I knew PackageHub had it too) the proof-of-concept browser, rpm-catalog. Yast is but one drop. While it is a significant application in its own right, equally many people consider zypper to be openSUSE's "package manager" lest rpm is "the" package manager anyway. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2019-10-17 at 10:31 +0200, Wolfgang Rosenauer wrote:
So what are people using to find certain packages available in the repos if you you look for a category?
Discover and GNOME Software which gets their categorisations from AppData, not the nonsense, mislabelled, unstructured, invalid, and unncessary burden on packagers that is RPM Groups. AppData already provides all the tagging and metadata nonsense which Jan seems to be crusading for, and so expecting something beneficial to be somehow accomplished by sticking on the failed concept of "RPM Groups" is downright bizzare to me. If anyone is seriously using RPM Groups under the illusion they're remotely accurate, they'd be better served by reading tea leaves, asking a magic 8-ball, or sticking their head out of the window and asking a passing airborne porcine. RPM Groups has been not used in CentOS/RHEL since version 5. They've been not only deprecated by our peers in Fedora but actively discoraged to be included in their packages for 2 and a half years. Jan's crusade here, and the manner in which he is conducting it, is so blatently infantile that he has successfully managed to motivate me from being on the fence on this topic to now ensuring that I will actively remove the RPM Group from any spec file I touch from this point today. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Oct 17, 2019 at 11:01 AM, Richard Brown
On Thu, 2019-10-17 at 10:31 +0200, Wolfgang Rosenauer wrote:
So what are people using to find certain packages available in the repos if you you look for a category?
Discover and GNOME Software which gets their categorisations from AppData, not the nonsense, mislabelled, unstructured, invalid, and unncessary burden on packagers that is RPM Groups.
AppData already provides all the tagging and metadata nonsense which Jan seems to be crusading for, and so expecting something beneficial to be somehow accomplished by sticking on the failed concept of "RPM Groups" is downright bizzare to me.
It requires adding additional metadata on top of packaging. It's not strictly bad, it's inconvenient. If you want appstream data to be a valid replacement, contribute to every single package to actually have appstream data, otherwise, there is no point to even talk about it as a replacement. Appstream covers virtually any package type, but no distribution has managed to provide anywhere close to the coverage to make it a thing outside of strictly desktop applications. It can describe fonts, drivers, addons, cli, web and desktop apps, codecs, firmware, input methods, icon themes, services, repositories and operating systems, almost everything that exists in the distro (with the exception of libs and other devel packages). If you seriously want to suggest it, we have a lot of work to do to actually deliver on the premise of appstream.
If anyone is seriously using RPM Groups under the illusion they're remotely accurate, they'd be better served by reading tea leaves, asking a magic 8-ball, or sticking their head out of the window and asking a passing airborne porcine.
RPM Groups has been not used in CentOS/RHEL since version 5. They've been not only deprecated by our peers in Fedora but actively discoraged to be included in their packages for 2 and a half years.
Since when are Fedora and CentOS/RHEL the experts of RPM, it's not like they made it. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/17/19 7:09 PM, Jan Engelhardt wrote:
On Thursday 2019-10-17 02:15, Simon Lees wrote:
On 10/17/19 6:26 AM, Jan Engelhardt wrote:
MAY OF 2018.
[4.0] JE: I'm trying to run a distro-wide endeavor here, there should be limits as to what maintainers can and cannot oppose.
This wasn't the way you worded it in your original email.
Perhaps https://lists.opensuse.org/opensuse-factory/2019-10/msg00044.html .
Well I was _hoping_ that people would be smart enough to recognize that two discussions and plenty of SRs mean something.
And if it's still not clear, let's say it out loud again: - THE GROUP FIELD IS FOR CATEGORIZATION. - CATEGORIZATION IS USEFUL WHEN THERE ARE PLENTY OF DIFFERENT PACKAGES. - A DISTRO IS THE PLACE WHERE DIFFERENT PACKAGES COME TOGETHER. - THEREFORE, THE GROUP FIELD IS A DISTRO-WIDE THING. - SOMETIMES, IT REACHES CROSS-DISTRO NIVEAU.
If this is what your thinking it seems you are trying to run a "distro-wide endeavor" without the buy in of most of the distro. It seems while some other people think "tags" might be useful,
No one else agrees that the current system is useful
PackageHub and rpm-catalog are counterexample of this opinion.
the fact that the info has been removed from openSUSE's tools
It has been removed from one tool (yast), others never had it (zypper), and there are other things that evaluate the field (PH, rc).
maybe the only place the current groups could be really useful is to convert to a new "tag" system if there comes to a consensus on that.
Hard to speak about consensus at this point, but as my overview tried to outline, I think there are more proponents for "group or tag (but in any case, keep)" than "remove".
If you would like to work on this as a distro wide project then you really need consensus from a significant part of the distro.
I had hoped I had the consensus, giving SRs were accepted so far to shift classic groups (which has later been shown to be a usable tag source too) to the right value.
Part of this would be proposing what the tags would look like
This was already proposed. By suggesting it should be proposed, you reaffirm my impression that you and others have not followed the discussion truly.
Tags made an appearance here
[1.6] https://lists.opensuse.org/opensuse-factory/2018-05/msg00518.html [] https://lists.opensuse.org/opensuse-factory/2019-09/msg00031.html
and, repeating myself again, because people, by this point in the mail, will have already forgotten again that classico groups turned out to also work as tags. (see PackageHub)
I have been loosly following the discussion, because frankly I don't care that much but no where have I seen a proposal that gives me some idea what level of the highrachy tags would follow and If I wanted to add tags to my packages I would frankly have no idea what would be appropriate.
I hope you can now understand my frustration with all the SUSE people that make or participate in the threads whose subject aptly includes "Group" and then pretend afterwards they did not see any replies, counterarguments, counterproposals and even proof of concept.
so that we can as a community decide they are useful and have the
As there is no formal (e.g. Debian-style) "voting process" in matters, discussion responses in essence get evaluated decentrally, and usually it is clear that there is a majority for one particular outcome or another.
I am on the board and have been an openSUSE developer for 8+ years, I have some idea of how things should work, generally for a new distro wide feature i'd expect a detailed proposal be posted to this list which can then be refined and generally agreed upon, I haven't seen that here for package tags. If you want a decent example look at the discussions around /usr/etc from earlier in the year.
Based upon this established process and my recollection of the prior responses, I have come to the conclusion that my position has a larger share of supporters. This is presented in the overview.
Yes but in this case you didn't count the implicit non responses, I don't expect that everyone who agree's with a proposal such as removing rpm groups needs to add a +1 to the email thread, that has generally not been the case here, it is up to people to object and of the nearly 500 registered developers we have very few chose to do so.
right level of granularity right now I have no idea what your tag system would look like so I have no idea if I think it would be useful and would support it. Maybe a wiki page with a proposal of tags would be a good starting point here.
A section was added just yesterday at https://en.opensuse.org/openSUSE:Package_group_guidelines
Thanks this is the starting point I'd expect to see for this kind of proposal
Four packages have been submitted in the direction of Factory very recently X11:Wayland/vulkan-*, more are to follow over time.
I think you also need to get buy in from the Yast team, Yast is openSUSE's package manager and if it is never going to support using tags in a meaningful way then personally I don't really see a whole lot of point in maintaining them.
Again, PackageHub, and (this was before I knew PackageHub had it too) the proof-of-concept browser, rpm-catalog.
Yast is but one drop. While it is a significant application in its own right, equally many people consider zypper to be openSUSE's "package manager" lest rpm is "the" package manager anyway.
Yep well i'd presume that the default package manager for those interested in searching for packages via group / tag would be yast, I don't expect people to need to install some other proof of concept tool. If the community does accept and adopt this "tag" based approach it would also be interesting to see stuff like software.o.o able to search via tag as that is another common way people search for packages. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2019-10-16 at 21:56 +0200, Jan Engelhardt wrote:
<snip childish nonsense>
Jan, I went through the installed packages on my system here and looked casually at the list of packages and their assigned groups. It led me to the following questions: what is discord doing in "Amusements/Games/Other"? why is xscreensaver in "Amusements/Toys"? Why is GNOME Builder not in "Development/Tools/IDE" but it's plugins are? Why is Archiving/Backup considered a subcategory of Productivity? Why is does Clustering have to do with Productivity? Why are gstreamer codecs in Productivity/Multimedia/Other when half the codecs it uses are in Productivity/Multimedia/Video/Editors and Converters? Why is guvcview in Productivity/Multimedia/Video/Players when cheese is in Productivity/Multimedia/Other? What is Networking doing under Producitivity? What is IRC doing under Networking? Why is ghostscript in Producitivity/Office/Other when the ghostscript fonts are all under Productivity/Publishing/PS? Why is the ghostscript fonts not under System/X11/Fonts? Why the hell is a gnome-calculator considered Productivity/Scientific/Math and gedit is Productivity/Text/Editors but most of the other GNOME apps are System/GUI/GNOME? Why is apparmor-abstractions Productivity/Security when apparmor-parser is Productivity/Networking/Security? WHAT DOES APPARMOR HAVE TO DO WITH PRODUCTIVITY? Why is sysfsutils in System/Libraries? Why is YaST not System/Management? Why in Podman in System/Management? Why do we have System/Sound Daemons when the only thing in it is PulseAudio and all the other Sound Daemons are in System/Libraries? Wtf is xdmbgrd doing in System/X11/Displaymanagers? WTH is tigervnc doing in System/X11/Servers/XF86_4? WTH is System/X11/Servers/XF86_4? Why is gnome-logs in System/X11/Utilities not System/GUI/GNOME? Why is hicolor-icon-theme in System/X11/Utilities? Why is xorg-x11 in System/X11/Utilities not System/X11/Servers? WTH is numlockx doing in System/YaST? I imagine if I went through with a fine toothcomb I'd find more examples, plus of course this is a sample size of approximately ~10% of the distributions packages. More than ever I am now convinced that the RPM Groups we have in the distribution right deserve to be thrown away with prejudice, and I'm not interested in considering an alternative until that's been done so we can start from a nice clean slate. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2019-10-17 11:01, Richard Brown wrote:
On Thu, 2019-10-17 at 10:31 +0200, Wolfgang Rosenauer wrote:
So what are people using to find certain packages available in the repos if you you look for a category?
Discover and GNOME Software which gets their categorisations from AppData, not the nonsense, mislabelled, unstructured, invalid, and unncessary burden on packagers that is RPM Groups.
So is the PackageHub grouping bad?
AppData already provides all the tagging and metadata nonsense which Jan seems to be crusading for, and so expecting something beneficial to be somehow accomplished by sticking on the failed concept of "RPM Groups" is downright bizzare to me.
If anyone is seriously using RPM Groups under the illusion they're remotely accurate, they'd be better served by reading tea leaves, asking a magic 8-ball, or sticking their head out of the window and asking a passing airborne porcine.
There are 57600ish rpm files in Factory (ARCHIVES.gz) // 12448 packages (osc ls openSUSE:Factory), but only 506 AppData files. That is an absolutely DESOLATE state at - at most - 4.0%. The coverage for Group (whether accurate or not) is 12214/12399, or 98.5%. The one with the illusion is you. (Confer with Stasiek's reply.) You should check out those British leaves... while they last.
Jan's crusade here, and the manner in which he is conducting it, is so blatently infantile that he has successfully managed to motivate me from being on the fence on this topic to now ensuring that I will actively remove the RPM Group from any spec file I touch from this point today.
Wow, so you're joining the edit war. Well if _that_ isn't infantile! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2019-10-17 11:30, Simon Lees wrote:
Based upon this established process and my recollection of the prior responses, I have come to the conclusion that my position has a larger share of supporters. This is presented in the overview.
Yes but in this case you didn't count the implicit non responses, I don't expect that everyone who agree's with a proposal such as removing rpm groups needs to add a +1 to the email thread
By your very argumentation, you also should not expect that everyone who agrees with my proposition needs to add a +1 to the thread. So it's fair to say that you can't just count 490 non-respondents as agreements for a removal.
right level of granularity right now I have no idea what your tag system would look like so I have no idea if I think it would be useful and would support it. Maybe a wiki page with a proposal of tags would be a good starting point here.
A section was added just yesterday at https://en.opensuse.org/openSUSE:Package_group_guidelines
Thanks this is the starting point I'd expect to see for this kind of proposal
Four packages have been submitted in the direction of Factory very recently X11:Wayland/vulkan-*, more are to follow over time.
I think you also need to get buy in from the Yast team, Yast is openSUSE's package manager and if it is never going to support using tags in a meaningful way then personally I don't really see a whole lot of point in maintaining them.
Again, PackageHub, and (this was before I knew PackageHub had it too) the proof-of-concept browser, rpm-catalog.
Yast is but one drop. While it is a significant application in its own right, equally many people consider zypper to be openSUSE's "package manager" lest rpm is "the" package manager anyway.
Yep well i'd presume that the default package manager for those interested in searching for packages via group / tag would be yast, I don't expect people to need to install some other proof of concept tool. If the community does accept and adopt this "tag" based approach it would also be interesting to see stuff like software.o.o able to search via tag as that is another common way people search for packages.
I cannot make much of a hypothesis about how yast is used (for package dealings) these days. For _installation_, a number of people had left yast for alternate, installers like "smart" a couple of years ago because (among other things) yast's startup speed back then. After a small excursion through the motions, openSUSE had the zypp stack and everybody was happy again. This may have also driven _browsing_ users away from yast as a catalog browser, towards webpage-based catalogs (fueled by the increased availability of Internet too). It is my conjecture that ultimately, browser-based rendering is the more popular presentation than within yast-x11/yast-ncurses. The removal of the group browser from yast seems logical in that sense. But that does not invalidate the metadata that is buried somewhere which the now-web-based services still rely on. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/17/19 9:43 PM, Jan Engelhardt wrote:
On Thursday 2019-10-17 11:30, Simon Lees wrote:
Based upon this established process and my recollection of the prior responses, I have come to the conclusion that my position has a larger share of supporters. This is presented in the overview.
Yes but in this case you didn't count the implicit non responses, I don't expect that everyone who agree's with a proposal such as removing rpm groups needs to add a +1 to the email thread
By your very argumentation, you also should not expect that everyone who agrees with my proposition needs to add a +1 to the thread. So it's fair to say that you can't just count 490 non-respondents as agreements for a removal.
I would expect that people who object to a proposal should raise there objections as a small number of people did. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2019-10-17 13:19, Simon Lees wrote:
On 10/17/19 9:43 PM, Jan Engelhardt wrote:
On Thursday 2019-10-17 11:30, Simon Lees wrote:
Based upon this established process and my recollection of the prior responses, I have come to the conclusion that my position has a larger share of supporters. This is presented in the overview.
Yes but in this case you didn't count the implicit non responses, I don't expect that everyone who agree's with a proposal such as removing rpm groups needs to add a +1 to the email thread
By your very argumentation, you also should not expect that everyone who agrees with my proposition needs to add a +1 to the thread. So it's fair to say that you can't just count 490 non-respondents as agreements for a removal.
I would expect that people who object to a proposal should raise there objections as a small number of people did.
And that's what I did for the removal proposal. So, we're even? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/17/19 10:03 PM, Jan Engelhardt wrote:
On Thursday 2019-10-17 13:19, Simon Lees wrote:
On 10/17/19 9:43 PM, Jan Engelhardt wrote:
On Thursday 2019-10-17 11:30, Simon Lees wrote:
Based upon this established process and my recollection of the prior responses, I have come to the conclusion that my position has a larger share of supporters. This is presented in the overview.
Yes but in this case you didn't count the implicit non responses, I don't expect that everyone who agree's with a proposal such as removing rpm groups needs to add a +1 to the email thread
By your very argumentation, you also should not expect that everyone who agrees with my proposition needs to add a +1 to the thread. So it's fair to say that you can't just count 490 non-respondents as agreements for a removal.
I would expect that people who object to a proposal should raise there objections as a small number of people did.
And that's what I did for the removal proposal. So, we're even?
As I said in a previous email i'm still waiting for a full detailed proposal email for the new tags and then people can start to provide feedback or object, but as everyone agrees there is enough issues with the current system that it needs replacing, if people agree to some form of replacement then what we do in between with the existing data that has lots of flaws is another question. There is already multiple people suggesting that its at the point that it should be scrapped and start again. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Am 17.10.19 um 11:01 schrieb Richard Brown:
On Thu, 2019-10-17 at 10:31 +0200, Wolfgang Rosenauer wrote:
So what are people using to find certain packages available in the repos if you you look for a category?
Discover and GNOME Software which gets their categorisations from AppData, not the nonsense, mislabelled, unstructured, invalid, and unncessary burden on packagers that is RPM Groups.
It is no burden for me. Jan corrected the groups in some of "my" packages, and I just did not touch them afterwards. The burden of just not touching the group: line is very low, compared to other stuff that gets imposed on packagers for no good reason.
AppData already provides all the tagging and metadata nonsense which Jan seems to be crusading for, and so expecting something beneficial to be somehow accomplished by sticking on the failed concept of "RPM Groups" is downright bizzare to me.
But rpm groups just needs a few bytes per package, whereas appdata is a multi-megabyte unbearably slow (apparently always coming from download.o.o?) download. It's so annoying that I finally patched libzypp to just ignore this useless (to me) stuff completely.
If anyone is seriously using RPM Groups under the illusion they're remotely accurate, they'd be better served by reading tea leaves, asking a magic 8-ball, or sticking their head out of the window and asking a passing airborne porcine.
Thanks for valuing Jan's contribution in fixing up the groups and making them more than "remotely accurate".
Jan's crusade here, and the manner in which he is conducting it, is so blatently infantile that he has successfully managed to motivate me from being on the fence on this topic to now ensuring that I will actively remove the RPM Group from any spec file I touch from this point today.
Better not touch "my" packages ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Moin, On Thu, 17 Oct 2019, 13:41:28 +0200, Simon Lees wrote:
... As I said in a previous email i'm still waiting for a full detailed proposal email for the new tags and then people can start to provide feedback or object, but as everyone agrees there is enough issues with the current system that it needs replacing, if people agree to some form of replacement then what we do in between with the existing data that has lots of flaws is another question. There is already multiple people suggesting that its at the point that it should be scrapped and start again.
while I have to admit, that Group: admission needs care, I never saw any announcement by anyone that "common understanding has changed". This really comes down to *who* is driving such changes? Nobody told us about anything which is driving _automagic_ removal of the Group: element from any of the packages, full stop! This is *not* what a committee is about, ie. *not* telling everybody, what they/someone has silently decided... Cheers. l8er manfred
Am 17.10.19 um 11:30 schrieb Simon Lees:
Yes but in this case you didn't count the implicit non responses, I don't expect that everyone who agree's with a proposal such as removing rpm groups needs to add a +1 to the email thread, that has generally not been the case here, it is up to people to object and of the nearly 500 registered developers we have very few chose to do so.
From my POV, Jan's proposal was so obviously good and correct, that there was no need to add more noise to this list.
But if you want to start counting: I object the removal of the Group tag, and I support Jan's proposals. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2019-10-17 at 13:33 +0200, Jan Engelhardt wrote:
On Thursday 2019-10-17 13:19, Simon Lees wrote:
On 10/17/19 9:43 PM, Jan Engelhardt wrote:
On Thursday 2019-10-17 11:30, Simon Lees wrote:
Based upon this established process and my recollection of the prior responses, I have come to the conclusion that my position has a larger share of supporters. This is presented in the overview.
Yes but in this case you didn't count the implicit non responses, I don't expect that everyone who agree's with a proposal such as removing rpm groups needs to add a +1 to the email thread
By your very argumentation, you also should not expect that everyone who agrees with my proposition needs to add a +1 to the thread. So it's fair to say that you can't just count 490 non-respondents as agreements for a removal.
I would expect that people who object to a proposal should raise there objections as a small number of people did.
And that's what I did for the removal proposal. So, we're even? Hi
I see that this is getting a bit emotional - maybe its time to take a deep breath and try to calm down a bit. Cheers Martin
On Thursday 2019-10-17 11:56, Richard Brown wrote:
On Wed, 2019-10-16 at 21:56 +0200, Jan Engelhardt wrote:
<snip childish nonsense>
Jan, I went through the installed packages on my system here and looked casually at the list of packages and their assigned groups.
It led me to the following questions:
I have answered some of these Qs previously somewhere, but because that is loosely scattered, I will do so again here for the viewers' convenience. Packages can and do get reviewed and checked into Factory quickly, sometimes without me getting a chance to see it in time (this is not a bad thing, it just happens). As mentioned in the past too, if and when I am aware of it, something will be done about it.
what is discord doing in "Amusements/Games/Other"?
I can concur Games feels odd, but, it is my hypothesis the packager thought of Discord as a program similar to TeamSpeak, an application that is used as a sidechannel communication while gaming (gamers seem to shun in-game voice transmission implementations, if they even exist). Basically, this package suffered from the single-valuedness of old groups. Thank for your making me aware of this package - I will make a proposal to its submitter under the new tag scheme. (Discord also has that special place in :NonFree...)
why is xscreensaver in "Amusements/Toys"?
Hypothesis: Amusements/ is the antithesis to Productivity/. There is not much you can do during a screensaving moment ;-) Would you rather expect it in "graphics"?
Why is GNOME Builder not in "Development/Tools/IDE" but it's plugins are?
This is a result of the single-valuedness of groups and because, in that old limited framework, the maintainer decided to highlight the fact that it is a "gnome" component over "ide". I shall make a SR to propose both "gnome" and "ide".
Why is Archiving/Backup considered a subcategory of Productivity? Why is does Clustering have to do with Productivity? What is Networking doing under Producitivity?
Would you rather want to classify Archiving as a non-productive use (i.e. amusements) -- note this is a rhetoric question, I don't expect any answer. Amusements and Productivity, in my opinion, are purely separators in the classisc cheme. It is useless as a tag and does not appear in the new tag list. All Amusements/X/Y and Productivity/X/Y get reduced to X, Y (or better) when tags are made out of it.
Why are gstreamer codecs in Productivity/Multimedia/Other when half the codecs it uses are in Productivity/Multimedia/Video/Editors and Converters?
It shall be fixed..
Why is guvcview in Productivity/Multimedia/Video/Players when cheese is in Productivity/Multimedia/Other?
Though cheese plays video material, I do not think anyone would consider it a video player (as in, VLC, mplayer), since it is a webcam program.
What is IRC doing under Networking?
Rather than a question about a package's choice of some group, now this is one about the classic groups themselves. Maybe IRC was seen as a protocol the same way SMTP is. I would suggest not to try to understand the old hierarchy, just fixing it. Hold my beer.. I sure have replies to your other individual question, but I will cut the mail short here so that it gets out to the public faster. I will take your list into consideration and, now that I am aware of more unfitting values, make submissions and get it fixed, like I also said at a past date. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/17/19 10:24 PM, Manfred Hollstein wrote:
Moin,
On Thu, 17 Oct 2019, 13:41:28 +0200, Simon Lees wrote:
... As I said in a previous email i'm still waiting for a full detailed proposal email for the new tags and then people can start to provide feedback or object, but as everyone agrees there is enough issues with the current system that it needs replacing, if people agree to some form of replacement then what we do in between with the existing data that has lots of flaws is another question. There is already multiple people suggesting that its at the point that it should be scrapped and start again.
while I have to admit, that Group: admission needs care, I never saw any announcement by anyone that "common understanding has changed".
This really comes down to *who* is driving such changes? Nobody told us about anything which is driving _automagic_ removal of the Group: element from any of the packages, full stop!
This is *not* what a committee is about, ie. *not* telling everybody, what they/someone has silently decided...
Well I work in SUSE's packaging team and even I have no idea what committee your talking about, I have never heard of such a committee related to anything like that. But the intention to remove groups was made by people who thought they had a consensus for atleast the last year. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Donnerstag, 17. Oktober 2019 11:56:12 CEST Richard Brown wrote:
On Wed, 2019-10-16 at 21:56 +0200, Jan Engelhardt wrote:
<snip childish nonsense>
^ this I consider just rude ...
More than ever I am now convinced that the RPM Groups we have in the distribution right deserve to be thrown away with prejudice, and I'm not interested in considering an alternative until that's been done so we can start from a nice clean slate.
The discussion is ongoing, and apparently there are three groups - a small one against Group tags, a small one for keeping it, and the majority does not care. Nevertheless, you have mass-submitted apparently thousands of SRs deleting the Group: tags. I don't care about the tag, but doing so *now* is IMNSHO also quite rude. It is also *massively* annoying. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Donnerstag, 17. Oktober 2019 14:36:22 CEST Stefan Brüns wrote:
On Donnerstag, 17. Oktober 2019 11:56:12 CEST Richard Brown wrote:
On Wed, 2019-10-16 at 21:56 +0200, Jan Engelhardt wrote:
<snip childish nonsense>
^ this I consider just rude ...
More than ever I am now convinced that the RPM Groups we have in the distribution right deserve to be thrown away with prejudice, and I'm not interested in considering an alternative until that's been done so we can start from a nice clean slate.
The discussion is ongoing, and apparently there are three groups - a small one against Group tags, a small one for keeping it, and the majority does not care.
Nevertheless, you have mass-submitted apparently thousands of SRs deleting the Group: tags. I don't care about the tag, but doing so *now* is IMNSHO also quite rude.
It is also *massively* annoying.
Another annoyance for every TW user will be the forced update of all packages, in case the maintainer just accepted and forwarded the request to Factory, just because some metadata changed. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Thu, 17 Oct 2019, 14:12:53 +0200, Simon Lees wrote:
On 10/17/19 10:24 PM, Manfred Hollstein wrote:
Moin,
On Thu, 17 Oct 2019, 13:41:28 +0200, Simon Lees wrote:
... As I said in a previous email i'm still waiting for a full detailed proposal email for the new tags and then people can start to provide feedback or object, but as everyone agrees there is enough issues with the current system that it needs replacing, if people agree to some form of replacement then what we do in between with the existing data that has lots of flaws is another question. There is already multiple people suggesting that its at the point that it should be scrapped and start again.
while I have to admit, that Group: admission needs care, I never saw any announcement by anyone that "common understanding has changed".
This really comes down to *who* is driving such changes? Nobody told us about anything which is driving _automagic_ removal of the Group: element from any of the packages, full stop!
This is *not* what a committee is about, ie. *not* telling everybody, what they/someone has silently decided...
Well I work in SUSE's packaging team and even I have no idea what committee your talking about, I have never heard of such a committee related to anything like that. But the intention to remove groups was made by people who thought they had a consensus for atleast the last year.
_consensus_ - obviously not visible to this list here. Otherwise we wouldn't be discussing the silent removal enforced by someone... :INIT Jan reported that it happened :LOOP Lots of arguments, pro and con, were raised again :BREAK_IF_WE_COULD_HAVE_SEEN_WHY: Nothing, other than the same arguments, but not, why someone decided to DO it! :GOTO LOOP :WHY Again, no reference to a publicly made decision Clear now?
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek
Cheers. l8er manfred PS: Luckily I deal with emergencies myself... Sorry, couldn't resist!
Am Donnerstag, 17. Oktober 2019, 14:36:22 CEST schrieb Stefan Brüns:
On Donnerstag, 17. Oktober 2019 11:56:12 CEST Richard Brown wrote:
On Wed, 2019-10-16 at 21:56 +0200, Jan Engelhardt wrote:
<snip childish nonsense>
^ this I consider just rude ...
More than ever I am now convinced that the RPM Groups we have in the distribution right deserve to be thrown away with prejudice, and I'm not interested in considering an alternative until that's been done so we can start from a nice clean slate.
The discussion is ongoing, and apparently there are three groups - a small one against Group tags, a small one for keeping it, and the majority does not care.
Nevertheless, you have mass-submitted apparently thousands of SRs deleting the Group: tags. I don't care about the tag, but doing so *now* is IMNSHO also quite rude.
I would even call it an aggressive act of violence. We're now at a point, that I plead for to avoid. Here's a template (c) Jan Engelhardt, to defend your crusade: osc request decline xxx --message="Group line removal disputed!" Similar to Jan, I tried to steer the discussion into sane grounds: the tool chain ignores the group tag: good, maintainer may care about or simply ignore it: good.., but you, Richard, started to perform an exorcism on the group tags out of the blue, while not providing a better replacement. Hence, you declare the work of many as void, actively loosing *some* classification, even if it's *less* than optimal, and replace it with - NOTHING (which is still less than what we have now). Even, if a number of people declare, they use them. Richard, you're misusing your position in an unfair act of violence. We're not in the Third Crusade anymore! That war IS over. It was a fail in hindsight. War is always a fail in hindsight. Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-10-17, 08:39 GMT, Jan Engelhardt wrote:
PackageHub and rpm-catalog are counterexample of this opinion.
Just to explain my position: 1. In my opinion (and I am afraid I am not alone) Groups are not used anywhere it matters. Yes, I have to admit I have no idea what PackageHub and rpm-catalog are (first just from the name looks like some kind of website, right? second will be probably some software). If one looks for some piece of software, who won’t just run search "openSUSE typeofsoftware" in the Internet Search of your choice? Is there anybody who really cares for PackageHub and rpm-catalog (and Gnome Software, for that matter?) 2. Because of #1, for most package maintainers Group label is nothing anybody cares about. It used to have to be filled with something which gets through rpmlint and that’s how far most package maintainers IMHO cares. 3. Given #2, groups are such mess, no user uses them for searching for their software, because nobody knows whether Network Manager is in Productivity/Networking/General, System/Networking, or something else. See below on problems with tree hierarchies. 3. Given #3, no sane software developer uses them in their software, so -> #1 Yes, of course, possible solution would be to make an Herculean effort to fix groups to be perfect even against the will of all package maintainers. The problem is that you still haven’t persuaded software developers to use it. I think it is a prevalent notion among people who care about classification, catalogues and similar stuff, that the tree hierarchy is inherently flawed and insufficient to classify which at least approximately corresponds with the real life. Even software is just too complicated to be squeezed into simple hierarchies and too complicated hierarchies are too complicated to be useful for the end-user. See for example https://www.w3.org/Provider/Style/URI The answer to this problem with strict hierarchies was the movement of folksonomy (https://en.wikipedia.org/wiki/Folksonomy), which basically means tags and search through them. It is better than strict hierarchies, because suddenly multiple tags can deal with the ambiguity of the classification, but the problem is (as anybody who tried to find a story on https://archiveofourown.org/ can atest), that unbridled generation of tags leads to the endless duplicates. Limited tags are again very hard to manage and require constant maintenance. However, I don’t think that we are limited just to strict hierarchies or tags. There is already one system, which is well maintained and easily utilized. Every package has Description field, and with zypper se -d (or https://archiveofourown.org/) this can be easily searched. And that is the reason I believe whole effort to create working Group: or Tags: is waste of time and effort leading to nowhere. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Basically, the only “intuitive” interface is the nipple. After that, it's all learned. -- Bruce Ediger when discussing intuivity of Mac OS http://groups.google.com/group/comp.sys.next.advocacy\ /msg/7fa8c580900353d0 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 17. Oktober 2019, 09:46:22 CEST schrieb Jan Engelhardt:
On Thursday 2019-10-17 02:02, Simon Lees wrote:
* I believe yast does not use any "alternate mechanism", because the
browse-by-group feature was killed off there.
It still has a "Package-Group" view that is doing something atleast on my tumbleweed install maybe that's a bug.
I am not sure what "Package-Group" is supposed to refer to, graphically. Here are my screenshots, there is clearly a "RPM Group" view (within the Search feature) in 42.1, but not in TW.
https://paste.opensuse.org/88172756 my tumbleweed https://paste.opensuse.org/59490542 42.1
Hmm, in my graphical yast2 of TW 20191014, there's still a Package Groups view: https://paste.opensuse.org/72466564 and yes, I'm using this view from time to time! Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2019-10-17 at 16:29 +0200, Hans-Peter Jansen wrote:
Hmm, in my graphical yast2 of TW 20191014, there's still a Package Groups view:
https://paste.opensuse.org/72466564
and yes, I'm using this view from time to time!
The problem here is that this does not even correspond to the hierarchy used in the Group tag - and waaay to much is listed in "Unknown group" Cheers, Dominique
On Donnerstag, 17. Oktober 2019 11:56:12 CEST Richard Brown wrote:>>> More than ever I am now convinced that the RPM Groups we have in
Richard, the>>> distribution right deserve to be thrown away with prejudice, and I'm>>> not interested in considering an alternative until that's been done so>>> we can start from a nice clean slate. while I personally don't care about whether we have Group: tags or not I do care about good behaviour in a community. Submitting requests for Group: tag removal while a discussion is still on-going just to set facts is rude! As a former board chair you should know better what it needs to keep a community in a healthy state. So for now I will decline all requests for removing Group: tag until a consensus is reached here. Period. Ciao, Michael.
On Thursday 2019-10-17 16:29, Hans-Peter Jansen wrote:
Am Donnerstag, 17. Oktober 2019, 09:46:22 CEST schrieb Jan Engelhardt:
On Thursday 2019-10-17 02:02, Simon Lees wrote:
* I believe yast does not use any "alternate mechanism", because the browse-by-group feature was killed off there.
It still has a "Package-Group" view that is doing something atleast on my tumbleweed install maybe that's a bug.
I am not sure what "Package-Group" is supposed to refer to, graphically. Here are my screenshots, there is clearly a "RPM Group" view (within the Search feature) in 42.1, but not in TW.
https://paste.opensuse.org/88172756 my tumbleweed https://paste.opensuse.org/59490542 42.1
Hmm, in my graphical yast2 of TW 20191014, there's still a Package Groups view:
Aha! So the Qt interface is quite different. Its View dropdown has 6 components: Patterns, Package Groups, Languages, Repositories, Search, Installation Summary. The ncurses "View" dropdown has 5 components: Technical Data, Package Description, Package Versions, File List, Dependencies. Quite inconsistent... Anyhow, the Package-Group bit in the yast qt ui has its own classification, and you can equally ask questions about that: why is "chafa" in "Games"? and not in "Graphics"? By having a separate index just for yast means half as many driveby contributions, so of course it can be expected that index has a worse quality that frustrates some people. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Oct 17, 2019 at 5:28 PM, Jan Engelhardt
On Thursday 2019-10-17 16:29, Hans-Peter Jansen wrote:
Am Donnerstag, 17. Oktober 2019, 09:46:22 CEST schrieb Jan Engelhardt:
On Thursday 2019-10-17 02:02, Simon Lees wrote:
* I believe yast does not use any "alternate mechanism", because the browse-by-group feature was killed off there.
It still has a "Package-Group" view that is doing something atleast on my tumbleweed install maybe that's a bug.
I am not sure what "Package-Group" is supposed to refer to, graphically. Here are my screenshots, there is clearly a "RPM Group" view (within the Search feature) in 42.1, but not in TW.
https://paste.opensuse.org/88172756 my tumbleweed https://paste.opensuse.org/59490542 42.1
Hmm, in my graphical yast2 of TW 20191014, there's still a Package Groups view:
Aha! So the Qt interface is quite different. Its View dropdown has 6 components: Patterns, Package Groups, Languages, Repositories, Search, Installation Summary. The ncurses "View" dropdown has 5 components: Technical Data, Package Description, Package Versions, File List, Dependencies. Quite inconsistent...
Anyhow, the Package-Group bit in the yast qt ui has its own classification, and you can equally ask questions about that: why is "chafa" in "Games"? and not in "Graphics"?
By having a separate index just for yast means half as many driveby contributions, so of course it can be expected that index has a worse quality that frustrates some people.
It was based on PackageKit groups, which were for the most part based on RPM Group tags. I say was because it was removed on Oct 8, but that change most likely didn't land in factory yet. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 17. Oktober 2019, 16:31:59 CEST schrieb Dominique Leuenberger / DimStar:
On Thu, 2019-10-17 at 16:29 +0200, Hans-Peter Jansen wrote:
Hmm, in my graphical yast2 of TW 20191014, there's still a Package Groups
view: https://paste.opensuse.org/72466564
and yes, I'm using this view from time to time!
The problem here is that this does not even correspond to the hierarchy used in the Group tag - and waaay to much is listed in "Unknown group"
Agreed, but none the less the group system is still useful as is. What's needed is a discussion, how this could be transformed to a tag based classification, that better matches with reality. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/10/2019 10.31, Wolfgang Rosenauer wrote:
Am 17.10.19 um 02:15 schrieb Simon Lees:
This wasn't the way you worded it in your original email. If this is what your thinking it seems you are trying to run a "distro-wide endeavor" without the buy in of most of the distro. It seems while some other people think "tags" might be useful, No one else agrees that the current system is useful, the fact that the info has been removed from openSUSE's tools, maybe the only place the current groups could be really useful is to convert to a new "tag" system if there comes to a consensus on that.
I agreed a few times with Jan that I find the groups helpful. That was up to 15.0 or 15.1 my primary source to browse available software based on categories. And yes, it was not always accurate but better than anything else we had and now have. At least within YaST there is no useful way for me to search for software where I don't know the name for. Tags might be a better thing but they do not exist.
So what are people using to find certain packages available in the repos if you you look for a category?
I do use the "view by package group" in YaST to search for useful applications, when not knowing a name for what I search, or when searching for new applications that I don't even know they exist. I fired up YaST to verify, and to my utter surprise the feature has been removed in 15.1! There is no longer "view by rpm groups! This is so unbelievable that I fired up a virtual machine with 15.0 to verify: it is true. So it seems there is an attempt to kill the feature. :-/ - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXaiTtgAKCRC1MxgcbY1H 1YxCAJ9lg4gHxYEWt+TI3Thtnvzc9HFGIACfRAB+jEuDU4l4duh3crc0y/DL7nQ= =Vjlo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 17. Oktober 2019, 16:33:50 CEST schrieb Michael Ströder:
Richard,
while I personally don't care about whether we have Group: tags or not I do care about good behaviour in a community.
Submitting requests for Group: tag removal while a discussion is still on-going just to set facts is rude! As a former board chair you should know better what it needs to keep a community in a healthy state.
So for now I will decline all requests for removing Group: tag until a consensus is reached here. Period.
Thank you, Michael. Am Dienstag, 27. August 2019, 14:40:39 CEST schrieb Hans-Peter Jansen:
OTOH, I cannot see a good reason to *actively* *eliminate* the Group line either, other than throwing away good work of good people.
A thousand years ago, people incited the crusades, just because there were other people, that doesn't fit their expectations.
Folks, don't incite a crusade against Group lines, please. They will not hurt you.
This week, my fear became reality. It started with spec-cleaner removing Group lines incidentally, and now Richards butchery. @Dominique: is there any way to repel this landslide from hitting factory? Cheers, Pete [1] https://lists.opensuse.org/opensuse-factory/2019-08/msg00268.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi! Just to add my point of view. I have nothing against the removal of the Group tag. In fact, in all packages I have already created for openSUSE, I can’t remember only one that did not make me confused about what to choose in the Group tag. On many occasions, there were 3 or 4 tags that fit. Most notably is Julia. It is a scientific language, but also a tool for many analysis. It can easily fit all the following categories: Development/Languages/Other Productivity/Clustering/Computing Productivity/Databases/Tools Productivity/Scientific/Astronomy Productivity/Scientific/Chemistry Productivity/Scientific/Electronics Productivity/Scientific/Math Productivity/Scientific/Other Productivity/Scientific/Physics Thus, IMHO, removing the Group tag as it is today from .spec is a good thing. Best regards, Ronan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2019-10-17 19:35, Ronan Arraes Jardim Chagas wrote:
Hi!
Just to add my point of view. I have nothing against the removal of the Group tag. In fact, in all packages I have already created for openSUSE, I can’t remember only one that did not make me confused about what to choose in the Group tag. On many occasions, there were 3 or 4 tags that fit.
Great - now you can just put those tags in the Group: field now and call it a day: julia computing astronomy chemistry electronics mathematics physics ... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Jan,
Em 17 de out de 2019, à(s) 14:40, Jan Engelhardt
escreveu: Great - now you can just put those tags in the Group: field now and call it a day:
julia computing astronomy chemistry electronics mathematics physics …
Good, this kind of Group I like and makes much more sense. Best regards, Ronan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 17. Oktober 2019, 19:35:24 CEST schrieb Ronan Arraes Jardim Chagas:
Hi!
Just to add my point of view. I have nothing against the removal of the Group tag. In fact, in all packages I have already created for openSUSE, I can’t remember only one that did not make me confused about what to choose in the Group tag. On many occasions, there were 3 or 4 tags that fit.
Most notably is Julia. It is a scientific language, but also a tool for many analysis. It can easily fit all the following categories:
Development/Languages/Other Productivity/Clustering/Computing Productivity/Databases/Tools Productivity/Scientific/Astronomy Productivity/Scientific/Chemistry Productivity/Scientific/Electronics Productivity/Scientific/Math Productivity/Scientific/Other Productivity/Scientific/Physics
Thus, IMHO, removing the Group tag as it is today from .spec is a good thing.
By the prize of losing *any* sane starting point for automatic conversion to a tag based classification. Consequently your package will not belong to any group, contributing to the great unknowns. Is that the plan?!? How is this any better than the less than optimal scheme, that *exists* today. Honestly, it's worse. Throwing them away today will generate more maintainer work later on. Guaranteed. Because users will complain, that there's no topic based classification, hence the distributions usability will suffer as a whole. IN order to solve that misery, a tag based classification will be invented. Distributing it effectively, *mandatory* classification will be enforced from the tooling. Yet another turn around during check in. We, the Group line promoter, want(ed) to avoid this. Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-10-17, 17:40 GMT, you wrote:
Great - now you can just put those tags in the Group: field now and call it a day:
julia computing astronomy chemistry electronics mathematics physics ...
OK, you don't have to bother because all these keywords are already in description and zypper se -d will find them. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Thou shalt not nede to be afrayed for any bugges by night. -- Coverdale's 1535 translation of Psalm 91 (or Christopher Higley's 1972 thesis explaining why programmers' are nocturnal beasts) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2019-10-17 20:00, Matěj Cepl wrote:
On 2019-10-17, 17:40 GMT, you wrote:
Great - now you can just put those tags in the Group: field now and call it a day:
julia computing astronomy chemistry electronics mathematics physics ...
OK, you don't have to bother because all these keywords are already in description and zypper se -d will find them.
Sure. And people could just ask Google for "site:packagehub.suse.com games" yet they probably don't, in favor of https://packagehub.suse.com/package-categories/games/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-10-17 13:19, Simon Lees wrote:
I would expect that people who object to a proposal should raise there objections as a small number of people did.
and here it is: I object to premature activities in any direction. ... as long as there is not a consensus here on this list. In my opinion, creating SRs at this point is trying to create facts in an unfair way: https://build.opensuse.org/request/show/740389 --> declined: Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Jan On 10/17/19 6:26 AM, Jan Engelhardt wrote:
MAY OF 2018.
[1.0] TC: too strict requirements on group JE: let's give ourselves some time to come up with better options
[1.0] TC: only yast and rpm display the group value, let's remove it JE: there are other programs that can display or use it in some fashion
[1.0] TC: it does not really make sense to install packages based groups JE: the Group field's purpose is not for installation, but browsing
I suspect you missed the post that would fit about here [1.1] in the timeline where you agreed that groups should be removed and hence others probably thinking they had a consensus and starting to do the work in yast etc which was completed some 12 months back 1.1: https://lists.opensuse.org/opensuse-factory/2018-05/msg00465.html -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Thu, 2019-10-17 at 18:28 +0200, Hans-Peter Jansen wrote:
Am Dienstag, 27. August 2019, 14:40:39 CEST schrieb Hans-Peter Jansen:
OTOH, I cannot see a good reason to *actively* *eliminate* the Group line either, other than throwing away good work of good people.
A thousand years ago, people incited the crusades, just because there were other people, that doesn't fit their expectations.
Folks, don't incite a crusade against Group lines, please. They will not hurt you.
This week, my fear became reality. It started with spec-cleaner removing Group lines incidentally, and now Richards butchery.
@Dominique: is there any way to repel this landslide from hitting factory?
This is going to be nasty - Even if the review team now were to block all such submissions: maintainers that decided to accept this change in their devel project would have to actively and manually revert the change again. In other cases, when the request would be declined now, all we gain is that it will still be part of a future update on the packages. I'm afraid this all might bring Tumbleweed to a stand-still for a couple days. It is close to impossible for me to get a staging project setup that works AND does not have any of this group-war intermingled. @Richard: would you be willing to at least revoke all the pending SRs until this is settled for good? This could at least minimize the impact on maintainers that do not follow this list and that accept the change in good faith. Cheers, Dominique
On Friday 2019-10-18 08:07, Simon Lees wrote:
[1.0] TC: too strict requirements on group JE: let's give ourselves some time to come up with better options
[1.0] TC: only yast and rpm display the group value, let's remove it JE: there are other programs that can display or use it in some fashion
[1.0] TC: it does not really make sense to install packages based groups JE: the Group field's purpose is not for installation, but browsing
I suspect you missed the post that would fit about here [1.1] in the timeline where you agreed that groups should be removed and hence others probably thinking they had a consensus and starting to do the work in yast etc which was completed some 12 months back
1.1: https://lists.opensuse.org/opensuse-factory/2018-05/msg00465.html
Is it not allowed to change one's mind? As part of that thread, there came a time when I realized, hey, groups not so bad after all if you actually spend time on the matter. https://lists.opensuse.org/opensuse-factory/2018-05/msg00508.html "I would totally want to retain RPM groups [for games]". The natural question then is, why stop at games. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/18/19 6:23 PM, Jan Engelhardt wrote:
On Friday 2019-10-18 08:07, Simon Lees wrote:
[1.0] TC: too strict requirements on group JE: let's give ourselves some time to come up with better options
[1.0] TC: only yast and rpm display the group value, let's remove it JE: there are other programs that can display or use it in some fashion
[1.0] TC: it does not really make sense to install packages based groups JE: the Group field's purpose is not for installation, but browsing
I suspect you missed the post that would fit about here [1.1] in the timeline where you agreed that groups should be removed and hence others probably thinking they had a consensus and starting to do the work in yast etc which was completed some 12 months back
1.1: https://lists.opensuse.org/opensuse-factory/2018-05/msg00465.html
Is it not allowed to change one's mind? As part of that thread, there came a time when I realized, hey, groups not so bad after all if you actually spend time on the matter. https://lists.opensuse.org/opensuse-factory/2018-05/msg00508.html "I would totally want to retain RPM groups [for games]". The natural question then is, why stop at games.
" Maybe this insight helps in finding where to go :)" isn't really a strong indication if others were happy with the removal I can clearly see who they thought they had a general consensus and thefore started the removal work, it was another year before you gave a strong indication that you wanted to keep them and by that time much of the work behind the scenes was done. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Friday 2019-10-18 10:02, Simon Lees wrote:
Is it not allowed to change one's mind? As part of that thread, there came a time when I realized, hey, groups not so bad after all if you actually spend time on the matter. https://lists.opensuse.org/opensuse-factory/2018-05/msg00508.html "I would totally want to retain RPM groups [for games]". The natural question then is, why stop at games.
" Maybe this insight helps in finding where to go :)" isn't really a strong indication if others were happy with the removal I can clearly see who they thought they had a general consensus and thefore started the removal work,
Fair enough.
it was another year before you gave a strong indication that you wanted to keep them and by that time much of the work behind the scenes was done.
What was done behind the scenes merely involved touching yast and zypper AFAICS (the other part was then in front of the curtain). It's not like yast is or could be the only catalog browser in the world, so I put that off with a shrug, since the metadata was still there and could be used by any other category browser (it's not like yast is holding a monopoly), so become a new category browser as a proof. As users started to notice yast suddenly lacked a feature, the raison d'etre of the proof kind of came to be. This might give an insight as to why the harder objections came in rather later: because I did not value yast as much as the metadata. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/18/19 6:54 PM, Jan Engelhardt wrote:
On Friday 2019-10-18 10:02, Simon Lees wrote:
Is it not allowed to change one's mind? As part of that thread, there came a time when I realized, hey, groups not so bad after all if you actually spend time on the matter. https://lists.opensuse.org/opensuse-factory/2018-05/msg00508.html "I would totally want to retain RPM groups [for games]". The natural question then is, why stop at games.
" Maybe this insight helps in finding where to go :)" isn't really a strong indication if others were happy with the removal I can clearly see who they thought they had a general consensus and thefore started the removal work,
Fair enough.
it was another year before you gave a strong indication that you wanted to keep them and by that time much of the work behind the scenes was done.
What was done behind the scenes merely involved touching yast and zypper AFAICS (the other part was then in front of the curtain).
Once the "consensus" was found the next step seems to have been that it then went through a internal SUSE change process to be accepted into SLE which is the fate that has been mentioned in some cases. Because of that and rpmlint now being fixed hence why people think it is ok to drop it. rpmlint has been undergoing major changes so I guess that's why it took so long for that part to fall into place otherwise i'm sure they would have started being removed sooner. Now that all those pieces have fallen into place based off the consensus over a year ago SUES engineers can now remove the Group tag from packages in SLE and other products and most Managers are under the impression that the tags are not needed and can freely be removed. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Fri, Oct 18, 2019 at 4:57 AM Simon Lees
Once the "consensus" was found the next step seems to have been that it then went through a internal SUSE change process to be accepted into SLE which is the fate that has been mentioned in some cases. Because of that and rpmlint now being fixed hence why people think it is ok to drop it. rpmlint has been undergoing major changes so I guess that's why it took so long for that part to fall into place otherwise i'm sure they would have started being removed sooner.
rpmlint upstream still maintains a Group tag check, openSUSE downstream modified this to match its own policy (different groups set, etc.), but now it's disabled like in Fedora's rpmlint policy. -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 17/10/2019 16:15, Matěj Cepl wrote:
2. Because of #1, for most package maintainers Group label is nothing anybody cares about. It used to have to be filled with something which gets through rpmlint and that’s how far most package maintainers IMHO cares.
3. Given #2, groups are such mess, no user uses them for searching for their software, because nobody knows whether Network Manager is in Productivity/Networking/General, System/Networking, or something else. See below on problems with tree hierarchies.
Yes the only problem with groups is the actual groups that were created, there's no attempt to fix the actual problem (except for Jan) just an unwarranted attempt to obliterate the tag in spec files. In fact I've just built ffmpeg-4 with a local rpmbuild using the line in the spec file: Group: Productivity/Multimedia/Video/Editors and Convertors:Multimedia/Audio/Editors and Convertors This is now present in the GROUP tag within the rpm that was generated. This means that the Group: tag in the rpm can also be used for multiple tags as proposed by Jan. Regards Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2019-10-18 at 16:37 +1030, Simon Lees wrote:
I suspect you missed the post that would fit about here [1.1] in the timeline where you agreed that groups should be removed and hence others probably thinking they had a consensus and starting to do the work in yast etc which was completed some 12 months back
1.1: https://lists.opensuse.org/opensuse-factory/2018-05/msg00465.html
So, the fact that Jan agreed back then was taken as an indication that "consensus" had been reached? Seriously? The fact that "nobody complained on the mailing list" does _not_ imply consensus. Of course, "consensus" is not required on stuff like this, some solid majority would be enough. But I doubt that this majority exists, either. The FATE mentioned is about YaST only. I see no compellent reason why all group tags need to be ditched just because YaST doesn't support them any more. I guess nobody would object if the statement was "SUSE is not going to invest resources into Group tag maintenance any more". But even that doesn't justify deleting the tag everywhere. Martin
On 10/23/19 8:06 PM, Martin Wilck wrote:
On Fri, 2019-10-18 at 16:37 +1030, Simon Lees wrote:
I suspect you missed the post that would fit about here [1.1] in the timeline where you agreed that groups should be removed and hence others probably thinking they had a consensus and starting to do the work in yast etc which was completed some 12 months back
1.1: https://lists.opensuse.org/opensuse-factory/2018-05/msg00465.html
So, the fact that Jan agreed back then was taken as an indication that "consensus" had been reached? Seriously?
The fact that "nobody complained on the mailing list" does _not_ imply consensus. Of course, "consensus" is not required on stuff like this, some solid majority would be enough. But I doubt that this majority exists, either.
In openSUSE development this is exactly how it works. If you would like to propose a distro wide change you do so here, it gets discussed and once some form of consensus is reached the people wishing to make the change are free to do so. The changing package guideline process similarly follows this although to reflect our current way we are using these too lists it probably should also be updated to mention discussion should happen here rather then the packaging list https://en.opensuse.org/openSUSE:Packaging_guidelines_change_process Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Hello, On Oct 24 13:57 Simon Lees wrote (excerpt):
once some form of consensus is reached the people wishing to make the change are free to do so.
sigh. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/24/19 5:25 PM, Johannes Meixner wrote:
Hello,
On Oct 24 13:57 Simon Lees wrote (excerpt):
once some form of consensus is reached the people wishing to make the change are free to do so.
sigh.
Your more then welcome to use the process to change the process if you can think of a better one :-) But this is the least bad one I can think of :-) -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 17/10/2019 10.31, Wolfgang Rosenauer wrote:
Am 17.10.19 um 02:15 schrieb Simon Lees:
This wasn't the way you worded it in your original email. If this is what your thinking it seems you are trying to run a "distro-wide endeavor" without the buy in of most of the distro. It seems while some other people think "tags" might be useful, No one else agrees that the current system is useful, the fact that the info has been removed from openSUSE's tools, maybe the only place the current groups could be really useful is to convert to a new "tag" system if there comes to a consensus on that.
I agreed a few times with Jan that I find the groups helpful. That was up to 15.0 or 15.1 my primary source to browse available software based on categories. And yes, it was not always accurate but better than anything else we had and now have. At least within YaST there is no useful way for me to search for software where I don't know the name for. Tags might be a better thing but they do not exist.
So what are people using to find certain packages available in the repos if you you look for a category?
I do use the "view by package group" in YaST to search for useful applications, when not knowing a name for what I search, or when searching for new applications that I don't even know they exist.
I fired up YaST to verify, and to my utter surprise the feature has been removed in 15.1! There is no longer "view by rpm groups!
This is so unbelievable that I fired up a virtual machine with 15.0 to verify: it is true.
Yes. The YaST Team was requested to remove it via Fate and we did it in October 2018. See: https://github.com/libyui/libyui-qt-pkg/pull/58 https://github.com/libyui/libyui-ncurses-pkg/pull/27 Cheers -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019/10/29, summary of Jan E's 10/16 msg by Linda W.:
-----------(Rough summary): MAY OF 2018. Comments by various authors: [1.0] TC, [1.0] TC, [1.0] TC, [1.3] WR, [1.4] WR, [1.5] MC, [1.6] MC [Note1] Conclusion: [Note2] move to "multi-valued" "Tags" from single-valued "Group" Supporting args by [1.3] Jan E. and suse proponents [1.9] Scott B., [1.4] Wolfgang R., [1.7] Adam M., & [1.8] Stefan B. -as- (Summary:) useful for indexing, exploring, finding-SW, & how to use; incl. use by Debian (initial src for other distros)
No opponent arguments for using future of a "Tags value" as multi-valued "Group" from: Tomas C., Matěj C., Michal K.
Note1: Supporters made case to work with it. Note2: Being meritocracy(?really?) decision to keep "Group tag"[sic].
Not exactly,: not as a *single-value* field, but as a multi-valued field, to-be-kept & enhanced.
JUNE OF 2019.
[2.0] IG: Fedora guy proposing adopting Fedora's deletion of such fields from Debian's packaging that included it, and Suse's re-implenting of such. (JE: Link to prev. discussion). [2.1] NG: Dislike of classification removal by Fedora + proposing continuation of it in some form.
[2.2] TC: "We are"[sic - "I am"] already in process of abandoning single-value group field as useless and a few are wrong.
CONCLUSION: JUNE 2019 - addition of more people aware and opinioned.
Note parallel to multiple, earlier, suse discussions/issues where a "do-acracy", [those who "do", "rule"] overrides a group consensus for alternate or parallel approach. There is more than one example, though some may primarily remember only one big example. I've been using suse for a bit over 2 decades (since the late 90's) and have seen this pattern repeated including examples involving current and previous board members, not all of whom will see this summary due to their own filters (some technical and some unconscious).
AUGUST 2019.
[3.0] TC: "As there was no major pushback" and "Your lonely complain[t] is not one"
A prime "doer" that no one has stopped him from him "doing" deletion work and dismisses arguments, against, as these discussions aren't by "doers".
Other views by SK, HPJ, BV, and JE expressed to: - not required Group line though noting no good reason to eliminate it - Noting that removal is added (extra) work.
ACTIONS (AUG. 2019) that: * Not enforcing Groups in ".spec" files and allowing freeform specification (rpmlint) AND not removing existing lines. * Showcase a tag browser w/backwards compat. using group as a tag.
OCTOBER 2019.
[] Group-removers express "Doacracy" Credo: maintainers are the *doers* and [4.2, 4.3] says there are problems with current system.
Group-to-Tags supporters display upset at doacracy's unilateral actions. [4.0, 4.4] JE & [4.5] HPJ
For exact footnote hyperlinks, see Jan Engelhardt's original summary: https://lists.opensuse.org/opensuse-factory/2019-10/msg00095.html. I won't, _explicitly_ offer my opinion on providing users with more information and/or "choice", but note that the less information users or user/implementors have, the more likely it seems they will go along with what has been chosen for them. I thought I had a point in all this, but in summarizing this, I seem to have misplaced it, and sorry if you felt reading this was time wasted. Carry-on -- all seem normal. p.s. - oh screw it, has anyone tried classifying music into the pre-existing '8' categories (now over 200 and still not a free-format list) that were provided by some music players 20-30 years ago and really thought that just one category applied to their music? Is software that different? 𝓛inda -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.10.19 um 23:09 schrieb L A Walsh:
p.s. - oh screw it, has anyone tried classifying music into the pre-existing '8' categories (now over 200 and still not a free-format list) that were provided by some music players 20-30 years ago and really thought that just one category applied to their music? Is software that different?
That's an interesting direction to look in: what other classifications are out there and how well do they work? I think art is always a bit hard to classify, although art historians try to put it into boxes as much as possible. But scientific papers are actually classified by systems very similar to rpm Group tags: * the Mathematics Subject Classification (MSC) [1], * the Physics and Astronomy Classification Scheme (PACS), discontinued but apparently still used [2], * the classification of papers in arXiv [3]. These are all hierarchical, and either allow just one classification, or have a primary classification. These classifications are probably not always perfect, and just like with Group tags it might happen that no group matches exactly, or multiple groups apply. Yet judging from their usage the benefits seem to outweigh the costs. Best regards, Aaron [1] https://en.wikipedia.org/wiki/Mathematics_Subject_Classification [2] https://en.wikipedia.org/wiki/Physics_and_Astronomy_Classification_Scheme [3] https://arxiv.org/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (25)
-
Aaron Puchert
-
Ancor Gonzalez Sosa
-
Bernhard Voelker
-
Carlos E. R.
-
Dave Plater
-
Dominique Leuenberger / DimStar
-
Hans-Peter Jansen
-
Jan Engelhardt
-
Johannes Meixner
-
L A Walsh
-
Manfred Hollstein
-
Martin Pluskal
-
Martin Wilck
-
Matěj Cepl
-
Matěj Cepl
-
Michael Ströder
-
Neal Gompa
-
Patrick Shanahan
-
Richard Brown
-
Ronan Arraes Jardim Chagas
-
Simon Lees
-
Stasiek Michalski
-
Stefan Brüns
-
Stefan Seyfried
-
Wolfgang Rosenauer