Quoting Stephan Kulow
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.
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 to.
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 ! Best regards, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org