Mailinglist Archive: opensuse-buildservice (74 mails)

< Previous Next >
Re: [opensuse-buildservice] API query to return all _real_ source packages
  • From: Jimmy Berry <jberry@xxxxxxxx>
  • Date: Mon, 13 May 2019 15:20:46 -0500
  • Message-id: <3045476.4E9SNbbiN8@boomba.local>
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups