From cf4e98451a80bea8616694fdc53042794c85d7b7 Mon Sep 17 00:00:00 2001
From: Kevin Fenzi <kevin(a)scrye.com>
Date: Tue, 23 Aug 2016 20:17:51 +0000
Subject: [PATCH] update freemedia form for fedora 24
roles/freemedia/files/FreeMedia-form.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/roles/freemedia/files/FreeMedia-form.html b/roles/freemedia/files/FreeMedia-form.html
index a9d2c48..78dad4f 100644
@@ -47,7 +47,7 @@ To request <b>ONE</b> copy of Fedora DVD or Live Media by mail, please fill out
<tr><td><b><small>Email</small></b></td><td><input type="text" size="20" name="email"></td></tr>
-<input type="radio" name="release" value="Fedora 23" checked>Fedora 23</>
+<input type="radio" name="release" value="Fedora 24" checked>Fedora 24</>
And also a run of the sundries playbook.
As you all know, Mozilla Persona is going down in the next few months. I've
spent the last weeks since Flock updating the Mailman UI code to use a
library that will allow us to support local accounts properly, on top of
external services accounts. I'm currently testing it in staging, and I'd
like to update to code in production after the alpha freeze. It's a pretty
decent amount of code change so I'm being careful here, and the DB schema
migration may take a couple minutes. There was also a big branch merged in
Mailman (unrelated, but a pretty large code change).
I'm thinking a day or two after alpha is released, in my morning (UTC+2) so
the US folks will be asleep and I can still get help from Patrick if
necessary (Patrick doesn't seem to have a timezone anyway).
Does this seem OK to you?
On Aug 12, 2016 4:00 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
> tflink pushed this change right around freeze, but it's not yet active
> on noc01 (needs a playbook run).
> +1s to just push it out? It shouldn't affect anything else.
while searching for doc in the infra repo, I stumbled
on a few occurence of us using rpm -ivh on http, and this kind of stuff.
I fixed the docs to use https, but would like to remind
people about making sure they do not forget MitM risks,
and also ask to verify that I didn't commit something
wrong to the repo (as I also fixed a few urls while on it)
Patrick and I also disagree on using DNS name in some part of the kickstart doc, so
if there is anything not working, please feel free to fix :)
The infrastructure team will be having it's weekly meeting tomorrow,
2016-08-18 at 18:00 UTC in #fedora-meeting 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 =
This shared document is for the next fedora infrastructure meeting.
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 (2016-08-18)
#chair smooge relrod nirik abadger1999 lmacken dgilmore threebean pingou puiterwijk pbrobinson
#topic New folks introductions
= 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 wikiedit fas group created for people who need to edit, but don't fit in other groups - kevin
#info inactive apprentices dropped monday - kevin
#info created bodhi-backend03 fedora 24 instance, mostly works - kevin
= 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 or 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 flock workshop followup - kevin
= Apprentice office hours =
#topic Apprentice Open office hours
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 info 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.)
#topic Learn about:
= Meeting end stuff =
#topic Open Floor
I am one of GSoC students of this year and my project is to bring
pkgs.fp.org <http://pkgs.fedoraproject.org/> on a pagure instance. The
script is almost ready but there is one issue which needs some advice.
The group *provenpackagers* currently has commit rights over all the
repositories. As you might know, in pagure if some group has commit rights
on a repository, all the members of that group also has rights on the
project and it's listed as their own project. This would mean that all the
members of provenpackagers would have >18k projects of their own.
(it says 1119 projects, it's under investigation at the moment.)
pingou came out with two ideas:
*1. Drop provenpackagers from pagure: *This would mean the proven packagers
won't get any particular advantage of shifting to pagure as they won't be
listed as admins of all the projects in the pagure db. They won't be able
to merge/close pull requests, edit a file directly via the web-interface or
execute any other admin rights on any of the repository they wish. They
would, however, have access to all the git repositories as they would be
present in gitolite conf file. They would be able to push to any of the
repositories as it is the case at present.
*2. Create exception for provenpackagers:* This is hackish. We can give
them admin rights on all the repositories but won't show them in their
profile. (only for provenpackager group). Proven packagers will get all the
fun on moving to pagure.
pingou is inclined to go with the first option and so am i.
What do you think? Does anyone have a strong preference for
one or the other?