On Thu, Jun 14, 2012 at 1:46 AM, 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.
openSUSE has grown. We have many interdependent packages in Factory. The problems are usually not in the packages touched, so the package updates work. What's often missing though is the work to fix the other packages that rely on the updated package. We need to do a better job making sure bugs caused by updates of "random packages" generate a working system. Very fortunately we have an increasing number of contributors that update versions or fix bugs in packages, but lately, the end result has been getting worse, not better. And IMO it's because we can’t keep up in the current model.
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).
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. 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. 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.
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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Project management, software or otherwise, is a well-established discipline. Yes, sometimes stuff happens and dates slip. But you work within the constraints of the time, money, people and hardware you have. My specific recommendations for 12.2 are: 1. Fix all the show-stopper bugs. If that means dropping back to an older KDE because the one on the beta is sending people to the KDE bug tracker, then do that. If we have to delete packages to get the GNOME and KDE LiveCDs to fit on 700 MB media, delete the least popular packages until you have the sizes down. If GRUB2 can't be made to work, drop back to GRUB1. 2. Slip the date just enough to deliver a release free of critical distro-killing bugs. If that means axing features, axe them. Going forward, I proposed a three-layer strategy. 1. Switch to a Debian-like model for servers. Have a stable server core (kernel, bootloader, installer, LAMP stack, PostgreSQL, Perl/CPAN, Ruby/Rails/Sinatra, Python/Django and WebYast). This should look like Debian stable except a *lot* smaller. It might even fit on a 220 MB LiveCD and certainly should fit on a CD. Release this only when it's solid and stable and supply security and bug fixes via updates. This should be something that can compete with CentOS, Debian stable and Ubuntu Long-Term-Support in level of available support, documentation, security, performance and stability. Bonus points for a Platform-as-a-Service like Cloud Foundry's MicroCloud or Red Hat's OpenShift Origin. But don't have a fixed "release schedule" - release when all software quality gates have been met. I can go over to SUSE Studio and build the media - minus the PaaS - in half an hour. I'm guessing nearly all of the QA and release engineering can be automated using existing infrastructure if we reduce the scope to the most commonly used and mature server stacks and change the commitment / social contract to Debian stable's "we will ship no distro before its time." ;-) 2. Move everything else: compilers, desktops, applications, advanced server technologies like Node.js and NoSQL databases and virtualization infrastructure - to a rolling release similar to Tumbleweed or Gentoo. And I think the kernel needs to be *out* of Tumbleweed. If you're doing kernel testing / development, you're not a user any more. ;-) I've pissed away *way* too many hours recompiling VMware Workstation, VirtualBox and NVidia driver modules. 3. Acquire our own community instance of SUSE Studio and make it the main distribution channel. It's extremely well-constructed and integrated with OBS, it seems to be stable, and the current instance seems little-used. You can make *anything* there - except a PaaS. ;-) -- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org