On 11/22/2011 08:51 AM, Aleksandar Kurtakov wrote: > Can I be added to the list of maintainers that need help very badly from the > beginning?
If such an list existed I dont see why that should be a problem. > I maintain a number of packages that are very low in the Java stack and would > force the whole Java stack to be removed if they are removed but noone wants > to maintain them. > That's how I gained them! If such a policy is adopted it would be very bad > decision if there isn't a mechanism prior to that for maintainers to list > packages that they maintain to keep the distro integrity but don't care about > them personally. I bet that there would be a very big list of maintainers > that would list a number of there packages in this list. Not sure what you mean about distro integrity since arguably shipping few but well maintained components is better then shipping many poorly maintained or not maintained at all. But basically you winded up being stuck with them since you wanted to ship component A but to do so you required B), C) and D) but nobody is/wants maintain B),C) and D). Nothing can actually be done here since that's the price one has to pay wanting to ship component A). > To give a better estimate - I'm owner of 69 packages(139 comaintainer) of > these I would like to maintain only 11 (eclipse*) packages but the rest is > crucial to something. The problem should be obvious now - I would like to > list this 58 packages as something I need help with. And to explain things > better - yes I do fix bugs when they arrive in this packages- but just a real > bugs (broken functionality, crashers, etc.) and let aside bugs asking for new > version update, new functionality, pony:) until I need them. It's volunteer > based effort and NOONE has the right to put more burden on packagers or you > will lose them. Nobody is putting burden on anyone other then the maintainers themselves. Either they do it directly to themselves ( by maintaining more things they can handle which eventually may lead to burnout ) or it's being done by other sloppy/non responsive/absent maintainers indirectly through the component they are supposed to maintain ( which they aren't doing which results in other maintainers have to do all the leg work themselves encase their components depends on the one that he maintains ) or through various policy's/processes we in place trying to deal with those. Which is what I would say is just another symptom of the underlying problem that needs to be dealt with as in active maintainers themselves are paying hefty price for those inactive once. Through bureaucracy and what you are experiencing above amongst other things. > And everyone stop telling the story about disappointed bug reporters, why > noone is saying about disappointed maintainers? My experience is quite the > opposite at least 7 out of 10 bug reports are from people that don't want to > help. I'm speaking for bug reports that stay needing info from reporters for > weeks and months before I close them as INSUFFICIENT_DATA. If a decision to > orphan packages is made a similar decision should be made to ban bugzilla > accounts that don't respond to information requests from maintainers. If a > packager is losing time for reporters if he doesn't respond, there are for > sure reporters that lose time of the packagers. In my case they lose me so > much time that I would have probably fixed some of the bugs that I haven't > responded to!!! > Does the previous paragraph sounds right? HELL NO!! There should be an effort > to make more people help as much as they can (even if it's one day per year), > not an effort to put more burden on people that are already doing work. We actually have process in place to deal with that name Triagers however a while back I and James I believe and perhaps few others in QA went ahead with How_To_<component>Debug pages to try to deal with that problem in an attempt to educate and have proper documentation for reporters and Triager to follow. Aiming for a workflow like this... Report comes in ( preferably containing proper information to begin with ) --> Gets triaged ( if == insufficent data point reporter to how to debug page for a given component and wait until he provides proper data ) --> Flag Triaged and hand it to maintainer for further processing. At that time we had what roughly 6000 - 7000 components in the distribution and I quickly realize that we could not write all those how to debug pages without maintainers participation in the process ( which went lala depending on who you were dealing with ) at least we needed to prevent further components being introduced into the distribution without having that information available so we eventually gradually would manage to work on those 6000 - 7000 components and slowly bringing that number down. ( We even had played with the idea if we could integrate this to Bugzilla somehow as on components page would be a link to the how to debug page ) But no the proposal made to FESCO/FPC winded up in *Recommendation* instead *Requirement* which automatically made that process and effort to be in vain since I knew that maintainers would not provide that information if they did not have to and guess what I turned out to be right. Same thing goes for "how to test" since maintainers would have to provide us with the information what was the best way to test their component ( for the most part anyway ). Without that information process like proven testers is just a waist of time and unnecessary bureaucracy. ( just one of the issues why something like proven testers does not and will not work ). As ( with my QA hat on ) we have done what we can to try to improve the situation from reporters stand point ( ofcourse we can always try to do better and I'm pretty sure armed with the knowledge/experience above played a significant part in why Red Hat started investing more in ABRT and AutoQA ) however it always boils down to the same thing to improve overall quality of the distribution we need to deal with that on maintainers level and preferably without "punishing" those active and responsive maintainers which are doing what they can when they. Increase/tighten the requirement for maintainers to join the distribution. Drop the ownership model and assign all components to their relevant sig like all java components get assigned to the java sig etc. then each sig could try to come up with a way to distribute that load evenly amongst it's members Seriously let's try to come up with something and try that which is better then doing nothing and allow things to continue as they are. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
