-
Notifications
You must be signed in to change notification settings - Fork 205
Meeting Notes
Attn: Christoph Deppisch, Paul Richardson, Rachel McGeever, María Arias de Reyna, Stan Lewis, Tomohisa Igarashi, Zoran Regvart, Luca Burgazzoli
- Which version of OpenShift/Minishift should we target to?
OpenShift 4 has Operator Hub which is useful for us. But then we deviate even more from being able to run this on vanilla Kubernetes. According to Zoran, Kurt is working on running over non-kubernetes environment like docker-compose and then rely on camel-k to run the integrations. This is a separation of the creation and running of the integrations which right now is coupled.
- Releases & Roadmap
We used to release quite often, but we have changed the frequency. There are some issues blocking releases like https://github.com/syndesisio/syndesis/issues/6997 Zoran volunteers on working on this issue. After fixing this issue on installations, we can release 1.9.0.
We will work on a roadmap on the mailing list.
- Camel 3
There is a branch that has camel 3 and compiles but tests fails. Zoran is rebasing from time to time. We are going to work and coordinate to fix the failing tests in order to merge with master.
As Luca points, we should target sooner or later camel-k and replace all not camel-k on Syndesis. For that we have to support extensions, which we are not prepared to do yet.
- Building process
Tests are flaky tests because we do a lot of integration tests, which are usually less stable.
On Circle CI we are on a FOSS program which is cheap and gives five threads. We have 34 things to run on those threads per PR which takes around 45 minutes. We can try to lower the number of jobs to run per PR. Also there are some tests that can be deferred to some nightly build. We also have cross-PR between branches.
Low hanging fruit: increment Circle CI threads. Using Red Hat resources may not be good for attracting non-RH developers as they won't have access to everything.
Attn: Barry LaFond, Christoph Deppisch, Kurt Stam, Maria Dominguez, Paul Richardson, Zoran Regvart
Agenda:
Approval of from RH regarding time estimates for the RH team to spend on community work.
Updates:
- Work progressing on Standalone (Kurt)
- Work progressing on Camel-3 (Paul, Christoph, Maria)
- QS on conditional flows (Christoph)
- Fork of Syndesis for the product in the jboss-fuse repo, so Syndesis is community. (Zoran)
- Project Steering Board was formed
- Incorporation of Data Virtualization (DV) code in the Syndesis Repository
Roadmap
-
- Building Community
- a. Syndesis Standalone #6556 (5)
- b. Switch runtime to CamelK (8)
- c. Run with Community bits (8) - this includes forking Syndesis to joss-fuse and helping set up build infrastructure for that.
-
- Resolving TechDebt
- a. Replacing JSONDB by a relational DB (8)
-
- Integrating DV codebase into repository
- a. Driven by DV team in collaboration with syndesis (so when DV are ready!)
Agenda:
1. Approval of Sept 13 2019 Notes
2. Capture quick status progress
- Nominations for PSB open for one week.
- Action: María to send some emails through the mailing list for this.
- Action: María to create Gitter.
3. Fuse vs Camel bits
I think we agree that we should be consuming Camel bits rather than Fuse bits. However it seems that this may not be that easy for the 2.x branch. Camel-K requires 3.x which is what we are targeting anyway, so maybe it makes sense to wait with the Fuse -> Camel switch till we can go Camel-K.
- Christoph started experimenting with this.
- Action: Continue experimenting with latest Camel upstream.
- Wait for Camel-K "1" (depends on Camel 3) to be available <- versions for Camel K are not aligned with versions of Camel. It looks like the wait won't be long and we could using the Release Candidates right now, which would allow us to provide some feedback.
- Separate Upstream and Downstream into two separated repositories
- Discuss on mailing list how to do it.
4. Outreach
FOSDEM, blog?, twitter, more quickstarts?, quickstarts for developers?
- Action: Move this!
We have a (random) list of rough ideas collected here: https://github.com/syndesisio/syndesis/wiki/Planning-for-Syndesis-2.0, I’m hoping this list gets more organized as we move forward.
Agenda:
1. Go over high level goals why we want more Project presence (time box 10 min)
Community: get direct feedback from users, create mindshare and project adoption. Attract Developers, make it as easy as possible try. Less steep learning curve to start developing on it. Be good citizens ourselves contributing back to upstream projects. Have our voices heard in those projects (Camel, not use the Camel-Fuse Branch).
2. Identify what communication channels we should be using going forward so the community is included
Like all communities, no one likes to be excluded from conversations. We need to make sure to publish our notes, and make the project more self organized. Start a thread on the mailing list about a certain feature and see what the interest is. Open a GH issue, see who wants to help. Create a PR.
Agreed solutions
- Replicate what's used on Camel: Gitter.
- Mailing list: Syndesisio Google Group (replace with Syndesis logo - looks like this is RH organization group, so we prob need to move it)
- StackOverFlow: let's try replaying questions we have internally so other people can benefit and so Google starts picking it up.
3. Identify top 5 items we should address first and see who is interested in working on them and create GH Issues for them so we can discuss implementation there.
- a. We need to make it easier for people to try out Syndesis by 1. adding a Standalone zip file of just the design time #6556 and 2. by supporting deployment to Kubernetes #6200
- b. Build with Community bits (not Fuse): check if 2.24.2 has all components #6614
- c. Proposal on how to govern Syndesis project #6598
- d. Start spreading the word: Blogs, Revamp Website, do talks #6594
- e. We desperately need some diagrams and definitions on what Syndesis is - add to wiki
Next
- f. Releases (with release notes) with syndesis cmdline and standalone zip
- g. Vetted extensions on extension page in the UI (with user rating?)
4. Open a GH and add it behind the tasks above