The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.
Difference between revisions of "News:Project Unfork Status"
Line 5: | Line 5: | ||
|Author=Drobbins | |Author=Drobbins | ||
|Publication Status=Published | |Publication Status=Published | ||
|Deprecated By=Unfork Tree is Live! | |||
|Publication Date=2015/10/03 | |Publication Date=2015/10/03 | ||
}} | }} |
Revision as of 17:07, October 12, 2015
Project Unfork Status
This news item is not current. You can find updated information on this topic at Unfork Tree is Live!.
Hey everyone -- I wanted to give you an update on the status of Project Unfork.
Many of you have heard of Funtoo's Project Unfork on Facebook or Twitter. Here is a quick summary of what it's about: historically, Funtoo has generally had only one option available to address issues with upstream Gentoo ebuilds that cause problems for our builds, or for our users -- and that option involved forking the ebuilds in question, and maintaining them ourselves.
Over the years, we've accumulated a lot of forked ebuilds, and while that gives us more control over the upstream ebuilds, it comes with a maintenance cost. Since the ebuilds are now forked, they now need to be maintained. And since our team is extremely small (1-3 people,) over time, these ebuilds go out of date. In addition to about 250 ebuilds forked in funtoo-overlay, we have integrated the Progress overlay, consisting of hundreds of python ebuilds, as well as forked pretty much the entirety of GNOME (about 200 ebuilds).
If forking were the only option we had available to ensure that ebuilds built reliably, then I'd keep forking ebuilds. But fortunately, there is a new option available, and that is by using a method I created using a thing called 'shards'. The benefit of 'shards' is that they will allow Funtoo to provide consistent results to users without relying on the maintenance-intensive practice of forking Gentoo ebuilds. This, in turn, will also help us to collaborate more closely with Gentoo, and to focus on things that make a difference, rather than duplicating work.
What are shards and how do they work? A shard is a set of related ebuilds from Gentoo, such as 'all the GNOME ebuilds', 'all the python ebuilds', or 'all the perl ebuilds'. My merge script grabs the latest changes to these sets of ebuilds and stores them in a git tree. Now, in the past, we have imported Gentoo changes automatically every few hours, except for ebuilds we have forked which change a lot less often. With shards, I can freeze the version of a specific set of Gentoo ebuilds to a particular point in time. This provides a consistent and known-good set of ebuilds to Funtoo users. Before bumping to an updated revision of the shard, Funtoo can now proactively perform quality assurance testing to do our best to make sure that any updates will not cause problems for our users. This way, we can proactively test rather than respond reactively to problems after they have arisen. This is much more time-efficient and provides a better experience for our users.
How Can You Help?
Currently, I am maintaining a special 'unfork' Portage tree where a lot of unforked things are being tested. You can find this Portage tree located at https://github.com/funtoo/funtoo-staging-unfork. By using this Portage tree as your main Portage tree, you can help me test the upcoming unforking changes. This particular tree currently no longer contains the Progress overlay, and also does not include our forked version of GNOME. Instead, it contains upstream GNOME and we now have a special gnome-3.16-fixups mix-in which can be enabled after the gnome mix-in, to test GNOME 3.16 on Funtoo. Currently, enabling this mix-in after the gnome mix-in should allow GNOME 3.16 to merge from upstream with systemd disabled, for testing purposes. Please report any issues you find to our bug tracker at http://bugs.funtoo.org.
And please check the status of Project Unfork at the Project Unfork page, coming soon!