#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
Resolution:                   |   Keywords:
Blocked By:                   |   Blocking:
------------------------------+-----------------------

Comment (by robyduck):

 Replying to [comment:2 ausil]:
 > > * 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.
 >
 > The naming scheme should be exactly the same as it was for Alpha and
 Beta. it will be changing again in Fedora 20. the changes were outside of
 our control.

 We don't have Alpha or Beta Spins on http://spins.fedoraproject.org but
 advance to the next release only at GA. Unfortunately we can't even test
 it locally because the Json for the next release is not available until GA
 release date or a few hours before.

 > > * 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?
 >
 > the processes we use to compose require some parts to be i686 but as
 people complained that live and spins being i686 and the repo trees that
 require the basearch being i386 was confusing we changed the spins and
 live dirs to i386 but some parts do require i686 we should have been
 consistent thought the fedora 19 cycle. and they should have matched what
 was in fedora 18. any changes are a bug and we would need to rectify it.

 Yes, the i386-i686 question is really unclear. I understand to have the
 dir's nominated to i386 as the arch in the repos, but let's keep all the
 rest as iti is now (i686). There was a change indeed compared to F18, live
 and spin ISOs remained i686 and that is fine, but CHECKSUMS changed from
 i386 to i686. Don't know if we should define it as a bug, IMO it's more
 clear now, all i686. (hoping they won't rechange it from now on!)

 > > * 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).
 >
 > If a spin builds or not is known in advance but going forward we are
 going to be enforcing testing so some that build will not be shipped and
 not known until late.  we need to work out a better way to communicate
 this to the websites.

 Yes, that would be nice. I also read something about having builds with
 the spin leaders for every stage (alpha and beta) before GA, this surely
 will help.

 > > * 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...
 >
 > We name the spins based on what the kickstart file is called. the
 kickstart is fedora-live-jam-kde.ks and the naming to my knowledge has
 never changed, i suspect that it was a miss-communication or people not
 understanding how things work and not asking for clarification. Had anyone
 asked I would have told them it would be called jam-kde.
 >
 > > * 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.
 >
 > Its not a change at all, we had both arm and armhfp for fedora 18, we
 dropped support for software floating point so the arm tree went away. i
 guess we maybe did not document or communicate this properly, but it was
 the case that we shipped Beta this way, there was no arm alpha.

 I think a document where to get all this informations in time would have
 been useful for us.

 > > 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.
 >
 > There needs to be open communication, most of the issues would have been
 avoided if we talked.
 >
 > >
 > > 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.
 >
 > this should be scriptable.
 >
 > > 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?
 >
 > Talk and we need to write some scripts to help each other out.

 Ok we can even talk, but we also understand the single teams are doing a
 lot of work to ship their versions (Spins, 2nd arches, CLoud...) in time
 and make them working smoothly. It would be really useful to have some
 scripts where the single teams involved write down the stuff we need, for
 other things we can talk and this time I was asking a lot around to get as
 much informations as possible.\\
 It's nice to have this discussion here, if we want having teams write down
 the info's we need we have to involve their leaders and we should also
 insert it in the single Release Tasks every team has. Which form? We could
 start with a wiki page or any other document where people can add all the
 stuff.\\
 Obviously it would be up to us to create such a document. Thoughts about
 how should it be?

 Thank you ausil for your nice reply, I'm sure this ticket will lead to a
 smoother process :)

-- 
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5654#comment:3>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project