Wolfgang Rosenauer schrieb:
Am 21.03.2016 um 13:43 schrieb Yamaban:
Otherwise, I'd like to call out to all
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
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
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
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
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
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.
(o_ Ludwig Nussel
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org