Wolfgang Rosenauer schrieb:
Am 21.03.2016 um 13:43 schrieb Yamaban:
Otherwise, I'd like to call out to all interrested parties, for proposals of: 1. of upgrades in package versions for 42.2 2. added packages to 42.2 (new, replacement for, ...) 3. removal of packages from 42.2, (EOL, replaced by, ...)
Now since I finally had the time to look at packages which are interesting to me and my usecase.
Can we as a maintainer group agree, that we do not want to discuss every single update request on the list which the above seems to imply?
We have OBS and AFAIK it handles the case correctly when a package update is submitted from a non-maintainer that it'll automatically insert a review request to the actual maintainer. If that is the case I propose at least to handle "simple" upgrade and insertion requests like this.
What is "simple" in the end is not always easy to decide and if in doubt this should be discussed between the requester and the maintainer or if it even has a bigger impact and no agreement we should bring it to this list probably.
Can we agree on this simplification or is this already written in some process I missed?
Thanks for bringing the topic up! It's not OBS itself which decides whether to ask the maintainer but a quickly hacked bot that combines the maintenance bot and the factory source checker used by backports: https://github.com/openSUSE/osc-plugin-factory/blob/master/leaper.py The bot adds the Factory package maintainer as reviewer if the package exists in Factory. It also checks whether the origin of the package according to the lookup file changes (in a far too simple way). The bot adds me as fallback reviewer way too often. So I'd appreciate a good policy and maybe a leap review team the bot can use as fallback. I don't want to be the fallback reviewer. Wrt documentation so far we have https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap but that's about it.
Another thing I'm wondering about is how to easily monitor updates to 42.2 which are either "forks" or pulled in from Factory (compared to updates automatically pulled in from SLES12 and 42.1 updates).
Because I think it makes a lot of sense to have as many eyes as possible on those updates to assess if the upgrade path from 42.1 to 42.2 stays feasible as we try to position Leap 42 as some kind of LTS (similar to SLES service packs).
The aforementioned bot at least knows where a package comes from. So it could do whatever one implements with that information :-) And there's also https://github.com/openSUSE/osc-plugin-factory/blob/master/manager_42.py which keeps the lookup file up to date. It could of course also be extended to create some sort of notification or summary. Right now it's stateless though so sending it's raw output would become annoying quite quickly.
Currently I see https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/00Meta/looku... as a snapshot which is not too easy to work with.
So question to Ludwig who does a great job with the "New Tumbleweed snapshot XXX released": Would it be possible and feasible to have something similar for the ongoing 42.2 work?
That script works on the DVD. At that point it doesn't have the origin information. It could of course send diffs between Leap builds, I'm not sure that's so useful right now though. Especially since Leap doesn't use the "totest" throttling mechanism of Tumbleweed. So ISOs are published when OBS releases them rather then when openQA considers them good. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org