Biweekly virtual meetingDeveloper discussions that will only happen if a proposed agenda exists. Some instructions and a link to the agenda can be found in the RIOT wiki (https://github.com/RIOT-OS/RIOT/wiki/Meetings). Remote participation will be provided.
Dear RIOTers,
as the Google Calendar reminds is: tomorrow is our “biweekly” virtual meeting. I started an agenda at [1]. Feel free to add to it if you think something needs to be discussed.
Hi,
find attached the minutes of the virtual meeting:
# Virtual Meeting™ on October 5, 2016
## Attendees
* Martine (chair)
* Hauke
* Cenk
* Peter
## Minute Takers
* Martine
* Peter
## Proposed Agenda
1. CI server problems
1. sock progress
1. NDP overhaul
1. SPI on telosb
## CI server problems
* How to prevent server problems we had at the weekend?
* downloads.riot-os.org was moved from kupfer to Kaspar's
server due to power outage at FU
* => Kaspar became single point of failure
* Solutions:
* More people access to kupfer
* Move to server at HAW (smlng can grant access to other people)
* More people access to Kaspar's server?
* Let's talk with Kaspar first (**Cenk** is doing this)
## NDP overhaul
* Martine opened a PR for NIB
* Please criticize and review!
## SPI on telosb
* Peter: Did anyone use SPI on telosb in the last time?
* Hauke: Did anyone use it in the last 3 years?
* Peter: That explains everything!
Sorry, couldn't make it, but some comments/questions:
* How to prevent server problems we had at the weekend?
* downloads.riot-os.org was moved from kupfer to Kaspar's
server due to power outage at FU
* => Kaspar became single point of failure
* Solutions:
* More people access to kupfer
* Move to server at HAW (smlng can grant access to other people)
* More people access to Kaspar's server?
point of failure - independent if it is hosted at FUB, HAW or Hetzner. We
should have at least one fallback server.
* Simon plans to rework GNRC TCP in the extended future (at Hack'n'ACKs?)
Can't we first merge the current solution ASAP and then do the rework?
Sorry, couldn't make it, but some comments/questions:
* How to prevent server problems we had at the weekend?
* downloads.riot-os.org was moved from kupfer to Kaspar's
server due to power outage at FU
* => Kaspar became single point of failure
* Solutions:
* More people access to kupfer
* Move to server at HAW (smlng can grant access to other people)
* More people access to Kaspar's server?
From my point of view, the most important view is getting rid of this single
point of failure - independent if it is hosted at FUB, HAW or Hetzner. We
should have at least one fallback server.
* Simon plans to rework GNRC TCP in the extended future (at Hack'n'ACKs?)
Can't we first merge the current solution ASAP and then do the rework?
I don't think it sends a good signal if we merge a PR that was build
against an API we just deprecated... I'd rather do the rework to sock
with Sebastian (and/or Simon) myself than having conn_tcp merged at
this point, since I'm working on sock_tcp for lwIP in the next few
days I think I will gather enough experience (and have enough
preparation) to maybe be able to do this in a few hours with their
guidance.
> * How to prevent server problems we had at the weekend?
> * downloads.riot-os.org was moved from kupfer to Kaspar's
> server due to power outage at FU
> * => Kaspar became single point of failure
> * Solutions:
> * More people access to kupfer
> * Move to server at HAW (smlng can grant access to other people)
> * More people access to Kaspar's server?
From my point of view, the most important view is getting rid of this single
point of failure
Please don't get rid of me!
- independent if it is hosted at FUB, HAW or Hetzner. We
should have at least one fallback server.
For downloads.riot-os.org, kupfer worked fine for years without
downtime. Let's have the domain point back there. My webserver can serve
as backup, it is already set up. Oleg and I can set up automatic
mirroring between the two, and maybe Oleg can provide access to the
riot-os.org name server, so when sth like this happens the next time, we
can switch more quickly.
(The problem was prolonged because *noone* had a local copy of a needed
file...)
