Notes of informal release-team meeting at GUADEC 2017

[Resending as mail for the last weeks did not get delivered. 
Should be fixed now.]

20170730 1330-1430UTC

* aklapper
* jjardon
* mcatanzaro
* mclasen
* ovitters 

DISCLAIMER: In these notes I am paraphrasing; I did not get some stuff
and hence some stuff is missing. And I love to get lost in Flatpakhub
Feel free to edit / correct.


TODO andre to update
and contact several rather inactive people
Also to remove from mailing list; security@; mention emeritus to those
previous members. (potentially document these offboarding steps?)
TODO mclasen and jjardon to contact potential new r-t members.


mcatanzaro: Security mailing list stuff?
Tobi Mueller sometimes replying but not really anyone else
GPG key setup? Nobody really in for that it seems
Chain of 'security' already breaks when we inform maintainer and they
push a fix into Git
jjardon: might get better with Gitlab?
ovitters: but future is GitLab anyway

(feature / workflow discussion)

mcatanzaro: transition team taking care of it, scripts existing, see
mclasen: don't want to necessarily take over 3000 open gtk bugs
ovitters: but you could close them anyway
aklapper: want to see migration code
jjardon: take your own sandbox, like github
mclasen: any refressions like gnome blocker bugs?
aklapper: everything can be a tag / project.
jjardon: create project, you have burndown charts
ovitters: would love to have some weekly stats, not critical
aklapper: API to pull data and host externally, if nothing provided
jjardon: GitLab API has become more stable


jjardon: if we move to GitLab, interested in having CI for every
project and make everything that goes to master to compile. Then
Continuous only for integration, then have GitLab for anything else
(unit tests etc)?
General agreement of looking forward to proper/better CI


general impression that it seems to go well
ovitters: Meson broke damned-lies but hopefully easy to fix?
mcatanzaro: if Evolution wants to maintain a separate CMake build,
fine, but we don't want e-d-s to be the only core component using CMake
jjardon: cannot force but want to make Meson the recommended option


mcatanzaro: maybe federico is looking into put all bundled dependencies
into the tarball?


currently tarballs
Allan (?) wants Flatpaks
jjardon: but flatpaks only for applications
mcatanzaro: we have flatpak builders separately for every application,
plans to move stable ones to flathub. Goal is to have one set of build
definitions. How is this going to work?
can we use buildstream to generate flatpak manifests?
jjardon: should be possible?
mclasen: flatpak manifest is canonical way to define how to build
mcatanzaro: we care about the manifest because we want to define our
build definitions only once. how can we sync (e.g. flatpak vs
avoid building your own runtime.
15min left - come closer to consensus? 
keep individual flatpak builder manifest? one build definition for
mclasen: comes down to core applications vs 3rd party applications,
latter can do what they want and not depend on what we do
ovitters: user pov? if it's a core thingy tied to gnome then I expect
when gnome-core runtime gets updated that's part of it
mclasen: in practice, comes down to version numbers, pick from ftp
list. [...] Extracted NEWS file more interesting
mcatanzaro: maybe even get rid of official gnome releases at some
point, as distros care more about application releases?
ovitters: more like a list 'during this gnome release we used these
versions and tested this'
can continue with gnome-continuous, just not sufficient currently. we
need this on a level.
mcatanzaro: what to put into Buildstream? Unresolved, maybe discuss on
Wednesday BoF with Alex Larsson around and get Alex' input?

Ovitters: MAGEIA vs format-string warnings, make continuous add that?
mcatanzaro: for Buildstream yes

ovitters, jjardon: regular meetings again? every 3 months?
if not on irc, must document stuff

Andre Klapper  |  ak-47 gmx net

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]