| Re: [eclipse.org-architecture-council] IPZilla rant |
|
I think this case is even worse since it’s a pretty complex _javascript_ app with deep dependencies on a huge collection of npm modules. Watching Mickael struggle with all this, I am very hesitant to do such a project at Eclipse. Tooling
is a big issue, but the licensing of all those npm modules are pretty suspect making it questionable whether we can even get approval for all this. This is likely a discussion mainly for the board level since they make the rules. But I believe we have influence as the body of technical leaders at Eclipse. We managed to figure this out with Maven. And, yeah, npm modules tend to be smaller
and more plentiful. What is our recommendation of changes that need to be done to support contributing to the _javascript_ ecosystem as richly as we’ve contributed to the Java one? Doug. From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx <eclipse.org-architecture-council-bounces@xxxxxxxxxxx>
On Behalf Of Billings, Jay Jay Mickael, I think you're speaking truth here, brother. While I think there is room for improvement in the EDP and the IP policy (and I realize we don't have any sway over the latter...), I feel like there are substantially
large gains to be had in improved tooling around working through CQs and other tasks. Jay Jay Jay Billings Team Lead, Scientific Software Development From:
eclipse.org-architecture-council-bounces@xxxxxxxxxxx <eclipse.org-architecture-council-bounces@xxxxxxxxxxx> on
behalf of Mickael Istria <mistria@xxxxxxxxxx> Hi all, For the 1st time, I've been in the shoes of someone willing to contribute a new project to Eclipse Foundation and who had to face the challenge of opening multiple CQs. I think that more than the process, the tool is really irritating at that scale. I've opened
https://bugs.eclipse.org/bugs/show_bug.cgi?id=538424 to track my rants. I'm sending this to AC because it's where we usually discuss how the process can be made simpler and more welcoming. My feeling on this is that often, the process is simple enough, but the tools to process it require hard work from contributors. Basically, repetitive and error-prone tasks; or tasks that requires
advanced knowledge about the EDP while tool fails at (re)explaining or linking to the right part of EDP at this point. I think a UX audit of the PMI (mostly to be more be more "educative" about why and what is a release and what are the possible variations and how to profit from them) and IPZilla (to reduce the
cost of contributing new projects relying on a lot of other libraries) would have a better ROI than trying to deeply renovate the EDP. Cheers, -- Mickael Istria Eclipse IDE developer, for
Red Hat Developers |