On Sat, 2016-02-20 at 15:33 -0800, Adam Williamson wrote: > As a pre-note: I'm really only concerning myself with the "Official > Release Process Composes" here, the composes we consider part of the > (still) more-or-less monolithic 'release cycle'. I didn't try to > think of a design that accounts for separate release cycles per > image or product or 'variant' or whatever (because jeez, this is hard > enough) and I didn't include any possible side/alternative composes > done for testing or whatever. At this point in time I don't care what > anyone wants to call or do with those, so long as I can ask PDC for > a list of the 'official' composes and just get those. You know...writing this pre-note made me think "hmm, maybe this is wrong, and I should design a system that *does* think about those things". So now I'm stewing on that. But before writing another big novel, let's see what people think of this. Still, a quick preview: 1. maybe "all the composes that are part of the full-fat Fedora release sequence" is just *one* 'type' of compose, and we should just keep building them and name them by date and index number, and instead of "type" for those composes we need info like "were all blockers addressed when this compose was built?" and we make decisions about human-readable names and blessing releases and creating test events based on *those* properties, rather than conceptually bundling them up into an erroneous "type" notion. 2. maybe we extend this notion so we store information like "what repositories were enabled for this build" and "what images did we attempt to build"; any bundling of those things gets done at the *input* end, as a sort of 'compose profile', and we use logic based on the essential properties of the output to decide what we might want to do with the result... so we might have the information for a given compose "all images targeted, package override repository enabled, all blocker bugs addressed", we can determine "did all blocking images successfully build?", we either include the information "Alpha milestone freeze passed" or we can go get it from the schedule API, maybe QA feeds into PDC "all required validation tests passed or waived", then our rule engine can look at that build and say, hey, this is the Alpha release! thinking about it in terms of qualitative (rather than arbitrary) properties of composes, and rules engines for imposing actions and definitions onto composes based on those properties, gives us a whole lot more flexibility to do stuff like "all Atomic blocking images built successfully, test systems report (required test set) passed, it's been 2 weeks since last Two Week Atomic release - this gets blessed as a Two Week Atomic Release!", and pretty much anything else we want to do. We just have to store the attributes and build the rules engines. I think the *hardest* question then becomes "what do we set as the compose ID?" - perhaps we should simply assign literally a serial number to each compose, no matter what set of repositories or whatever it's built from, and use rules to create more friendly names based on the compose's attributes at the point where the compose gets staged out from the initial pool where we stick *all* the composes? OK, I should stop now. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
