rel-eng September 2010

rel-eng@lists.fedoraproject.org

5 participants
161 discussions

#3802: Symlink for latest branched and rawhide mash
by Fedora Release Engineering 19 Oct '12

19 Oct '12

#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

1 8

#2025: Too hard to build dependent packages in stable
by Fedora Release Engineering 17 Oct '12

17 Oct '12

#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

1 2

#4139: Fedora Hosted gitweb invalid URLs
by Fedora Release Engineering 17 Oct '12

17 Oct '12

#4139: Fedora Hosted gitweb invalid URLs -----------------------+---------------------------------------------------- Reporter: mschwendt | Owner: rel-eng(a)lists.fedoraproject.org Type: defect | Status: new Milestone: | Component: git Keywords: | -----------------------+---------------------------------------------------- https://admin.fedoraproject.org/pkgdb/acls/name/mash -> http://pkgs.fedoraproject.org/gitweb/?p=mash.git -> http://pkgs.fedoraproject.org/git/mash.git -> 404 not found Seems to affect all projects listed at http://pkgs.fedoraproject.org/gitweb/ http://pkgs.fedoraproject.org/gitweb/?p=zlib.git;a=summary -> http://pkgs.fedoraproject.org/git/zlib.git -> 404 not found -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4139> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 6

#4056: Update sigul systems
by Fedora Release Engineering 19 Mar '12

19 Mar '12

#4056: Update sigul systems ----------------------+----------------------------------------------------- Reporter: jkeating | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: | Component: other Keywords: | ----------------------+----------------------------------------------------- there is new python-nss stuff we should built up and look at. Might also setup a staging environment on el6 and see if things work (better?) there. Also need to make a change to the user environment so that v3 sigs are preferred by default. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4056> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

#3740: fix critpath generation to be per branch and properly import into pkgdb
by Fedora Release Engineering 26 Jan '12

26 Jan '12

#3740: fix critpath generation to be per branch and properly import into pkgdb ---------------------+------------------------------------------------------ Reporter: notting | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: | Component: koji Keywords: | ---------------------+------------------------------------------------------ As I understand it, critical path generation should work like this: {{{ * Lists are generated at rawhide, branched, or updates compose time * These lists are synced into pkgdb for that branch * bodhi then reads these from pkgdb }}} Where are we currently? For the first item, we only generate critpath during rawhide/branched compose. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3740> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 14

[Fedora Release Engineering] #859: updates-newkey doesn't have group_gz member
by Fedora Release Engineering 26 Jan '12

26 Jan '12

#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

1 12

#4054: Add regular FTBFS handling to each cycle
by Fedora Release Engineering 04 Aug '11

04 Aug '11

#4054: Add regular FTBFS handling to each cycle -------------------+-------------------------------------------------------- Reporter: kevin | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: | Component: other Keywords: | -------------------+-------------------------------------------------------- Each cycle Matt Domsch runs a mass rebuild against all fedora packages: http://fedoraproject.org/wiki/FTBFS Those that fail to build from source have bugs filed on them to be fixed. After the Alpha we should orphan all packages that have FTBFS bugs that are in "NEW" state (ie, not looked at by the maintainer). This would give other folks a chance to pick up the package and fix it so it builds. In the event that the package is not taken over or fixed, it would be dropped at the same time as all the other orphans are dropped. Timing for this should be determined and added to the rel-eng calendar and list of tasks as well as a SOP written up to handle how to do this. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4054> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#3565: Please Tag libproxy-0.3.1-4.fc13 for F-13 Beta - default install of libproxy modules
by Fedora Release Engineering 05 May '11

05 May '11

#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

1 4

#3729: unblock package perl-version in cvs
by Fedora Release Engineering 04 Feb '11

04 Feb '11

#3729: unblock package perl-version in cvs ----------------------+----------------------------------------------------- Reporter: mmaslano | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: | Component: cvs Keywords: | ----------------------+----------------------------------------------------- This package lives again. Please unblock cvs in all needed branches: F-12 F-13, F-14. Bugzilla ticket with review of package perl-version: https://bugzilla.redhat.com/show_bug.cgi?id=579682 -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3729> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 11

#3575: Provide deltaisos for development releases
by Fedora Release Engineering 03 Feb '11

03 Feb '11

#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

1 24

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng September 2010