make mechanical stream version numbers more meaningul

[dustymabe]

For our production and development streams the date stamp in the version string for each build reflects the time the yum repo was updated (i.e. a reflection of the freshness of the package set). This datestamp is derived from the input lockfile (that was generated by the bump-lockfile job. For mechanical streams we don't have an input lockfile with timestamps, so the datestamp version for our mechanical streams is just today's date.

It would be nice if the datestamp in the mechanical stream version numbers could also reflect the repo timestamp (package freshness indicator).

[dustymabe]

I've almost talked myself into implementing lockfiles for rawhide. I feel like we need more control of that stream, but I also don't know if it's worth adding every rawhide RPM to our coreos-pool, which will balloon that resource and slow things down.

[jlebon]

I think this is related but not the same. Do you want to open a tracker issue to discuss maybe adding lockfiles to rawhide?

[dustymabe]

I think this is related but not the same.

Yes, but if we implemented lockfiles it would solve this issue, which is why I was brought it up here (probably off topic, though).

Do you want to open a tracker issue to discuss maybe adding lockfiles to rawhide?

I think I talked myself out of it.

[dustymabe]

This is mostly cosmetic issue for mechanical streams (which aren't user facing). It's a low priority.