That's bitkeeper, bitmover is a company, but whatever...
: 3 repositories, under distinct control; 3 for each of odd and even minors.
:
: 1 repository contains the "production" release, the 2.0.33, etc.
: 1 repository contains the "pre" release, beta stage, stuff that's experimental
: all been tested.
: 1 repository contains the "alpha" release, the 'not neccessarily working'
: code. This is where bug fixes and new code get input into the system.
That's all doable.
: The other part, which may or may not be neccessary, is an SQL database and
: web frontend, which contains the patch sumitted, submittor, release, description,
: subsystem affected, localized changes (files changes), and any other stuff.
The current plan is all of this information is part of the revision control
system.
: The above is a project I'd be willing to work on in my spare time.
If you wanted to add a database for browsing the system quickly, that would
be cool, as would web stuff.
: This means that people will have to change their way of
: patching things.
Not that much, however. The only difference is that they'll have a revision
control system and they have a new command which generates the patch for
them. Patches will look pretty simiarl to what they look like now, the
difference is that they will contain more information like the revision
commentary and any other meta data.
: Patches will comprise 5 files or less, and ony affect a localized section of a
: subsystem (no multi-subsystem patches).
OK, so this is a policy decision, right? Because there is no such limit
in what I'm doing, I think you are basically saying "big patches are
probably bad". I don't have an opinion on that one way or the other,
that's policy. In this system, I'm Mr Mechanism...
-
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/