James Denholm wrote: > Felipe Contreras wrote: > > James Denholm wrote: > > > On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote: > > > > (...) I would venture to say you have never made a package in your > > > > life. > > > > > > And you have, Felipe? Let us see the years of experience you surely have > > > in the field. > > > > As a matter of fact, yes I've written many packages, for Debian, Fedora, > > ArchLinux, and others. Even Windows installers. > > I'd hardly say that a few PKGBUILDs count. I've written some myself, not > hard to do. Not hard, but Junio clearly hasn't done so. > That said, if I had realised you were going to discuss such a trivial > thing - _making_ packages rather than _maintaining_ them in a repo - I'd > have dismissed your statement as mere idiotic vitriol. Why would anybody write packages and not maintain them? Of course I'm talking about maintaining packages. > Do you honestly think that Junio has _never made a package?_ Never, on > any of the systems he's ever touched, run makepkg or debuild or > whathaveyou? I didn't say _build_ a package, I said _write_ a package. And of course I mean a significant package, that other people use, and as such needs to have some maintenance. > I could be wrong here, but I'm fairly sure that Junio is a *nix software > developer of some kind or another. You know, given that he's the > maintainer of git, kinda might be the case. And I really doubt that any > *nix dev, _anywhere_, could have _any_ sort of success without looking > sideways once or twice at a package builder, given that pre-release > homebrewing of expected packages is only an absolutely critical part of > testing. > > Come on, man. Don't be silly. You are the one being silly, looking at a package builder doesn't give you any insight about the way packaging is done in distributions. If Junio has or hasn't done so is totally unimportant. You are just talking about completely irrelevant stuff, so I'm going to ignore your points about the matter. > > But that's a red herring. Even if was the worst packager in history, > > that doesn't make Junio's decision any more correct. > > No, but it would render your bizarre, tantrum-like accusations as > generally baseless. I mean, I don't think anyone actually puts weight on > them anyway, but hey, never hurts to shine a spotlight on nonsense. > > > > > The fact that you think packagers of git would simply package > > > > git-remote-hg/bzr as well is pretty appalling. > > > > > > It's not an outlandish thought, in fact, I'd suggest it as probable - > > > provided that they find the projects to be stable and of high quality. > > > > Do you want to bet? > > Not a betting man. However, ignoring that for a moment, I doubt we'd be > able to agree on checks and balances for the case where > git-remote-hg/bzr were rejected due to the code being of poor quality or > unstable. So no, I won't bet, because you hold your own work and > opinions as sacrosanct and infallible. It is not poor quality or unstable, Junio said so himself when he graduated them to the core. I suppose you don't trust Junio's opinion either. > > > You, or someone else, might have to tap them on the shoulder and play > > > nice to _ensure_ they know about them (after all, we all know that > > > packagers _never_ read READMEs, do they), but you're capable of that, > > > I'm sure. > > > > In my experience packagers scratch their own itches, and if > > git-remote-hg/bzr are not their itch, I don't see why any amount of > > nice poking would make them package them. Some other packager would have > > to do it, not the Git packagers. > > If there's a demand, Felipe, and the build process is sane, I can't see > why they wouldn't. Your failure of foresight doesn't change what will actually happen in the future. Moreover, your argument that follows is a straw man, I argued that the original maintainer of the "git" package wouldn't do the "git-remote-hg" package, you didn't address that at all. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html