Hi, all, I don't know much on the infrastructure thing like being talked in the original topic. I did notice some projects of our current development model didn't response well. According to coolo, some factory packages didn't got fixed in two weeks or more, even if we have email notification and a factory repository enabled in all devel projects. It means if you login b.o.o every day, you must be able to notice that your package fails. But some projects of our current development model responses very well. (like auto-build team) Those two apparently different situations both happened under the same development model. So personally I think it's not because we have faults or bias on the design part of current development model. So why everyone of us are so _hurry_ to design a new model for one of our major release? It requires many collaborations. For instance, if we want to raise the priority of Tumbleweed, we have to adjust a lot of things like OBS, tumbleweed team and almost every other teams' focuses. I think it's foreseeable that we won't finish it in a short time. Especially we are under such a tough situation that many repository maintainers are not available right now. (everyone knows they are absent, but no one knows where they are absent for/to.) They can't be awaken under a very short time like two or three months. So I think the temporary solution to 12.2 is that we existing active maintainers have to contribute more. Instead of blaming and marking invalid or "won't fix", we have to fix every bug we met and are able to fix. Actually personally I think it's not because current development model are not "good", but we lack of a supervisor system to push it to be good. We didn't educate our maintainers so well to let them know their responsibilities. (eg: they have to test the package in his maintaining repository for stability, to make them build for factory, to answer bug reports, instead of just accept and forward. Because they have super permissions than ordinary packagers, they have to take the related responsibilities) Every existed and to-be-designed development model is based on one simple hypothesis, that is, every( or most of, majority of) maintainer is active, especially repository maintainers. But it's not the case right now. we have almost 30000 packagers on b.o.o, but anyone ever calculate the active ratio? It must be very regretful. Imagine now we have 30000 email senders to this mailing list, it must be a huge traffic. but it's not the case right now. I guess we have an active ratio even lower than packman. (they have only 100+ maintainers, but their mailing list is as busy as ours) So now the case is: we are not lacking of maintainers and bug fixers, but lacking of active ones. you know, we're a big FOSS empire as big as Debian! So personally I think what we need to do is find a way to wake up our sleeping maintainers and packagers, instead of designing a new development model or something ASAP. (personally I think coolo mistakes one thing: it's not because we have too many maintainers so the current development model can't fulfill the needs, but we lack of enough active maintainers to make our engine running! the OBS traffic and infrastructure pressure mostly comes from those who builds but not builds for factory.) If there's anyone doesn't believe it, let's make a test(or ping, which is famous in accent Chinese kingdom, to hand out a report to every majors in his empire, and ask them to reply.), create a new account, to require "add role" permission from every devel project, then coolo will know which ones are active and which ones are silent. To solve this problem, personally I have a few ideas: 1. We have to kindly warn those silent repository and package maintainers two or three times, then do a clean. 2. Then we have promote some active packagers who are not maintainers yet. 3. Do it regularly. 4. we have to enable build failure notifications of devel repository/factory on hermes.o.o by default, and it can't be shutdown by yourself. you can mark it spam, but you can't shut it down. (I am the maintainer of M17N, and we have 3 sub projects and 320 packages. many of the package maintainers are promoted in 2007 or even earlier, I might be wrong about it, since I am fresh and don't know when we have OBS. but they didn't submit any single SR since then. many of them are even SuSE staff. they may even work for Windows now, girl! what if they didn't maintain their packages? oh others don't even know what his package is for.) 5. We need a check-in system. Not every package needs to be modified regularly. But we have to have the information that how many maintainers we still have. 6. We need a karma system. At first I want to be clear, everyone is born equal, but hard workers need to be encouraged. And a ranking system is not against our guiding principle, because we already have ranking systems like members and the board. But we're lacking of a quantified one. Nowadays if once you're an repository maintainer, you're still repository maintainer when you're died. We kept adding new ones, but then maintainers can shirk, "oh he will update that package". If everyone thinks so, then no one will update that package or fix that bug. Of course those karma doesn't mean anything, because no one here is payed to work except SuSE people. (But they do the works far beyond their salaries.) = For packagers: = Those karma can "exchange" build power on OBS. Today our OBS can build most of the packages in a short time (if OBS is not broken). But what if you're working on an important package? buy it. Those karma can "exchange" openSUSE member position. Today we're using manual selection, which requires a lot of work so reacts slow. And some losers might be question it. A quantified high karma which can't be earned in one or two years solves that problem. Those karma can "exchange" openSUSE gifts, like our lizard doll. Actually I was so active because last Xmas SuSE China sent me a lizard doll and a novell cup, I want a larger one this year. Gifts will be very valuable to newbies. If you have 30000 karma, why not deliver you a real lizard? XD. = For repositories: = The devel repositories' karma equals to the sum of their maintainers plus an adjustable amount from coolo, according to their recent busy hours and importance to our factory. Then no one will carelessly add those who will be certainly silent after a while.( because one's karma can be negative!) = How to earn karma? = By creating packages which are not in factory yet, by adopting existing unmaintained packages(no package will be dropped sadly), by developing features on f.o.o, by fix bugs on b.n.c, by answering question on mailing lists...... ( a high karma person's answer might be more useful. after we have a karma system, I personally no longer need to get the first impression by name or email address, it's pure guess who to trust nowadays, you know, to a fresh woman and a so called foreigner like me, every foreign nickname looks the same to me) Things like that, and by check-in every day (a check-in means 1 point. And since you're on b.o.o every day, why not fix some minor bugs?). If you're not active, those karma will fade. drop 1 point per day. or you didn't claim to fix your bug, it will drop some amount. If you got a negative karma, you have to work a lot to make it positive. after you got a certain negative number of karma like -30, sorry, you build power is limited. like lauchpad, you have to wait certain hours to queue your builds. Some of the karma are forever. like contributing to 12.2 will +3 golden points. it will not fade and is commemorate. But such karma can't let you be in a repository maintainer status forever, because repository maintainership will require 30 points. This karma system is ported from plurk, launchpad, foursquare and many existing social networks. It's been tested for a long time and useful to maintain active ratio. And it can be port to almost everywhere like our connect.o.o, our planet, our forums and more, even to board election( without 100 points? sorry, you can't be a candidate; love coolo? give him 3000 points and buy him a chairman!). Those are just thoughts and personal ideas I think we should have. If interested, we can improve them; if not, it will not weaken the faith I hold on openSUSE. Greetings, Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org