Quoting Stephan Kulow <coolo(a)suse.de>de>:
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.
Having Factory 'more stable' during development has been a goal for a
while.. at times it looked fine, at times it's terrible.
I don't remember a time during 12.2 development
when we had less than
100 "red" packages in Factory. And we have packages that fail for almost
five months without anyone picking up a fix. Or packages that have
unsubmitted changes in their devel project for six months without anyone
caring to submit it (even ignoring newly introduced reminder mails).
This is clearly an issue! I keep on looking on the 'Status' screen as
well, and indeed sometimes this is depressing. Flagging non-building
packages as 'to be deleted' after a period of time sounds like a good
approach. A resubmit of the package would have to go through a full
re-integration process. Of course we have some silly packages which we
can't just 'drop', as they would invalidate another stack. But
generally, those are 'cought up' in the chain, if notified (from my
experience, if I see anything down the chain causing issues on GNOME:*
packages, I try to address them...)
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
At times when I was working on 'large integrations' (like gcc 4.7)
this could have helped sometimes.. I had my depressing times looking
at what is broken with GCC 4.7, knowing that the fix had been
submitted 3 weeks earlier... but those were exceptional ones; most of
the time this worked fine.
I'm not sure I would have felt confident pushing all my patches just
in. Fixing > 100 packages in short period also leaves room for errors,
where a review by two other eyes is welcome.
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.
Again based on my experience with GCC 4.7 (and partly X 1.12): staging
helps a lot! The 'biggest' issue was to find real issues introduced by
the specific package. But that was only an issue due to the > 100 red
packages in Factory. not having those red packages would have made
this much easier (coming down to: Factory should be as building as it
can.. makes staging efforts easier).
Too many staging projects will not help though in my opinion: while on
team works on updating Gcc 4.7, another team keeps on upgrading KDE
stack and another team keeps on maintaining the gnome stack... at one
point the 'clash together';
One thing I could imagine could help a bit (bringing the situation
from pull to push): Build Failures could create BNC Entries...
assigned to the bug owner of the package.
Of course, it might still be that the error is in an underlying
package (as seen today with gvfs not finding samba for example, which
was due to krb update and/or other splits), but it would potentially
raise direct awareness... Just thinking out loud of course !
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org