#5665: Providing a master CHECKSUMS file for boot.fpo
-----------------------------+------------------------
Reporter: shaiton | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Alpha | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hi, as requested to webmasters[1], could we get a CHECKSUMS file (as
provided for other Fedora releases) including all checksums?
It also needs to be signed of course.
You might decide that it is not needed, just forwarded the query.
[1]
https://lists.fedoraproject.org/pipermail/websites/2013-July/011535.html
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5665>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#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
#5678: koji package for cloud images so they can be non-scratch, and garbage
collection policies for those packages
-----------------------------+------------------------
Reporter: mattdm | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Replying to [ticket:3897 mattdm]:
> We want to generate non-scratch cloud images. Because of a bug, these
currently need to have the name of the architecture in the package. That
will be fixed in the Real Soon Future, but in the meantime I'd like to get
going with what we have. Could we please create koji packages named
>
> {{{
> Fedora-19-cloud-x86_64
> Fedora-19-cloud-i386
> Fedora-20-cloud-x86_64
> Fedora-20-cloud-i386
> Fedora-rawhide-cloud-x86_64
> Fedora-rawhide-cloud-i386
> }}}
>
> And, we would also like to have a custom garbage collection policy for
these; even though they are not scratch builds, they don't need to stay
around forever. If we can do a nightly builds (ideal), then I think a week
is fine; if they are weekly, keeping a month around seems good. Of course,
longer is always better.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5678>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5622: [RFE] Allow user to (create/)delete private branches
-----------------------------+------------------------
Reporter: vondruch | Owner: rel-eng@…
Type: enhancement | Status: new
Milestone: Fedora 19 Alpha | Component: git
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
I'd like to be able to manage my private branches. For example, in
preparation for Ruby 2.0 release, I was pushing my changes to .spec file
into Ruby's repository in dist git, into ruby-2.0 branch. This branch is
already merged into master for some while and I'd like to delete it, but
it is forbidden:
{{{
$ git push -f origin :ruby-2.0
remote: + refs/heads/ruby-2.0 ruby vondruch DENIED by fallthru
remote: error: hook declined to update refs/heads/ruby-2.0
To ssh://vondruch@pkgs.fedoraproject.org/ruby
! [remote rejected] ruby-2.0 (hook declined)
error: failed to push some refs to
'ssh://vondruch@pkgs.fedoraproject.org/ruby'
}}}
Would it be possible to allow some development branches, which can be
created and deleted as well, without need of opening rel-eng tickets etc?
Thanks
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5622>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5329: RFE: Send branched report only when there is any change committed
-----------------------------+------------------------
Reporter: pnemade | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 18 Alpha | Component: mash
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hi,
While we are in freeze, can branched report be only sent to the
devel/test list when there is any change added for any package?
Parag.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5329>
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
#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
#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