#opendaylight-devforum5: Inter-Project Infrastructure Services
Meeting started by tykeal at 18:25:19 UTC
(full logs).
Meeting summary
- How to do cross project testing (tykeal, 18:26:06)
- tools we have: jenkins, sonar, nexus
(tykeal,
18:26:46)
- docs & integration projects -- integrating
the ecosystem (tykeal,
18:27:41)
- Talking about tools we have, tools we
need (dfarrell07,
18:29:27)
- Tools we have: Jenkins, Sonar, Nexus, docs,
integration projects (dfarrell07,
18:29:53)
- Tools we need: Branding strategy (I think
that's what the board says) (dfarrell07,
18:30:23)
- "We need to scale tykeal" (dfarrell07,
18:30:57)
- Getting Started for Projects wiki is helpful
for scaling andy (dfarrell07,
18:31:26)
- General discussion about how projects get
started, where they look at docs and such (dfarrell07,
18:33:11)
- regXboi points out that there's some reasons to
privilage important things like project starting/building wikis,
group decides this is out of scope (dfarrell07,
18:34:50)
- Can't rely on individual projects talking to
tykeal, doesn't scale, via rovarga (dfarrell07,
18:35:33)
- Possible solution is infra project,
rovarga (dfarrell07,
18:35:48)
- Sounds great, but who will write it -
colindixon (dfarrell07,
18:36:10)
- regXboi points out that adding tooling on the
fly without process is a problem (dfarrell07,
18:37:29)
- colindixon notes that to outsource
infrastructure from the projects you need a well defined interface.
That iterface today is POM files (phrobb,
18:38:26)
- "Infra project" would be responsible for
defining structure, API - rovarga (dfarrell07,
18:39:18)
- May need to hire someone to look a things like
POM files, say they have issues. In general, if outsorcing project
gen/tools, need more people first, then automate (dfarrell07,
18:41:11)
- continued discussion about automation vs person
to help projects with infra/tools/building (dfarrell07,
18:42:29)
- rovarga wants it to be very easy for committers
to start a new project with minimal knowledge of underlying
infrastructure (phrobb,
18:42:39)
- Issues/limitations with mvn being
discussed (dfarrell07,
18:45:10)
- this infrastructure project would evaluate and
document how changing infrastructure components would impact all
projects. example is moving from maven to gradle (phrobb,
18:46:19)
- Pushback on changing tooling, don't want to
make this a per-release tool change. Need to become stable at some
point. (dfarrell07,
18:48:10)
- Docs on how to use and audit build tools are a
good first step, cool things in the future would be good of course,
but making sure folks know what to do is 90% (dfarrell07,
18:50:07)
- starting to formalize problems, find people to
fix them (dfarrell07,
18:53:17)
- Problem: Many general POM issues (dfarrell07,
18:54:03)
- Problem: Projects don't know how to set up
Jenkinds, POMs, Sonar, etc (dfarrell07,
18:54:30)
- cleaning up the POM hierarchy is a problem
for DevinAvery (phrobb,
18:54:36)
- Problem: People should use odlparent and be
able to tel lif they are dangerously overriding things (dfarrell07,
18:55:05)
- effective POM doesn't explain the hierarchy and
references across different POM files from different projects
(phrobb,
18:56:10)
- Problem: POM file structure is really *unknown
word*, eg, don't mirror dir structure (dfarrell07,
18:56:31)
- Problem: HOWTOs and wiki pages can help once,
but don't help with maintaining (dfarrell07,
19:00:11)
- Problem: How do we manage inter-project
versions? (dfarrell07,
19:00:36)
- Problem: Howe do we "go back in time"
(dfarrell07,
19:00:47)
- Problem: How do we bump versions? (dfarrell07,
19:02:51)
- continued discussion about bumping
versions (dfarrell07,
19:04:50)
- "What problem do we hate the most"? Let's pick
one and focus on it. (dfarrell07,
19:05:31)
- Main problem proposal0: Versions (dfarrell07,
19:06:04)
- Problems that become inter-project actually
only screw over a few people who do inter-project work, projects
can/do ignore it (dfarrell07,
19:07:01)
- Hack fest to work on one or more of these
projects, maybe tomorrow attack one of these (dfarrell07,
19:08:19)
- Major problem proposal1: ODL parent does dep
and plugin managment, not list of version strings, if you don't
specifiy you get the right one, throw warning if you choose a
different one, hard to override but not impossible (dfarrell07,
19:10:11)
- Major proposal2: Make sure OpenFlow Java
inherits from common parent (dfarrell07,
19:12:02)
- Major proposal3: Tool to check for this family
of issues (dfarrell07,
19:12:24)
- properly commenting file and having code review
may be better than tool to check for all possible mistakes in this
domain (dfarrell07,
19:13:05)
- Tests are better, says many people (dfarrell07,
19:13:35)
- Major project proposal4: Make really solid POM
file to use as example (dfarrell07,
19:14:46)
- Recap of major projects people seem to care
about the most: Fix ODL parent, make ODL Java use it, docuemnt what
POMs do and how they do it (dfarrell07,
19:15:56)
- Who sould own ODL parent? How do we handle
artifcats that you don't maintain in your code. Maybe scope creep
here (dfarrell07,
19:17:05)
- TODO0: Fix ODL parent; with plugin managment;
with dependency managment for 3rd party artifacts (dfarrell07,
19:18:13)
- TODO1: Convert OpenFlow Java to use TODO0 in
best current practice (dfarrell07,
19:18:39)
- TODO2: Document what TODO1 solves, how and
why (dfarrell07,
19:18:54)
- this needs to be an unconf or just grab a room
and do it (dfarrell07,
19:19:13)
- send email to -discuss when this happens so
others can find it (dfarrell07,
19:19:33)
- Edit to TODO0: It should not break other
projects (dfarrell07,
19:20:26)
- Edit to TODO0: Get it into Gerrit, start
thinking looking, don't merge soon (dfarrell07,
19:21:19)
Meeting ended at 19:22:10 UTC
(full logs).
Action items
- (none)
People present (lines said)
- dfarrell07 (53)
- regXboi (9)
- tykeal (8)
- phrobb (5)
- odl_meetbot (5)
- dbainbri (2)
- zxiiro (1)
Generated by MeetBot 0.1.4.