ron minnich rminnich@lanl.gov writes:
one thing I don't much like are packages that require users to get a bunch of software and load it before they can get the package. I like to minimize barriers to entry, and we probably have all seen situations where to get package Y, you need to get package X, which doesn't work on your system Z due to conflicts with language/compiler A, B, and C.
darcs requires people to get a Haskell and build it. Not so sure I like this.
arch is a single C program but if we are really proposing changes I'd rather not end up with maintaining an RCS as part of the project, so I think the changes should go back into arch if they're really needed.
Agreed. Arch is at the maturity level now that it should be usable. But at the same time I expect a few tweaks along the edges would be nice. Have you seen me work on a project make changes and not push it back to the original developers? And a big part of what a distributed version control system does it that it makes this easier.
In the end, what does arch do better than bitkeeper?
- Merging, arch has several methods. - Branches, with arch you don't need multiple copies of your archive. - The License. The free Bk license requires at least your change history to be released, which for early development can trivially violate NDAs, which is a big concern on the LinuxBIOS side. The free Bk license forbids working on competitors to bk. - Distribution. All you have to do to export an arch repository for all the world to see is to point an ftp or http server at it's directory. - Renames. Since arch does not revision control the files individual but a change at a time you don't get into awkward situations with the SCCS version control file named differently than the file itself.
I'd like to understand that. bk is used for the Linux kernel itself, as well as the infiniband source tree, which indicates to me that it is fairly robust. bk has the same problem as darcs and arch, however: users will need to get these and get them working before they can get etherboot/linuxbios.
Partly that is what releases are for, and we need to make those on the LinuxBIOS side. The only arch dependencies are diff, patch, tar, and C. And there should be prebuilt packages along shortly.
As for the Linux kernel half the developers don't use bk for lots of things including at the moment Andrew Morton the 2.6 maintainer. Getting arch to the point where the majority of the kernel developers can use it productively is likely what will require the most development effort at this point.
But it is possible at this point with almost no knowledge of arch to take a raw repository to extract your changes with patch and tar.
The infiniband project fixed this by exporting to sourceforge. But sourceforge was failing again for me today, so depending on that seems a mistake.
Yay they responded to my complaints. :)
Also there is also a different level of care you need to give to an open source tool and a tool with a more restrictive license. With a more restrictive license, some people will never use the tool. With an open source tool the only concern is the tool painful to setup.
The 'arch' web pages have a few 'we need help' items, which leaves me somewhat concerned.
arch is maturing quickly and has an active developer community. With tla 1.1 out arch does not appear to be lacking anything significant. The core looks fairly solid but arch is not so old there still won't be itches to scratch.
I am in the middle of a fairly in depth technical review. And I am going to make darn certain there we need missing before I seriously suggest switching over. I have what two sets of criteria I am using to evaluate arch, immediate needs, and expected long term needs. So far I have seen nothing in the immediate needs category missing. For the long term needs I have seen a few possibilities.
The best analogy I can think of is cluster applications like mpi. It is trivial to scale to 20 or 30 nodes. Getting an implementation that works and scales to the 1000s of nodes is a bit more work, even when there is a good design that support it. There are always issues at the large scale you can't see at the small scale.
Arch is that way right now. The design looks good. It runs fine on small projects but it has not been pushed to the large scales yet.
Is the motivation here perceived problems with CVS (not hard to imagine) or with sourceforge (also not hard to imagine).
CVS, sourceforge, and the fact that there are currently at least 4 repositories for the freebios2 tree alone. And for LinuxBIOS that inherently makes sense. With a distributed source code control system we can continue working the way we are working now and have the tools to merge the repositories.
Basically with a distributed version control system everybody and their brother can have commit access. They just can't commit to the official branch.
On the etherboot side the only real problem I have is by checking in the repository multiple times getting code from one repository to another is a pain. As evidenced by the fact that EFI support still has not made it into the 5.2 and 5.3 branches yet...
Eric