| Re: [ecf-dev] ECF project and Tycho |
|
Hi All,
I have several comments about Tycho work, as well as some requirements below. First, I want to say that I appreciate Aleksandar's/Mat's/Red Hat's offer of assistance. However, there are several things to consider here. 1) I'm not convinced that participation in the LTS project...as currently formulated...creates enough value for us to justify participating. As with much these days, LTS creates additional releng work for ECF committers with no resourcing (see discussion on [1]). Further, I'm not convinced that LTS delivers sufficient value for ECF consumers/community. ECF has received quite a large number of requests for enhancements/additions [e.g. 2-4] as well as documentation, demos, examples, etc, and given our very limited resources (i.e. all volunteer/unpaid committers) currently I don't think doing what's necessary for LTS participation can be justified relative to addressing...as best we can...these longstanding community needs. 2) As Markus says, it's not at all obvious that Tycho is best choice for us to spend our releng resources on. Buckminster is/has been working fine for us, and it will remain well-supported due to our existing relationships/history/knowledge/usage. Gradle is achieving popularity quickly in OSGi world. Bnd/bndtools is a possibility. Sadly, IMHO the OSGi tooling world...particularly WRT Eclipse...is now a total mess, and IMHO the last thing we/I can afford is 'releng churn'. If we were to expend all of our meager resources on releng alone, we simply would/will not be able to do anything that the community clearly wants [i.e. 2-4]. 3) As the person most directly responsible for the existing releng infrastructure, I defer to Markus' judgment on what is done moving forward. I ask that all committers also defer to Markus' final judgment on matters ECF releng. Question for Aleksandar/Mat: Are you offering to have Mat join the ECF project as a committer? If yes, it makes it much easier for us to justify putting committer resources into using Tycho. If no, that makes it very hard for me to justify the required ECF committer time necessary to do the transition and maintain it. Another option (btw) is that you/Red Hat provide support for existing ECF committers. Again, this would make it much more reasonable for us to justify the committer time required to work on a Tycho-based build. Particularly given our involvement with OSGi EEG/Standards (R6 RS/RSA CT-compliant impl), as well as IoT (e.g. Wim's talk) this might be appealing to multiple parts of Red Hat. I'll leave with you, Aleksandar, to consider and/or propose something to Red Hat. Please let me know if you want more info, or to discuss. Wim and all: As project lead, my own requirements for any Tycho efforts by ECF committers are the following: 1) The existing build must not be destabilized or broken at any point 2) If changes are required to existing metadata (manifests, etc) the existing build must be updated prior to pushing the change to master, so that stability be maintained. In other words: the existing builds (on master) cannot be destabilized until all existing projects are successfully migrated. 3) When/If the transition is done, some ECF committer(s) (you, Markus, Matt, multiple people, etc), be identified and resourced to maintain a Tycho-based build. Thanks, Scott [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=435889 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=426186 [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=378350 [4] https://bugs.eclipse.org/bugs/buglist.cgi?bug_severity=enhancement&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=RT&list_id=10414498&product=ECF&query_format=advanced On 11/5/2014 8:12 AM, Wim Jongman wrote:
|