Canonical Plans a Version-Tracking Tool for Devs
daria42 writes "Canonical, the company behind Ubuntu, has started work on a new project which aims to make easier for Linux developers to find the latest open source software updates, no matter which distribution they are contributing to. The effort encompasses distributed bug tracking, revision control, language translations and more. Canonical founder Mark Shuttleworth wants Ubuntu to take advantage of the software, saying: 'As the framework [for using code from across the community] sets, hopefully we are at the centre of it. Further down the pipeline we may need to differentiate on other grounds.'"
This is just another short-term bypass to a long-term problem. Eventually, this will be just as usefull as CVS/Subversioni is right now for open source projects on different distributions.
:)
IMHO
The summary gives the impression that Launchpad development just started, but it's been around for a few months at least. Bug reports from the unsupported packages in Ubuntu's latest release go to Malone, which is a part of Launchpad. Also, I think people have been using Rosetta to do translations for Hoary as well. It looks promising.
Before you ask, Launchpad isn't open source. Yet.
I assume from the sumarry that this means finding a niche that puts them apart from netbsd's pkgsrc and the gentoo system...both of which already address tracking source updates across multiple distros (and even OSes -eg pkgsrc and gentoo on bsd).
What I would like to know is, are they going to spin it off into a commercial version as well (ala xchat) or simply live off of support or something else?
Now if they make a similar project for the average end user that has the simplicity of Gentoo's emerge system, but is cross-platform, I'm sold.
I am scientifically inaccurate.
CVS and Subversion are centralised in that there is a central repository.
Systems such as ARCH allow a virtual repository that is fragmented across multiple servers - some of which might be official, and some might not.
This lets you branch from a project, but still remain in sync with it, and more importantly do so without permission or help from the official repository.
There is a lot more to it too.
CVS was a good start, and Gentoo takes the next step, but they all require somebody to be "developer in the middle" for every single configuration decision. Debian is very cool in that it seeks to always provide a "foundation" to build on, but it's much too slow advancing [updating the foundation] for "internet" usage. I've thought it was time for a while now to develop the "next" system... which I could gaurantee is unique to OSS and nobody else. Gentoo's ebuild is great, but it doesn't go back to the developer/ outside of gentoo. Think about this a minute... if Gentoo is source only, then it should be simple to make a ebuild for any other distro too... but "it's not that easy" you say... I'd ask WHY?
Ideally, every person who compiles should be able to submit their results "upstream" as well as "downstream" that's the current distro problem we face now. Every distro fixes things differently, but the original author can't keep up with all the changes coming from a dozen distros... so they all stay "fragmented". The "next" system should fix bugs once... and be able to relay the issues back to the guy who maintains that particular piece of source code. Gentoo comes close, but it can't "put back" and suggest changes and test cases to the original developer... That's the step that's slowing down development all around. It's the need for things like drivers and kernel modules to fix third- and fourth- levels of interaction... the best testing environment is the "real world" because there are far more combinations of programs out there than any one developer could ever hope to test... The ability to guess where a bug might be by looking at logs from ALL the compiled versions... and see what's breaking stuff... to reduce the reliance on "custom" distros, you need a sytem that can spot bugs that happen once per thousand or even ten-thousand users... The other advantage is that proprietary developers would be able to tap the same up-to-date pool for their projects... so they wouldn't be pertually "out of the loop" dragging things down!!
and
So in other words it takes both a secure position and money to make things happen in the OSS world. No vow of poverty there.
I'm not a Linux developer, but isn't this just another SourceForge.net?
With all of the fallout with BitKeeper and the need for a Version Control System, has anyone looked at a new filesystem with would natively support this? Not only would software development be great with it, but back-ups would be a breeze.
Could name it VCFS (Version Control File System)...has anyone used those letters before (amid the NTFS, NFS, SMB, VFAT file systems)?
The big draw for Ubuntu of course would be that the main version is always free... That means they have to have an idea to make money without per-seat fees... i.e. you'll download the free version for all your desktops and they'll make profit from helping you write custom software? I could see it spun as they help your business with tools and your payments directly help the community... i.e. schools, employees, etc. when it's something you'd pay for anyway.. I'm interested to see where he takes this!
They are now propriatary software developers, and it is immoral to support ubunto because of it, unfortunatly.
You need to understand that OSS licensing is merely a set of terms in a transaction. If the terms are suitable for you, fine, if not, fine, but it isn't a moral dillema at all.
It is entirely possible to argue against closed standards without using the morality card (which really makes you look immature, BTW). What about investment protection? What about risk mitigation? What about cost savings? What about interoperability?
I could rant for days on end against Microsoft, for example, and not once say they are immoral. While they certainly have very poor ethics, I'm not convinced it comes down to fire-and-brimstone morality, yet.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
Will it result in inconsistant translations? I translated few of the item's and already noticed how somebody's translation differed from what I would've written. The Gnome finnish translation team does provide a dictionary for english > finnish ( http://www.gnome.fi/cgi-bin/sanakirja.cgi ) but will everybody translating from english to finnish use it? How about other languages? Who get's to decide which term to use in the actual release?
Distributed this and that is great. But a lot of projects are hosted on systems like sourceforge, they have their own tracking features. And most distributions also have their own trackers and what not.
What we need is an OPEN STANDARD that everybody want's to integrate into their system so it can truely be distributed instead of going to yet another site that doesn't want to play along with the other kids.
e.g.
> reportbug SomePackage
should send a bug to the debian bug tracking software, which in turn will signal the the other bug trackers that are associated with the package.
Why exactly are Ubuntu attempting to recreate the wheel here?
This has already been done by Specifix / Foresight Linux (www.foresightlinux.com)
These distros use a system called Conary, developed in part by the guy behind RPM, and the idea of Conary is to offer distro independent management.
Troves can be shadowed between distros, so you can create a distro easily by shadowing a "parent" distro and picking and choosing your updates.
It stores source code and changesets, so all you Gentoo ricers can do an emerge from conary, and the rest of us sane people can just pull up the changesets that give the system instructions on what to change to install package "xyz". The other beauty of changesets is that it gives a degree of distro neutrality.
Bizarre that Ubuntu want to reinvent the wheel rather than contributing to something that already exists.
Sunday you're Thinking Different, Monday you're a huge tool, paying too much and waiting to think like everyone else.
That idea has been tried numerous times before and it doesn't work well. Most things do not need to be versioned, or versioning them is harmful to system performance. The things that do need to be versioned require a lot more functionality than a file system can provide on its own.
At this point, it is doubtful to me that anything remotely related to versioning or metadata belongs anywhere near the kernel. But if it does, then the right way to provide it is via user-level servers (like Plan 9), not by hacking stuff deep into the bowels of the file system. Simple versioning, like the kind that has been provided in file systems, could be safely, transparently, and simply provided in the C library, in a way analogous to the way Emacs does it.