-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Contribute to some Eclipse.org project to include it in Eclipse packages #25
Comments
m2e is expected to install required extensions automatically as part of project import and there is also quick-fix for users who chose not to let m2e install. This should be almost transparent to the users, so if this does not happen to you, open a bug report against m2e and provide steps m2e developers can use to reproduce the problem. I also would not mind if interested eclipse epp packages included m2eclipse-tycho. The code is released under EPL license, so there shouldn't be a problem from IP point of view. Somebody just needs to do the work to file the CQs and update relevant EPP packaging scripts. Eclipse already ships large amount of thirdparty code, so I don't why m2e-tycho can't be treated the same. I have absolutely no interest moving this code to Eclipse foundation, however. I have reasons to believe Eclipse Foundation mostly concerned about large corporate members like IBM or RedHat. From my experience small/individual developers are treated as second-class citizens. Not worth it for me, given other options to get the code to the users. |
I believe the Foundation is concerned about all members. Certainly at Eclipse Board meetings, as an elected committer representative who is not an employee of a large corporate member, I am especially sensitive to the concerns of all members. I never feel like I'm treated as a second-class citizen. Quite to the contrary, I know that my voice and vote carry weight, and that all opinions at board meetings are considered respectfully. I think the biggest concern about hosting a project at the Foundation is the personal overhead of the IP process. In that regard, there is significant support for simplification from even the large corporate members. I speak from personal experience as a member of the Board's IP Committee. Folks were open to suggestions, for example, increasing the lines of code that can be contributed without IP review from 250 lines to 1000 lines. There are ongoing discussions about how further to improve (simplify/streamline) the IP process. With support from experienced people like Mickael Istria, it might not be so hard to move your project to Eclipse. I understand that the burden is significant, and I understand if that's a reason not to do the work; we'd all rather be developing. But in the end, I don't I feel, based on my personal experience, that individuals are treated as second class at Eclipse. |
I didn't mean small/individual developers are necessarily treated differently than large corporate members. What I meant, Eclipse policies and dev process are heavily biased to benefit large corporate members. IP policies add non-trivial overhead to day-to-day load and for the most part only relevant for large corporations, for example. And release paperwork. Simply does not make any sense for the small guys like myself. As m2e and tycho project co-lead, I have pretty good idea what's involved in moving code to and developing at Eclipse. I also know what benefits having the code at Eclipse provides. And I simply cannot justify the overhead. Having said that, I will be willing to help Eclipse EPP developers integrate m2e-tycho as a thirdparty dependency. I believe this will provide best of the both worlds. I will continue to work on m2e-tycho here, at Github, at my own time and pace. And Eclipse EPP users will get out-of-the-box get m2e-tycho integration. |
I agree that Eclipse's IP policy is designed significantly, if not for the most part, to benefit consumers with extremely picky legal concerns. Of course that's mostly the case only for large corporate consumers (not necessarily even members), with heavy-weight legal departments. But you should be aware that on the Eclipse Board, the representatives of such organizations listen to the types of concerns you've expressed and that we as a group are actively working towards improvements. Certainly I feel your pain personally as the lead for a heavily-used one-man project. I actively avoid third party dependencies simply to avoid the IP overhead associated with such things. Piggyback CQs are a personal pet peeve that I'm hoping I can help eliminate with automated processes, though the overhead of the tool development work involved dwarfs the amount of time I'll personally ever save... The way I look at it isn't to say that this IP stuff makes no sense for me personally. In a sense that's certainly the case. I don't care what l install on my computer as long as it's not a virus, and I'm sure I'm not alone. But I do see personal the personal benefit of creating software that's broadly consumed. Consumers with large legal departments sometimes have money to spend on further development. But as you say, one must weigh the costs against the benefits. Given the obvious costs and the less than tangible benefits, I certainly won't fault you on the general premise that the overhead isn't justifiable for you personally. I can't help but feel that this idea of EEP packages consuming m2e-tycho as a third party dependency is somehow ironic. All the IP overhead associated with that would still need to be incurred by someone. That would include the code you've authored and the third-party libraries distributed along with your code. Once this cost incurred, it would need to be regularly repeated down the road, and yet it would be much more streamlined down the road if the project were hosted at Eclipse after passing such a review. That makes me very sad. I also agree that the release "paper work" is annoying at best and it always strikes me as somewhat useless. Who even looks at this stuff? I personally try to do as little as possible! As such, the overall effort for two projects was less than an hour of work. Thank goodness for the IP log generator, which is the only part of the process that seems to be of some limited use (to the types of consumers we talked about above). In any case, I'll continue do what I can personally to help improve the situation, and I would hope that you get help and encouragement to host your useful technology at Eclipse. I should mention that I love Tycho! Without the ability to do reliable and fast local Maven/Tycho builds for Oomph, it would not be possible to do development. |
@ifedorenko Have you quantified the overhead? Maybe you should come to the cross-project mailing-list and try to recruit someone ready to share the extra-work with you. |
Currently, someone doing some Tycho stuff (which is most of plugins developers nowadays) has to install m2e-tycho by themselves. Figuring out that one need to install something is not trivial, the quick-fix on pom editor help a little, but that's still an additional step to get ready.
It would be more convenient to add m2e-tycho to some Eclipse project so that it could be included in the packages targeting Eclipse development (Committers, RCP/RAP, XText...).
The text was updated successfully, but these errors were encountered: