As I am working on bringing pagure as a front-end to our dist-git, a question is
Currently ACLs are stored in pkgdb, it allows having a per-branch ACL model,
which in itself is quite cool, but I wonder: is it that useful?
I know pkgdb brings us other things too and I am explicitely ignoring them here
because I think we can find solutions for them, which may even have benefits
over our current processes.
So, does per-branch ACLs make sense to you? Have you had cases where you thought
it was good/bad? More importantly, have you had cases where you would want to give
someone access to just one branch and really really do *not* want them to have
access to the other branches?
Of course, EPEL vs Fedora comes to mind here, but I wonder: if the EPEL maintainer
has also commit on the Fedora branches, is it really that much of a big deal?
Before I investigate what it would take to drop pkgdb entirely and let pagure
handle the ACLs, I wanted to hear from you if you think this is a terrible idea
or worth investigating.
Thanks in advance for your feedbacks and ideas,
PS: for full disclosure: pagure does not support per branch ACLs at the moment
and in the current way we are syncing information from pkgdb to pagure, we are
only taking rawhide into account. So if you have commit on rawhide, you will
have commit access on pagure to all branches, if you do not have commit access
on rawhide, you won't have commit access on pagure.
Note that this concerns only commit access via the UI and the ability to merge
PR as gitolite underneath (used when doing git push via ssh) still per branch
PS2: I am also considering this question having in mind the change in branching
model the modularity work will bring (ie: branch no longer tied to a Fedora
version but rather to upstream's version)
There was an issue with GCC7 during the mass-rebuild. Despite the Fedora-wide
setting of -Werror=format-security, GCC did not process its command-line
properly and an unknown number of packages were built without this flag
appropriately set. As a result, all of those packages built successfully during
the mass-rebuild, where many should in fact have reported compilation errors and
As part of the modular builds that the Base Runtime is performing, we need to
rebuild all packages that are going into the base runtime (as well as the set of
packages required to self-host the base runtime). Because GCC has been updated
to properly handle the CLI arguments, somewhere between two and three dozen
packages now throw errors on building.
Because we are under time-constraints, Petr Šabata and myself will be using our
provenpackager privileges to apply patches to these packages without waiting for
maintainer correspondence. The patches will be very simple, as the fix for this
issue will be in most cases the equivalent of replacing printf(variable) with
In very rare cases where the fix is non-obvious, we may take the short-term
solution of setting -Wno-format-security for that package and open a Bugzilla
for the maintainer to fix it properly (or engage upstream to do the same).
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
# Fedora Quality Assurance Meeting
# Date: 2017-04-03
# Time: 15:00 UTC
# Location: #fedora-meeting on irc.freenode.net
We haven't met for a couple of weeks, so let's get together and see
If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.
== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. Fedora 26 status
3. Test Day status
4. Open floor
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
test-announce mailing list -- test-announce(a)lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org