rel-eng February 2014

rel-eng@lists.fedoraproject.org

11 participants
138 discussions

#5215: Stage comps and spin-kickstarts during freezes
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5215: Stage comps and spin-kickstarts during freezes -----------------------------+------------------------ Reporter: adamwill | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: git Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ As noted on the F17 QA retrospective by me and Bruno Wolff: https://fedoraproject.org/wiki/Fedora_17_QA_Retrospective it's a problem that we use git master of both comps and spin-kickstarts for composes - not the latest packaged version - and both these git repos are not frozen during freezes. During the 17 cycle, we had a concrete example of a comps change during a freeze causing considerable trouble: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=807879 - pulling Boxes into comps during the Beta freeze made that issue a serious problem. For spin-kickstarts, the same kind of thing is possible, and we also have a release criterion requiring a spin-kickstarts package which matches the .ks files used for the compose to be present in the release repository; obviously, the lack of a git freeze makes this tricky to ensure. So we would strongly recommend, at minimum, a mechanism for freezing spin- kickstarts and comps at Alpha, Beta and Final freeze. Post-freeze changes could be made following the same blocker/NTH process used for other post- freeze changes. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5215> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#5223: F18 TODO: automate torrent generation
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5223: F18 TODO: automate torrent generation -----------------------------+------------------------ Reporter: ausil | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Torrent Releases Infrastructure SOP http://torrent.fedoraproject.org/ is our master torrent server for Fedora distribution. It runs out of ServerBeach. Contact Information Owner: Fedora Infrastructure Team Contact: #fedora-admin, sysadmin-torrent group Location: ibiblio Servers: torrent.fedoraproject.org Purpose: Provides the torrent master server for Fedora distribution Torrent Release When you want to add a new torrent to the tracker at http://torrent.fedoraproject.org you need to take the following steps to have it listed correctly: 1. login to torrent.fedoraproject.org. If you are unable to do so please contact the fedora infrastructure group about access. This procedure requires membership in the torrentadmin group. 2. upload the files you want to add to the torrent to torrent.fedoraproject.org:/srv/torrent/new/$yourOrg/ 3. use sha1sum and verify the file you have uploaded matches the source 4. organize the files into subdirs (or not) as you would like 5. run /srv/torrent/new/maketorrent [file-or-dir-to-torrent] ([file-or-dir-to-torrent]) to generate a .torrent file or files 6. copy the .torrent file(s) to: /srv/torrent/www/torrents/$yourOrg/ 7. cd to /srv/torrent/torrent-generator/ or /srv/torrent/spins- generator/ (depending on if it is an official release or spins release) 8. add a .ini file in this directory for the content you'll be torrenting. we use fedora-torrent-ini.py from fedora releng git repo to generate it 9. mv all files from /srv/torrent/new/$yourOrg into /srv/torrent/btholding/ - this includes the files you uploaded as well as the .torrent files you've created. Your files will be linked on the website and available on the tracker after this. $yourOrg is one of fedora or spins this all needs to be setup to be done via a single script. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5223> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 4

#5332: [RFE] Generate .composeinfo for Fedora secondary arches
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5332: [RFE] Generate .composeinfo for Fedora secondary arches -----------------------------+------------------------ Reporter: bpeck | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Please generate a .composeinfo for secondary arches. The secondary arches that we are interested in are: arm, ppc, and s390. Ideally we could get a .composeinfo when *all* these arches are complete. But I understand that they have different time schedules and may update at different times. Worst case we look to see if the datetime on the file changes and we can re-import again with the newly added arch. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5332> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#5775: switch to partitioned image and "hd00" pvgrub akis for EC2; remove editing of menu.lst from image processing
by Fedora Release Engineering 09 Mar '15

09 Mar '15

#5775: switch to partitioned image and "hd00" pvgrub akis for EC2; remove editing of menu.lst from image processing ----------------------------+------------------------ Reporter: mattdm | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Beta | Component: koji Keywords: | Blocked By: Blocking: | ----------------------------+------------------------ The "hd00 aki" is like the pvgrub kernel image we are using now, but meant for a partitioned device. If we switched to doing this, we could avoid editing the menu.lst file, and therefore would have a more-identical image. . See http://www.dowdandassociates.com/content/howto-amazon-ec2-kernel- images-pv-grub/ (or http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UserProvidedkernels.html, which seems to have vanished today) for more. You can find the images in each region with: euca-describe-images -o amazon --filter "manifest-location=*pv-grub- hd00*" and of course take the newest version. At this point, I doubt we want to change this by alpha, but maybe we could for beta? -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5775> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 6

#4985: Extend test image creation SOP to require notification of delays
by Fedora Release Engineering 09 Mar '15

09 Mar '15

#4985: Extend test image creation SOP to require notification of delays ----------------------+----------------------------------------------------- Reporter: adamwill | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: | Component: koji Keywords: | ----------------------+----------------------------------------------------- Working through the F16 QA retrospective here: https://fedoraproject.org/wiki/Fedora_16_QA_Retrospective One of the notes is: "jlaska - Alpha TC1 - Missed the Alpha-TC1 milestone by 1 week, little to no communication regarding status. With only two weeks Alpha ISO test time, losing 50% of time almost certainly results in a slip. See rel-eng ticket#4844 . None of the Alpha rel-eng release tickets have been filed at this time. adamw - perhaps releng image compose SOP should require updating of ticket with progress info, especially when image compose / delivery is delayed?" So: this ticket proposes that the releng 'Composing test images' SOP - https://fedoraproject.org/wiki/Composing_test_images - should be extended to require whoever is creating the images to post a comment on the image request ticket if the compose is delayed, explaining the reasons for the delay (so that any other interested party can attempt to contribute to resolving them) and giving a best estimate of an ETA if possible (so other groups can adjust their scheduling as best they can). Thanks! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4985> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 4

#5836: Update gitolite to gitolite3
by Fedora Release Engineering 09 Mar '15

09 Mar '15

#5836: Update gitolite to gitolite3 ------------------+------------------------ Reporter: till | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: git Keywords: | Blocked By: Blocking: | ------------------+------------------------ The package gitolite3 in EPEL should be used to update gitolite for dist- git. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5836> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

#5846: move away from md5 for look-aside cache
by Fedora Release Engineering 23 Feb '15

23 Feb '15

#5846: move away from md5 for look-aside cache ------------------+------------------------ Reporter: till | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: other Keywords: | Blocked By: Blocking: | ------------------+------------------------ The lookaside cache uses md5, but something more secure like sha-256 or sha-512 should be used instead. Maybe it should even be made to allow easy changes in the future. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5846> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 22

#5654: Report full image creation for quality website updates
by Fedora Release Engineering 19 Jan '15

19 Jan '15

#5654: Report full image creation for quality website updates -----------------------------+------------------------ Reporter: shaiton | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 19 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi, we already discussed a bit about this issues with nirik, before the F19 release day. However, yesterday was worse as expected. Please see the number of fixes: https://git.fedorahosted.org/cgit/fedora-web.git/log/ (7 important fixes after the merge into prod aedf487eb). == Summary of major issues: * http://torrent.fedoraproject.org/spins/ changed to http://torrent.fedoraproject.org/torrents and we had no idea about this. * The naming scheme of the file changed which introduced a bug in our spins website build as it is based against the Json file. We had to fix a 2 years old python code. And we did not know about this. * Each release we have the 32 bit arch named i686 or i386, it's always changing. We defined variables in order to help us maintain the websites.. And this does not help us. I know that it depends of the proc instruction set. But where is the need to change that really? Could we avoid it? Sooner or later we will drop 32 bit arch... Couldn't we define which arch to stick with? * We don't know before last minute if the Spin has built for GA and therefore if it is going to be released. We need to check it manually. And really, we can't do it all manually. (as lazy programmers we can't even think about this). * Even the spins name has changed in the past, which break our code and already existing URLs. And then we need to define URL redirect... I hope jam-kde won't be changed to jam-mate-compiz-fusion-dark at some point.. Just wondering... * The secondary (ARM) path changed from Images/arm/ to Images/armhfp/.. I understand the need to tell if it's using FP or not, but again we didn't know about this before testing in prod. That should not happen again. Please, help me define the best way to avoid this. It could be improving SOP, or updating a file after each build.. whatever. It's a probably wider collaboration issues as it is involving primary, secondary, SIGs (spins, cloud).. But starting with Releng we can probably sort this and define the smoother solution for all. What we need in a simple way (script friendly) and easy to generate for you is a way to get: All image full name, path (if possible before release), size (not needed for torrents), format (torrent, spin, dvd, cloud... whatever) and checksum. What can't be available easily can have an easy process to get them or at least we need to know how and when to get them. The most important of course is the image full name. If we don't know that this image exists (or died), we won't be able to update it. Any brillant idea? -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5654> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 9

#5859: Releng improvements ideas 2014
by Fedora Release Engineering 19 Jan '15

19 Jan '15

#5859: Releng improvements ideas 2014 -----------------------------+------------------------ Reporter: till | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Final | Component: other Keywords: meeting | Blocked By: Blocking: | -----------------------------+------------------------ Ideas to improve releng: - Properly announce in advance if meetings are skipped -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5859> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 5

#5679: merge buildbranched/buildrawhide into a single script
by Fedora Release Engineering 10 Nov '14

10 Nov '14

#5679: merge buildbranched/buildrawhide into a single script -----------------------------+------------------------ Reporter: ausil | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ in order to simplify things it would be good to make a single script to build rawhide and branched. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5679> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng February 2014