Re: [PATCH] remote-helpers: point at their upstream repositories
- From
James Denholm <nod.helm@gmail.com>
- Date
- May 18, 2014, 01:24 UTC
- Message-ID
- <20140518012423.GA31087@debian>
- In-Reply-To
- <5376f27b74d9f_66768eb3048f@nysa.notmuch>
Felipe Contreras wrote:
Show 10 quoted lines
> 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.
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.
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 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.
> 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.
Show 7 quoted lines
> > > 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.
Show 9 quoted lines
> > 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. Package maintainers are aware they provide a service to their distributions. If you really want, poke them _with_ the majority of the necessary work done, hand them the PKGBUILDs/whathaveyou yourself. Pre-scratch the itch if you really feel they won't care.