Meeting Summary 2016-07-20

[Jo-Philipp Wich]

Hi all,

this is a brief summary of our last IRC meeting last wednesday, 20th.

Please refer to
http://meetings.lede-project.org/lede-adm/2016/lede-adm.2016-07-20-17.28.html
for the meeting minutes and links to the full IRC logs.

We didn't manage to go through the entire proposed agenda, therefor
we'll most likely need to schedule a follow up meeting soon to discuss
remaining topics.


1) Infrastructure

We got a new download master server sponsored which is located at the
RWTH Aachen and which should offer better overall Rsync performance.

Ted has been working on identifying and reporting Flyspray issues
upstream and expressed his interest in putting some more effort into
issue triage.

Not strictly infrastructure related but as part of the triage process,
Ted wants to gather a list of developer topic to see what issues should
be assigned to which developer.


2) Codebase Updates

Some effort has been spent during the last weeks to merge PRs and
patches sent via the list, John and Felix spent time reworking the image
building code in order to lay the groundwork for the multiple rootfs
build code.

Alexander stated that he is working on adding support for Beaglebone
Black Capes to OMAP and John deems IPQ8060x mostly stable now.

We also noted that the ToDo items on the web page are outdated and need
an overhaul.


3) Releases

The multi rootfs build code has been identified to be the largest
blocker for the first LEDE release, Felix subsequently started tackling
this topic and has a working prototype sitting in his staging tree now.

We more or less agreed on numbering future releases in the form
yy.mm[.n] where the number denotes the year and month of branching. The
micro version field would be reserved for the build-number or patch
level of a given release.

The intended approach for future release is to expand the buildbot setup
to crunch less volatile (stable) release branches while keeping the very
same process logic used for the snapshot builds. Basic idea here is to
eliminate most manual work needed to carve out a release build and to
support ongoing release maintenance (e.g. security updates for binary
packages) through simple pushes to the respective branches.


4) OpenWrt merge discussion

Most attending people expressed continued interest in a re-merge with
OpenWrt, though the process seems, once again, stuck on both sides.

We discussed on how to deal with wiki and forum and I made the point
that hosting an own wiki and/or forum will most likely lead to
duplication of content and splitting of communities and community-resources.

One proposal I made was maybe having a LEDE sub forum in the OpenWrt
wiki, provided that OpenWrt agrees to that. We agreed on taking the
matter to the lists in order to facilitate more feedback on this.


The remaining topics on the agenda have not been discussed due to a lack
of time.


Regards,
Jo