#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
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
We don't have Alpha or Beta Spins on http://spins.fedoraproject.org
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,
changing. We defined variables in order to help us maintain the
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
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
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
> * Even the spins name has changed in the past, which break our
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
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
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
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
avoid this. It could be improving SOP, or updating a file after each
> It's a probably wider collaboration issues as it is
secondary, SIGs (spins, cloud).. But starting with Releng we can
sort this and define the smoother solution for all.
There needs to be open communication, most of the issues would have been
if we talked.
> What we need in a simple way (script friendly) and easy to generate
is a way to get:
> All image full name, path (if possible before release), size
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
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