Does trying to become a packager. Involve being currently a Developer, as in Programming skills\certification, whether Perl\Python\c++ etc.
Frank
On 06/04/2009 01:13 PM, Frank Murphy (Frankly3d) wrote:
Does trying to become a packager. Involve being currently a Developer, as in Programming skills\certification, whether Perl\Python\c++ etc.
Not necessarily. It's useful to understand the codebase but if you have a active upstream responsive to bug reports, you can just take care of the packaging aspects of it. You can always ask for help from others within Fedora or upstream if needed.
Rahul
Rahul Sundaram wrote:
On 06/04/2009 01:13 PM, Frank Murphy (Frankly3d) wrote:
Does trying to become a packager. Involve being currently a Developer, as in Programming skills\certification, whether Perl\Python\c++ etc.
Not necessarily. It's useful to understand the codebase but if you have a active upstream responsive to bug reports, you can just take care of the packaging aspects of it. You can always ask for help from others within Fedora or upstream if needed.
Rahul
I would content you need an ability to understand scripting languages (as spec files are really a DSL/scripting language) and an understanding of skills commonly associated with a developer:
- Source Code Control - Source Layout - Software Component Types (e.g. scripts, libraries, documents, etc).
however, as Rahul said, the ability to crank out the latest oCaml/Erlang/Java/C/Assembler/NameYourPoison is not required.
-- bk
On 06/04/2009 04:56 AM, Bryan Kearney wrote:
Rahul Sundaram wrote:
On 06/04/2009 01:13 PM, Frank Murphy (Frankly3d) wrote:
Does trying to become a packager. Involve being currently a Developer, as in Programming skills\certification, whether Perl\Python\c++ etc.
Not necessarily. It's useful to understand the codebase but if you have a active upstream responsive to bug reports, you can just take care of the packaging aspects of it. You can always ask for help from others within Fedora or upstream if needed.
Rahul
I would content you need an ability to understand scripting languages (as spec files are really a DSL/scripting language) and an understanding of skills commonly associated with a developer:
- Source Code Control
- Source Layout
- Software Component Types (e.g. scripts, libraries, documents, etc).
however, as Rahul said, the ability to crank out the latest oCaml/Erlang/Java/C/Assembler/NameYourPoison is not required.
Going even further, understanding diff and patch and tools used to build software (make/autotools/CMake/ant/maven/distutils/etc) work is probably of more importance to a packager than being able to program in C/Python/Java/etc. Knowing the basics of programming will help you tremendously but there's other people upstream and within Fedora that can do that work for you if it becomes necessary. Knowing the basics of the build tools your package uses are needed for even the most trivial deviations from what upstream provides (and in some cases, you may understand this aspect of programming better than upstream).
-Toshio
Frank Murphy (Frankly3d) wrote:
Does trying to become a packager. Involve being currently a Developer, as in Programming skills\certification, whether Perl\Python\c++ etc.
And to answer that part, you don't need any sort of certification to become a Fedora packager, you just need to write one or more specfile(s) which follow(s) our guidelines.
Kevin Kofler
On Wed, Jun 3, 2009 at 11:43 PM, Frank Murphy (Frankly3d) frankly3d@gmail.com wrote:
Does trying to become a packager. Involve being currently a Developer, as in Programming skills\certification, whether Perl\Python\c++ etc.
I would put it this way.... there should be an expectation that packagers are willing to learn programming skills relevant to the packages they are maintaining. There's no proficiency level or anything like that. But if you aren't interested in learning how to read and use python..you should probably not maintain a package that is heavily dependent on python. Those are the sort of personal choices that can turn the time you gift as a volunteer contribution to Fedora into a burden instead of having fun doing the work.
I personally do not maintain package for things that are written in languages I'm not interested in learning how to use. I avoid perl. I avoid java. I generally have no personal interest in developing or refining my ability to read or use either(but it seems like I won't be able to avoid the java trap for long as part of my day job). And as a result I don't try to maintain packages for either.
I wish I knew how to organize some optional program language specific skills development sessions aimed at packagers that made sense..but I don't. Nothing like a cert or anything like that, but to introduce packagers and potential packagers to languages just as a good skills building exercise.
-jef
I wish I knew how to organize some optional program language specific skills development sessions aimed at packagers that made sense..but I don't. Nothing like a cert or anything like that, but to introduce packagers and potential packagers to languages just as a good skills building exercise.
More than learning development skills for the language you package, it would be great to introduce stuff like how software is build / installed.
I'd love to learn how autotools, setuptools, and other equivalents for other languages work. Not necessarily because I want to build a project using those, but because I sometimes have a hard time figuring out how to patch a Makefile in one of my packages, why I should patch a .in or .am file,...
Actually, those would be great ideas for Fedora Classrooms I guess.
----------
Mathieu Bridon (bochecha)
On 06/04/2009 10:18 PM, Mathieu Bridon (bochecha) wrote:
I'd love to learn how autotools, setuptools, and other equivalents for other languages work. Not necessarily because I want to build a project using those, but because I sometimes have a hard time figuring out how to patch a Makefile in one of my packages, why I should patch a .in or .am file,...
Actually, those would be great ideas for Fedora Classrooms I guess.
Yes, that would be great. People who are experts in such things (I know we have a good number of those) should step up and participate in the Fedora Classroom sessions or help document it in a way relevant to package maintainers.
Rahul
Jeff Spaleta wrote:
I would put it this way.... there should be an expectation that packagers are willing to learn programming skills relevant to the packages they are maintaining. There's no proficiency level or anything like that. But if you aren't interested in learning how to read and use python..you should probably not maintain a package that is heavily dependent on python. Those are the sort of personal choices that can turn the time you gift as a volunteer contribution to Fedora into a burden instead of having fun doing the work.
I personally do not maintain package for things that are written in languages I'm not interested in learning how to use. I avoid perl. I avoid java. I generally have no personal interest in developing or refining my ability to read or use either(but it seems like I won't be able to avoid the java trap for long as part of my day job). And as a result I don't try to maintain packages for either.
Well, it really depends on the package. Some packages need a lot of attention, they constantly need fixing and upstream is non-responsive or just introduces more bugs all the time. Maintaining such a package requires knowing the language it's written in very well. On the other hand, I'm maintaining ocaml-facile just fine with basically nonexistent OCaml skills (because it's used by Kalzium to balance chemical reaction equations). I guess I could figure out enough OCaml to fix issues if I had to (and I'm sure the OCaml SIG can help me if I really can't figure out what's going on), but so far I didn't have to change anything in the OCaml code. The makefile needed fixing (but Debian already had a patch for that, so I didn't have to write even that), but otherwise it just works. No open bugs. Nor even closed ones except the ppc64 ExcludeArch tracking bug which I opened because OCaml wasn't available on ppc64 (it now is). There also haven't been any updates from upstream for ages, probably because there's nothing to fix. So maintenance workload and required skills can vary a lot from package to package.
Kevin Kofler
-
Bryan Kearney -
Frank Murphy -
Jef Spaleta -
Kevin Kofler -
Mathieu Bridon -
Rahul Sundaram -
Toshio Kuratomi