Mailinglist Archive: opensuse-factory (1134 mails)

< Previous Next >
Re: [opensuse-factory] Calling for a new openSUSE development model
On Thu, 14 Jun 2012 10:46:32 +0200
Stephan Kulow <coolo@xxxxxxx> wrote:

Hi,

It's time we realize delaying milestones is not a solution. Instead,
let's use the delay of 12.2 as a reason to challenge our current
development model and look at new ways. Rather than continue to delay
milestones, let's re-think how we work.

<snip introduction >

So I would like to throw in some ideas to discuss (and you are welcome
to throw in yours as well - but please try to limit yourself to things
you have knowledge about - pretty please):

1. We need to have more people that do the integration work - this
partly means fixing build failures and partly debugging and fixing
bugs that have unknown origin.
Those will get maintainer power of all of factory devel projects, so
they can actually work on packages that current maintainers are
unable to.

That sounds good for me. If we have such people don't stop them by
permissions and bureaucracy. On the other hand it would be nice if we
use them only if needed.
So I think we can set some deadlines and have easy way how to find such
information.

So e.g.
- open pull request ( should be processed in 3 days )
- crash in factory ( 3 days )
...

And when such deadline exceed then such "power" users can start acting.

It helps with people vacations, other work time consumation etc.
From my side I must say that sometime there is almost no time to care
packages in opensuse and sometime there is enough time. Usually my
packages are packages where I am upstream or it is dependecies I
require, so I am sure that nothing important is missed ( like new
versions or bugfixes), but I don't have sometime time to handle all
various breakage ( like ruby 1.9 update or gcc fix ) or submit
requests.
Also it show what activity we expect from regular contributor that
maintain package ( I see difference between contributor that send
single pull request and that want to care about package ).


2. We should work way more in pure staging projects and less in
develop projects. Having apache in Apache and apache modules in
Apache:Modules and ruby and rubygems in different projects may have
appeared like a clever plan when set up, but it's a nightmare when
it comes to factory development - an apache or ruby update are a pure
game of luck. The same of course applies to all libraries - they
never can have all their dependencies in one project.
But this needs some kind of tooling support - but I'm willing to
invest there, so we can more easily pick "green stacks".
My goal (a pretty radical change to now) is a no-tolerance
strategy about packages breaking other packages.

I also agree here. Have one staging is fine for me, as I can see
directly if something is broken if I update critical part ). What could
be nice is feature that show for pull request if all dependent packages
( we already have such information ) also build after such change.

Strategy revert breaking package is also fine for me if we have some way
how to submit set of changes ( like new non-compatible API send
together with new version of programs that use it ).


3. As working more strictly will require more time, I would like to
either ditch release schedules all together or release only once a
year and then rebase Tumbleweed - as already discussed in the RC1
thread.


I think this doesn't solve a problem. Tumbleweed mainly benefits from
not doing critical updates, but it also need it time to time and
for Tumbleweed it is opensuse new version.
What I see possible is to set set of critical tools, that can be
upgraded (upgrade mean critical change like new incompatible
version like ruby 1.9, gcc 4.7 etc. ) during milestone 1, then have
another less critical set that can be upgraded in milestone 2 and
continue and allow only leaf package upgrades in last release before RC.
I think that such change can prevent big breakage and lead from big
challenges to smaller one like new firefox or new vim, that break only
small subset of system.

So I think that challenges can be solved and of course everything have
some disadvantage, but I agree with coolo, that current state is not
good to release good product in time.


Josef

Let's discuss things very openly - I think we learned enough about
where the current model works and where it doesn't so we can develop
a new one together.

Greetings, Stephan


--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
This Thread
References