Mailinglist Archive: opensuse-factory (1029 mails)

< Previous Next >
Re: [opensuse-factory] O Factory - Where art Thou?
  • From: Tomáš Chvátal <tchvatal@xxxxxxx>
  • Date: Thu, 28 Nov 2013 16:01:33 +0100
  • Message-id: <1860183.yGkGHp7zID@bugaboo>
Dne Čt 28. listopadu 2013 14:32:54, Dominique Leuenberger a.k.a. Dimstar
napsal(a):

Hello Dominique,

https://progress.opensuse.org/workflow/factory-proposal.html

We basically want to put the pressure on the submitting packager not the
user. Using factory should be safe, for this we want to revive a thing
that has been lost on the way: Bernhard's factory-tested project.

That looks interesting.. with two, for me, undefined 'dark processes'
with huge impact:

- Needs staging?
- Needs QA?

Yep they are now dark because we plan to sent the detailed per-parts as we
have something to show up to community or as we start working on it.

It for sure won't be on/off switch but rather slowly we will adapt the tools
and then enable enable it as we roll and see the features ready. :)


Are there already ideas on how to implement/formulate this decision tree?


There are some really really rough things which are not good for posting right
now, but rather allow us to think on it internaly and when we start working on
it as I said above, it will all be sent here for discussion and
optimalizations.

Basically now the decision for both of those are done by coolo or me with
mixed results. So we will formalize it and give the power to technical review
as you see the influx of new stuff in there hopefully better. And leave us to
actually improve the tooling around rather than just work with them :)

...
ok, I think THAT partially answers above question with a 'no'


Eeexactly viz above :P

*snip*


So far it's in 'trying' to detect those cases early enough, Stephan
does a great job in this, his endless experience is a great asset for
him being able to do so.

Also, we need to be able to define an exit trigger from a staging
project: when do we consider it 'ready'. This does not forcibly mean
100% 'builds' against the offending package (imho), as this could
potentially block a kernel from entering due to some low-hanging fruit
just not having support for that kernel.. critical for the users of
that module, sure, but critical enough to block a kernel update?

(just to show, this is not black/white magic.. and describing this in
a way that it's clear and not 'subject to the mood of Stephan' is
difficult, but should be a goal to strive for).

Yes I wholeheartly agree that currently it is just a magic we do there.

One of the options on the table was "lets force staging projects on
everything" but sadly that is too much on the OBS and we would just be boiling
it with all the rebuilds. In the end we go with above way which is technically
possible and we can learn and improve it on the way wrt detecting culprits.

Basically Review team will have update SR reviewing tools with possibility to
group, review, and mark for qa/staging on any submission with some possibility
to edit the severity/f**kupablity of the package so they can do the right
decision.

But even tho I am now interested for sure to talk about it, lets wait till we
work on that area. Have no fear that one of the goals of this is to at worst
keep the workload on reviewers the same, prefferably reduce it, which again
will be expanded later :)

HTH

Tom
< Previous Next >