[opensuse-packaging] Board Decision on groups in spec files.
Hi All, It likely comes as no surprise to anyone one that the groups in spec file issue was raised with the board (one of these was on a public list). In this specific email we are acting in our role of "helping resolve conflicts" complaints were also made directly about the behavior of certain individuals (again including on this list). The board has chosen to deal with these issues in private as is our general approach to such issues. Firstly the board generally agrees that in the following thread [1] there was a plan and general agreement to follow it for the removal of groups if certain other issues were resolved. As such we believe they acted with good intentions when starting to remove group support from various places such as Yast, rpmlint and spec cleaner. The board decided to wait until the discussion on new proposals settled down, before going forward with the issue, at the time we had the discussion we believed this to be the case. Of all the proposals discussed the board agreed that the one submitted by Ludwig [2], to move groups into the repository meta data is technically the best solution and the one most broadly supported by contributors. As such we welcome any contributions from the community towards getting this working and integrated into tooling where it makes sense such as Yast and software.opensuse.org Given that our core tooling no longer displays groups and that the board has a copy of all the existing groups that can be used as a starting point for the new system the board has decided that including groups in spec files should now be optional with the final decision resting with the maintainer as some maintainers may still use there spec files in distro's that still support groups although we believe most packages going into factory wont. We realize that this decision will not make everyone happy but hopefully it eventually leads to better group support in the future. 1. https://lists.opensuse.org/opensuse-factory/2018-05/msg00460.html 2. https://lists.opensuse.org/opensuse-factory/2019-10/msg00263.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
Em qua, 30 de out de 2019 às 02:07, Simon Lees <sflees@suse.de> escreveu:
We realize that this decision will not make everyone happy but hopefully it eventually leads to better group support in the future.
1. https://lists.opensuse.org/opensuse-factory/2018-05/msg00460.html 2. https://lists.opensuse.org/opensuse-factory/2019-10/msg00263.html
Hi, Is this kind of technical decision in the scope of the Board? [0] says: "The board should provide guidance and support existing governance structures, but shouldn't direct or control development, since community mechanisms exist to accomplish the goals of the project. The board should document decisions and policies." Regards, Luiz [0] https://en.opensuse.org/openSUSE:Board -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 11/1/19 1:29 AM, Luiz Fernando Ranghetti wrote:
Em qua, 30 de out de 2019 às 02:07, Simon Lees <sflees@suse.de> escreveu:
We realize that this decision will not make everyone happy but hopefully it eventually leads to better group support in the future.
1. https://lists.opensuse.org/opensuse-factory/2018-05/msg00460.html 2. https://lists.opensuse.org/opensuse-factory/2019-10/msg00263.html
Hi,
Is this kind of technical decision in the scope of the Board?
[0] says: "The board should provide guidance and support existing governance structures, but shouldn't direct or control development, since community mechanisms exist to accomplish the goals of the project. The board should document decisions and policies."
If the matter had not been raised with the board then it would not be within it's scope to deal with. However given that this issue was raised with the board by parties with strong views on both sides as well as people caught in the middle unable to do there job "resolving the conflict" fits within the board's role. In this case the board decided cleanest solution to the conflict was to recommend a technical solution. The board is still somewhat limited in its power here, in that we can not compel people to do work, we can only tell them not to do certain things which generally is something the board tries to avoid. For example we can state that groups shall be optional and up to the maintainer because that is not forcing anyone to do work, likewise if we felt it was the best solution we could have told maintainers that submissions that drop the group field won't be accepted. What we can't do though Is tell everyone that they need to go through and remove groups likewise we can't tell the yast team that they need to re add support for groups or tell someone that they must go and implement something in a certain way. All of these actions would force someone to do work and we don't have that power. What we can do though is recommend that if people are interested in groups, "the following would be a good way" but whether anyone chooses to go away and implement that is a completely different thing and they may choose to do something different which would also be fine. But in this case the fact that there is a better solution played a role in our (well at least my decision to support the proposal the board put forward). -- 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-11-01 00:38, Simon Lees wrote:
The board is still somewhat limited in its power here, in that we can not compel people to do work, we can only tell them not to do certain things which generally is something the board tries to avoid. For example we can state that groups shall be optional and up to the maintainer because that is not forcing anyone to do work,
Well, you could spin the argument either way: Removing the Group line and moving it to a separate dataset is work to construct this new format. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 11/1/19 7:13 PM, Jan Engelhardt wrote:
On Friday 2019-11-01 00:38, Simon Lees wrote:
The board is still somewhat limited in its power here, in that we can not compel people to do work, we can only tell them not to do certain things which generally is something the board tries to avoid. For example we can state that groups shall be optional and up to the maintainer because that is not forcing anyone to do work,
Well, you could spin the argument either way: Removing the Group line and moving it to a separate dataset is work to construct this new format.
Yep it is work, in the same way that keeping the data up to date is work or maintaining a package is work, people can choose not to do this work like they can choose not to do any other work. -- 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
participants (3)
-
Jan Engelhardt -
Luiz Fernando Ranghetti -
Simon Lees