#859: updates-newkey doesn't have group_gz member
-------------------------------------+--------------------------------------
Reporter: james(a)fedoraproject.org | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
-------------------------------------+--------------------------------------
I assume the createrepo instance that generates the Fedora 9 updates-
newkey/updates-testing-newkey is the RHEL-5 version?
Can we change this to be the Fedora 9 version so that we'll get group_gz
as well as group (ie. comps.xml.gz as well as comps.xml). This makes for
much less data to download, to get group information.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/859>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4722: Create tickets and plan tasks for EOL
-----------------------------+----------------------------------------------
Reporter: ausil | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: Fedora 15 Final | Component: koji
-----------------------------+----------------------------------------------
Create tickets and plan tasks for EOL
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4722>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4719: Propose Schedule for Next Release
-----------------------------+----------------------------------------------
Reporter: ausil | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: Fedora 15 Final | Component: koji
-----------------------------+----------------------------------------------
Propose Schedule for Next Release
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4719>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4994: Make it clear in releng SOPs that branching must be complete prior to Alpha
compose
----------------------+-----------------------------------------------------
Reporter: adamwill | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: other
Keywords: |
----------------------+-----------------------------------------------------
I'm working through the F16 QA retrospective:
https://fedoraproject.org/wiki/Fedora_16_QA_Retrospective
One of the notes there from jlaska reads:
jlaska - Alpha branch - Unclear when the F16 branch was completed as not
all tasks in the Mass_Branching_SOP were completed. The SOP either needs
to be followed or updated.
MirrorManager was not updated to add a fedora-16 repo tag, therefore,
TC1 installations could not find a repository to install from (RHBZ
#727428)
TC1 images were built with Version=16-Alpha.TC1 specified as the
--version argument to pungi. This results in a file /.buildstamp in the
install image with an incorrect version (Version=16-Alpha.TC1) that is
used as the $releasever variable for yum. The net result is that there are
no yum repos that match repo=16-Alpha.TC1&arch=x86_64. The version needs
to be an integer, or MirrorManager redirects need to be established prior
to compose.
The fedora-release package was not properly updated to include
[fedora] with enabled=1. As a result, TC1 images included a fedora-release
package that didn't enable the Fedora 16 repos.
The fedora-release package was not updated to include the Fedora 16
release name Verne. This is a minor issue, but results in login prompts
claiming the system is Rawhide. Recommend updating (or creating) the
existing Mass_Branching_SOP to document expected results when updating
fedora-release
adamw - seems branching may not actually have been completed by time
of TC1 delivery, even. Perhaps appropriate releng SOPs should be updated
to clarify that branching - or at least some specified subset of branching
tasks - must be completed before Alpha TC1 delivery
Due to all of those issues, it seems like releng should have an SOP for
all the various tasks involved in branching, and the relationships between
releng SOPs should make it clear that all the branching tasks have to be
completed before an Alpha compose is attempted.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4994>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4906: some form of QA access to torrent and mirror content prior to public
posting
----------------------------+-----------------------------------------------
Reporter: robatino | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: Fedora 16 Beta | Component: koji
Keywords: |
----------------------------+-----------------------------------------------
In the last several releases, there has been a high probability that at
least some of the Alpha and Beta torrents will have only unsigned checksum
files (see https://fedorahosted.org/fedora-qa/ticket/237 ). No matter how
quickly the problem is noticed, one is always told that it can't be fixed
after public posting, since people are already downloading. Unfortunately,
QA has no access prior to public posting to prevent it. There are
documentation issues in releng's SOP pages that probably aggravate this
problem (see the other ticket), but even if these are fixed, QA should
still have a chance to check the content before it's public. A lesser
problem is if the checksum files are signed more than once and different
files are used on the torrents vs. mirrors (as in F15 Final). I realize
there are possible secrecy issues regarding access to the signed files
prior to the official release, but the mirrors are given access days in
advance, and they almost always leak. QA might be able to set up some kind
of AutoQA checking to minimize the amount of human access. In any case, QA
could at least be given access to the .torrent files, to check the size of
the checksum files. Signing adds about 1K to the size, so it would be
possible to detect if the unsigned file was used. Having access to the
actual signed file would be nicer, if possible, since the test could be
both simpler and more reliable (verifying the signature itself).
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4906>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4921: Remove packages from EPEL-4
--------------------+-------------------------------------------------------
Reporter: smooge | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
--------------------+-------------------------------------------------------
Please remove the following packages from the EPEL el4 repositories as
they are retired.
mediawiki114
mediawiki115
mediawiki116
They do not work and have broken dependencies.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4921>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4954: f17-mono koji target
------------------+---------------------------------------------------------
Reporter: chkr | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
------------------+---------------------------------------------------------
In order to implement the approved changes to the mono stack (
https://fedoraproject.org/wiki/Packaging:Mono#File_Locations ), we have to
fix and rebuild all mono-based packages (around 65). This will take a
couple of weeks.
Please create a specific build target to avoid breakage in rawhide during
that time.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4954>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4920: name rules at dl.fp.o/alt/stage
-----------------------------+----------------------------------------------
Reporter: hongqing | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: Fedora 16 Final | Component: other
Keywords: |
-----------------------------+----------------------------------------------
We Fedora QE team would like to set up a mirror or proxy of
dl.fp.o/alt/stage, because the isos are needed to run the the AutoQA
tests. But I find some other directories, such as deltaiso that the AutoQA
does not need, are also there. So I would like to discuss with you about
the name rules of Rawhide, Alpha, Beta and Final releases, and whatever
others will also be putted there, so we can define the parse rules to
download the compulsory isos. If you have any internal name rules there,
please let us know, or let's define a new one. Thanks.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4920>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project