#5846: move away from md5 for look-aside cache
by Fedora Release Engineering
#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
9 years, 2 months
#5654: Report full image creation for quality website updates
by Fedora Release Engineering
#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
9 years, 3 months
#5859: Releng improvements ideas 2014
by Fedora Release Engineering
#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
9 years, 3 months
#4071: Block pushes to origin/ in gitolite ACLs
by Fedora Release Engineering
#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
9 years, 7 months
#4355: metadata for "grouped" files on master mirror
by Fedora Release Engineering
#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
9 years, 7 months
#5653: script automatic weekly install rawhide trees
by Fedora Release Engineering
#5653: script automatic weekly install rawhide trees
--------------------+------------------------
Reporter: mattdm | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: other
Keywords: | Blocked By:
Blocking: |
--------------------+------------------------
This was removed as part of the No Frozen Rawhide at the anaconda team's
request. Dennis mentions that at this point they're for having a weekly
tree (but no more). Dennis further notes that this is basically just a
matter of
* setup a cronjob
* get the compose box to mount /pub/alt rw
* automate cleanup of old trees
And Kevin noted that the rw mount was no problem.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5653>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years, 7 months
#3903: change component owner in bugzilla
by Fedora Release Engineering
#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
9 years, 7 months
#5700: mass bugzilla script uses wrong urls
by Fedora Release Engineering
#5700: mass bugzilla script uses wrong urls
-------------------+------------------------
Reporter: ausil | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: other
Keywords: | Blocked By:
Blocking: |
-------------------+------------------------
the script for mass filing bugs puts the wrong urls in to log files. they
are short lived anyway. we need to find a better way to deal with them.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5700>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years, 8 months