In article <39BF8FF8.7CB22200@inet.com>,
Eli Carter <eli.carter@inet.com> wrote:
>Mitchell Blank Jr wrote:
>> Daniel Quinlan wrote:
>> > "Version" - the base kernel version. For example, "2.4.0-test8-pre1".
>> > The web page will list valid version strings.
>> Ideally this should be overridable for patches marked experimental, since
>> they might be to some modified kernel. Of course you wouldn't do an
>> test for applyability :-)
>
>Yes you can. Use the "Requires" identifier to add all the previous
>patches first. But if the patch for the prerequisite modification isn't
>available, what is the point of submitting the patch?
If both patches are submitted at near the same time, the prerequisite
patch may not arrive until after its dependents; in that case, you'd want
the patch tracking system to hold on to the dependents until the
prerequisite showed up.
Consider the following scenario:
developer A makes a patch P.
developer A sends a copy of P to the patch tracking system.
developer A CC's a copy of P to developer B in the same email.
the copy of P for the patch tracking system enters a Microsoft
Exchange email server during a Visual Basic Scripting
Host virus incident, and is delayed by 48 hours.
developer B fixes a bug in P, making patch Q.
developer B submits Q to patch tracking system with
"Requires: P" (assuming B has some identifier for
P; see below for ideas on how to do this).
the patch tracking system receives Q from B.
To cope with the scenario outlined above, in addition to a numeric ID
assigned by the patch server, the server should support reference to
a patch by the MD5 hash of the patch text, or by message-IDs in email
headers when patches are submitted. When the patch server can
unambiguously translate one of those into a locally unique ID for the
patch, it should do so, but leave the original specification in its
internal database so that the patch can be meaningfully exported again.
I'd recommend using the MD5 hash (ok, SHA-1 if you insist) of the patch
text (i.e. the stuff you actually input to 'patch') as the actual
patch identifier, and make the other ID forms search queries that
ultimately resolve the MD5 hash. This has the advantage of allowing
for a single globally unique identifier for all patches even if there
are multiple kernel patch servers operated by different groups.
-- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:26 EST