Unity and Yoper, a tale of two distros...
57 views
Skip to first unread message
devnet
Feb 17, 2011, 9:24:10 PM2/17/11
to ul-developers, unity-devel, yoper-dev
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:
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:
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
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:
- Automate as many tasks for development as possible
- Make the process repeatable and quantifiable (for quality assurance checks and balances)
- Make the entire process open to all for collaboration
- Make the process distro agnostic (for collaboration)
- 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
Reply all
Reply to author
Forward
0 new messages