On Tue, Nov 12, 2019 at 7:03 PM Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote: > > > > On Tue, Nov 12, 2019 at 7:55 PM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: >> >> Hi, Aleksandar, >> >> On Tue, Nov 12, 2019 at 6:40 PM Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote: >> > >> > >> > >> > On Tue, Nov 12, 2019 at 7:31 PM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: >> >> >> >> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: >> >> > >> >> > On 12. 11. 19 17:02, Aleksandra Fedorova wrote: >> >> > > Again, no one forces you or any other packager to use modularity >> >> > > tooling right now. >> >> > > >> >> > > As Fedora developer you have a choice to join the effort, bring your >> >> > > input and use cases, try and test (and revert if it doesn't work) or >> >> > > you can stay away from it and keep using same tools as before. >> >> > >> >> > >> >> > Unfortunately, this is not true. It is not possible to ignore modularity, if the >> >> > dependencies are modularized. It is not possible to ignore modularity, if the >> >> > dependents are modularized. It is not possible to ignore modularity, if the >> >> > packages I wish to use are modularized. >> >> > >> >> > I wish Fedora packagers and users cold "stay away". But that is currently not >> >> > possible. My proposal to keep all defaults as non-modular packages would make it >> >> > exactly so. >> >> >> >> Ursa Prime effort achieves the same goal. It removes the "viral" part >> >> of Modularity I think. >> >> >> >> As well as policy which restricts the set of default modules, which I >> >> think we need to change from "FESCo approves new default modules" to >> >> "each request for new default module should be treated as a >> >> System-Wide Change". >> >> >> >> Again I fail to see the _technical_ difference between the ursine rpm >> >> package and a package which was built as a part of default stream. It >> >> is the same rpm spec from the same dist-git sources, which is built by >> >> the same rpmbuild command. Thus I think it is a process/policy >> >> difference, which we should resolve. >> >> >> >> And I will support a hard block on creating new default streams, until >> >> it is resolved. >> >> (With the exception of eclipse probably, which is in a broken state >> >> already, and for which we need to find a solution.) >> > >> > >> > The way Eclipse is treated makes me really sad and kind of regret the time spent on Fedora over the years! Being forced to be a module but blocked to be default stream by FESCo arguing over whether it wants modularity (sorry, this is how it looks) is the best way for Fedora to show to project and people they are not wanted in the community! >> > The net effect for me personally is to totally move my eyes away as I get really pissed off. >> >> I am sorry that it looks this way for you, but you are misinterpreting it. >> >> FESCo was willing to enable the default stream for eclipse the moment >> it was requested given by the fact that it actually solves the >> problem. But it wasn't the case. > > > Would you please elaborate how this was not the case? There was the glassfish package provided by two streams issue which has been fixed in maven module but eclipse still is not approved as default package. What am I missing? You can check the logs from the FESCo meeting. To make a proper decision FESCo needs to understand which problem we are solving, what is the proposed solution what is the impact of this solution and what are the alternatives. The IRC meeting format is not the best way to discuss complex things that is why it usually needs a preparation in advance in a form of ticket to FESCo via Pagure which provides a common context for the conversation. The previous decision on eclipse was AGREED: Drop the unmaintained eclipse from the non-modular repositories and ship module streams of eclipse. Whenever the conflicts are resolved later, we can make a default stream available (+6, 0, 0) zbyszek to add eclipse to fedora-obsolet-packages mbooth to drive the retirement of non-modular eclipse The bug about eclipse not being installable is approved as FESCo FE (+6, 0, 0) To move forward we need at least to get a status update on it. 1) status of retirement of non-modular eclipse packages 2) status of conflict between maven and eclipse modules 3) status of the module - is it verified that enabling eclipse module explicitly now solves the problem? - will "dnf install eclipse" work on new Fedora with all updates? - will "dnf install eclipse" work on Fedora with updates and maven module installed previously? - .. maybe some other cases? We didn't get all of this information during the meeting, there was no feedback in the relevant BZ with the verification either, and the attempt to verify the solution during the meeting provided contradicting results. Thus we asked to provide the data asynchronously via FESCo ticket. -- Aleksandra Fedorova bookwar _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
