[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: adding a modification timestamp to the
From:       Brian Harring <ferringb () gmail ! com>
Date:       2010-01-18 15:42:09
Message-ID: 20100118154208.GD5008 () hrair ! c ! nixle ! com
[Download RAW message or body]


On Sun, Jan 17, 2010 at 11:09:07AM +0000, Ciaran McCreesh wrote:
> 2010/1/17 Christian Faulhammer <fauli@gentoo.org>:
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> >  As much as you love to have the new and shiny VDB2, it is far off.
> > Prototyping and drafting implementations would be great to have some
> > base where we can discuss on (in a civil manner).  So having this
> > timestamp would be a good way to prepare a sane migration path.
> 
> No, it wouldn't. Brian's proposal a) would be of no use whatsoever for
> VDB2 migration, and b) would not be used by VDB2. Having a *decent*
> cache validation mechanism is a good idea; having a half-baked one is
> a waste of time.

Propose something, or shut up frankly.

If all you're going to contribute is "it's half baked" claims, you're 
wasting folks time.  You've had a couple of months of time to 
counterpropose something- back it up with a proposal or be silent 
please.

As is, quite a few folk see how experimental vdb2/vdb1 synchronization 
can be done w/ this timestamp- your claims thus far that it won't work 
seem to boil down to "but not everyone will update the timestamp".

Which gets right back to why I'm elevating this to the council to 
*force* PMS to include this, thus force the holdout (paludis) to 
update the timestamp thus invalidating your cyclical claim.

Either way, you find issues w/ the proposal you're more then free to 
propose something else- hell, I'll even listen if it's sane.

What I won't do is sit around and listen to you whinge about the sky 
falling or that I/others are being idiots via not going 
the route *you* want and standardizing caches across all the managers- 
as I said, you want that functionality *you* propose it.

About the only thing paludis shares w/ portage/pkgcore is a potential 
installed-pkgs-cache of pkg names; this isn't incredibly useful 
frankly (it's nice for cold cache searches but that's it).  The cache 
usage between portage/pkgcore vs paludis differs a fair bit, as such 
trying to define an LCD vdb cache is pointless.  Further it's not what 
I'm after and you've already opposed adding caches to vdb1 w/in the 
ticket- you want something beyond this, then go nuts.


Either way, that's pretty much the bar I'm sitting for continuing 
discussion of this w/ you- either it's going to be productive w/ 
specific claims (no more of this vague handwaving bullshit) and moving 
towards accomplishing something or I'm just going to continue 
ignoring your disruptive behaviour, instead getting majority PMS 
consensus and then pushing it up to the council bypassing your 
shenanigans.

It's not how things should be done, but it's about the only way to get 
something done when you dig in and go cyclical.  Wish it weren't that 
way, but I've more interest in progress then playing games w/ 
folk looking to be poisonous.

Seriously, if you can't even be bothered to spell out your claims in 
full or layout a counter proposal, instead spending your time 
screaming "nyah nyah it won't work!" as you did for prefix, I'm not 
having it.

There are better uses of folks time frankly, and users deserve 
functionality over daft pissing matches.

Be productive and constructive, or be ignored pretty much.
~harring

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]