On 11/16/10, Maciej (Matchek) Blizinski <[email protected]> wrote: > No dia 16 de Novembro de 2010 17:00, Philip Brown <[email protected]> > escreveu: > > How does the release manager know what's the best for the user? It's > not a rhetorical question. I'm interested to know in the process.
Maciej, we've been round this particular discussion at least 3 times before :-/ Previously, you have been asking with an eye to "well, tell me the process, and then we'll automate it". To which the reply has been, is, and always will be, "you cant automate EVERYTHING. Certainly, the things that can be, we should. But there are things that cannot be". If you are NOT asking in that "Give me machine readable procedure" context, but truly out of inquiry, then I will attempt to give you a good faith answer. (It's a pain in the butt. I WISH it could be more automated :) Your extra gar-checkpkg stuff has helped, which is nice) My registration script gives me a quick overview of what files are in the package, what dependancies it has, and what shared libs it uses. (maybe one or two other things i forget). For trivial packages, I usually just "wave them through". ** For new maintainers, I try to spend a bit more time digging. For new packages, I try to spend a bit more time digging. For packages that have changed (names, etc) I try to spend a bit more time digging. If I notice some odd pathnames, I query the maintainer. If I notice some odd/obsolete/non-optimal dependancies, I query the maintainer For packages that have not been updated in a very long time, I try to spend a bit more time digging. Some types of package I tend to wave through, UNLESS they have obnoxious names or other blatant oddities. eg: perl, ruby, and python packages. If someone wanted to actually spend TIME being a (perl/ruby/python) release manager, I would welcome the extra scrutiny. I myself am not qualified to deeply examine them, so I usually just pass them through, with the exception of the libpython, and "where do the scripts live" issues, which I attempt to keep consistent for the good of all. Some things that will be viewed as inconsistent: I have limited time. I'm not paid for this. So, sometimes, things get delayed, when I think, "this one should probably be looked at more, but I dont have time right now". And sometimes, I wave them through because they've waited long enough, and I just hope to look at them more 'next time around'. Or, "the maintainer has already done 10 of this type, I'm sure this one is the same" And sometimes, I was simply not aware of a problem the first time(or 2nd or 3rd) a package goes through. But after seeing similar issues with other packages, I will then hold up something to bug a maintainer, for an issue which they previously thought was okay. Sometimes, a particular thing does not seem like an issue to me at first. but then when I notice 3 or 4 packages going through the same way, my mind may notice something and say "Hey wait a minute!" and bug that maintainer. Nothing against that maintainer personally... its just at that point that my eyes happen to notice something in the file listings scrolling by, or whatever. > I guess there's also the question of the reasons for rejecting a > package. The release manager, despite having more power, can't reject > a package because, let's say, he doesn't like the maintainer. There > has to be a valid reason. I hope you agree. Of course. I can say with all honesty that I have *never* rejected a package because I "dont like" someone. Some people may claim that I have... but its important to note that they usually make this claim, instead of doing work to alter what I'm complaining about. If they had just done the work, they would have seen the package go through. Bad feeling may build up, when a maintainer goes through multiple times of rebuilding a package, but it's nothing about the maintainer personally. Its just that when I reach a problem, I say "fix this please", without looking further. Once they fix the problem, then I continue looking through it. What is unfortunate for positive feeling, is that I do usually look harder at a package that has had a problem already. NOT because I "dislike the maintainer", but because it is very often the case, that when a package has one problem, it usually has more. So when I hit a problem with a package, I do look even harder once I get a repackage of it. Not because I dislike the maintainer, but because I want our packages to be as clean for our users as possible. So where there are likely more problems, I look for more problems. I havent kept records, but it does seem like packages more often have 2+ problems, than just 1. and if you're wondering how I judge "problem", I go by our "core value": 'to provide a straightforward, easy-to-use experience for the user' The tricky bit is in balancing the needs from all of our different types of user: home, corporate, smallscale, and large scale. It requires a lot of human judgement. For which, I use my 7 years experience as a release manager, and 20 years experience as a sysadmin. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
