| 1 |
On Sun, Jan 17, 2010 at 11:09:07AM +0000, Ciaran McCreesh wrote: |
| 2 |
> 2010/1/17 Christian Faulhammer <fauli@g.o>: |
| 3 |
> > Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>: |
| 4 |
> > As much as you love to have the new and shiny VDB2, it is far off. |
| 5 |
> > Prototyping and drafting implementations would be great to have some |
| 6 |
> > base where we can discuss on (in a civil manner). So having this |
| 7 |
> > timestamp would be a good way to prepare a sane migration path. |
| 8 |
> |
| 9 |
> No, it wouldn't. Brian's proposal a) would be of no use whatsoever for |
| 10 |
> VDB2 migration, and b) would not be used by VDB2. Having a *decent* |
| 11 |
> cache validation mechanism is a good idea; having a half-baked one is |
| 12 |
> a waste of time. |
| 13 |
|
| 14 |
Propose something, or shut up frankly. |
| 15 |
|
| 16 |
If all you're going to contribute is "it's half baked" claims, you're |
| 17 |
wasting folks time. You've had a couple of months of time to |
| 18 |
counterpropose something- back it up with a proposal or be silent |
| 19 |
please. |
| 20 |
|
| 21 |
As is, quite a few folk see how experimental vdb2/vdb1 synchronization |
| 22 |
can be done w/ this timestamp- your claims thus far that it won't work |
| 23 |
seem to boil down to "but not everyone will update the timestamp". |
| 24 |
|
| 25 |
Which gets right back to why I'm elevating this to the council to |
| 26 |
*force* PMS to include this, thus force the holdout (paludis) to |
| 27 |
update the timestamp thus invalidating your cyclical claim. |
| 28 |
|
| 29 |
Either way, you find issues w/ the proposal you're more then free to |
| 30 |
propose something else- hell, I'll even listen if it's sane. |
| 31 |
|
| 32 |
What I won't do is sit around and listen to you whinge about the sky |
| 33 |
falling or that I/others are being idiots via not going |
| 34 |
the route *you* want and standardizing caches across all the managers- |
| 35 |
as I said, you want that functionality *you* propose it. |
| 36 |
|
| 37 |
About the only thing paludis shares w/ portage/pkgcore is a potential |
| 38 |
installed-pkgs-cache of pkg names; this isn't incredibly useful |
| 39 |
frankly (it's nice for cold cache searches but that's it). The cache |
| 40 |
usage between portage/pkgcore vs paludis differs a fair bit, as such |
| 41 |
trying to define an LCD vdb cache is pointless. Further it's not what |
| 42 |
I'm after and you've already opposed adding caches to vdb1 w/in the |
| 43 |
ticket- you want something beyond this, then go nuts. |
| 44 |
|
| 45 |
|
| 46 |
Either way, that's pretty much the bar I'm sitting for continuing |
| 47 |
discussion of this w/ you- either it's going to be productive w/ |
| 48 |
specific claims (no more of this vague handwaving bullshit) and moving |
| 49 |
towards accomplishing something or I'm just going to continue |
| 50 |
ignoring your disruptive behaviour, instead getting majority PMS |
| 51 |
consensus and then pushing it up to the council bypassing your |
| 52 |
shenanigans. |
| 53 |
|
| 54 |
It's not how things should be done, but it's about the only way to get |
| 55 |
something done when you dig in and go cyclical. Wish it weren't that |
| 56 |
way, but I've more interest in progress then playing games w/ |
| 57 |
folk looking to be poisonous. |
| 58 |
|
| 59 |
Seriously, if you can't even be bothered to spell out your claims in |
| 60 |
full or layout a counter proposal, instead spending your time |
| 61 |
screaming "nyah nyah it won't work!" as you did for prefix, I'm not |
| 62 |
having it. |
| 63 |
|
| 64 |
There are better uses of folks time frankly, and users deserve |
| 65 |
functionality over daft pissing matches. |
| 66 |
|
| 67 |
Be productive and constructive, or be ignored pretty much. |
| 68 |
~harring |
Archives