This time also the CHECKSUM files changed from i386 to i686.

Replying to [ticket:5654 shaiton]:

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.

There was zero changes in the processes used to here and should have been no changes. though looking now, i seem to have forgotten to copy to the spins path only. likely an oversight because we only use that for final. the fix would have been to ping me and i would have made sure they were in the right spot. there was no need for a website change.

• 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.

• 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.

• 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.

• 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.

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.

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 :)

I changed the component, because this does not appear to be a koji-related ticket.

We are going to rewrite the download page on the Fedora Project (still designing mockups). This is the right time to drop our hard written (with many small fixes) code in favor of something clever.

Sure, I know better communication always help. But you know, when people are in rush to publish in time, they don't see websites as important (even if without us there won't be right communication).

Could we start thinking about scripting what is pure releng/infra? (Fedora live/DVD)
Isn't ARM going to go primary soon?

About spins, if it's just based (100% of time) under the kickstart name, could you provide us the generic path? Also if the team could generate the list of accepted spins for release, that would be great.

There's a somewhat-related plan to provide this just for cloud images (https://fedoraproject.org/wiki/Features/FirstClassCloudImages/KojiPlan); I'm all for doing it in a general way and with more info.

Unless we have a compelling reason to do otherwise, https://launchpad.net/simplestreams seems like a good format to work with.

This seems like a good candidate for consideration in the F21 schedule https://lists.fedoraproject.org/pipermail/devel/2013-August/188143.html

So, f22 is coming up now... where are we at?

Oh yeah, that's rather old now.

I'm paying more attention to all changes and Dennis is helping the websites team providing all useful informations in time (thank you for that). We are also redesigning spins.fpo, so my idea is to find another solution for the image paths, because having the json working only the very last day is not very useful and makes me worry ;)

i386 and i686 situation is stable now and I didn't notice any changes during the last two releases (thanks to releng). I think it's the best to close this ticket and eventually file a new one once we have all new websites running, but probably it will not be necessary anymore.

I'm just not sure if we should keep this ticket or file a new one for F23, because we have a spin more (Cinnamon) but I'm not sure it fits on a single layer DVD.