Mailinglist Archive: opensuse-factory (1029 mails)

< Previous Next >
Re: [opensuse-factory] O Factory - Where art Thou?
Stephan Kulow <coolo@xxxxxxx> writes:

Integrating these to make a good distribution is real work. And one of
my favourite songs (in that context) goes:

No one said it would be easy
But no one said it'd be this hard
No one said it would be easy
No one thought we'd come this far

:D

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

Cool diagram, extremely helpful to convey the idea!

We basically want to put the pressure on the submitting packager not the
user.

yay :) !

There are several problems with the current "everything through devel
project" approach we need to solve. Our ideas are just ideas, but I
had several discussions in various places and nobody offered a better
idea. So we really would like to start with it and I would like to
hear your concerns so they can be part of the final solution.

This will be a major improvement to what we did so far :) !


There is one thing that I'm missing, but that probably would need other
changes on obs than using it differently and adding submit request
groups.


The build server is what it says: a *build* server.

We use it as an integration server, quite successfully, and it comes
close, but it is not explicitely targeted at integration.


So it is missing a few features to better support integration:

* Tools like git support 'merge' tracking of changes in branches back
to mainline and from progress in mainline back to the branch. This
then also allows to bisect regressions to the integration issue.


* Integration means testing, and testing may be a gate/decision point
whether further builds make sense at all (think rings). This
tracking of test status is not in the tool. And tests should gate
further work based on test status. And tests, automatic or manual,
have a smart and a stupid order doing them.


* There is one thing in which the current proposal will reduce the
problem for openSUSE:Factory.

Integration means integration into some baseline, to create a new,
improved baseline, that should be stable at all times. You want to
catch problems early.

And for that you contain changes until you are confident they are
good for wider release. That's what the current proposal does
address.


What it will not solve is that you need the very same containment
when you target several baselines with the same update, the other
thing obs is used for, besides Factory and openSUSE.

There, too you want to contain changes until they are 'good enough'
to be available for the 'next ring' of things, until you approve
them for the whole target baseline.

Our current projects simply scope package builds based on what is in
the project, not on what is affected in the baseline, let alone what
is already tested.

You need to 'know' and 'pull in' 'the right packages' to fully cover
all dependent packages. And when you use 'links', your project may
break because the baseline changes then 'push' into your project.

So your project, unless it is accepted as Factory project, will
continue to break at random times.


What I like with the current proposal is that it is setting a great
course for openSUSE Factory, and we need to move towards a more stable
factory, a smoother flow.

However how will this help dependent multi-target projects (like gnome,
or kde or databases or d:lang:*) to likewise be stable at all^wmost
times?

It looks to me like the flow that is proposed here continues to break
projects that build for both factory and other released distributions.


S.

--
Susanne Oberhauser SUSE LINUX Products GmbH
+49-911-74053-574 Maxfeldstraße 5
Processes and Infrastructure 90409 Nürnberg
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
References