On Thu, Jun 14, 2012 at 2:26 PM, Sascha Peilicke
On 06/14/2012 01:42 PM, Robert Schweikert wrote:
On 06/14/2012 04:46 AM, Stephan Kulow 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.
Well, reality and you message beat me to the punch. I do have a presentation on my box I was planing to give at oSC (assuming I can get the necessary travel approved). But I digress....
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 think there are issues with the model, but I think that they cannot be fixed if we do not address what I consider underlying issues. I believe that an underlying issue to the overall state is the package maintenance model. Look at any perl or python package in the devel projects and you'll find tons of people listed as "maintainers" but almost non of them is a "true" maintainer. Everyone of the listed "maintainers" is inherited from some parent project and in the end no one really feels responsible.
That this is an issue is also evident in the increased mail traffic on the list about lingering SRs.
I believe we need to clean up our package maintainer model. We should have 2 or 3 people at the most that are responsible for a package. These people will get messages about build failures for their packages, and these cannot be disabled. Further, just because you are a maintainer of a package that does not imply you become a maintainer of the parent project. Any devel project should probably not have more then 10 maintainers. If we have packages that do not have "true" "committed" maintainers they cannot go into Factory. This implies that in any given devel project the maintainers of the devel project can decide to have "unmaintained" packages that are nice to have in OBS, and that "drift along". However, these would never show up in factory.
Basically I am proposing that we get stricter about maintainership of packages. This may be sufficient to avoid the trouble we're in now in the future. If it is not at least we will have a base to build a new development model on for factory. With the current package maintainer model and the way it is presented any new model we come up with will, IMHO, be built on quick sand.
In summary, I think without fixing what we build on, i.e. the package maintainer model a discussion about the Factory development model is somewhat of a moot point.
Coincidentally, I just wrote about the same thing :-). I can only agree that IMO less maintainers will lead to increased responsibility and shorter response times when it comes to package submissions between projects. Yet, I'm unsure if this will also help raising awareness of issues within Factory. Nonetheless, it's worth discussing.
I am not sure I agree with your logic. If all of the current maintainers won't handle submissions, what makes you think a subset of them will? If getting submissions accepted is one of the major bottlenecks, I don't think further tightening that bottleneck will be beneficial, quite the opposite. I think people should only sign up to be maintainers if they feel some responsibility to the packages. But I am not sure there is a simple way to enforce this. Yes, you can limit the number of maintainers. What happens when you reach the limit on a package while none of the maintainers are dedicated, and someone who is dedicated tries to step up. Do you turn them down? Make them jump through hoops to get a special exception? I don't really see how limiting the number will help things, rather I think it will serve to turn off people who could be able to fix these. You could have a policy where maintainers who aren't contributing enough are removed, but then there is no reason to have a limit on number as long as they all do what they need. Currently as far as I am aware you are either a maintainer or you have to go through a maintainer, which leaves people who want to help a lot but not enough to really be maintainers either improperly as maintainers or swamping the maintainers with tons of requests. Perhaps a solution might be for there to be a second class of users for packages and projects, maybe "Contributors", who have access rights to improve the package or project because they make substantial contribution but are not considered dedicated enough to be "maintainers". This would help clarify the role of users in the package and project. -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org