On Monday, May 13, 2019 1:31:07 AM CDT Adrian Schröter wrote:
first of all, _multibuild and multiple spec files via source links are two independend concepts. They can be even combined, only a factory policy forbids this atm.
It was a side discussion, but definitely very similar concepts that could be simplified a lot on both sides by being combined regardless of some abstract way to utilize both simultaneously.
Multibuild ==========
My question regarding the purpose was because I think that you don't need to have this logic outside of OBS. It is even harmfull when we enhance our mechanics more (eg. further multibuild features), because it will break this logic again.
The purpose of this email was to request such functionality be in OBS. Otherwise, there would be no point in discussing as I would just modify the code to perform an additional 15,000+ queries.
so it does not matter that you get the mutibuild source containers. This is why I keep asking what you want to do with that information...
I was very clear about what the purpose of the information was in the original email. Both tools and interfaces (for humans) to review status or perform operations on all packages without being cluttered by all the extra psuedo- packages. Performing a bunch of expensive queries on all multi-build packages (or local links) which have the same sources, and thus the same result, is not helpful. What would be helpful is that the /source/<project> API do what the prefix implies and provide a listing of source containers which can then be further filtered to exclude local links and maintenance packages. Another example is a simple tool to email all maintainers of the packages they have within Leap before release. Ludwig runs this tool manually with custom e- mail text to give maintainers a final heads up before release. Running such a tool on a SLE project would result in 15,000 entries instead of 3,000. The origin-manager tooling would be useful to apply to maintenance projects, but runs into the same problem. For SLE, instead of taking an hour to run it takes 17 hours due to getting 15,000 entries instead of 3,000. Making the rest of the APIs handle the psuedopackages is nice, but filtering them to avoid the useless query entirely is much much better.
Maintenance Release Projects ============================
Last, we can indeed support some simplified listings for maintenance_release projects. We will need an extra option, but shouldn't be too complicate.
Does this sound like a plan?
It's not just for maintenance_release projects. SLE :GA projects contain all the maintenance packages due to the layering. Regardless of what is done to the web interface an API-level filter is needed. I specified exactly what is needed in the original email.
/source/<project>?maintenance=0&multibuild=0&multispec=0
However one words it or implements it is up to the implementor. -- Jimmy -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org