2008/4/3 Jameson Chema Quinn <[EMAIL PROTECTED]>: > 1. for "version threading", what we need for an activity is not a claim like > "I am a version of activity ID XXXX" but "My prior version was XXX and the > one before that was YYY". What is the granularity of XXX and YYY? I'd say, a > hash on the activity.info would be fine - that way, version changes are > automatically picked up, but not every change in the source code. If, later, > activity.info picks up some elements which are too volatile (thus leading to > unnecessarily-long geneologies), we could filter those out before hashing. > Note that this is totally orthogonal to whether an activity version is > signed by the original devteam, and yet allows for forks to become > independent without fighting over who is the "real pippy > org.laptop.XYZ1FFE3". I submit that merges are unnecessary.
I think this is overkill. A single unique tag, randomly generated, suffices to identify all applications which claim to be a version of "Activity X". Let's make it As Simple As Possible. > 2. If we get the version threads right, then the auto-update on sharing > becomes safer. I still don't understand who has to sign to avoid a break in > the ownership chain - I would presume a given set of maintainer/developers, > and I would presume that there would be some way for the group to change > over time - but those details can be worked out. You're still thinking that the "signing key" corresponds to a *person*. It doesn't. It corresponds to an *activity*. With the first version of Pippy, cjb generates a new key. The "chain is unbroken" as long as new versions of Pippy continue to be signed with that key, whether because cjb gives the key to a new maintainer, entrusts it to a group, or because he's making them himself. When cjb releases Words, it has its own unique "signing key". Replacing an old key with a new key would be interesting, but it adds a lot of unnecessary complexity. Better (to me, for the moment) to just let the chain be broken when that becomes necessary. --scott -- ( http://cscott.net/ ) _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
