gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: arch performance with large trees


From: Paul Mundt
Subject: Re: [Gnu-arch-users] Re: arch performance with large trees
Date: Thu, 10 Feb 2005 14:07:34 +0200
User-agent: Mutt/1.5.6i

On Thu, Feb 10, 2005 at 11:19:31AM +0000, Catalin Marinas wrote:
> Sad, but you can't do anything about it. I noticed yesterday that you
> can't even get the full patch from bkbits.net using the BKrev number
> for some changesets.
> 
Do you have an example of this, this is somewhat in contrast to Larry's
argument that everything is available via bkweb with the exception of BK
metadata. It would be good if this issue was raised instead of the
mindless political posturing that seems to dominate these threads.

> > I fear that _any_ successful attempt to wring useful meta-data out of
> > public sources will be met by similar attempts at obfuscation.
> 
> I fear the same.
> 
This issue was brought up before as well, it seems not enough people care
about this over the benefits that BK provides to the few.

We were using BK for sh64 and finally managed to get off of it with
minimal data loss (note that this wasn't a political move, there were
just some issues of BK working against us that we weren't overly fond of,
tla has worked well for our purposes since then.. plus I was already
using it for sh, so it was a natural choice), openbkweb and some other
things were excellent starting points for this. Then again, our merge
topology was much more isolated and simplistic then Linus's tree, though
we did end up spanning multiple trees each with their own rather
different merge topology.

> > [What I find _really_ amazing is that the hordes on the lmkl continue
> > to vociferously defend Larry with regard to this sort of thing, and
> > pile on the insults for anybody decrying his behavior.]
> 
> I understand that some of them are fed up with this kind of long
> threads but they just contribute to the noise (and make Larry more
> self-confident). I'm pretty sure that if next month Torvalds would
> give up BK, the same people would start complaining about this tool.
> 
This goes both ways. Many of these same people were out there levelling
personal attacks against Larry with no technical validity when the issue
of using BK was first brought up, many of these same people are now on
the other side of the fence. Personal attacks on either side are
completely unwarranted, pointless, childish, and usually just make the
side issuing them look stupid (though many of these people need no help
whatsoever in this department). If there is no technical issue to base a
discussion on then save yourself and everyone else the bandwidth, google
never forgets.

It's also worth noting that some of the most vocal people in these
threads produce the least amount of code, so most of this is killfile
fodder. No doubt another one of these threads will end up on slashdot or
kerneltrap and then there will be a new burst of opinions not encumbered
by facts fueling the threads again.

Attachment: pgpVbCyLE0MPK.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]