Suggestion for a standard, minimalistic development environment
Marc Richter
I had the idea to provide a standard, minimalistic "Funtoo Standard
Testenvironment" for developers, to help the Core Team Members,
upcoming/current package developers and those developers, who will have to
test the committed packages in the future to have a standard environment
to easily issue basic testing for compatibility and quality. The idea is,
that each package, before it is "allowed" to be submitted it has to pass
an installation routine on a standard and minimalistic "test parkour".
I'd like to describe a short example why this might come handy:
Let's say, there is a developer who wants to add a new package to the
portage tree. He reads about the requirements in the documentation,
fulfills it on his system, adds those requirements to the package
description and, because everything runs fine locally, he submits that
package. Since most of the hard-core users, developers, core team members,
etc. tend to have packages unmasked and/or run experimental stuff from
overlays etc. that wouldn't be on a normal user's system and nearly no two
sets of USE flags are the same out there, chances are great that some kind
of "hidden fulfilled dependency" kicks in on that developers system,
because the software *really* needs further requirements, which are not
explicitly defined in the docs. Such a package will run fine on the
developer's machine(s), but as soon as a user doesn't have that packages
installed, the build will fail.
To make sure everything runs fine, it should become a must in the future
to test a new package on such a minimalistic, non-customized system prior
to submitting.
It would be great if this wouldn't be the case, but in the real world
there are always some "black sheep" out there, who do not invest a sane
amount of time in testing. Another gain of such a standard system would be
to enable a Core Team Member, who has to decide if he adds a package to
the portage tree to first of all test the package in this standard,
minimalistic environment. If it not even compiles (and works) fine in
this, chances are great that the submitting developer not tested it on his
own prior to submitting. So all further tests become obsolete.
To make this even more handy, we could combine this environment with
virtualisation. Such a VM could then be set up once, then take a snapshot
of it, like nearly all current virtualisation applications are offering
these days. When one wants to test such a package then, he can try to
install it within that virtual machine (VM). If everything works fine, he
can easily go back to the state of the snapshot in just a few seconds and
he ends up with a clean testenvironment again.
Such a machine could even be distributed on a regular and automatic basis
like the stages or the portage snapshots are. For example, as an openVZ or
QEmu container or such. So all could use the exactly same environment. But
we could create only a guide, too.
I think, regardless of that (very good!) idea of a Funtoo Maintenance
Overlay concept [1] will become reality or not, this might be a very good
option for development and might become a further tool to help to make
Funtoo a little bit better.
I'd like to know what you're thinking about that and would be happy to
read your ideas and opinions either in this ML or in the corresponding
thread [2] in the Funtoo forums.
Best regards,
Marc "Whitewolf Fox" Richter
[1] http://forums.funtoo.org/viewtopic.php?id=583
[2] http://forums.funtoo.org/viewtopic.php?id=585