On Tue, 31 Jul 2007 07:21:55 +0530 Kumar Appaiah <akumar@ee.iitm.ac.in> wrote: > I wish to know how you can evaluate skill level. For example, if ative > contribution to a FOSS project is a required skill, I really won't fit > in. You mean upstream? No, it isn't a required skill for all maintainers but it DOES affect how the sponsor assesses the capabilities of the maintainer, especially with regard to packages that have a dead upstream. All the Debian bugs for the package become the responsibility of the maintainer - you - so if there is no upstream team, bugs that would have just been forwarded now have to be fixed within Debian, by the maintainer. > But if it is just knowledge of issues with the package and > packaging techniques, that's all right. Of course, I realize that it's > my responsibilities to get bugs fixed as well. That's the point - if you do not have the skills to fix upstream bugs, you are dependent on upstream remaining viable and active. This may seem fine now but it is not at all uncommon for a small but "active" upstream team to become completely inactive quite suddenly due to various "real-life" issues. This typically starts with a build up of unfixed bugs and often escalates to one or more Release-Critical bugs in Debian. You, as maintainer, *must* be able to fix these problems or the package will be removed from Debian. Sponsors who upload packages that result in more than a fair share of RC bugs are not looked upon favourably by the release team or other parts of Debian. (This is why I do not sponsor PHP packages, despite using PHP extensively myself.) ;-) > So, how do you propose to evaluate people? Though evaluation is > necessary, isn't it tough for people who don't really have a "FOSS > contributor" background? The evaluation is simply asking (or determining from answers to other questions) whether the maintainer is able to fix bugs in the upstream code. The rest follows on from that. Maintaining packages in Debian *is tough* for people who have no upstream experience or knowledge simply because they are dependent on others to fix certain bugs. It is easier for Debian *and* for upstream if the Debian maintainer has detailed knowledge of the upstream code because bug reports can include working patches. One example is architecture-specific bugs - upstream have no real way of fixing bugs that only appear on some of the supported Debian architectures because they don't have access to the hardware. If the Debian maintainer has insufficient knowledge of the upstream code to fix problems specific to Debian, these kind of bugs tend to escalate in severity until either someone else has to do an NMU or the package is removed from testing. This is why I also do not sponsor python, ruby, mono/C# or KDE packages. (I'm OK with C++ for non-GUI apps but I don't develop in KDE - don't even have it installed on any of my machines - and I have no idea where to start with the KDE/Qt class libraries.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpTcbhRdFSmC.pgp
Description: PGP signature