[gentoo-dev] College Course in Gentoo Development

[gentoo-dev] College Course in Gentoo Development

[Anthony G. Basile]

Hi everyone,

Give the talk on the list about attracting devs, I've should probably 
mention that I'm teaching a College Course on Gentoo Development next 
semester.  I know two students will most likely go through the 
recruitment process, others may at least contribute.  So its like GSoC 
but the focus is not one project but an overview of general gentoo 
development, and I will have to touch on lots of stuff outside of gentoo 
per se, like how autotools and other build systems work.

So what should I teach?  Here's what I've got off the top of my head:

1. Open source communities and Gentoo's internal political structure.

2. Building a gentoo system, ie the handbook.  Gentoo as metadistribution.

3. Delivering the goods: code -> build system -> portage -> compiled 
goodies -> working system

4. How to work with gnu autotools.  Writing a build system.

5.  How to write ebuilds, ie the dev manual.  How to work with cvs and git.

6. Arches, arch testing.  Profiles.

7. Building stages.  Catalyst.

Somewhere in there I'll squeeze in Gentoo's "alt" factor: alternative c 
libs, alternative compilers and hardening, alternative kernels, prefixes.

Please comment.  If it gets systematized enough, it can be a guide to 
future devs too.  Everything will be creative commons.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] College Course in Gentoo Development

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
> Hi everyone,
> 
> Give the talk on the list about attracting devs, I've should probably
> mention that I'm teaching a College Course on Gentoo Development next
> semester.  I know two students will most likely go through the
> recruitment process, others may at least contribute.  So its like GSoC
> but the focus is not one project but an overview of general gentoo
> development, and I will have to touch on lots of stuff outside of gentoo
> per se, like how autotools and other build systems work.
> 
> So what should I teach?  Here's what I've got off the top of my head:
> 
> 1. Open source communities and Gentoo's internal political structure.
> 
> 2. Building a gentoo system, ie the handbook.  Gentoo as metadistribution.
> 
> 3. Delivering the goods: code -> build system -> portage -> compiled
> goodies -> working system
> 
> 4. How to work with gnu autotools.  Writing a build system.
> 
> 5.  How to write ebuilds, ie the dev manual.  How to work with cvs and git.
> 
> 6. Arches, arch testing.  Profiles.
> 
> 7. Building stages.  Catalyst.
> 
> Somewhere in there I'll squeeze in Gentoo's "alt" factor: alternative c
> libs, alternative compilers and hardening, alternative kernels, prefixes.
> 
> Please comment.  If it gets systematized enough, it can be a guide to
> future devs too.  Everything will be creative commons.
> 
Can I take this course online? Will the lectures be recorded?

- -ZC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQz0IQAAoJEKXdFCfdEflKikMP/iXGzyM1Bda1hfWa8L9Iby8e
kpRee1N/7+QpjZB/caDVzNm5CWEJn3Vs2LP71Ig/Ybve41EvqGJXGfBDAbF7cfIb
d6kXZqgPfKj480TT2toUAY/fIji3jbmrPxrTYBXigDsIcUxrpiMykgQMifW4esK/
1ZddA5UCI8LQxIjrDDItVQL88PMz7vSBQqgJvobXAPEdHG/xDXLUews4UsgN6z7c
F95220G2DmaPzxnITIuJfFQ1sui1ahkHJRLr4uz1e8BMFcnCbWJOFsQAqNvX8YZV
iAcb4HHTC6EXD5MUKF+OGv+sy1PJy8f4G7/cnERJxdADdyZkOUj8HQGEnuY3znt+
nbvSoCQVGAEkdm0mQY6x7kbZDzQhvztvrP2ovMCLz9FPzai+wcWQ07d00nbQd17v
mUPntVXSYKsXKg+hTPj1rGzh3Nu9zGcw7mwtJwH/z0J3sqPJRSlp88KCWIOP7bro
J+7trObO8c9GYQK6JVAFL7sxBQct9vBO4DETOJ6XxMG7lJ89GLA/zdSIBWbvWPZf
GZ+Z3+ohV//Bf9I28S5AeRVczBdAE13EFUj7VcvsRYTMkTgawHo3jQtU+gzRHfhk
H/16vCDoZ511F4wu4PF9zKWuffiVy25y0PLPewbwlPbvPwAIWiK4hsGt87t2mckr
cerDzNSNBYf9NfbHiMe7
=7Vnh
-----END PGP SIGNATURE-----

Re: [gentoo-dev] College Course in Gentoo Development

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

On 12/17/12 7:32 AM, Anthony G. Basile wrote:
> So what should I teach?  Here's what I've got off the top of my head:
> Please comment.  If it gets systematized enough, it can be a guide to
> future devs too.  Everything will be creative commons.

I think it's worth to mention somewhere that although packages take
longer to compile than downloading binaries, people don't have to
_watch_ the compilation, and many things can be done e.g. overnight.

Also, remember that Google's ChromeOS takes a lot of things from Gentoo,
including the package manager and many ebuilds. The idea here is that it
has applications in the industry.

Oh, unbundling libraries _might_ be valuable too. Or automagic
dependencies and other such packaging issues.

Paweł



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] College Course in Gentoo Development

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/12/12 10:32 AM, Anthony G. Basile wrote:
> Hi everyone,
> 
> Give the talk on the list about attracting devs, I've should
> probably mention that I'm teaching a College Course on Gentoo
> Development next semester.  I know two students will most likely go
> through the recruitment process, others may at least contribute.
> So its like GSoC but the focus is not one project but an overview
> of general gentoo development, and I will have to touch on lots of
> stuff outside of gentoo per se, like how autotools and other build
> systems work.
> 
> So what should I teach?  Here's what I've got off the top of my
> head:
> 
> 1. Open source communities and Gentoo's internal political
> structure.
> 
> 2. Building a gentoo system, ie the handbook.  Gentoo as
> metadistribution.
> 
> 3. Delivering the goods: code -> build system -> portage ->
> compiled goodies -> working system
> 
> 4. How to work with gnu autotools.  Writing a build system.
> 
> 5.  How to write ebuilds, ie the dev manual.  How to work with cvs
> and git.
> 

"5.5:  BUGS"

Very appropriate here to include somewhere (perhaps as a precursor to
#4 or as part of #5) how to (A) generate useful patches, (B) apply
patches for testing (overlay ebuild, epatch_user, etc), (C) use
bugzilla (useful submissions, bug-wrangling, herds).  QA related
issues would be good to deal with, also (maybe under arch testing in
#6?).  IE: missing dependencies, automagic dependencies, --as-needed
failures, etc. etc.


> 6. Arches, arch testing.  Profiles.
> 
> 7. Building stages.  Catalyst.
> 
> Somewhere in there I'll squeeze in Gentoo's "alt" factor:
> alternative c libs, alternative compilers and hardening,
> alternative kernels, prefixes.
> 
> Please comment.  If it gets systematized enough, it can be a guide
> to future devs too.  Everything will be creative commons.
> 

The exam isn't going to be the ebuild quiz, is it? :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlDPVP0ACgkQ2ugaI38ACPBxNQD/RvBkMHaJiwds7HpLUXnocWUi
cKXoBLfTMzeWPuVaV7QA/A3tWYw7FSTK6TCMEI68c3INcrFEF5jqjKlXha7rzq0s
=igjU
-----END PGP SIGNATURE-----

Re: [gentoo-dev] College Course in Gentoo Development

[Anthony G. Basile]

On 12/17/2012 12:23 PM, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 17/12/12 10:32 AM, Anthony G. Basile wrote:
>> Hi everyone,
>>
>>
>> 5.  How to write ebuilds, ie the dev manual.  How to work with cvs
>> and git.
>>
> "5.5:  BUGS"
>
> Very appropriate here to include somewhere (perhaps as a precursor to
> #4 or as part of #5) how to (A) generate useful patches, (B) apply
> patches for testing (overlay ebuild, epatch_user, etc), (C) use
> bugzilla (useful submissions, bug-wrangling, herds).  QA related
> issues would be good to deal with, also (maybe under arch testing in
> #6?).  IE: missing dependencies, automagic dependencies, --as-needed
> failures, etc. etc.

Yes!  Definitely.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] College Course in Gentoo Development

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

On 2012.12.17 16:02, Rick "Zero_Chaos" Farina wrote:
> On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
> > Hi everyone,
> >
> > Give the talk on the list about attracting devs, I've should
> > probably mention that I'm teaching a College Course on Gentoo 
> > Development
[snip]

> Can I take this course online? Will the lectures be recorded?
> 
> -ZC
> 

I would be interested in an online version too.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] College Course in Gentoo Development

[Maxim Kammerer]

On Mon, Dec 17, 2012 at 5:32 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> Please comment.  If it gets systematized enough, it can be a guide to future
> devs too.

Hi, what is the level of the students, what are the prerequisites
(i.e., have they already seen some systems programming using C?), and
how many weekly hours? Have you already designed some assignments? I
can think of the following:

1. Create a small makefile-based project with a separate shared
library, an executable, and a man page. Determine run-time and
build-time dependencies. Then convert to autotools, update
dependencies. Do it all on GitHub, with a separate branch for
converting to autotools.

2. Write an ebuild for the project above, maintained in an overlay
(also on GitHub), with sources fetched from GitHub. Add some small
patch to configure.ac in the ebuild. Add USE flags. Add "make check"
support to the build system, test with FEATURES=test. Many
ebuild-related tasks can be easily added (e.g. installing init.d
scripts).

3. Take an old-version ebuild for a project with a known bug, fetch
the relevant git tag, and bisect to find the bug. Prepare a patch,
describe patch submission process.

Wrt. subjects covered, will you cover sandboxing, installing to image
vs. merging to live system, etc.? I would expect students to like such
stuff.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] College Course in Gentoo Development

[Michael Mol]

On Mon, Dec 17, 2012 at 1:09 PM, Roy Bamford <neddyseagoon@gentoo.org> wrote:
> On 2012.12.17 16:02, Rick "Zero_Chaos" Farina wrote:
>> On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
>> > Hi everyone,
>> >
>> > Give the talk on the list about attracting devs, I've should
>> > probably mention that I'm teaching a College Course on Gentoo
>> > Development
> [snip]
>
>> Can I take this course online? Will the lectures be recorded?
>>
>> -ZC
>>
>
> I would be interested in an online version too.

As would I.

(I'd also be very interested in seeing the structure duplicated to
produce similar material for other common distributions...but I'm a
chrestomathy addict.)

--
:wq

Re: [gentoo-dev] College Course in Gentoo Development

[hasufell]

> 
> 4. How to work with gnu autotools.  Writing a build system.

Writing a build system from scratch is actually not a requirement.
However one should understand basics of the most popular build systems
and probably have some advanced understaning of Makefiles and how flags
work, where they should be placed and so on which leads me to what you'v
been missing a bit:

QA

Why we do it and what the most common QA issues are (things like
disrespected CFLAGS/CC/LDFLAGS, bundled libs, broken parallel make,
portage QA notices (i.e. broken strict-aliasing), automagic dependencies
and so on).

That's what seperates us from many other distros.

> 
> 5.  How to write ebuilds, ie the dev manual.  How to work with cvs and git.

a few more specific thoughts on this...

IMO one of the more important points of writing ebuilds is to figure out
the dependencies correctly and how to implement use flags properly.
So figuring out dependencies usually involves reading the build system
and might even involve grepping/reading source files for includes/dlopen
or language specific things (note the differences in ruby, perl and
python...), cause assuming that the information from upstreams
INSTALL/README file suffices is almost always wrong.
Regarding useflags it's important to a) decide whether it makes sense to
offer that useflag/choice at all, b) what name to choose, so we don't
confuse the user, c) give descriptions in metadata.xml if the usecase
differs from the global description and d) test them all (which leads us
to point 6)

And that's exactly how I usually begin writing an ebuild:
- figure out all dependencies
- figure out what useflags to provide and how to implement them
- fix QA issues/patch the build system

Then the next thing is just understanding phase functions and the
regular helpers like econf/cmake-utils.eclass/eutils.eclass which you
can read up quite easily.

I would probably leave a few things behind like java ebuilds, ruby
ebuilds or even python ebuilds (due to the current eclass
conversion/confusion) and focus on autotools, cmake and plain Makefile
related things.

Give a few good and bad examples for each of them, so people understand
that every build system can be messed up.

Re: [gentoo-dev] College Course in Gentoo Development

[hasufell]

On 12/17/2012 07:11 PM, Maxim Kammerer wrote:
> Then convert to autotools, update
> dependencies. Do it all on GitHub, with a separate branch for
> converting to autotools.
> 

That's not really a common thing to do for ebuild development (neither
converting nor writing from scratch).

Actually you only do that if you have direct access to the upstream repo
or know that they will accept your patch.

That happened only once to me.

Re: [gentoo-dev] College Course in Gentoo Development

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

On Mon, 17 Dec 2012 10:32:03 -0500
"Anthony G. Basile" <blueness@gentoo.org> wrote:
> 5.  How to write ebuilds, ie the dev manual.  How to work with cvs
> and git.

An important thing to teach here is how to code to a spec vs how to
code to an implementation. It's also something people should know in
general...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] College Course in Gentoo Development

[Hinnerk van Bruinehsen]

On Mon, Dec 17, 2012 at 11:02:24AM -0500, Rick "Zero_Chaos" Farina wrote:
<SNIP>
> Can I take this course online? Will the lectures be recorded?
> 
I would second the idea of an "online course" if that is possible: I
would even gladly do the "beta testing" of such an online course... ;)

WKR

Hinnerk

Re: [gentoo-dev] College Course in Gentoo Development

[Maxim Kammerer]

On Mon, Dec 17, 2012 at 8:18 PM, hasufell <hasufell@gentoo.org> wrote:
> On 12/17/2012 07:11 PM, Maxim Kammerer wrote:
>> Then convert to autotools, update
>> dependencies. Do it all on GitHub, with a separate branch for
>> converting to autotools.
>
> That's not really a common thing to do for ebuild development (neither
> converting nor writing from scratch).

These are proposed course assignments (supposed to cover understanding
of certain subjects), not a training for writing ebuilds. :)

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] College Course in Gentoo Development

[Michael Orlitzky]

On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
> Hi everyone,
> 
> Give the talk on the list about attracting devs, I've should probably 
> mention that I'm teaching a College Course on Gentoo Development next 
> semester.  I know two students will most likely go through the 
> recruitment process, others may at least contribute.  So its like GSoC 
> but the focus is not one project but an overview of general gentoo 
> development, and I will have to touch on lots of stuff outside of gentoo 
> per se, like how autotools and other build systems work.
> 

This is a great idea, and is essentially the "pay someone to recruit"
approach taken to an extreme. I would be willing to pay for a class like
this (online or otherwise) if it meant that there were a clear set of
goals, which if met, meant that I'd become a developer.

Why can't something like this *be* the recruiting process? Put up a
syllabus. The "wait to be noticed" process is so vague as to be useless.

Re: [gentoo-dev] College Course in Gentoo Development

[Michael Hampicke]

Am 17.12.2012 17:02, schrieb Rick "Zero_Chaos" Farina:
> On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
>> Hi everyone,
> 
>> Give the talk on the list about attracting devs, I've should probably
>> mention that I'm teaching a College Course on Gentoo Development next
>> semester.  I know two students will most likely go through the
>> recruitment process, others may at least contribute.  So its like GSoC
>> but the focus is not one project but an overview of general gentoo
>> development, and I will have to touch on lots of stuff outside of gentoo
>> per se, like how autotools and other build systems work.
> 
>> So what should I teach?  Here's what I've got off the top of my head:
> 
>> 1. Open source communities and Gentoo's internal political structure.
> 
>> 2. Building a gentoo system, ie the handbook.  Gentoo as metadistribution.
> 
>> 3. Delivering the goods: code -> build system -> portage -> compiled
>> goodies -> working system
> 
>> 4. How to work with gnu autotools.  Writing a build system.
> 
>> 5.  How to write ebuilds, ie the dev manual.  How to work with cvs and git.
> 
>> 6. Arches, arch testing.  Profiles.
> 
>> 7. Building stages.  Catalyst.
> 
>> Somewhere in there I'll squeeze in Gentoo's "alt" factor: alternative c
>> libs, alternative compilers and hardening, alternative kernels, prefixes.
> 
>> Please comment.  If it gets systematized enough, it can be a guide to
>> future devs too.  Everything will be creative commons.
> 
> Can I take this course online? Will the lectures be recorded?
> 
> -ZC
> 

I would be interested in this course as well :)

Re: [gentoo-dev] College Course in Gentoo Development

[Anthony G. Basile]

On 12/17/2012 01:11 PM, Maxim Kammerer wrote:
> On Mon, Dec 17, 2012 at 5:32 PM, Anthony G. Basile<blueness@gentoo.org>  wrote:
>> Please comment.  If it gets systematized enough, it can be a guide to future
>> devs too.
> Hi, what is the level of the students, what are the prerequisites
> (i.e., have they already seen some systems programming using C?), and
> how many weekly hours? Have you already designed some assignments? I
> can think of the following:
>
> 1. Create a small makefile-based project with a separate shared
> library, an executable, and a man page. Determine run-time and
> build-time dependencies. Then convert to autotools, update
> dependencies. Do it all on GitHub, with a separate branch for
> converting to autotools.

Its a second year course so they've had some programming in Java but no 
serious C.  It meets 3 hours a week but I expect about 6 hours more per 
week in assignments.

There is some overlap with other stuff I've taught: Makefiles, 
autotools, git and shared objects.  I did my lecture materials in git 
and then ran a git rebase -i in class and redid the commits showing them 
what happened on each point.  You can see some of that stuff here ->

practice with git -> 
http://tweedledum.dyc.edu/gitweb/?p=model-git.git;a=summary

how autotools works -> 
http://tweedledum.dyc.edu/gitweb/?p=autotools.git;a=summary

how Makefiles work -> 
http://tweedledum.dyc.edu/gitweb/?p=makefile.git;a=summary

how shared objects work -> 
http://tweedledum.dyc.edu/gitweb/?p=shared-objects.git;a=summary

>
> 2. Write an ebuild for the project above, maintained in an overlay
> (also on GitHub), with sources fetched from GitHub. Add some small
> patch to configure.ac in the ebuild. Add USE flags. Add "make check"
> support to the build system, test with FEATURES=test. Many
> ebuild-related tasks can be easily added (e.g. installing init.d
> scripts).

This would be totally new to them but I agree that's a good idea.  I 
don't know about GitHub.  Can you delete projects from it when you're 
done because I don't want to polute GitHub with lots of unpolished stuff.

>
> 3. Take an old-version ebuild for a project with a known bug, fetch
> the relevant git tag, and bisect to find the bug. Prepare a patch,
> describe patch submission process.
Hmm ... I didn't think of this but I could do that with the kernel on 
virtual machines.

>
> Wrt. subjects covered, will you cover sandboxing, installing to image
> vs. merging to live system, etc.? I would expect students to like such
> stuff.
>
At some point I would have to cover that.  Like when I got over the 
phases of emerging, stepping through them with ebuild.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

[gentoo-dev] Re: College Course in Gentoo Development

[Duncan]

Paweł Hajdan, Jr. posted on Mon, 17 Dec 2012 08:48:01 -0800 as excerpted:

> On 12/17/12 7:32 AM, Anthony G. Basile wrote:
>> So what should I teach?  Here's what I've got off the top of my head:
>> Please comment.  If it gets systematized enough, it can be a guide to
>> future devs too.  Everything will be creative commons.
> 
> I think it's worth to mention somewhere that although packages take
> longer to compile than downloading binaries, people don't have to
> _watch_ the compilation, and many things can be done e.g. overnight.

++

Two reasons.  From a user perspective, I often see people's complaints 
about how much of a waste of time gentoo is, watching the build output 
scroll by.  People simply don't seem to realize that you can go away and 
do something else while all that's happening, or on a modern multi-core 
system with a decent amount of memory, set PORTAGE_NICENESS and MAKEOPTS 
appropriately, and even just go on using the system as you normally would 
if you weren't compiling in the background (of course as long as that 
"normally" isn't something like multi-thread ray-tracing, or using the 
machine as part of a low-latency sound studio, etc), and that what REALLY 
takes the time is updating the config files and otherwise adjusting to 
new versions of whatever packages you just upgraded, which would take the 
SAME amount of time to go thru, for a similar version update, regardless 
of whether the distro is binary-based or from-source.

From a dev and student-dev perspective, more your focus here, it's an 
even MORE important lesson, as these guys will likely be doing a lot more 
package building over their schooling and career than the average user 
(tho maybe not so much more than the average gentoo user), even if they 
don't stick around on gentoo, and the earlier they get the message that 
they can let the computer do what the computer does best and that once 
it's setup properly they don't have to constantly watch it, only check on 
it once in awhile and check the final status and summary messages, the 
more efficient they're going to be as students, devs, and ultimately, 
employees.

> Also, remember that Google's ChromeOS takes a lot of things from Gentoo,
> including the package manager and many ebuilds. The idea here is that it
> has applications in the industry.

Good thought.  Anchor the theory in real-world practicality. =:^)


And since I replied here, I might as well throw in my own suggestion here 
as well.

I don't see any mention of overlays on that list of covered subjects.  
Perhaps mention them under point #2, covering gentoo as a metadistro, 
then cover them in more detail under point #3, delivering the goods.  

Keep in mind that many gentoo devs begin working with project overlays 
well before they're official devs, under the supervision of the devs 
responsible for that project.  Depending on an individual student's 
interest, they could be getting involved with projects and working in the 
respective project overlays before the end of the course, so introducing 
them fairly early on and giving them a chance to work with them, first as 
a user, then as they progress, as a dev, should work out quite well.

Overlays should work in quite well with your coverage of git, too, since 
many of the overlays are git-based.  You could either take Maxim K's 
github idea and do the overlay there, or do something similar using 
overlays.gentoo.org.

Either way you'd presumably work with the hosting provider, github, 
gentoo, or other.  I don't know if you can delete github projects, but if 
I were github, I'd *JUMP* at the chance to cooperate with someone 
offering a college level course integrating github, and would likely 
offer to work with you on integrating anything special you needed, like 
deletable projects, in ordered to do it.  This since once a student's 
using github, they're going to take that practice with them, and in a few 
years, many of them will likely be pushing paid github accounts at 
wherever they end up working.  If you pursue the github idea, I'd 
DEFINITELY recommend contacting github, as they may well be able to 
suggest or even create other features to fit your class as well, and they 
should have a pretty high motivation to do so.  They /might/ even offer 
to sponsor some of the course material cost, etc, especially since they 
can almost certainly write it off as either advertising/PR expense or 
educational donation. =:^)

OTOH if you chose overlays.gentoo.org for your hosting, you should get 
quite close cooperation as well, likely even closer due to scale and 
direct focus, and AFAIK gentoo already has some experience there from the 
Google Summer of Code projects.  But the experience isn't as easily or 
directly useful for students beyond the course and gentoo, as working 
with github would be.  OTOH, working too closely with github might be 
seen as a commercial endorsement you or your school may not wish to make 
(except perhaps if they /do/ actually offer sponsorship, most schools 
know how to make /that/ work), while gentoo as a non-profit that's 
already directly part of the course shouldn't have that issue, and could 
be seen as useful in its own right since it parallels the adaption to an 
existing work environment that an employee (and for that matter, 
volunteer joining a FLOSS project) generally must make, regardless of 
whatever github or etc experience they may have already.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] College Course in Gentoo Development

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
> Hi everyone,
> 
> Give the talk on the list about attracting devs, I've should probably
> mention that I'm teaching a College Course on Gentoo Development next
> semester.  I know two students will most likely go through the
> recruitment process, others may at least contribute.  So its like GSoC
> but the focus is not one project but an overview of general gentoo
> development, and I will have to touch on lots of stuff outside of gentoo
> per se, like how autotools and other build systems work.
> 
> So what should I teach?  Here's what I've got off the top of my head:
> 
> 1. Open source communities and Gentoo's internal political structure.
> 
> 2. Building a gentoo system, ie the handbook.  Gentoo as metadistribution.
> 
> 3. Delivering the goods: code -> build system -> portage -> compiled
> goodies -> working system
> 
> 4. How to work with gnu autotools.  Writing a build system.
> 
> 5.  How to write ebuilds, ie the dev manual.  How to work with cvs and git.
> 
> 6. Arches, arch testing.  Profiles.
> 
> 7. Building stages.  Catalyst.
> 
> Somewhere in there I'll squeeze in Gentoo's "alt" factor: alternative c
> libs, alternative compilers and hardening, alternative kernels, prefixes.
> 
> Please comment.  If it gets systematized enough, it can be a guide to
> future devs too.  Everything will be creative commons.
> 

You might want to have a lecture about software licensing.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] College Course in Gentoo Development

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

On 12/17/2012 07:46 PM, Anthony G. Basile wrote:
>>
>> 2. Write an ebuild for the project above, maintained in an overlay
>> (also on GitHub), with sources fetched from GitHub. Add some small
>> patch to configure.ac in the ebuild. Add USE flags. Add "make check"
>> support to the build system, test with FEATURES=test. Many
>> ebuild-related tasks can be easily added (e.g. installing init.d
>> scripts).
> 
> This would be totally new to them but I agree that's a good idea.  I
> don't know about GitHub.  Can you delete projects from it when you're
> done because I don't want to polute GitHub with lots of unpolished stuff.

You can.

>>
>> 3. Take an old-version ebuild for a project with a known bug, fetch
>> the relevant git tag, and bisect to find the bug. Prepare a patch,
>> describe patch submission process.
> Hmm ... I didn't think of this but I could do that with the kernel on
> virtual machines.

You might want a userland program to avoid having to do reboots. I
suppose git itself could be a good candidate for this.

>>
>> Wrt. subjects covered, will you cover sandboxing, installing to image
>> vs. merging to live system, etc.? I would expect students to like such
>> stuff.
>>
> At some point I would have to cover that.  Like when I got over the
> phases of emerging, stepping through them with ebuild.
> 

You make me wish that this class was available when I was doing my
undergraduate degree. I had to learn this on my own.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Re: College Course in Gentoo Development

[Kevin Chadwick]

> People simply don't seem to realize that you can go away and 
> do something else while all that's happening

Like servers I prefer build machines to be more secure dedicated build
machines without a browser or X, so I expect it's a bit of a barrier
for me.

Having said that I haven't found the time to see how much time and
resources are involved compared to Sabayon and how often yet whilst
using libreoffice binaries.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________