Jordan Mendelson wrote:
> If a solution to kernel source management is to be found, it must
> incorporate
> all the same features that the current system allows. There are four
> distinct
> pieces to the kernel development process:
>
> § Source Repository
> § Bug Reporting & Tracking System
> § Patch Submission & Peer Review System
> § API Documentation Submission
To add some other points:
*the traditional solution for bugfixes in OpenSource is "take the newest
version from the stable tree" - so the backup of older versions is
definitely _no_ problem. Only few scientists will be interested in
five-year-old Linux versions.
*Especially the Linux sources are mirrored on hundreds of servers all over
the world, so if one server eats the files on it we can restore by
catching any copy out there. If the main server (at Linus' side) crashes
he still can catch a copy from somewhere and then ask the developers to
resend their patches. Crashes are unlikely (under a stable Linux server)
so this case will be very rare and the manual solution is acceptable.
*The mirror servers have quite large disks (remember: diskspace is cheap
these days) - the size of the local image is no problem.
*Many developers have only slow and expensive Modem-lines to transfer and
update theyr database. The questions are:
- how much does the system compress my data (or even: may I plugin newer
and better compression algorithms)
- how much overhead does the transfer need (counted in bytes transferred
through the net, not bytes stored on local/remote harddisk; call it
compression of metadata)
- may I chose in which changes I am interested and which not to transfer
(eg. Alan may decide to transfer everything from Linus and some other
trusted users but he might want to review a short description of the
patch for those patches from everyone else)
*OpenSource is less hierarchical than commercial development - so it is
necessary to get good (easy to understand) views of the various source
trees and patches. And we would need flexible tools to (un)merge and
change patches and to move whole sets of patches from one tree to
another.
*Many developers will decide to hold their own local tree of patchsets. So
we need a tool with a kind of access rights and distributed
administration. The base server for the linus-tree will be another one
than the base server for ac or davem. And the base servers definitely do
not want to mirror my local tree. But I will want to crossreference
patches from the linus-tree into my own.
*Most developers and most mirror sites don't have the money to buy $1000
software (or more expensive), so it should be either cheap enough or
OpenSource. And they don't need commercial support, they need a good
README - they still are experts.
*Bugreports become difficult for Linux, because a) more and more newbies
send bugreports without knowing what is important and b) there are many
experts which just don't know enough about the kernel (because they are
busy with other projects) to send excellent reports. So this tool (or a
connected one) should be able to force the user to enter all important
data (by asking appropriate questions) and then redirect the report to
the right forum/developer.
*Most important: Linux changes in source _and_ in organization (with every
feature added to the kernel a new group evolves and with every
restructuring the responsibilities change). So the system should be very
changeable - what means it should last only few weeks till there is a new
feature in it. I know that any OpenSource project has this ability (if
the maintainer disappeared or refuses to change it - I can ask anyone
else to do that).
We talk about a really _big_ OpenSource project with really _many_ backups
all over the net. So don't talk about hypothetic cases where all the
servers crash or some nifty admin refuses to give me the backup tapes.
What is needed is a way to handle the source management for Linux and
nothing else. My simple (but hard to answer) questions are these ones:
*Which of the above abilities does BK have and which does Aegis (or any
other free tool) have?
*Which do they not have and how long would it take to fix that?
*Now the heaviest: does it become easier and faster to do this work with
that tool? Or does it only help to solve the problems which we wouldn't
have without it?
BTW: Larry, if you can't offer really cheap licenses to the mirror sites
and developers then be quiet from now on, we talk about OpenSource
development not about rich firms.
happy thinking,
Konrad Rosenbaum
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/