About JS framework
by Pierre-Yves Chibon
Good Morning Everyone,
Our infrastructure is mostly a python store, meaning almost all our apps are
written in python and most using wsgi.
However in python we are using a number of framework:
* flask for most
* pyramid for some of the biggest (bodhi, FAS3)
* Django (askbot, Hyperkitty)
* TurboGears2 (fedora-packages)
* aiohttp (python3, async app: mdapi)
While this makes sometime things difficult, these are fairly standard framework
and most of our developers are able to help on all.
However, as I see us starting to look at JS for some of our apps (fedora-hubs,
wartaa...), I wonder if we could start the discussion early about the different
framework and eventually see if we can unify around one.
This would also allow those of us not familiar with any JS framework to look at
the recommended one instead of picking one up semi-randomly.
So has anyone experience with one or more JS framework? Do you have one that
would you recommend? Why?
Thanks for your inputs,
Pierre
1 year, 6 months
What are we going to do about sigul?
by Neal Gompa
Hey all,
So, we've got a bit of a problem. The sigul package is not installable
in Fedora 29, and pygpgme is half-broken in Fedora 28 and was retired
during Fedora 29 development due to constant breakage.
This means that sigul is in danger of being retired in Fedora.
Unfortunately, sigul is the only supported signer system for Koji at
the moment.
What do we want to do here? It's well-known that sigul does not work
with GnuPG 2, though I vaguely recall that some work was done to try
to fix this.
Do we want to port sigul to python3-gpg, switching Sigul to Python 3
and the official gpgme bindings so that it works with GnuPG 2?
Or do we want to adapt the bridge to work with obs-signd (which is
already used by Copr)?
--
真実はいつも一つ！/ Always, there's only one truth!
5 years, 1 month
cloud retirement
by Kevin Fenzi
Hey everyone.
As you know, we currently have a RHOSP5 ancient cloud. After a bunch of
work last year, we got a RHOSP13 cloud up and mostly working, but it was
a ton of work. After hearing from the Fedora Council and our various
management chains we determined that it wouldn't really be a good use of
our time moving forward to keep maintaining a OpenStack cloud.
We have not yet determined what we want to do with the hardware that we
had allocated to this, but are weighing our options. We may want to
setup OpenShift bare nodes so we can do kubevirt, we may want to just
setup a normal virthost setup managed by ansible.
For the items currently in our cloud, we will be looking at options for
them, we are definitely not shutting things off until we have plans in
place.
Happy to answer any questions and will make sure everything is properly
migrated.
kevin
5 years, 1 month
[PATCH] Configure a separate namespace for Flatpaks
by Owen Taylor
From: "Owen W. Taylor" <otaylor(a)fishsoup.net>
Configure pagure to allow a flatpaks/ namespace, and koji and MBS
to allow building from it.
When we sync package ownership to Koji, the f29-flatpaks tag (which has
the Flatpak containers) tag gets everything in the flatpaks/ namespace,
while the f29-modular tag gets everything in modules/ *and* flatpaks/,
since modules can be built from either.
Signed-off-by: Owen W. Taylor <otaylor(a)fishsoup.net>
---
.../backend/files/koji-sync-listener.py | 2 +-
roles/bodhi2/backend/tasks/main.yml | 2 +-
.../backend/templates/owner-sync-pagure.j2 | 55 +++++++++++--------
roles/distgit/pagure/templates/pagure.cfg | 3 +-
roles/koji_builder/templates/kojid.conf | 2 +
roles/mbs/common/templates/config.py | 10 +++-
6 files changed, 45 insertions(+), 29 deletions(-)
diff --git a/roles/bodhi2/backend/files/koji-sync-listener.py b/roles/bodhi2/backend/files/koji-sync-listener.py
index 02b0e3f18..cbcbd280f 100644
--- a/roles/bodhi2/backend/files/koji-sync-listener.py
+++ b/roles/bodhi2/backend/files/koji-sync-listener.py
@@ -23,7 +23,7 @@ def handle(content):
sys.stdout.flush()
# XXX If you modify this taglist. Please also modify the other copy in
# bodhi2/backend/tasks/main.yml
- taglist = 'f30 f30-container f30-modular f29 f28 f29-container f28-container f28-docker f29-modular f28-modular epel7 dist-6E-epel module-package-list modular'
+ taglist = 'f30 f30-container f30-modular f29 f28 f29-container f29-flatpak f28-container f28-docker f29-modular f28-modular epel7 dist-6E-epel module-package-list modular'
cmd = [
'/usr/local/bin/owner-sync-pagure',
'--package', package,
diff --git a/roles/bodhi2/backend/tasks/main.yml b/roles/bodhi2/backend/tasks/main.yml
index 114c113d5..e65feb417 100644
--- a/roles/bodhi2/backend/tasks/main.yml
+++ b/roles/bodhi2/backend/tasks/main.yml
@@ -166,7 +166,7 @@
# bodhi2/backend/files/koji-sync-listener.py
# This cronjob runs only once a day. The listener script runs reactively.
cron: name="owner-sync" minute="15" hour="4" user="root"
- job="/usr/local/bin/lock-wrapper owner-sync '/usr/local/bin/owner-sync-pagure f30 f30-container f30-modular f29 f28 f29-container f28-container f28-docker f29-modular f28-modular epel7 dist-6E-epel module-package-list modular'"
+ job="/usr/local/bin/lock-wrapper owner-sync '/usr/local/bin/owner-sync-pagure f30 f30-container f30-modular f29 f28 f29-container f29-flatpak f28-container f28-docker f29-modular f28-modular epel7 dist-6E-epel module-package-list modular'"
cron_file=update-koji-owner
when: inventory_hostname.startswith('bodhi-backend01') and env == "production"
tags:
diff --git a/roles/bodhi2/backend/templates/owner-sync-pagure.j2 b/roles/bodhi2/backend/templates/owner-sync-pagure.j2
index 89d7a371c..e558a26b9 100755
--- a/roles/bodhi2/backend/templates/owner-sync-pagure.j2
+++ b/roles/bodhi2/backend/templates/owner-sync-pagure.j2
@@ -65,6 +65,7 @@ if not PDC_URL.endswith('/'):
PDC_TYPES = {
'rpms': 'rpm',
'modules': 'module',
+ 'flatpaks': 'flatpak',
'container': 'container',
}
@@ -118,26 +119,29 @@ def get_options():
return opts
-def get_namespace_and_version_from_tag(tag):
+def get_namespaces_and_version_from_tag(tag):
if 'container' in tag:
- namespace = 'container'
+ namespaces = ['container']
version = tag.split('-')[0].split('f')[1]
elif 'docker' in tag:
- namespace = 'container'
+ namespaces = ['container']
version = tag.split('-')[0].split('f')[1]
elif 'modular' in tag:
- namespace = 'modules'
+ namespaces = ['flatpaks', 'modules']
try:
version = tag.split('-')[0].split('f')[1]
except IndexError:
version = RAWHIDE
+ elif 'flatpak' in tag:
+ namespaces = ['flatpaks']
+ version = tag.split('-')[0].split('f')[1]
elif tag == 'module-package-list':
# See https://pagure.io/releng/issue/6663
# and https://pagure.io/fm-orchestrator/issue/333
- namespace = 'rpms'
+ namespaces = ['rpms']
version = RAWHIDE
else:
- namespace = 'rpms'
+ namespaces = ['rpms']
if tag.startswith('epel'):
version = tag.split('epel')[1]
elif tag.startswith('f'):
@@ -378,15 +382,15 @@ if __name__ == '__main__':
unique_namespaces = set()
tag_info = {}
for tag in tags:
- namespace, version = get_namespace_and_version_from_tag(tag)
+ namespaces, version = get_namespaces_and_version_from_tag(tag)
branch, arches = get_branch_and_arches(tag, version)
tag_info[tag] = {
- 'namespace': namespace,
+ 'namespaces': namespaces,
'version': version,
'branch': branch,
'arches': arches
}
- unique_namespaces.add(namespace)
+ unique_namespaces.update(namespaces)
# Get all the project to branch mappings for every namespace
namespace_to_projects = {}
@@ -401,24 +405,27 @@ if __name__ == '__main__':
if verbose:
print('Determining which projects have the namespace "{0}" and '
'branch "{1}"'.format(namespace, tag))
- namespace = info['namespace']
+ namespaces = info['namespace']
pkgs = []
- for pkg, branches in namespace_to_projects[namespace].items():
- if info['branch'] in branches or tag == ('f' + RAWHIDE):
- # The tag and branch names are the same for "old-style" branches
- pkgs.append(pkg)
- elif namespace == 'modules':
- # Add modules to f27-modular-updates even if their only branch is '2.4'
- pkgs.append(pkg)
-
- # This is a special project, not in dist-git, but which needs to be in
- # the package list.
- if namespace == 'rpms':
- pkgs.append('module-build-macros')
+ for namespace in namespaces:
+ for pkg, branches in namespace_to_projects[namespace].items():
+ if info['branch'] in branches or tag == ('f' + RAWHIDE):
+ # The tag and branch names are the same for "old-style" branches
+ pkgs.append(pkg)
+ elif namespace in ('modules', 'flatpaks'):
+ # Add modules to f27-modular-updates even if their only branch is '2.4'
+ # Similarly, flatpaks will be built into f29-flatpak-updates-candidate
+ # if they use the f29 runtime, even from master or stream branches.
+ pkgs.append(pkg)
+
+ # This is a special project, not in dist-git, but which needs to be in
+ # the package list.
+ if namespace == 'rpms':
+ pkgs.append('module-build-macros')
if verbose:
print('Setting the Koji ownership and package list on packages in '
- 'the tag "{0}" and namespace "{1}" and for arches "{2}"'
- .format(tag, namespace, ', '.join(info['arches'])))
+ 'the tag "{0}" and namespaces "{1}" and for arches "{2}"'
+ .format(tag, namespaces, ', '.join(info['arches'])))
set_koji_ownership(tag, pkgs, info['arches'], verbose=verbose)
diff --git a/roles/distgit/pagure/templates/pagure.cfg b/roles/distgit/pagure/templates/pagure.cfg
index 4b8e00b1b..46173b9b6 100644
--- a/roles/distgit/pagure/templates/pagure.cfg
+++ b/roles/distgit/pagure/templates/pagure.cfg
@@ -211,7 +211,7 @@ LOGGING = {
# Configuration item that are specific for this odd pagure instance
ENABLE_UI_NEW_PROJECTS = False
-ALLOWED_PREFIX = ['rpms', 'modules', 'container', 'tests']
+ALLOWED_PREFIX = ['rpms', 'modules', 'flatpaks', 'container', 'tests']
EXCLUDE_GROUP_INDEX = ['packager']
PRIVATE_PROJECTS = False
FEDMSG_NOTIFICATIONS = True
@@ -235,6 +235,7 @@ ACLS = {
REQUIRED_GROUPS = {
'container/*': ['packager'],
+ 'flatpaks/*': ['packager'],
'modules/*': ['packager'],
'rpms/*': ['packager'],
}
diff --git a/roles/koji_builder/templates/kojid.conf b/roles/koji_builder/templates/kojid.conf
index 9fbb8216a..a1eb32338 100644
--- a/roles/koji_builder/templates/kojid.conf
+++ b/roles/koji_builder/templates/kojid.conf
@@ -81,6 +81,7 @@ allowed_scms=
!src.stg.fedoraproject.org:/forks/*
!src.stg.fedoraproject.org:/cgit/*
src.stg.fedoraproject.org:/container/*:false
+ src.stg.fedoraproject.org:/flatpaks/*:false
src.stg.fedoraproject.org:/git/rpms/*:false:fedpkg,sources
!src.stg.fedoraproject.org:/git/*
!pkgs.stg.fedoraproject.org:/fork/*
@@ -88,6 +89,7 @@ allowed_scms=
!pkgs.stg.fedoraproject.org:/cgit/*
!pkgs.stg.fedoraproject.org:/git/*
pkgs.stg.fedoraproject.org:/container/*:false
+ pkgs.stg.fedoraproject.org:/flatpaks/*:false
pkgs.stg.fedoraproject.org:/rpms/*:false:fedpkg,sources
pkgs.stg.fedoraproject.org:/*:false:fedpkg,sources
src.stg.fedoraproject.org:/*:false:fedpkg,sources
diff --git a/roles/mbs/common/templates/config.py b/roles/mbs/common/templates/config.py
index 47f3ad790..4ed7a9ef2 100644
--- a/roles/mbs/common/templates/config.py
+++ b/roles/mbs/common/templates/config.py
@@ -140,7 +140,10 @@ class ProdConfiguration(BaseConfiguration):
PDC_URL = 'https://pdc.stg.fedoraproject.org/rest_api/v1'
SCMURLS = ['git+https://src.stg.fedoraproject.org/modules/',
'https://src.stg.fedoraproject.org/modules/',
- 'https://src.stg.fedoraproject.org/git/modules/']
+ 'https://src.stg.fedoraproject.org/git/modules/',
+ 'git+https://src.stg.fedoraproject.org/flatpaks/',
+ 'https://src.stg.fedoraproject.org/flatpaks/',
+ 'https://src.stg.fedoraproject.org/git/flatpaks/']
{% else %}
KOJI_PROFILE = 'production'
@@ -155,7 +158,10 @@ class ProdConfiguration(BaseConfiguration):
PDC_URL = 'https://pdc.fedoraproject.org/rest_api/v1'
SCMURLS = ['git+https://src.fedoraproject.org/modules/',
'https://src.fedoraproject.org/modules/',
- 'https://src.fedoraproject.org/git/modules/']
+ 'https://src.fedoraproject.org/git/modules/',
+ 'git+https://src.fedoraproject.org/flatpaks/',
+ 'https://src.fedoraproject.org/flatpaks/',
+ 'https://src.fedoraproject.org/git/flatpaks/']
{% endif %}
RESOLVER = "db"
--
2.20.1
5 years, 2 months
Project Details
by Leigh Griffin
Hey everyone,
I am trying to get a handle on the number of projects that we are
actively working on for any given day of the week. Could I ask everybody to
reply here with some information. At a minimum if you could share with me:
- Project you are actively working regularly on
- Link to the Landing Page / Tracker / Source / Docs / anything relevant
really that might help me get a handle on the project
- Got a roadmap link? Or backlog link?
- Any upcoming release plans that you are aware of / have committed to?
- Anything else you think is worth sharing by all means include it
I want to try and get a picture of the landscape and to take all of that
into account when we start looking at the upcoming priorities for the Red
Hat team. I want to try paint a bigger picture of our current
responsibilities and commitments to help us inform what our future
commitments look like.
I intend to transpose this *somewhere* in due course, the Wiki might be a
good starting point but for now I'm happy to take the details within this
thread and I can follow up with another conversation as the information
flows in.
Thanks,
Leigh
--
LEIGH GRIFFIN
ENGINEERING MANAGER,
Community Platform Engineering
Red Hat Ireland <https://www.redhat.com/>
Communications House, Cork Road
Waterford City, Ireland X91NY33
lgriffin(a)redhat.com M: +353877545162 IM: lgriffin
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@redhatway <https://twitter.com/redhatway> @redhatinc
<https://instagram.com/redhatinc> @redhatsnaps
<https://snapchat.com/add/redhatsnaps>
5 years, 2 months
Infra team schedule tasks
by Ben Cotton
I am beginning to prepare the schedule for Fedora 31. One thing I want
to do is to make sure it still accurately reflects the work of
different teams within Fedora. Please look at the tasks on your team's
schedule [1] and discuss them in your team. Let me know if there are
tasks that should be added, removed, or modified. You can email me
directly or file an issue in Pagure[2].
I ask that you please provide feedback by Friday, 18 January, although
I will be able to incorporate changes after that.
[1] https://fedorapeople.org/groups/schedule/f-30/f-30-infrastructure.html
[2] https://pagure.io/fedora-project-schedule/issues
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
MBI (Playground 2.0)
by Igor Gnatenko
MayBe I …(can do something useful)?
Hello,
We've been discussing some (hopefully) nice idea with Mikolaj, Neal and
Jakub how we could improve packager (and user) experience and we have some
proposal which will be described below.
We would like to ask you to read it, understand it and ask us any questions
you have. From the Fedora Infrastructure we would like to ask for some
machines to implement this idea (you can find some more information in
"Implementation details" part).
I would like to apologize for HTML email, but it is much easier to have it
that way to have better visibility and reading easiness.
Feel free to reply to this email or comment in google doc (there is a link
on the bottom).
Proposal Owners
-
Mikolaj Izdebski (mizdebsk) <mizdebsk(a)redhat.com> - Java SIG, Fedora
infrastructure
-
Igor Gnatenko (ignatenkobrain) <ignatenkobrain(a)fedoraproject.org> - Rust
SIG, Golang SIG, Neuro SIG, RPM and libsolv contributor
-
Neal Gompa (ngompa) <ngompa13(a)gmail.com> - Rust SIG, Golang SIG, RPM
contributor
-
Jakub Čajka (jcajka) <jcajka(a)fedoraproject.org> - Golang SIG, Container
SIG
This proposal aligns with the objective of improving the packager experience
<https://fedoraproject.org/wiki/Objectives/Packager_Experience> by
developing a platform whereby the proposal owners and others can experiment
with improvements that can be funneled back into the official production
infrastructure.
ProblemsProblem №1: Build-only packages
Some ecosystems have many build-only packages (packages which are used to
build other packages, without having them installed on end-user systems).
Those ecosystems include Java, Rust and Go.
It is extremely hard to keep up maintaining them due to lack of
time/people. Upstreams are usually changing quickly (sometimes when you
update just one such package, you’d need to update tens of the
dependencies). Few facts about such packages:
-
They are almost always outdated in released versions of distribution;
-
They are often FTBFS (e.g. because there was compiler update but not
package update, broken deps, broken APIs due to deps rebases, …).
In Rust ecosystem, we abuse Rawhide to build and store such packages there
and then generate end-user application (e.g. ripgrep) which uses some of
those packages and produces binary for all supported releases. Those
applications have high quality and are supported.
Rawhide gating makes this much more complicated because builds appear in
buildroot slower, updating group of packages would need side tags and it’s
just painful to work with.
https://pagure.io/fesco/issue/2068
And, after all, those packages shouldn’t be shipped to users.
Problem №2: Testing of new rpm/koji/mock features/configuration
When developing new features in RPM (e.g. rich dependencies) or testing
different Koji configuration (e.g. removing gcc/gcc-c++ from the
buildroot), it is required to make custom configuration and try building
things.
Problem №3: Developing modules
Modules are built in MBS as a single unit. It is hard to develop big
modules by progressively improving individual packages or small package
groups. Scratch builds for modules are not implemented. Local builds work
differently from official module builds, they don’t scale and don’t allow
groups of people to work collaboratively. All these problems can be solved
by first developing a flat repository of packages in a shared environment
and then generating modulemd from such package set.
Problem №4: Testing things before push
Primary Fedora Koji and dist-git are not suited for packaging
experimentation. Packagers are expected to experiment on their own systems
and push changes of successful experiments only. But this approach doesn’t
scale with number of maintained packages. Often you can find commits like
“d’oh, forgot to upload sources” or “let’s try with this settings”. People
need to build things somewhere quickly, do development and testing. And
only after that, they should push commit(s) to Fedora.
Solution
-
Separate Koji + Koschei deployed in Fedora infrastructure cloud;
-
Builders are optimized for the best performance (see below
<https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...>
);
-
People can have their own targets where they can break things as they
wish without affecting others;
-
Package changes are eventually contributed to Fedora proper by merging
changes to Fedora dist-git and rebuilding packages in official Fedora Koji;
-
All improvements can eventually be contributed back to official Fedora
infra.
Ideas
All ideas which you’ll find below are just an ideas and do not have to be
implemented.
Idea №1: Automated legal review
openSUSE released their review app called Cavil
<https://github.com/openSUSE/cavil> which we could try running in automated
way.
Idea №2: Automated package review
Currently review process is burden and we could run automated legal review,
create a repo, run set of checks and notify person. Somewhat similar to
fresque <https://github.com/fedora-infra/fresque>. In future might be
integrated with approval process and auto-imported into Fedora.
Idea №3: Building packages for multiple distributions
In Rust ecosystem, we managed to get have same packaging guidelines in
openSUSE, Mageia and Fedora. We could automatically build some packages on
multiple distributions and be kinda upstream.
Idea №4: Building custom images with user content
Deploy (or build) a tool(s) to enable user-built install, appliance and
container images with their content (modulo restrictions similar to COPR)
on top of Fedora.
Implementation details
-
Koji and Koschei deployed in fedorainfracloud.org
-
A few builders constantly running, with a possibility to add more
builders as needed and as available cloud resources allow
-
Deployed and maintained by proposal owners - not supported by Fedora
infrastructure
-
Other contributors can have access granted by proposal owners (for the
time being only users in “packagers” group will be eligible to get access)
-
Possibility to have some builders running outsides of Fedora
infrastructure - contributed by proposal owners
-
Koji builds can be done from SCM (src.fp.o, pagure.io, github, …) or
from SRPM upload
FAQWhy not COPR?
-
COPR has been starved of resources for years, which has impaired its
ability to provide reliable service at scale. Fedora Infrastructure refuses
to consider supporting it officially and Fedora Release Engineering seems
to have some undefined issues with COPR.
-
It is not official build system of Fedora which is not helping with Problem
№2: Testing of new rpm/koji/mock features/configuration
<https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...>
.
-
COPR is not extensible enough, more specifically:
-
No query API (e.g. it is not possible to find out from which SCM
commit the package has been built)
-
Builds always have access to all previous builds in a repository
(i.e. not possible to control when/how repo is created)
-
GC doesn’t exist
-
No scratch builds
Why not staging Koji?
-
Staging Koji is meant for testing Koji itself and not for package
development.
-
Staging Koji is often in broken state where it is not possible to build
anything.
-
No one can touch staging Koji, so it’s pointless for offering a useful
service.
How can you make Koji builds faster?
-
By tuning Koji for performance, not correctness and reliability.
-
By building only on a single, fast architecture.
-
By extensive caching. Files like RPM packages, repodata and files in
lookaside cache don’t change after they are initially stored, so builders
can cache them aggressively.
-
By keeping build repositories small. Some package sets don’t need to be
built against full Fedora, but can use a minimal subset of Fedora. Such
repositories can be generated by Koji in seconds, not minutes.
Why not the Open Build Service (OBS)?
-
OBS is not yet packaged for Fedora officially. The upstream code lacks
adaptations necessary to deploy and run on Fedora and in Fedora
Infrastructure.
-
OBS is not official build system of Fedora, which does not help with Problem
№2: Testing of new rpm/koji/mock features/configuration
<https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...>
.
What does MBI stand for?
-
M for middlestream, module, mizdebsk, …
-
B for build, bootstrap, …
-
I for infrastructure, initiative, ignatenkobrain, …
-
MBI might be pronounced as “maybe I …(can make something cool)?”
-
MBI is also initials of mizdebsk (Mikolaj Bozydar Izdebski)
-
MBI is also IBM spelled backwards :)
Is it somehow related to Fedora Playground
<https://fedoraproject.org/wiki/Playground>?
Yes, it is. Although it is more developer-focused. Users could enrol for
some specific things like experimental Java/Rust packages.
MBI (Playground 2.0)
<https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...>
5 years, 2 months
Lost access to my Fedora Account (FAS)
by Guillaume Bernard
Hi there,
I think that there’s a problem with my FAS account because I cannot acess it
anymore, the password associated with it does not longer works and even when
using my login and email address it does not send me anything to regain access
to it. I posted something on Ask Fedora few months ago and I just wanted to add
information, which I cannot do anymore. You’ll see on my Ask profile [1] that I
registered my own website, which can prove, in a way, my identity (who will give
a website which is not its own?). And as well, i use this username (guilieb) on
GNOME Damned Lies app [2]. My GPG key should also be registered on my account,
number 0x31E06F062CA02892.
FAS login: guilieb
[1]: https://ask.fedoraproject.org/en/users/19096/guilieb/
[2]: https://l10n.gnome.org/users/guilieb/
Thanks a lot for your precious help,
Best regards,
--
Guillaume Bernard
5 years, 2 months
Reminder: Infrastructure meeting 2019-01-31 15:00 UTC
by Stephen John Smoogen
This shared document is for the next fedora infrastructure meeting.
= Preamble =
The infrastructure team will be having its weekly meeting tomorrow,
2019-01-31 at 15:00 UTC in #fedora-meeting-1 on the freenode network.
We have a gobby document
(see: https://fedoraproject.org/wiki/Gobby )
fedora-infrastructure-meeting-next is the document.
Please try and review and edit that document before the meeting and we
will use it to have our agenda of things to discuss. A copy as of today
is included in this email.
If you have something to discuss, add the topic to the discussion area
with your name. If you would like to teach other folks about some
application or setup in our infrastructure, please add that topic and
your name to the learn about section.
= Introduction =
We will use it over the week before the meeting to gather status and info
and
discussion items and so forth, then use it in the irc meeting to transfer
information to the meetbot logs.
= Meeting start stuff =
#startmeeting Infrastructure (2019-01-31)
#meetingname infrastructure
#topic aloha
#chair nirik pingou puiterwijk relrod smooge tflink threebean cverna
mkonecny
= Let new people say hello =
#topic New folks introductions
#info This is a place where people who are interested in Fedora
Infrastructure can introduce themselves
#info Getting Started Guide:
https://fedoraproject.org/wiki/Infrastructure/GettingStarted
= Status / Information / Trivia / Announcements =
(We put things here we want others on the team to know, but don't need to
discuss)
(Please use #info <the thing> - your name)
#topic announcements and information
#info nirik will have sparse hours due to house move
#info devconf happened and many meetings occurred. Feedback will occur.
#info outage at PHX2 colocation around 2019-02-02
#info cleanup of sysadmin groups
= Things we should discuss =
We use this section to bring up discussion topics. Things we want to talk
about
as a group and come up with some consensus /suor decision or just
brainstorm a
problem or issue. If there are none of these we skip this section.
(Use #topic your discussion topic - your username)
#topic Discuss: Is the Fedora pastebin still useful? - relrod
#topic Oncall
#info smooge is on call from 2019-01-31 -> 2019-02-07
#info ?????? is on call from 2019-02-07 -> 2019-02-14
#info ?????? is on call from 2019-02-14 -> 2019-02-21
#info ?????? is on call from 2019-02-21 -> 2019-02-28
#info Summary of last week: (from relrod )
#topic Monitoring discussion
#info https://nagios.fedoraproject.org/nagios
#info Go over existing out items and fix
#topic Tickets discussion
#info https://pagure.io/fedora-infrastructure/report/Meetings%20ticket
Go thru each ticket one by one
= Apprentice office hours =
#topic Apprentice Open office minutes
#info A time where apprentices may ask for help or look at problems.
Here we will discuss any apprentice questions, try and match up people
looking
for things to do with things to do, progress, testing anything like that.
= Learn about some application or setup in infrastructure =
(This section, each week we get 1 person to talk about an application or
setup
that we have. Just going over what it is, how to contribute, ideas for
improvement,
etc. Whoever would like to do this, just add the i/nfo in this section. In
the
event we don't find someone to teach about something, we skip this section
and just move on to open floor.)
#info
= Meeting end stuff =
#topic Open Floor
#endmeeting
--
Stephen J Smoogen.
5 years, 2 months
