#5654: Report full image creation for quality website updates

[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