On Fri, Jul 01, 2016 at 06:14:00PM +0200, Adam Samalik wrote: > Thanks for the response. I agree, asking you "I am building something I > haven't described, how do you want to use it?" might have not been the best > idea... So please, let me try that again and better. :-) Thanks Adam :) > I have created a wiki page [1] that briefly describes the BPO component, > what data would be available, and the main three possible functions. > > > > > > > * Should there be a 'developer' or 'end user' type here? Ie, is it > > expected that they would want to look at this to see what the latest > > version of some module they care about is, or if there's new ones > > that might be coming along soon? Or is that another tool? > > > It would be probably both. But I would focus mainly on developers in the > early stage. Later, there might be something similar to what you described > for the end user. > > > > > > * Depending again on the kinds of things this can report on, > > infrastructure might be interested in it. Could we query it via > > nagios to let us know about problems in module building or testing ? > > > If you would use something like this, I would be happy to include it in the > BPO. > > > > > > * Modules can depend on other modules right? If so, a way to see that > > tree of dependencies in building would be nice (ie, moduleA depends > > on moduleB, and moduleB is currently rebuilding for foo, moduleA > > should show that it's pending rebuilding after that, etc) > > > Yes. This should also be there. > > > > [1] https://fedoraproject.org/wiki/Modularity/BPO Here are some thoughts on the context. Currently, when a packager packages a new upstream release, then build it for rawhide and then they think "what stable releases to I want to also build and ship this for?" Maybe all of them? Maybe just F24? The point is that the packager thinks about it, knows what they're doing, and then does it. Then, about 24 hours later, releng scoops up whatever has been done. - For rawhide, pungi builds the repos and ships it out. - For stable releases, bodhi mashes repos, and ships them out. The most grizzled veterans will rightly balk when I say, "it's easy to know what state an update is in." But.. it's more or less linear. Was it patched but not built? Was it built but not added to an update? Was it in an update but not yet pushed? Is it pushed but not yet on the secondary mirrors? Etc.. In the Modularity Working Group (for various reasons) we're talking about building automation services on top of koji that will automatically rebuild modules based on new available components (these are rpms) (and only sometimes, based on policy). Furthermore, we're hoping to break some of the releng tasks (like the 24 hour nightly compose/push) out into ad hoc tasks that happen alongside, shortly after builds of intermediary components are done (triggered by message bus events). So, that's hard to do. We're working on trying to get it right. One side effect of deploying it is that it's going to be super confusing for packagers to look at this whole thing and figure out what state a patch is in. Say I patched a CVE in component X. Has it been rebuilt into modules L, M, and N? Did it fail in module O's buildroot? If those have been built, which have been shipped? That's all from the developer standpoint who starts from a patch. Release engineering would want a similar kind of question to be answerable: if we have a patch that fixes CVE blah-blah-blah, has that been built into all the artifacts we ship now? Can we say that we've fixed it across the board so we can write a press release? We'll have data scattered all over the place that, when put together, can answer questions like this: some in koji, some in PDC, some in bodhi, some in mirrormanager. The idea here is to make this 'BPO' service (the Build Pipeline Overview service) something that can make those questions easily answerable in one place. In architecture terms, it is like a 'data mart' (convenient access to data that comes from the 'data warehouse', which is bigger and harder to interface with).
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
