Re: [gentoo-dev] Becoming a Gentoo developer?
Monday 13 Apr 2015 03:27:19, Daniel Campbell wrote : On 04/12/2015 05:17 AM, Yanestra wrote: Hi, I am long time user of Gentoo and I tinker with the idea of becoming Gentoo developer. I am a software developer by profession, but I am not quite sure if I should involve with Gentoo ebuild development. To be honest, I have not the slightest imagination what becoming a Gentoo developer might mean. Things seem to be abhorringly complicated. As far as I understand, there are developers, proxy developers, then there is something like Project Sunrise which I don't understand. There are apparently several different portage source repositories, basing on different software, and furthermore, there is layman. As far as I remember, portage is stored in cvs, where there is also git, and somewhere subversion seems to linger. And there is lots of documentation that appears to be outdated or strangely unattached to questions concerning organisation and overall structure. Can someone please tell me where to start becoming a developer? Do there exist something like quality guidelines for ebuilds? Why is there such a chaos? Thanks! As someone who is undergoing their IRC interview soon, I think I can answer some of these questions: * There are developers, proxy-maintainers, and the Sunrise project. Developers have access to the main Gentoo repository of ebuilds and do their best to maintain a quality tree. Proxy-maintainers are regular Gentoo users who adopt packages and pledge to help Gentoo developers in maintaining them until either they become a developer themselves or until another developer adopts the package officially. The Sunrise project is a separate tree where developers and users collaborate in getting new or specialized packages into a semi-official repository. Developers assist users in getting ebuilds up to snuff and help them build practical skills in contributing to Gentoo in a more structured manner. * Documentation, like the rest of Gentoo, is powered by volunteers. If you find any missing, erroneous, or outdated information, please file a bug or, if you have permissions on the Wiki, edit it yourself! * The general structure of Gentoo as an organization is somewhat simple. The Council makes all the big and important decisions, while developers have their own herds for specific goals (say, the perl, lisp, java, and games herds), which also correspond to projects with the same goals. The Foundation exists to give Gentoo adequate monetary and legal support in carrying out its goals as a distribution. Everything else is pretty much just a bunch of developers working together. * Gentoo's official tree is in CVS for now, but there is a git migration planned. I don't know the timing or exact plans for the immediate future, but my guess is things will be switching to git over the long term once logistic problems are solved. SVN repositories are available over layman only, as far as I'm aware. * Layman itself is a way to activate other repositories. That method is partially deprecated in favor of /etc/repos.conf/ files, which allow for greater, clearer control over repositories. Current releases of layman will interface with the new way of managing, and there are tools in place to make migration (mostly) painless. * The way to begin your journey to become a developer lies mostly in just helping out Gentoo, studying the Devmanual [0], and contacting recruiters to see if there is a mentor available for you. If you're interested in becoming an ebuild developer, you should try out the ebuild quiz [1]. For the most part it just takes a cautious and attentive eye, some adequate knowledge of bash, and familiarity with common building and admin tools. Since you're a developer by trade, I'm sure it wouldn't be a big problem for you to reach developer status. It takes time and effort, but in my personal opinion it's been worth every moment. I hope this helps! ~Daniel [0] https://devmanual.gentoo.org [1] https://wwwold.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt Hi Yanestra Daniel summed it up pretty well: becoming a dev is a long and lengthy process but worth it in the end cause you'll get to meet smart and passionate folks along the path. However, I'd like to point out yet another URL nobody has mentioned so far: bugzilla [2] aka the Gentoo bug tracking system. There are always tons of bugs waiting to get picked up. You're a software developer by profession so I would advise you to look for bugs that lie in your field of interest. Gentoo isn't one big aggregate of developers. We're broken down into small teams of people working on a specific topic. You can check out the list of Projects here [3]. For instance do you like Perl? Help out the Perl team package Perl packages. Or maybe you're a Pythonista? Give the Python team a hand. And so on and so forth. Pick something you like
Re: [gentoo-dev] Becoming a Gentoo developer?
If, by any chance, you happen to like Java, we're looking for fresh blood. We're kinda short of manpower in the team at the moment: with over 1000 bugs assigned to java@g.o, any form of help is welcome. Further, you'll get to work on maintaining some of Chewi's ebuilds, some of which encompass Minecraft. (you might wonder: who's interested in playing Minecraft on Gentoo? I asked myself the same question till I bumped into Chewi..) Patrice Monday 13 Apr 2015 14:20:56, Patrice Clement wrote : Monday 13 Apr 2015 03:27:19, Daniel Campbell wrote : On 04/12/2015 05:17 AM, Yanestra wrote: Hi, I am long time user of Gentoo and I tinker with the idea of becoming Gentoo developer. I am a software developer by profession, but I am not quite sure if I should involve with Gentoo ebuild development. To be honest, I have not the slightest imagination what becoming a Gentoo developer might mean. Things seem to be abhorringly complicated. As far as I understand, there are developers, proxy developers, then there is something like Project Sunrise which I don't understand. There are apparently several different portage source repositories, basing on different software, and furthermore, there is layman. As far as I remember, portage is stored in cvs, where there is also git, and somewhere subversion seems to linger. And there is lots of documentation that appears to be outdated or strangely unattached to questions concerning organisation and overall structure. Can someone please tell me where to start becoming a developer? Do there exist something like quality guidelines for ebuilds? Why is there such a chaos? Thanks! As someone who is undergoing their IRC interview soon, I think I can answer some of these questions: * There are developers, proxy-maintainers, and the Sunrise project. Developers have access to the main Gentoo repository of ebuilds and do their best to maintain a quality tree. Proxy-maintainers are regular Gentoo users who adopt packages and pledge to help Gentoo developers in maintaining them until either they become a developer themselves or until another developer adopts the package officially. The Sunrise project is a separate tree where developers and users collaborate in getting new or specialized packages into a semi-official repository. Developers assist users in getting ebuilds up to snuff and help them build practical skills in contributing to Gentoo in a more structured manner. * Documentation, like the rest of Gentoo, is powered by volunteers. If you find any missing, erroneous, or outdated information, please file a bug or, if you have permissions on the Wiki, edit it yourself! * The general structure of Gentoo as an organization is somewhat simple. The Council makes all the big and important decisions, while developers have their own herds for specific goals (say, the perl, lisp, java, and games herds), which also correspond to projects with the same goals. The Foundation exists to give Gentoo adequate monetary and legal support in carrying out its goals as a distribution. Everything else is pretty much just a bunch of developers working together. * Gentoo's official tree is in CVS for now, but there is a git migration planned. I don't know the timing or exact plans for the immediate future, but my guess is things will be switching to git over the long term once logistic problems are solved. SVN repositories are available over layman only, as far as I'm aware. * Layman itself is a way to activate other repositories. That method is partially deprecated in favor of /etc/repos.conf/ files, which allow for greater, clearer control over repositories. Current releases of layman will interface with the new way of managing, and there are tools in place to make migration (mostly) painless. * The way to begin your journey to become a developer lies mostly in just helping out Gentoo, studying the Devmanual [0], and contacting recruiters to see if there is a mentor available for you. If you're interested in becoming an ebuild developer, you should try out the ebuild quiz [1]. For the most part it just takes a cautious and attentive eye, some adequate knowledge of bash, and familiarity with common building and admin tools. Since you're a developer by trade, I'm sure it wouldn't be a big problem for you to reach developer status. It takes time and effort, but in my personal opinion it's been worth every moment. I hope this helps! ~Daniel [0] https://devmanual.gentoo.org [1] https://wwwold.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt Hi Yanestra Daniel summed it up pretty well: becoming a dev is a long and lengthy process but worth it in the end cause you'll get to meet smart and passionate folks along the path. However, I'd like to point out yet another URL nobody
Re: [gentoo-dev] Importance of SLOTs on Java dependencies
Chewi suggested a similar solution in #gentoo-java. How do we get started with
contributing to repoman?
However.. everytime I tried asking questions about repoman, I've been told I
shouldn't bother improving it because this magic python script that seems to be
doing all sort of things (over 3000 lines packed in one file) (yes my dear) is
being rewritten.
Is it still underway?
Cheers
Tuesday 07 Apr 2015 20:41:05, Pacho Ramos wrote :
El dom, 05-04-2015 a las 17:16 +0100, James Le Cuirot escribió:
Hello all,
Firstly, I would like to take this opportunity to remind all devs
touching ebuilds with Java .jar dependencies about the importance of
restricting these dependencies to specific SLOTs.
There is no cross-platform or even platform-specific location for
Java .jar files so each distro tends to do its own thing. Gentoo's Java
eclasses install metadata about any .jar files in a file called
package.env either at /usr/share/${PN}-${SLOT} or just /usr/share/${PN}
when the SLOT is 0.
java-config is executed both at build time and at run time to read this
metadata so that it can build a classpath. If one of the dependencies
unexpectedly changes SLOT due to package updates then the chain breaks.
You must therefore *always* restrict the SLOT, even if that dependency
currently has a SLOT of 0.
Why do we SLOT Java stuff so much? Java applications tend to have many
third party dependencies so it is inevitable that we would sometimes
need to have more than one version of a library installed at one time.
The write once, run anywhere nature of Java also means that upstream
doesn't expect you to run against library versions other than the ones
they shipped their application with. We do have a tool to check for
compatibility between versions though to avoid SLOT proliferation
getting out of hand. Classpath conflicts involving multiple versions
have rarely been an issue up till now but we have thought of measures
to combat this in future if needs be.
I felt the need to write the above because I have seen many instances
where devs not familiar with Java packaging have made this mistake. Now
I need to ask what to do in the case of ebuilds that have already been
marked stable.
To bring up a real example, I would like to bump dev-java/jna with a
new SLOT for the new version. There are several reverse dependencies, 3
of which do not specify a SLOT, and 2 of these have already been marked
stable. Upon giving jna a new SLOT, all these packages would instantly
fail to build if jna:0 is not already installed and they would also
fail to run if jna:0 gets depcleaned. Simply leaving the stable ebuilds
as they are is therefore not an option. My preferred solution would be
create a revbump that solely amends (R)DEPEND, leaving the KEYWORDS
exactly as they are. This is controversial but what other choice is
there? I could delay the jna bump but this would push back this thread
of work by a month when I already have a huge backlog. Please do not let
bureaucracy get in the way here.
Of course I would certainly give any maintainers a heads up before
doing this. Unfortunately, in this particular case, I contacted miknix
about dev-embedded/arduino over 2 weeks ago and haven't heard anything
back. He hasn't been seen on IRC for over 5 months. :(
Wouldn't be possible to show a repoman warning when a dependency on any
dev-java/${PN} doesn't specify a SLOT? That would save of from
forgetting this in some years ;)
