#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
#5218: block httpd-devel.i686, php-devel.i686 from x86_64 compose
-----------------------------+------------------------
Reporter: jorton | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 18 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Could the .i686 packages for both httpd-devel and php-devel be blocked
from inclusion in the x86_64 compose, we don't (can't/won't) support them
biarch.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5218>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#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
#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
#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
#4071: Block pushes to origin/ in gitolite ACLs
----------------------+-----------------------------------------------------
Reporter: jkeating | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: git
Keywords: |
----------------------+-----------------------------------------------------
Common typo to create a new branch that starts with "origin/". We can
stop that at the ACL level.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4071>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4355: metadata for "grouped" files on master mirror
---------------------+------------------------------------------------------
Reporter: mdomsch | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: other
Keywords: |
---------------------+------------------------------------------------------
This may be less of an issue now that we don't have the split CD set, but
I would like it if rel-eng could produce a file into the master mirror
tree for "groups" of files that should be a single consistent download
set, such as a DVD and the checksum file, or the set of files that are
together inside a single torrent. MirrorManager is growing the idea of a
"file group", a single requestable entity that will return a metalink
listing each of the files in the file group. The intent was to use it for
the multi-CD download sets, but it's just as valuable for the DVD and
checksum file, or other similar groups. But it needs to be a file (say,
.fileset or something), in a directory that MM can find and use to build
the FileGroups.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4355>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3903: change component owner in bugzilla
----------------------+-----------------------------------------------------
Reporter: mmaslano | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: other
Keywords: |
----------------------+-----------------------------------------------------
Could you create perl-fedora-maint as bug owner for all my perl-* modules
and perl component? I'm sharing bugs with my colleagues in RHEL and we'd
like to have it also for Fedora. I suppose set up mailing list is also
needed.
This should be applied only for perl modules, where I am an owner of the
package. Not only co-maintainer.
The group perl-fedora-maint should include mmaslano, ppisar, psabata.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3903>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5214: Setup koji tags and repo for Docs
-----------------------------+------------------------
Reporter: crantila | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 18 Alpha | Component: koji
Keywords: docs | Blocked By:
Blocking: |
-----------------------------+------------------------
Posted here as per [https://fedorahosted.org/fedora-
infrastructure/ticket/3320]
'''phenomenon'''
To support simpler and more robust updates to docs.fp.o, need to setup
koji to handle a new tag and repo for Docs.
'''implementation recommendation'''
<Sparks> What would be required to stand up a separate instance of koji
for Docs? <dgilmore> Sparks: why would you want a seperate instance?
<dgilmore> Sparks: i dont see any valid reason to do so <Sparks> dgilmore:
For the Docs website. Publican has the ability publish documentation from
packages (separate repo from the Fedora repo) for the website. We want to
replace the git repo that operates it now. <dgilmore> Sparks: and why does
that need a seperate koji? <Sparks> The git repo has gotten HUGE and is
becoming an issue. <dgilmore> Sparks: so, why does that mean a seperate
koji instance <dgilmore> Sparks: we could use a seperate tag and targets
in koji <dgilmore> i dont see why it would need its own koji <Sparks>
dgilmore: It's either that or try to get everyone setup as packagers.
<dgilmore> Sparks: get everyone setup as packagers <Sparks> dgilmore:
Except that they really won't be packagers. <dgilmore> Sparks: though you
dont need to be a a packager to get a koji cert <dgilmore> you just need
fas <dgilmore> Sparks: what would be the workflow? <Sparks> dgilmore:
Okay, and with that we can send packages through koji and tag them
separately? <Sparks> dgilmore: Basically we just tell Publican to build
the package and submit it to koji. The Publican software does all the
work. <dgilmore> Sparks: I still really dont know what your trying to do.
pretend im an idiot(not really that hard) and explain what it is and how
it should work <Sparks> dgilmore: I'm not far off... <Sparks> dgilmore: So
Publican will make an SRPM package, submit it to koji destined for a repo.
Our Publican backend will install those packages and publish the data to
the website. <Sparks> ...as I understand it <dgilmore> Sparks: so we would
need to set up seperate tags and tagets for it, defining a koji policy
allowing srpms to be built. likely we would add a new group to koji and
add people allowed to build docs to it and limit access to the
tags/targets to people in that group <dgilmore> Sparks: so its all doable
<Sparks> dgilmore: Well that's a lot easier. :) <Sparks> dgilmore: We
already have a group in FAS for people that should have access (docs-
publishers). Should I open a ticket? <dgilmore> Sparks: koji doesnt know
anything about fas <dgilmore> Sparks: please file a ticket. We wont be
able to make changes until after f17 is done <Sparks> dgilmore: That's
fine. We're not completely ready for the transition so after F17 would be
good. <Sparks> dgilmore: Thanks!
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5214>
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