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?
So the delay of the decision on Eclipse has nothing to do with the
generic Modularity trouble, it is based solely on the fact that we
need a working solution, and there was a certain miscommunication and
lack of coordination in providing it.
And this is exactly what I said in my previous mail. We treat eclipse
as exceptional case and it is not affected by this conversation.
--
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
--
Alexander Kurtakov
Red Hat Eclipse Team_______________________________________________ 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
