Unity Linux and Yoper Linux, two rpm5 distributions of yore (ok, maybe not
of yore...but definitely of legend?) have begun a collaboration project that
hopes to revolutionize the way both distributions are built, maintained, and
developed. It's ambitious. It's edgy. Lady Gaga sings about it on her
next album. Ok, so Lady Gaga may not be singing about it...BUT, we've
started working on this project with aims to automate and assist packagers
and developers in their task of maintaining distributions.
With this project which we're calling "ubuild", the mountainous task of
maintaining up to date software that faces packagers will become much, much
easier. Instead of packagers and developers worrying about keeping software
up to date, retiring older packages and making sure packages fit common
criteria (built in chroot, both 64bit and 32bit, built against specific
versions of software only) they'll be freed up to do other things like
interact with the community and come up with even cooler ideas to make the
distro great.
The idea is this:
1. Automate as many tasks for development as possible
2. Make the process repeatable and quantifiable (for quality assurance
checks and balances)
3. Make the entire process open to all for collaboration
4. Make the process distro agnostic (for collaboration)
5. Profit!
Have we peaked your curiosity yet? Would you like to be a part of a project
that gives non-technical users the ability to work with and upgrade packages
yet doesn't sacrifice package quality?
Would you like to be a part of a project that allows users to create a
distribution of Linux with a single file? If so, read on! And if you have
any questions not covered by the FAQ below, please ask them and they will be
answered!
*
1. What is ubuild?*
A collaboration effort of core developers of Unity Linux and Yoper Linux to
produce a 'better' buildsystem than either the Unity Linux community or
Yoper Linux currently have. It also sets out to lower the entrance barriers
for users to contribute to development tasks for any distribution that
chooses to use ubuild for it's development.
*
2. How will this help Unity Linux?
3. How will this help Yoper Linux?*
Not only with this make development of Yoper and Unity Linux easier, it will
also make the quality of the work higher. Using QA checks built into
automated processes in ubuild, packages will be rejected if they don't meet
a certain set of standards.
Ubuild will also allow the participation of community members who aren't
that technically minded but still would like to contribute. It will
automate common tasks to free up developer time and provide a better
framework to eliminate broken dependencies...even something as simple as a
lack of menu entry in your favorite desktop environment for whatever
application that is being packaged. It also will assist with checking to
make sure that translations into your native language are present...all
processes auto-magically delicious!
Please note that these benefits will be spread across ANY distribution and
ANY branch that uses ubuild. This means both Yoper and Unity will benefit!
*
4. How will this benefit branches?*
When we initially set out the goals of Unity Linux...we wanted to be the
'core' of as many Linux desktop distributions as we could. This mission
hasn't changed. What has changed is our ability to allow our branches to
inherit benefits from upstream and vice versa...in other words, our branches
wouldn't benefit from one another. If one branch made an awesome change and
pushed it back up to Unity core, other branches may not benefit from this
improvement.
With ubuild, branches can have true dependencies to each other which are
respected through the entire infrastructure. QA checks will allow ALL
branches instant notification when something is wrong so that the maximum
number of developers can work on resolving these issues WHEN they happen and
not wait for verification on if the problem exists before fixing it.
Users who are not technical will be able to create their own branch with a
single file and point click to update packages. This lowers the barrier for
branches to become involved and base off of Unity and Yoper Linux.
*5. Isn't the current Build Server for Unity/Yoper enough?*
The current build server for Unity relies on human interaction to push
packages and has no internal Quality Assurance checks that it runs before
accepting or rejecting packages (it tries to build ANY package that is
submitted to it!). Yoper's build server lacks the distro agnostic and
client server approach that ubuild is setting out to accomplish.
So while both build servers get the job done, there is always room for
improvement. Ubuild sets out to be this improvement.
*6. What about local command line tools for rpm building and ISO generation?
*
These utilities will still exist. An example is the tool create-basesystem
which was recently created to allow branches to create a base system ISO for
their branch. This utility will still exist...however, we're confident that
ubuild utilities will replace them eventually. In fact, with the ability to
QA packages built into ubuild, branches and developers should use it in
place of local command line tools on their own to benefit from the many
checks and balances that will help them churn out quality software!
Ubuild also has plans to support satellite 'nodes' that will facilitate
users. Ubuild utilities will be able to exchange information with one or
more ubuild nodes ( servers ) that have much more data and rules at hand to
make a decision, ubuild utilities will literally be able to ask nodes for
decisions regarding certain actions.
In summary, local utilities will be present but we hope to make ubuild so
awesome that you won't even want to use them.
*7. What do you mean by "Quality Assurance" of packages?*
Quality Assurance, as defined, is the monitoring of software engineering
processes and methods to ensure quality. If we're running our software
packages through a series of tests and checks and monitoring the outcome,
we're doing quality assurance of our packages. Currently, in Unity Linux,
these checks are left up to manual checks by each packagers. While this
doesn't mean you'll have bad software, it DOES mean that developers are
spending a lot of time on a process that can be automated and made
repeatable.
Ubuild will automate these time consuming tasks for packagers. Things like
detection of when would be a good time to retire a package and how it will
effect the repository, detection and spawning of automatic rebuilds for
updates and tracking of updates to packages and queing for rebuild will be
covered by ubuild (thanks to KDulcimer's code on a side project for update
detection!)
These types of processes and methods are what Unity and Yoper will seek to
automate in order to free up developers and packagers so they can do other
things to help out their distro :)
*
8. Can anyone help out? *
Sure! We don't just need coders to help with the internals of ubuild...we
also need help constructing workflow and documenting processes. If you can
document in a wiki or in a text file or can think about the workflow a
package takes from beginning to end, you can help us!
*
9. How can I get involved?*
Since development on ubuild will take place at a fast pace, it's better to
use IRC to collaborate. Visit #ubuild on Freenode. Mdawkins and TobiG are
running point on ubuild currently so ask them how you can help! You can
also visit the various project pages of ubuild:
- source code : http://gitorious.org/ubuild
- irc.freenode.net #ubuild, logs @ http://ubuild.yoper-linux.org/
- documentation : http://docs.unity-linux.org/Ubuild
- Bug list, etc. http://dev.unity-linux.org/projects/ubuild
*
10. Is this system geared toward one specific distribution or is it
distribution neutral?*
Ubuild is being specifically coded with neutrality in mind...however, the
workflow may only be for Unity and Yoper. So, if you are part of a
different distribution and are looking to leverage ubuild, it would be wise
to give your input specifically on the workflow portion so that it fits your
individual distributions' needs.
Ubuild should be easy to adopt for any rpm distribution and could
potentially even work for a Debian based distribution with some work on the
core code.
*So what Now?*
Over the course of the next 6 weeks or so ubuild will continue to take
shape. It will NOT be employed until it is a finished project. However, a
sandbox environment has already been constructed that will allow us to test
things in real time...so, come on into #ubuild on freenode and help us work
on finishing this project....even if you don't know how to code, you can
assist us in testing workflows and packages that are built using this
method. Together, we will grow stronger by constructing a common base our
communities can grow from!
On behalf of the Unity Linux developers and Yoper Linux developers,
Devnet
