> The more I think about it the more I tend to like my general proposal > from the follow-up to this email, which is that we should build the > tooling to think about the *essential properties* of composes. This is > in specific contrast to building the tooling to work on *constructed* > properties like the 'SNAPSHOT', 'CANDIDATE' and 'POSTRELEASE' concept I > came up with above. > > See, look at it like this: What do 'SNAPSHOT', 'CANDIDATE' and > 'POSTRELEASE' really mean? They're what I'm currently thinking of as > "synthetic properties", which really stand for a bunch of essential > properties reduced in a particular conceptual way. The problem with > this is that the way we bundle the properties up is *innately tied to > our current release process*. The more I think about it, the more I'm > concerned that by baking those into the compose IDs we're essentially > baking certain properties of the current release process in at too low > a level. > > So say we look at SNAPSHOT, CANDIDATE and POSTRELEASE composes. The > essential property that differs between them is really only *when* in > the (current) release cycle they're built: SNAPSHOTs before the > relevant freeze point is reached or all blockers for it are addressed, > CANDIDATEs after the freeze point for a milestone is reached and all > blockers addressed, POSTRELEASE after the "final" release is done. But > they all kind of *assume* a few essential properties that aren't > stated: > > i) built from the repositories and compose metadata appropriate to the > current 'main sequence' release process > ii) targeting all the images in current 'main sequence' release > composes > iii) for the current primary arches > > and the whole scheme for naming them is quite innately tied to *the > current monolithic release process*. So by adopting this naming scheme, > we're kind of inadvertently encoding an awful lot of things about the > current release process right into the compose IDs, which I suspect may > be a mistake. > > Even the *release number* is really a synthetic property: "this is a > Fedora 24 compose" is only a valid concept based on the system where we > make regular numbered releases of Fedora (and a single sequence of > increasingly-numbered releases, at that). If we bake that into the > compose ID, then what if we switched to a rolling release model? What > 'release number' do we use for composes from that point onwards? Just > hardcode one and have it sitting there uselessly in the compose ID > forever more? Change the scheme? > > The compose ID's job, ultimately, is to be just that: an *identifier*. > To let us uniquely identify a particular compose, mainly in order to > ask other tools for information about it or to do something with it. > The more I think about it the less I like the idea of encoding > properties of the release in it, especially these *synthetic* > properties that may become incorrect or irrelevant. So I start wanting > to simplify more and more. The current scheme for Rawhide composes is > actually not bad, because it only encodes three properties, and two of > those are 'essential': > > i) Release number > ii) Compose date > iii) Index relevant to other composes on the same date > > My suggestion to just give each compose a numerical compose ID which > increments by 1 every time we do a compose - *any* compose - is not > very different from just doing "YYYYMMDD.(index)" or something similar. > It's just that the latter kinda arbitrarily selects "date of compose" > as an 'essential property' that's indicated by the compose ID instead > of / as well as metadata (or PDC). > > So yeah: on second thoughts, I don't think it's a good idea to > construct and denote 'synthetic properties' in the compose ID. If you can distill everything above into a 30-seconds explanation how things work, which is easy to understand and doesn't sound like a university paper on nuclear physics merged with philosophy, then maybe :) Because it can be easily done for "20160401.0.c". And often the KISS principle is much better than higher abstraction, which is more universal and "cleaner" but much harder to grasp. It's very possible that I simply did not understand your revised proposal, but "20160401.0.c" seems to strike the balance between simplicity and usefulness to me. If you mean that we will have a sequentially growing integer number of any kind of compose, and we'll define everything somewhere else (PDC), then it's probably cleaner, but it's harder to use by humans and therefore less useful. Putting the date into the ID doesn't harm anything (it's just a particular type of sequentially growing numbers) and helps human usage a lot. The snapshot type identifier might be more questionable, but still seems more useful than not. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
