 |
Just to follow up with the Graphics Team update, I wanted to talk about some other things which have been discussed.
Task Management ∞
We’ve settled much of the internal communications structure, but there’s a big roadblock when it comes to task management. One big problem with big projects is that they get burdened the larger they grow and with the more people who join.
We’re not exactly “large” right now, but we already feel the strain of a growing team. Some 30 people and another 10 candidates, and we haven’t even made a release yet!
So, communications.. One thought has been to use some sort of technical task management system. We investigated some, and we had a conversation on processes and workflow which ultimately went over my head. But it came down to the fact that SourceForge couldn’t provide what we needed.
So what’s being investigated is, of all things, help desk software! After all, we’re not really in software development as such. Our main product is a series of packages. So this is still an interesting an essential discussion that’s ongoing.
KDE3 ∞
I’ve always felt that our primary audience isn’t a “user” per se., but more a group customizing a branch. This is why I’ve paid special attention to how things are handled when it comes to interest in a new branch.
So let’s follow a bit of the story. Granular Linux is currently a remaster of PCLinuxOS. They have been the major supporter of KDE3.
However, since KDE4 was released, it is widely thought that KDE3 will be abandoned by the KDE team. A lot of people aren’t bothered, as the recent KDE4 releases have become more and more excellent in their minds. With that, the Granular team lead Anurag Bhandari had already decided to drop KDE3 from the future Unity Linux-based Granular in preference for KDE4.
Nobody really minded for some time, but recently more and more voices have been heard. Those voices say “I prefer KDE3”. But there has been no KDE3 branch declared. As I think about it, several non-English branches may also have an interest in KDE3 but we have not had this conversation yet.
I had a few long conversations with a couple of interested people, and I shared what I knew but I could not confirm if KDE3 would have any significant official support because of the lack of a KDE3-based branch.
Well, out of nowhere a team of four has declared their intention to create Meridian Linux, a KDE3-based distribution. (announcement)
This forces all kinds of issues about our integrating new people, providing resources and more.
It’s all good.. it’ll kick us in the pants and make us run a little.
Well, as long as we’re walking that way anyways. If we weren’t walking that way but we were instead walking towards the kick.. then it would be less pleasant. ;)
The base development environment ∞
The base development environment took an interesting turn last weekend, when I stumbled through a series of instructions with such blind incompetence that others were inspired to idiot-proof things. =) The documentation I made was really great, and I got to package a couple of things, but the process revealed various holes and cool possibilities for improvement.
So instead of having a virtual environment or separate partition with a host distribution with a a special build user and such, instead we have a chrooted build environment. I know just enough to know how cool that is. Well, I know just enough to chroot to fix Lilo.
At any rate, this means that there will be less moving parts between a developer and the build environment. Specifically it means no VMWare, VirtualBox or other virtualization is needed. This means much faster packaging. We’ll need all the speed we can get, we’re going to be hand rebuilding every package in the base. More on that next..
Packages ∞
The rate at which packages are getting rebuilt is astonishing. Strangely, since we’re not yet organized in other areas anyone with any time is building or learning building.
We’re still working on a lot of core libraries. I last heard QT4 was done. I’ve not been closely following that side of things, since I’ve become swamped with docs and organizational-related interests/needs. Here are some good resources for following packaging:
I’ve heard all kinds of crazy numbers, like a 300 package binge one of our guys did. I’ve also heard 1600 packages are done, but I’ve heard other numbers too so I don’t know what to trust.
My goal is 20,000 packages so we can grin sideways at “other distributions”. =)
Of course, we don’t need so many packages to get a public alpha out, and a closed alpha is already in the works for next week. We’d really only need to build the packages required by each of our branches to get into maintenance mode. Umm. Crap, that’s probably 19,999 packages. =(
Docs and Leadership ∞
I had the thought that leadership should rotate either on a schedule or after a major version release. I figured that documentation has always had serious issues with “this version vs next version” and that a change in leadership would help bring a fresh mind in which can be more forward-looking.
Mind you, it looks like the project will be documentation-driven. This means that the development will lag behind the documentation instead of the other way around, as it is elsewhere.
This is handy, since I do want to be able to shift my focus from Unity Linux to Oldschool Linux. I especially want to do this since I’ve been doing some spare-time researching and such. I also heard one other branch is keeping up to speed so closely that they expect to have a branch release a week after Unity Linux is officially launched. I want to do that too!! =)
Coming Soon ∞
There’s more to talk about, but I’ll leave it at this.
Thanks for the updates.