So, in general I think this is a pretty cool idea and I am in favor of it. I do think we are going to have to learn and adjust as we go here somewhat, we can't be 100% sure of how this will pan out. Of course we should plan as best we can now too. :) Some random things in no particular order: * This is the sort of thing that doesn't really fit the change process too well, since it's not really tied to a release or adding some deliverable to a release or whatever. I guess it's the best we have though currently. * So, while you say "we will not be shipping any content produced from ELN directly to the general public", it sounds like ODCS composes and of course packages from koji will be available for those that know where to look for them, which brings up: ** Can you add that you will document how these packages interact somewhere? I guess the ELN wiki page if nothing else. ie, say eln packages are built with different compiler flags, we should have some way to tell people who get a hold of them what hardware will work on them or fail completely. ** If we get a lot of demand we may need to redo stuff around ODCS, as it's currently just a pair of vm's with a nfs mount to serve those composes. If there's a lot of load we may need to put some caching in front of it or put it on a dedicated download server or something. * Might note that this will require a new "release" in bodhi. I don't think thats much work (might just be config), but could be good to check. * Might add in the benifit to fedora that ODCS will get worked on and perhaps someday we can move all our other composes into it. (This would allow us to not have a bodhi-backend machine, it could be all in openshift, and let us let koji do the heavy lifting instead of a rawhide-composer instance) * Suggestion: How about making a ELN tracker bug and require anything that uses %eln or has some failure to build being filed against the package and tracked in the tracker. This would allow people who care to follow along and see how many issues there are, etc. * Depending on when we get this going, timing might be not that great. We have the datacenter move coming up. In late may/early june we will likely have a lot less capacity of builders until we can re-add machines as they arrive from shipping. I think as long as you don't mind things being slow, we could tune it so ELN builds are not as high priority as normal builds (so they will wait until there's capacity for them). They would still finish, just might take longer and not impact other builds. In fact, perhaps we should set this from the start and see if it causes you any issues? * Additionally there will likely be some more disk usage from this (on ODCS and in koji). However, if we only need to keep around the last working eln build and don't keep a bunch of composes I don't think this should be too big an issue. Definitely something to watch tho. Anyhow, those are probibly also a lot of things we can just sort out with releng, but figured I'd throw them out there while I was thinking about them. Overall I think this could be a very nice effort and won't even hopefully cost us much in time and energy. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
