43 entries in 0.527s
ossabot: Logged on 2019-11-30 13:30:48 diana_coman: at any rate, the hour was spent: ~10 minutes figuring out the change and making it directly on my blog so that the results were clear; ~30 minutes for full vpatch process: retrieve+press current
v-tree to head; make code +
manifest file changes; test press of result & check + final sign; ~20 minutes for write-up + upload + overall final check.
diana_coman: at any rate, the hour was spent: ~10 minutes figuring out the change and making it directly on my blog so that the results were clear; ~30 minutes for full vpatch process: retrieve+press current
v-tree to head; make code +
manifest file changes; test press of result & check + final sign; ~20 minutes for write-up + upload + overall final check.
a111: Logged on 2019-05-03 03:18 Mocky:
http://btcbase.org/log/2018-11-24#1874402 << this suggests that each key holder can only host $key/gns at one ip address. And what about vpatch ordering and the
v manifest file? If i have an entry for archive.is and want to change that entry, I can't just make and sign a patch of my own, i have to patch on top of the 'consensus' press, otherwise
manifest won't match and can't press multiple heads. Am I wrong about how that works?
Mocky:
http://btcbase.org/log/2018-11-24#1874402 << this suggests that each key holder can only host $key/gns at one ip address. And what about vpatch ordering and the
v manifest file? If i have an entry for archive.is and want to change that entry, I can't just make and sign a patch of my own, i have to patch on top of the 'consensus' press, otherwise
manifest won't match and can't press multiple heads. Am I wrong about how that works?
☝︎☟︎ a111: Logged on 2018-09-08 23:31 mod6: Hi all, I wanted to get some review, on this
manifest file that would be introduced into trb. It would be placed inside the 'bitcoin' directory along the 'Makefile' and 'src' directories. It follows trinque's proposal here:
http://trinque.org/2018/06/02/v-manifest-specification diana_coman: asciilifeform, since your udp genesis is using the sha hashes + a "history" file I'm not sure: do you have something against the move to keccak + standard
manifest file for
v-trees?
mod6: After looking at PeterL's blogpost, was curious if there had been any consideration into if a
manifest file should grow up or down (i.e. newest change first, or newest change last in the file). This is purely a cosmetic thing, I suppose it would be up to the author too. Probably why trinque didn't touch on this in the post either
http://trinque.org/2018/06/02/v-manifest-specification/ phf: asciilifeform: well, i'm not sure what "spuriously bifurcated tree" means in this case, the goal was stated in the one of the posts, that i'm explicitly maintain two separate branches, that hinge on two separate
manifest paths. this is the kind of stuff
v is designed for neh? press to vdiff_sha_static to get one thing, press to vtools_vpatch_newline to get the other
a111: Logged on 2018-07-07 23:27 phf: i've been using vpatch/vdiff without full blown
v, because i can order the patches by hand (and there's now an explicit ordering provided by
manifest), and vpatch verifies the hashes for me. it would be handy if i could also press existing sha patches with `vpatch -a sha` or whatever
phf: i've been using vpatch/vdiff without full blown
v, because i can order the patches by hand (and there's now an explicit ordering provided by
manifest), and vpatch verifies the hashes for me. it would be handy if i could also press existing sha patches with `vpatch -a sha` or whatever
☟︎ mircea_popescu: point being, "blind"
v could exist that just puts in the patches as seen in
manifest, checks no sigs.
a111: Logged on 2018-06-26 17:45 phf: trinque: one reason i didn't include patch name in the
manifest is because patch name becomes a promise, unless you enforce it by tooling. i didn't want to go that way, but since current standard
manifest does include patch name, than perhaps
V ought to check the
manifest against the patchset. relatedly fully
manifest-based
v doesn't even need graph tooling, can presumably press according to
manifest's chain.
phf: trinque: one reason i didn't include patch name in the
manifest is because patch name becomes a promise, unless you enforce it by tooling. i didn't want to go that way, but since current standard
manifest does include patch name, than perhaps
V ought to check the
manifest against the patchset. relatedly fully
manifest-based
v doesn't even need graph tooling, can presumably press according to
manifest's chain.
☟︎ mod6: Perhaps we need to 1: Formally adopt the
manifest spec proposed by trinque, 2: build a
V that supports it.
ben_vulpes: "
manifest capabilities" are baked into all
V implementations
mod6: is his lisp version of
V to become the new defacto thing that has
manifest capabilities?
ben_vulpes: mod6: focus on the
manifest design, not the
v implementation linked in trinque 's post
mod6: that said, everything must be pretty much "firmly" in place with
V rules,
manifest, naming conventions, what have you, before I wanna move on that.
esthlos: trinque: I added a
manifest to my v_genesis vpatch. I'm curious, though, how these items (vtron,
manifest) become declared "standard", if ever
mircea_popescu: alright, plox trinque write a
v manifest specification, so it can be linked to for the future.
a111: Logged on 2018-05-01 16:26 mircea_popescu: trinque, what's your stance here, do you particularly want to implement a grapher /
manifest / generally fix a
v ? not really ?
mircea_popescu: trinque, what's your stance here, do you particularly want to implement a grapher /
manifest / generally fix a
v ? not really ?
☟︎ a111: Logged on 2018-05-01 06:55 mircea_popescu: is the
manifest issue fixed ? is the graphing done ? am i what, going to lose
v now because i'm too polite to yell, and left to your own devices you're just going to break it, permanently, obscurely, and forget about it ? or what's the fucking logic here.
mircea_popescu: is the
manifest issue fixed ? is the graphing done ? am i what, going to lose
v now because i'm too polite to yell, and left to your own devices you're just going to break it, permanently, obscurely, and forget about it ? or what's the fucking logic here.
☟︎ assbot: Logged on 22-12-2015 22:43:02; mod6: so i think jurov has a good question; if we don't drop the turdballs into
V, which we're not, and the
MANIFEST is the only thing in the 'shit' directory that is pressed out by '
V', where do the tarballs come from?
mod6: so i think jurov has a good question; if we don't drop the turdballs into
V, which we're not, and the
MANIFEST is the only thing in the 'shit' directory that is pressed out by '
V', where do the tarballs come from?
☟︎ mod6: <+mircea_popescu> the
manifest should live wherever the rotor.sh lives neh ? << I would argue that all of these scripts would live outside of bitcoin source
V tree.
mod6: this
Manifest we're talking about creating would need to fit somewhere in the directory structure of bitcoin itself, if it is to be '
v'-ified.
assbot: Logged on 25-09-2015 01:27:12; mod6: one possibility to publish releases in the future now that we have
V is to create a
manifest of
V patches and have the co-chairs sign the
manifest, as well as the patches.
mod6: one possibility to publish releases in the future now that we have
V is to create a
manifest of
V patches and have the co-chairs sign the
manifest, as well as the patches.
☟︎