[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] ECF project and Tycho

----- Original Message -----
> From: "Scott Lewis" <slewis@xxxxxxxxxxxxx>
> To: ecf-dev@xxxxxxxxxxx
> Sent: Wednesday, 5 November, 2014 6:08:26 PM
> Subject: 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.
> 

I would be happy to join the project as a committer.

> 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

Of course. As mentioned in another mail, the risk of introducing Tycho is very low and we can iterate on the implementation until the build outputs are identical before switching over.

> 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.

Absolutely. Until the switch, the "canonical" build must be the existing one.

> 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.
> 

I can't speak for others, but if I were a committer on the project then certainly I could justifiably commit a portion of my time to the ongoing maintenance of the Tycho 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:
> 
> 
> 
> Hi,
> 
> I am definitively in favor of making ECF build with Tycho. I know the current
> build system a little so I can help as well in this area.
> 
> Thanks for initiating this Alexander.
> 
> Matt did you already do some work in this area? How do you normally structure
> your parent poms? One parent or several?
> 
> The buckminster and tycho build can happily live side by side so there is no
> immediate risk involved for the current build.
> 
> Cheers,
> 
> Wim
> 
> On Wed, Nov 5, 2014 at 4:21 PM, Markus Alexander Kuppe <
> ecf-dev_eclipse.org@xxxxxxxxxxx > wrote:
> 
> 
> On 05.11.2014 16:15, Markus Alexander Kuppe wrote:
> > Lets focus on more important stuff than auxiliary build systems. :)
> 
> E.g. purge outdated ECF bits from the git repository [1] so that new
> adopters don't get confused by compiler errors [2].
> 
> M.
> 
> [1] https://bugs.eclipse.org/424259
> [2] http://www.langleystudios.net/software/eclipse/469
> 
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
> 
> 
> 
> _______________________________________________
> ecf-dev mailing list ecf-dev@xxxxxxxxxxx To change your delivery options,
> retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
> 
> 
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/ecf-dev