> # tl;dr > > (LATER) OK, this email got really long, so here's my tl;dr summary. > Proposed compose ID scheme: (RELEASE)-(DATE).(INDEX).(TYPE), e.g. > 24-20160401.0.s (types are SNAPSHOT, CANDIDATE, POSTRELEASE). > Alternatively: type is stored as separate bit of metadata instead of > / as well as in the compose ID. > > Proposed additional metadata in PDC: 'nominated' (bool, whether a > SNAPSHOT was nominated for manual validation testing or a CANDIDATE > nominated as an RC), 'release' (one of a set of consts, 'ALPHA', > 'BETA', 'FINAL', 'POSTRELEASE', indicating that a CANDIDATE was > released as that milestone). > > Rules: all 'override' packages go in all composes, we never build more > than one compose type for one release at a time, we switch from > SNAPSHOT to CANDIDATE when all blockers are addressed and back to > SNAPSHOT after the milestone release, we switch to POSTRELEASE after > Final. > > Location: we can either have PDC be the canonical store of location > information, or just have some kind of engine (whether it's still my > 'fedfind' or something else) which can work out where to find a given > compose based on all the metadata mentioned in this proposal. I like the proposal, great job, thanks. Minor questions below. > The basic ideas here are pretty simple. The naming scheme for composes > is: > > (RELEASE)-(DATE).(INDEX).(TYPE) > > The compose 'types' are SNAPSHOT, CANDIDATE, and POSTRELEASE. Their > shortenings for the compose IDs are 's', 'c' and 'p'. (These don't > sort "correctly" alphabetically, but that shouldn't be a problem). This > is similar to the scheme currently used for snapshots, but with a type > identifier after the index number (I don't know if '.n.' in the current > IDs is supposed to indicate "nightly" or "number" or what, but if we > want to indicate the type in the compose ID, it makes much more sense > to have it after the index than before). > > Importantly, the compose IDs for a given release sort into their > release order. The only potential issue is if we have more than 9 of a More than 10, the index starts from 0. > compose type on a day. To deal with that we could just make the index > two digits instead of one, Can we easily adjust the numbering scheme if it ever happens that we need more than 10 composes per day? I wouldn't do it right away since it doesn't seem likely we would need it, but if we ever hit that point, we should make sure it's fairly simply to change it even during our release cycle. > or it's relatively easy to do a numeric sort > instead (just filter all the non-digit characters and do a numeric sort > on the rest). I don't follow you here. If we have 24-20160510.2.c 24-20160510.10.c Then after filtering out non-digit characters we have: 24201605102 242016051010 which still sorts incorrectly: 242016051010 24201605102 Unless you meant to parse the compose index out and then do a numeric sort just on that. That works. If we don't intend to bump up number of digits (at least potentially), we should document in PDC docs that the index is supposed to be sorted numerically, that can save us troubles in some tools in the future. > > Note that we don't really *need* to indicate the compose 'type' in the > ID. We could instead just have it in the compose metadata. I don't care > strongly either way, though I think it's maybe slightly more convenient > to have it in the ID. Originally I wanted to say I like it, because it's then easy to go through the list of all the composes and still see where Alpha candidates started (if you roughly know the date) and which was the final Alpha compose (the last candidate). But then I realized that doesn't have to be true, the last candidate doesn't have to be the one accepted for release. So I don't know if we're not making it easy with the TYPE tag to do the same mistake by other people. (OTOH, the same problem is with our usual Alpha RCx names, the last one doesn't have to be the release one). Still, it seems to help humans, and we should document how to do it properly with "automata". > Also not visible in the mockup: "compose override" packages are *always > included in all types of compose*. This is the concept Dennis and I > came up with for handling blocker / freeze exception fixes; it's just a > more formal version of the current process, really, whereby we mark > packages that should be pulled into composes. At present these are only > pulled into TCs and RCs, they never appear in the old-style "nightly > composes". I believe we should *always* pull them in; it makes the > system a good deal simpler. I'm a bit confused here. The override packages were used for TCs and RCs, but not for Live nightlies done in Koji. Pungi4 will now do all of that as part of a single compose, daily, right? So are you just saying those override packages will end up used in all compose artifacts produced, and we no longer need to care about the TC+RC vs Live nightly difference? In that case that's great. > There's also another issue we could use 'nominated' to answer. That is: > when exactly do we build 'CANDIDATES'? Do we follow the current process > and build them only on manual request, meaning that effectively every > 'CANDIDATE' is equivalent to a current RC? Or do we build a 'CANDIDATE', > say, *every time the "compose overrides" set changes*, and then > 'nominate' RCs from the larger set of CANDIDATEs? If we want to do that, > then the 'nominated' attribute for CANDIDATE composes would indicate > which were selected as RCs. I like the latter. More automation, less manual work for releng. > That's pretty much the entire system. I had thought about things like > storing compose "identifiers" like RC2, RC3 etc. in the compose metadata > or in PDC directly, and stuff like requiring PDC to construct and store > "sequences" of releases. But with this design, I don't *think* any of > that is necessary. I believe the constraints specified in the proposal > and the information in the compose IDs and the extra PDC fields is > actually sufficient to all the tooling purposes I can think of. The idea > is that tools can simply query PDC for groups of composes and apply > logic to construct certain ideas. > > For instance: say we decided we're going to build CANDIDATEs for every > change to "compose overrides", and we now want to "nominate" an RC. We > can just ask PDC for all CANDIDATEs for the current release which have > been "nominated" so far, and it's trivial to produce the sequence of RC > names from that and determine what ours should be. (To spot the > milestone changes you just look for the composes which also have the > 'release' attribute). So the releng tool to stage the CANDIDATE as an RC > and the QA tool to create wiki pages can easily produce a nice "RC name" > for humans, if we want to do that. For 24-20160510.0.c, it seem quite natural to me to talk about it as "the candidate from May 10". So even if we scratch "RC2", it doesn't seem as a big deal to me. The only issue I see is with 0-based index numbering, because for 24-20160510.2.c many people will say "the second candidate from May 10", which it is not, and confusion will arise. You did a similar mistake above when counting the number of possible single-digit-index composes (and I realized it only when writing this paragraph). Human mind can be deceiving. Should we start indexing from 1, if we were to abandon "RCx" names? (Despite all that I have to say I really like the zero there, it makes the date more readable, zeroes are somehow clutterless :)). -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
