#1107: auto-cleanup rawhide trees
-------------------------+--------------------------------------------------
Reporter: notting | Owner: rel-eng(a)lists.fedoraproject.org
Type: enhancement | Status: new
Milestone: | Component: koji
Keywords: |
-------------------------+--------------------------------------------------
Rawhide tree expiry is manual at the moment, unless I missed something.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/1107>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3624: fullfilelist changes
-------------------------+--------------------------------------------------
Reporter: mmcgrath | Owner: rel-eng(a)lists.fedoraproject.org
Type: enhancement | Status: new
Milestone: | Component: other
Keywords: |
-------------------------+--------------------------------------------------
After each push, we need to run the following command:
rsync -r . > fullfilelist
This should overwrite the fullfilelist that's there and isn't very useful
at the moment:
http://download.fedora.redhat.com/pub/fedora/fullfilelist
We can't do this via a cron job, it has to go out after each push so it
needs to be added to those scripts.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3624>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#2244: How to mass branch s390utils and other non-primary arch packages
--------------------+-------------------------------------------------------
Reporter: toshio | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
--------------------+-------------------------------------------------------
This is a rel-eng decision that I'll need input on. Currently the
packagedb branches packages which are not blocked in koji. Some packages
which are not built for the primary arch are blocked in koji -- s390utils
for instance. Does the packagedb need to whitelist these or should the
packages be unblocked as they are discovered?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/2244>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#2025: Too hard to build dependent packages in stable
-------------------------+--------------------------------------------------
Reporter: hadess | Owner: rel-eng(a)lists.fedoraproject.org
Type: enhancement | Status: new
Milestone: | Component: koji
Keywords: |
-------------------------+--------------------------------------------------
It's too complicated, human-dependent, and time-consuming to build
interdependent package updates in stable releases.
Two cases:
* gstreamer and gstreamer-plugins-base are released at the same time, and
so are pre-releases of those. They soft-depend on each other (gstreamer
can be updated on its own). It's currently not possible for me to offer
both pre-releases of gstreamer and gsteamer-plugins-base without either:
1. asking for a package to be tagged into the build roots
2. pushing gstreamer into stable (takes a few days at best), and push the
gstreamer-plugins-base package separately
* gnome-bluetooth and gnome-phone-manager, where I need to ask for gnome-
bluetooth to be pushed into the buildroot tree. Sometimes that just
doesn't work (as could have been seen in
http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7140 /
https://fedorahosted.org/rel-eng/ticket/1945 and
http://koji.fedoraproject.org/koji/buildinfo?buildID=112091 )
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/2025>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#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
#3565: Please Tag libproxy-0.3.1-4.fc13 for F-13 Beta - default install of
libproxy modules
----------------------------+-----------------------------------------------
Reporter: kwizart | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: Fedora 13 Beta | Component: koji
Keywords: |
----------------------------+-----------------------------------------------
Hello,
I request libproxy-0.3.1-4.fc13 to be tagged as F-13 Beta.
This is the last update before the ABI change of the 0.4.0 version that
has already appeared in F-14.
Here is the Changelog between 0.2.3 and 0.3.1:
http://code.google.com/p/libproxy/source/browse/trunk/ChangeLog
On a side note, installing libproxy on a default desktop install of F-13
Alpha will, lead to have:
libproxy
libproxy-bin
libproxy-python
With this package, the default will lead to have:
libproxy
And that will be all, as all unneeded dependencies have been dropped as
described in:
https://bugzilla.redhat.com/show_bug.cgi?id=537569
Once that said, it would be more valuable to have libproxy-gnome installed
as soon as the gnome desktop is selected on install. (1)
Upstream advice is to use Rpm's 'Suggests' instead of 'Requires', as
requires would imply some circle dependencies.
But we don't use Suggests much if possible. So I think it would be better
handled by comps for now.
(1)
Same for:
libproxy-kde and KDE desktop
libproxy-mozjs and firefox
libproxy-webkit and WebKit-gtk
libproxy-networkmanager and NetworkManager
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3565>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3575: Provide deltaisos for development releases
--------------------+-------------------------------------------------------
Reporter: kparal | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: other
Keywords: |
--------------------+-------------------------------------------------------
'''Background:'''
Currently Fedora 13 is in a development, that means Test Composes, Release
Candidates and Final versions of Alpha/Beta/Final milestones are regularly
released. During this period there may be even several releases in one
week. Each release consists of 1x 3.5GB DVD, 6x 700MB CD, 1x 200MB netinst
image and 1x 1GB LiveCD. This is created for i386 and x86_64
architectures.
This is quite large amount of data. Every person interested in occasional
or regular testing must download substantial part of this release. That
makes certain demands on user's internet connection and also !RelEng
infrastructure (internet bandwidth, I/O).
'''Proposal:'''
Release Engineering team will create a deltaiso file for every release of
current Fedora development series. This deltaiso file will contain
differences between that particular release and a previous release. That
means deltaisos will be created in this fashion:
* Fedora 13 Alpha TC1 -> Fedora 13 Alpha TC2
* Fedora 13 Alpha TC2 -> Fedora 13 Alpha RC1
* Fedora 13 Alpha RC1 -> Fedora 13 Alpha
* Fedora 13 Alpha -> Fedora 13 Beta TC1
* Fedora 13 Beta TC1 -> Fedora 13 Beta RC1
* Fedora 13 Beta RC1 -> Fedora 13 Beta RC2
* Fedora 13 Beta RC2 -> Fedora 13 Beta
* Fedora 13 Beta -> Fedora 13 (Final) TC1
* Fedora 13 (Final) TC1 -> Fedora 13 (Final) RC1
* Fedora 13 (Final) RC1 -> Fedora 13 (Final) RC2
* Fedora 13 (Final) RC2 -> Fedora 13 (Final)
Because deltaisos are useful typically for media that consists
[https://fedoraproject.org/wiki/Delta_ISOs mainly of RPM files] this
process would involve mainly DVD image and would not involve LiveCD. For
other media (CD, netinst) the decision is still to be made. Deltaisos for
DVDs are [http://thepiratebay.org/user/andre14965/ typically around
100MB].
Deltaisos will be stored in a single directory (e.g. deltaisos/ in
[http://alt.fedoraproject.org/pub/alt/stage/ /pub/alt/stage]), so it is
easy to convert any older ISO the user currently has into a new one, even
several releases forward. These deltaisos will be stored for the period of
the development release - beginning with Fxx Alpha TC and ending with Fxx
Final (with a small extra time after the final release to allow people to
upgrade their ISOs to the final release).
The deltaiso creation process may be easily automated and
[https://fedoraproject.org/wiki/Delta_ISOs is described on our wiki]. No
additional human interaction should be needed.
'''Rationale:'''
The main reason for this proposal is to enable people with slower internet
connection to participate in installation testing. This often involves not
only developing countries, but also highly-developed countries
[http://lists.fedoraproject.org/pipermail/devel/2010-March/133326.html
like the USA]. I believe that although some more people would be
interested in doing installation testing, it is currently too expensive
for them from download time and bandwidth perspective.
Quite interestingly this also includes me as a Red Hat employee. While it
is my job to perform installation testing regularly, our office does not
have internet line thick enough such that I could afford downloading DVD-
sized images several times a week. Performing regular nightly mirroring is
not an option when new releases may be pushed even daily.
Up till now Andre Robatino (CCed) has been performing the repetitive task
of downloading every development release for every architecture, creating
deltaisos and publishing them [http://thepiratebay.org/user/andre14965/ as
torrents] (because he doesn't have any publicly available storage). Our
evidence shows that these torrents are used, which means they are useful
for people (and his work is invaluable for me personally). QA has started
to exploit his work officially
[https://fedoraproject.org/wiki/Test_Results:Fedora_13_Beta_RC3_Install on
every installation testing page].
The problem is that Andre is usually the only seeder, so the download
speed is really slow and there are connection problems sometimes, so
people often
[http://lists.fedoraproject.org/pipermail/test/2010-March/089110.html
complain about it]. Second problem is that those deltaisos are published
with a noticeable delay (Andre has to detect new release, download, build,
upload and announce). Overall this a huge waste of Andre's time and
energy. A defined and automated process from !RelEng side would simplify
all of this and improve the experience for our users a lot.
Another benefit would be lowered IO/bandwidth load on Fedora
infrastructure.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3575>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3507: Secondary arche only packages need to be unblocked in primary arch koji
---------------------+------------------------------------------------------
Reporter: ausil | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: meeting |
---------------------+------------------------------------------------------
Blocking secondary arch only packages causes two issues
1) they do not get branched at mass branch time
2) they get blocked in secondary arches when they sync blocked packages
I recommend that we unblock them on the primary arches.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3507>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3561: metadata_expire=7d in branched Fedora repo files
---------------------+------------------------------------------------------
Reporter: notting | Owner: rel-eng(a)lists.fedoraproject.org
Type: defect | Status: new
Milestone: | Component: other
Keywords: |
---------------------+------------------------------------------------------
We put:
metadata_expire=7d
in the 'main' fedora repo files. This works great with the release tree,
as it doesn't change. This doesn't work well with the branched repo,
however, as we push it every day.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3561>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project