Hi, Daniel Carosone wrote: > That's kind of my point about the separate date certs we have > currently. You propose a mechanism whereby an out-of-order or > future-dated date cert would be considered invalid and untrusted -- > instead of now where it's trusted but essentially ignored (other than > for display and as a selector target). It doesn't seem like much > benefit, which is why I think it only becomes interesting when we're > looking at signing-dates on certs that make other kinds of statements > (like asserting branch membership).
Looks like we are just approaching the problem from different angles. I've been analyzing what's required to convert to atomic certs (or super-certs or whatever you'd like to call it). I'm thinking that we need to clean up our current certs to be able to convert them. > I could attach a special netsync-instruction type of cert that says > "don't send until date X", or I could attach a branch cert that says > "add to branch Y after date X" (and then rely on netsync branch > pattern selection. In practice and in general, I don't think this > really cuts it as a solution. In particular, I probably do want to > sync these revisions in a limited context (such as between my own > machines just for backup purposes).[*] Secondly, the decision for > when I'm ready to publicise that work is rarely date-based. I fully agree here. I'm in the need for such a feature often enough as well. But it looks like it depends on atomic certs *and* policy branches, so we are not likely to get that feature in the near future, IMO. :-( > To me, a better use for "valid-from" might be on testresults and job > scheduling. Say I want to automatically build downloadable snapshots > for multiple architectures of the most recent revision to have passed > a set of tests, but the scheduling of when during the day to start the > build depends on some complex pattern that I can't easily represent in > the multiple platform's scheduling tool. So, I make the build depend > on a summary test cert, that passes if all the other prerequisite > tests pass. As those test certs come in, I issue summary test certs > for revs during the day that have passed the set - and I future-date > them for the time this evening that the build should start. The build > slaves just check on a basic interval for new work. When the cert > validity time comes around, the build slaves suddenly see all the > summary certs for the day, and build the latest (by ancestry) rev with > a valid cert. Hm.. do we really want to dig into scheduling of build bots? I don't quite think that fits the scope of monotone. Certainly not yet. > Oh, as a somewhat dumb use for a "valid-until" field: a suspend cert > for a head I want to come back to -- but not until next month. You can 'un-suspend' the branch at any time by simply committing a new revision. So I don't think this us an utterly needed feature. > Or another: a tag cert that names the current base for patch > submissions for the next quarterly integration branch. Next quarter, > the tag expires and a new one is made. Hm.. that might count. Although, doesn't policy branches provide a more flexible mechanism to do these things? (I.e. general purpose cert revocation, instead of only time based). > Or another: maybe I'm doing a ZipperMerge, with an explicitly-named > intermediate zipper branch in the middle; perhaps I expect to take a > day or two to progress through the merge. In any case, it's really > only the last few zipper merge certs that I care about - the current > central head, and whichever left or right node I next want to bring > in. I could set these certs to expire quickly, and hold off syncing > until then - if expired certs aren't sent via netsync, they no longer > need to be passed around the rest of the world. Again, sorry, but I don't think saving a few kbytes for these certs is worth the effort (and confusion) introduced by certs expiring by date. > [*] I have in mind a different mechanism for this, based on a concept > of key-based netsync communities (to mostly replace the current > netsync permission hooks), which I've never taken the time to > write down - in part because I haven't really thought about how it > intersects with branch policy, and in part because I'd really like to > think of a nice way to make it work for revision encryption too.. Sounds very much like something that could work together with policy branches, no? Regards Markus Wanner _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel