#6278: Request to unretire valabind
-------------------+------------------------
Reporter: rebus | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: git
Keywords: | Blocked By:
Blocking: |
-------------------+------------------------
Hello,
please can you unretire the valabind and assign rebus and brouhaha to be
admins/owners of the package.
https://bugzilla.redhat.com/show_bug.cgi?id=1270630
Thank you
Michal Ambroz
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6278>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6259: Please build eu-central (Frankfurt) AMI IDs for public cloud images
-----------------------------+------------------------
Reporter: robyduck | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 23 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Since F23 Alpha there is no AMI ID for eu-central (Frankfurt). Actually we
dropped this from the websites too, but we will have automatic scripts
running for F23 final.
Therefore it would be fine to have a complete list of all 9 regions,
Frankfurt included.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6259>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6260: Retire all packages with broken deps before the F23 release
-----------------------------+------------------------
Reporter: kalev | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 23 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
As per https://fedorapeople.org/groups/schedule/f-23/f-23-releng-
tasks.html packages with broken dependencies should get blocked before the
F23 final freeze (Tue 2015-10-13). We have to figure out who's going to
send out notices to package maintainers and who's going to do the
blocking.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6260>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
Dear all,
You are kindly invited to the meeting:
Fedora Release Engineering on 2015-10-19 from 15:30:00 to 16:30:00 UTC
At fedora-meeting-1(a)irc.freenode.net
The meeting will be about:
Fedora Release Engineering weekly meeting
Source: https://apps.fedoraproject.org/calendar/meeting/2026/
Hello all,
We currently have a lot of documentation in the Fedora Wiki[0][1]
that is either old and out of date or just not relevant anymore and I
know many people don't like to work in the wiki so I would like to
make a proposal to change the documentation workflow so that we can
improve the docs for ourselves and for potentially new community
contributors who would like to join the fun.
I would first like to explain a couple options I have about Release
Engineering documentation first.
I believe we should ultimately have two "types" of documentation for
different roles that contributors would like to take on.
I think we can define this as "Rel-Eng Ops" and "Rel-Eng Tools Devs" such that:
Rel-Eng Ops are those who are doing the work to create composes,
manage the infrastructure, the day to day operations, and the like.
This is where the Standard Operating Procedures[1] for Fedora Release
Engineering should live as well as an on-boarding guide for new
community members who would like to know more about Fedora Rel-Eng
and/or join the group and share in the work.
Rel-Eng Tools Devs are people who are going to be collaborating on
release tools upstream such as pungi, mash, mock, koji, and others.
These tools should each independently have their own documentation and
test suites in order to describe how community developers who would
like to contribute to these tools can do so. Things here that should
be documented are common development workflows, tools that are used to
make development/contribution easier, coding guidelines, contribution
and pull request workflow guidelines, etc.
I think the tools themselves should be referenced in the SOPs or
"Rel-Eng Ops" documentation in order to bridge those who are using the
tools to the tools themselves as someone participating in one form of
contribution (working on Ops tasks) may very well also participate in
the other (contributing code to tools) or vice versa. I definitely
don't want there to be any impression that these should be disjoint
types of contribution/contributors but more so that they can stand on
their own independently if someone out in the community who would like
to contribute is more interested in one area versus the other.
Proposal:
I would like to start with the RelEng Ops documentation as it's the
most "single point of entry", has a lot of docs that can be
"translated" from the Wiki along with getting updates, and would be a
good resource to have updated and documented in terms of the
on-boarding of potential new contributors which could lead to interest
in other tools that need individual documentation.
We would format all documentation using ReStructuredText[2] and
sphinx-doc[3] as that is the defacto standard in the python community
(which most of our tooling is written in), it's easy to use, and is
already in use by the Fedora Apps, Infrastructure, and QA teams.
(There are more example but I thought these were enough)
I propose these docs live in the releng pagure repository
(https://pagure.io/releng) and possibly have a space on
readthedocs.org[4] as it's already under heavy use with Fedora
projects with docs written in rst/sphinx.[5][6][7][8][9]
We could alternatively use pagure itself for docs hosting as pagure
hosts it's own docs also written in sphinx[10][11][12], it's not as
automatic for rendering and would take a little bit of scripting but
it's certainly an option.
If you've made it this far you get a cookie or something, but thank
you for sticking with it.
I'm open to questions, comments, general feedback, and of course snide remarks.
Thank you,
-AdamM
[0] - https://fedoraproject.org/wiki/ReleaseEngineering
[1] - https://fedoraproject.org/wiki/Category:Release_Engineering_SOPs?rd=Release…
[2] - https://en.wikipedia.org/wiki/ReStructuredText
[3] - http://sphinx-doc.org/
[4] - https://readthedocs.org/
[5] - https://fedora-fedmsg.readthedocs.org/en/latest/
[6] - http://autocloud.readthedocs.org/en/latest/
[7] - http://fedimg.readthedocs.org/en/stable/
[8] - http://nuancier-lite.readthedocs.org/en/latest/
[9] - http://libtaskotron.readthedocs.org/en/latest/
[10] - https://pagure.io/pagure/blob/master/f/doc
[11] - https://pagure.io/docs/pagure/
[12] - https://docs.pagure.org/pagure/
#6222: Unblock dist-tags for unretired package "mysql-connector-net"
-----------------------------+------------------------
Reporter: elsupergomez | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 23 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
The "mysql-connector-net" package has been unretired
Pkgdb is OK: https://admin.fedoraproject.org/pkgdb/package/mysql-
connector-net/
Push access to SCM is OK.
"fedpkg build" for master and f23 fails with "package mysql-connector-net
is blocked for tag f24".
See: https://bugzilla.redhat.com/show_bug.cgi?id=1223455
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6222>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project