Sat 24 Aug 2019 8:30PM

Minutes of the 2019-08-22 Council meeting

RJ Raphaël Jadot Public Seen by 148

Topics to be discussed:
* Taking independance from gitub
* C-meetings schedule.
* Improve packages update policy


Raphaël Jadot Sat 24 Aug 2019 8:41PM

Meeting log:

1: Taking independance from gitub:

After a long discussion, we came to the idea that it was too soon to choose a tool that would be dedicated to git repos exploration, or a more complete environment with project management and more.

Rather than choosing a tool, what we arguably need even more than current decision on git host is a Plan for what to do if various scenarios play out. Therefore we prefer to explore the pure git workflow solution, and see what tool(s) can be added on it after. To cover everyone's concern's we write a plan and include a description of options of what we can do if something goes wrong, including command line and switching to another interface

Next steps are:

  • Bero will set up a test repository on his server that should automatically mirror to github. Gitlab (hosted) and Tuleap (hosted) may also be considered as potential mirrors, depending on how we are authorized to synchronize thousands of repos on them.

    • We make sure that it works
    • then we can start testing UIs on top of our mirror for the real repositories
    • then once we're fairly sure that works, we flip the switch and github (with potential others) is only a mirror of the master repositories instead of being the master.

2: C-meetings schedule.

We know that no schedule can match everyone's availability, but Tuesday 17:00 UTC (16:UTC in Summer DST) each two weeks seems to be ok for a majority of C members. No important decisions will be taken during meetings (provided we also discuss before meetings by many means) but are to be taken through Loomio votes.

3: Improve package update policy

We are thinking about having a better and clearer policy about packages updates, especially in Rock (now 4.0). We investigated the idea of blacklisting updates to released versions by default. As we are willing ot have Rolling up and running, there's no need to send hundreds of updates to 4.0
Updates to Rock should be handled with extreme care...

About Rolling: We need to make sure we release 4.1 in a timely manner, and we have a blacklist of things that don't automatically move from cooker to rolling.

About cooker: keeping that open to just about everything (except core packages by policy) is good... so we should be set there

Release Manager: We would like to appoint explicitely a Release Manager by release who would handle the delicate balance between updates and stabilization during Rolling state (before release) and protect the release during the Rock state (after release)

Link worth to be reminded: https://wiki.openmandriva.org/en/Policies/Repository_Policies#Cooker


A big work for cleaning wiki and having up to date documentation has been initiated.