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

Re: ash splitting and Herbert Xu (Fw: Bug#97310 acknowledged by developer (Re: Bug#97310: More package-splitting stupidity))

On Sun, May 13, 2001 at 07:48:27PM -0700, Mike Fedyk wrote:
> On Sun, May 13, 2001 at 01:17:17PM -0700, Aaron Lehmann wrote:
> > On Sun, May 13, 2001 at 06:57:57PM +1000, Daniel Stone wrote:
> > > Your response to 96854: "Go away."
> > > Your response to 97310: "Piss off."
> > > Who are you telling to grow up? You have rudely told me to leave, without
> > > giving any technical justification, or any other matter than rudely telling
> > > me to go away. What's next, "Get fucked."?
> > > 
> > > I don't respond to bug reports with "Fuck off.", I actually work with the
> > > reporter, at the time, to get the problem solved. That's how it's done. You
> > > know, the mature way.
> > 
> > Yes, Herbert, you really could consider using the "wontfix" tag along
> > with a polite explaination. Just because Daniel is an obnoxious troll
> > is no excuse to ignore valid logic.
> > 
> What happens when something like this stays in the BTS?  Herb looks like he
> is refusing to fix a package, when he is already taking action on the issue.

What action?
> The problem is two fold:
> DS comes with a bug report telling HX to undo the split that he has spent
> his time on, without asking why it was done in the first place.  Maybe HX
> knows something that DS doesn't?

Hmm. If HX did, then HX was witholding in "kernel-{image,headers} package

> Then HX gets annoyed with DS and tells him to "Fuck Off".

Actually, it was "Piss off." for ash, and "Go away." for the kernel one. He
has told me to "Piss off." before in BTS somewhere. "Fuck off" was a
hypothetical, just to clear it up.

> Really, I think DS is the _First_ to do wrong.
> Whenever you're dealing with someone else's project, and time; address any
> changes very softly, and _suggest_ changes, not demand.

That's what "kernel-{image,headers} package bloat" was.

> Really, what does one more package hurt?

When this package is as large a scale as the kernel image and headers, it
matters in the form of caned mirrors[1].

> Is there some field that contains splitting information for large package
> sets?  Detailing such issues, that -doc or lib don't already show?

Um, when I split my package, I got help from a few friendly faces (hi, mhp!)
on IRC.

[1] See my reply to Hamish a little further down in the thread.

Daniel Stone

Reply to: