#4986: Create a 'Deliverables' page / SOP listing exactly what images, torrent
files, signatures, checksums etc should be provided with (pre)-releases
----------------------+-----------------------------------------------------
Reporter: adamwill | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
----------------------+-----------------------------------------------------
Going through the F16 QA retrospective, there's this series of linked
points from Andre Robatino:
"robatino - Alpha and Beta torrents often have unsigned checksum files -
this just happened with 16 Alpha. It also happened during F13 and F14 -
see http://lists.fedoraproject.org/pipermail/test/2010-April/090106.html
for F13 Beta, and https://bugzilla.redhat.com/show_activity.cgi?id=638738
for F14 Alpha and Beta. When it's pointed out, we're told that it's not
feasible to change them once people have started downloading, but if this
is true, there needs to be better checking (at least as much as for mirror
content, which can be changed) to make sure the torrents are correct
before being posted. Filed https://fedorahosted.org/fedora-qa/ticket/237
and https://fedorahosted.org/rel-eng/ticket/4906 . No response from releng
as of yet. Unless QA is given access prior to public posting, it is
powerless to prevent this.
robatino - Also, it's possible that the checksum files can be signed more
than once. There are two versions of the signed checksum files for F15,
one on the torrents (the original ones) and a different one on the
mirrors. See http://robatino.fedorapeople.org/checksums/15-Final/ for the
two versions - for example, Fedora-15-i386-CHECKSUM.orig and
Fedora-15-i386-CHECKSUM. While not nearly as serious as the above issue
(since the checksums are the same and both signatures are good), it could
be confusing. "
A quick mail discussion prompted the suggestion from Andre that the best
way to cover all these issues would be for there to be a Deliverables wiki
page / SOP which clearly lists all the 'bits' that should be delivered for
each image drop - Alpha, Beta, Final, TC and RC. This would provide a
simple reference for whoever's doing the build to make sure everything has
been provided.
It would make most sense for this to live in releng's wiki space, I think,
so filing against releng trac, but a QA person could certainly take care
of creating the page in theory, I think.
We should have this in place prior to F17 Alpha TC1.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4986>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4149: Need a way to point EC2 instances to specific mirrors
--------------------+-------------------------------------------------------
Reporter: gholms | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: other
Keywords: |
--------------------+-------------------------------------------------------
To get Fedora working well on Amazon's EC2 cloud computing service ![1]
the Cloud SIG is working on creating yum mirrors inside Amazon's network.
Doing so provides a number of benefits:
* Faster updates for users
* People with hundreds of Fedora instances don't overload other public
mirrors
* No data transfer costs for users or those who fund the EC2 mirrors
(traffic within a given cloud region is free)
Unfortunately, data transfers are only free if they stay within a given
region. This, combined with the fact that EC2's IP addresses freely roam
between regions, makes normal IP-based direction via !MirrorManager
impossible. We therefore need another way of directing clients toward the
mirrors that reside within their own regions.
Our list of proposed solutions to this are posted in the "Client Access"
portion of my overall proposal for EC2 mirror infrastructure ![2]. Could
you folks (a) offer any feedback, or (b) choose which solution would be
best? I apologize if this is more of a FESCo question; I can take it to
them if that would be better.
![1] https://fedoraproject.org/wiki/Features/EC2
![2]
https://fedoraproject.org/wiki/User:Gholms/EC2_Mirror_Proposal#Client_Access
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4149>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5181: i686 java-1.6.0-openjdk is in x86_64 repos
-----------------------------+------------------------
Reporter: dbhole | Owner: rel-eng@…
Type: defect | Status: new
Milestone: Fedora 17 Final | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
The x86_64 repos for Fedora 17 currently contain the i686 versions of
java-1.7.0-openjdk. These should be removed as 32-bit on 64-bit packages
are not supported atm:
http://mirrors.kernel.org/fedora/development/17/x86_64/os/Packages/j/
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5181>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5162: Keep Branched TCs/RCs until Final GOLD
-----------------------------+------------------------
Reporter: kparal | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 17 Final | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
There has been this discussion:
http://lists.fedoraproject.org/pipermail/test/2012-April/106961.html
After some responses were gathered on test list, I humbly ask RelEng team
to keep all the TCs/RCs available in the future until Fedora Branched is
GOLD, unless some technical problems appear (storage, bandwidth). It will
improve the release quality.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5162>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5224: F18 TODO: script pungi runs
-----------------------------+------------------------
Reporter: ausil | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 18 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
to do pungi runs to make fedora install dvds
we run
mock -r fedora-branched-compose-x86_64 --init
mock -r fedora-branched-compose-x86_64 --shell
then inside the chroot we run
pungi -c /srv/pungi/spin-kickstarts.ausil/fedora-install-fedora.ks
--destdir /srv/pungi/17.RC4 --cachedir /srv/pungi/cache/ --ver 17 --flavor
Fedora
if the compose is a final rc we additionally pass --isfinal
once we have go for release we do a final pungi run to make the source
isos passing --sourceiso
we do all this in 2 chroots one using fedora-branched-compose-x86_64 mock
config and the other using fedora-branched-compose-i386
sourceiso only needs made once
We need a script that we can pass in the variables to pungi and run pungi
in freshly made chroots. allowing for sourceiso creation also
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5224>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4963: Remove delta RPMs from Everything before release
--------------------+-------------------------------------------------------
Reporter: gholms | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: mash
Keywords: |
--------------------+-------------------------------------------------------
F15's Everything tree contains around 4G of delta RPMs that are of limited
use when the release is finalized. If they aren't necessary, I would
appreciate the extra mirror space that removing them from F16 and beyond
would free up.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4963>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5174: F-17 update cannot be pushed despite qualifying for stable
-----------------------------+------------------------
Reporter: pghmcfc | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 17 Final | Component: other
Keywords: bodhi | Blocked By:
Blocking: |
-----------------------------+------------------------
I have a critical path update that has been in updates-testing for over
two weeks and has no negative karma, yet I still can't push it to stable:
https://admin.fedoraproject.org/updates/FEDORA-2012-6165/perl-IO-Socket-
SSL-1.66-1.fc17
Yesterday I received an email telling me it had been in updates-testing
for 14 days and I could push it to stable - but I couldn't.
Today I received an "old testing" reminder that I was able to push the
update. I still can't.
There is no "Mark as stable" link, editing the update and putting "Stable"
for "Request" has no effect, and using the bodhi command-line client tells
me that the update has not yet met the stable update criteria.
What's going on?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5174>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4057: Update gitolite build
----------------------+-----------------------------------------------------
Reporter: jkeating | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: cvs
Keywords: |
----------------------+-----------------------------------------------------
Need to do a new gitolite build from upstream and get it into el6 and test
it on pkgs.stg then move it to pkgs. This should allow us to remove some
of our custom hacks.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4057>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3802: Symlink for latest branched and rawhide mash
--------------------+-------------------------------------------------------
Reporter: jlaska | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: mash
Keywords: |
--------------------+-------------------------------------------------------
== Problem Space ==
Currently, the [http://fedoraproject.org/wiki/Critical_Path_Packages
Critical Path Packages] wiki page links to most recently branched and
rawhide critpath.txt files. However, depending on the status of the
compose/mash/pungi, or the timing of the branched schedule, these log
files may not be available. In order to eliminate confusion and 404 links
from the wiki, it would be helpful to provide a link to an ''always''
available critpath.log URL.
== Proposal ==
Create a symlink for the latest successful branched and rawhide
pungi/mash/compose. This symlink will be referenced when directing users
to the latest definition of the critical path. For example:
* http://kojipkgs.fedoraproject.org/mash/rawhide-latest ->
http://kojipkgs.fedoraproject.org/mash/rawhide-20100618/
* http://kojipkgs.fedoraproject.org/mash/branched-latest ->
http://kojipkgs.fedoraproject.org/mash/branched-20100518/
The symlink would be updated upon successful mashing of rawhide or
branched.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3802>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5109: Change live media dirs to i386 to avoid confusion
----------------------------+------------------------
Reporter: kevin | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 17 Beta | Component: koji
Keywords: | Blocked By:
Blocking: |
----------------------------+------------------------
See: https://fedorahosted.org/fesco/ticket/602
We would like to change the dir that live media are in from i686 to i386,
and the iso images themselves to be i386 instead of i686.
This would reflect that they are all 32bit images.
If there's some reason we shouldn't/can't do this, feel free to reopen the
fesco ticket for more discussion.
Thanks.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5109>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project