Re: [PATCH] remote-helpers: point at their upstream repositories
Felipe Contreras writes: > Junio C Hamano wrote: >> Felipe Contreras writes: >> ... >> > So to make it clear, I now request that you do: >> > >> > 1) Remove all the code. >> ... >> I'll do that, but just one thing to make sure---do you want the >> helper to exit with status 0? > > It doesn't matter; if the remote helper doesn't respond to the commands > transport-helper exits with 128. You're right. >> > 4) Re-add the following release note: >> > >> > * "git push" via transport-helper interface (e.g. remote-hg) has >> > been updated to allow forced ref updates in a way similar to the >> > natively supported transports >> >> I am not sure if this one is consistent with 1), as remote-hg will >> no longer be with the release. > > Remove '(e.g. remote-hg)', the rest still applies. True enough. I was already deep in today's -rc4 tagging before this exchange, so it may be a while until the result is pushed out, but as far as I know the helpers are now stubs, and README no longer says "a random version that will go stale is kept here merely for convenience". As additional topics that touch contrib/remote-helpers/ need to be reverted from 'next', the final pushout may take longer than usual. We'll see. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Johan Herland wrote: > On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty > wrote: > > On 05/19/2014 11:31 PM, Junio C Hamano wrote: > >> Felipe Contreras writes: > >>> Where is git-imerge packaged? > >> > >> I didn't see it on the archive the said Ubuntu box slurps from, but > >> I did not check all the other distros. > >> > >> Michael, do you know what distro folks are doing with imerge? For > >> the purpose of this thread, "I do not follow distros, and I do not > >> know" is a perfectly acceptable answer, but it would be very > >> relevant if your answer is "I suggested these distros to include it, > >> but so far they have been uncooperative and I haven't had much > >> success". > > > > I haven't heard of any Linux distros that have git-imerge packages. I > > just searched the package archives for Debian, Fedora, Gentoo, and Arch > > without finding it. > > FWIW; someone has made an AUR package (a user-contributed Arch package > recipe) for git-imerge: > https://aur.archlinux.org/packages/git-imerge-git/ That doesn't say much. Anybody can put packages there, and it has a single vote, which suggests not many people use it (if any). -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: > Felipe Contreras writes: > > >> Let's try this in a different way, as I sense there is a > >> misunderstanding somewhere about your "wish". > >> ... > > No, I already said I do not want the code removed from v2.0, that's why > > I sent patches that simply added a warning, and I specifically said > > those were for 2.0. > > Yeah, I think there are mails crossing. I sent that "different way" > way before I read your "already said" happened. > > > So to make it clear, I now request that you do: > > > > 1) Remove all the code. > > > > Since my patches were removed from the list, here's an updated patch > > that applies on top of 'master' > > > > https://github.com/felipec/git/commits/up/remote/remove > > I'll do that, but just one thing to make sure---do you want the > helper to exit with status 0? It doesn't matter; if the remote helper doesn't respond to the commands transport-helper exits with 128. > > 4) Re-add the following release note: > > > > * "git push" via transport-helper interface (e.g. remote-hg) has > > been updated to allow forced ref updates in a way similar to the > > natively supported transports > > I am not sure if this one is consistent with 1), as remote-hg will > no longer be with the release. Remove '(e.g. remote-hg)', the rest still applies. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Felipe Contreras writes: >> Let's try this in a different way, as I sense there is a >> misunderstanding somewhere about your "wish". >> ... > No, I already said I do not want the code removed from v2.0, that's why > I sent patches that simply added a warning, and I specifically said > those were for 2.0. Yeah, I think there are mails crossing. I sent that "different way" way before I read your "already said" happened. > So to make it clear, I now request that you do: > > 1) Remove all the code. > > Since my patches were removed from the list, here's an updated patch > that applies on top of 'master' > > https://github.com/felipec/git/commits/up/remote/remove I'll do that, but just one thing to make sure---do you want the helper to exit with status 0? > 4) Re-add the following release note: > > * "git push" via transport-helper interface (e.g. remote-hg) has > been updated to allow forced ref updates in a way similar to the > natively supported transports I am not sure if this one is consistent with 1), as remote-hg will no longer be with the release. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >>
> >> After looking at the reverse-depends list of packages, my faith is
> >> strengthened in that the Git ecosystem is truly maturing and useful
> >> third-party plug-ins will be picked up by distro packagers.
> >
> > Where is git-imerge packaged?
>
> I didn't see it on the archive the said Ubuntu box slurps from, but
> I did not check all the other distros.
I will help you: it's not packaged anywhere.
> > Do you want to bet? Nah, you don't *ever* want to accept you were wrong,
> > even you clearly where.
> > ...
> > This is what's going to happen: there won't be an official git-hg
> > package for *years*, if there is ever one. That is my prediction based
> > on all the available evidence, I am willing to stand by it and accept I
> > was wrong if it proves otherwise.
> >
> > Are you willing to stand by your own decisions?
>
> If I understand correctly, you have made and you do maintain some
> packages and as an insider, you do not have to wait for "an
> outsider" to step up to make remote-{hg,bzr} packages yourself.
No, you do not understand how packaging works. ArchLinux's AUR[1] is a
community-driven repository, anybody can package anything and put it
there. That doesn't mean people can simply do `pacman -S git-remote-hg`,
far from it.
It's a placeholder for *outsiders*, not official package maintainers.
I am an outsider in ArchLinux.
> You may already have done so for your own use and told other people
> about them, and others may have chosen to wait for you to push them to
> distros instead of championing these tools by packaging them
> themselves.
You clearly haven't tried to package anything for any distro. You can't
just champion packages for a distribution. You have to go through an
arduous process before becoming an official packager.
> When you have such an influence on the outcome either way of your
> choice, I do not see much value in such a bet.
If I champion these packages I would be making you win the bet. Why
would I do that?
> But I actually think that "we package what we want to use" is a good
> thing for programs whose primary audience is the software developer
> types. The packagers are part of their audiences [*1*]. Because of
> that, even if remote-{hg,bzr} do not get packaged for a long time, I
> doubt that it tells us what you are stipulating. The only thing we
> can infer would be that these programs did not interest the software
> developer types to motivate them enough, and we wouldn't know why
> they found the programs uninteresting. It may be because those who
> have history in Hg prefer to interact with remote Git repositories
> by pushing into and fetching from them using Hg tools than using Git
> tools. It would not indicate "useful tools fall through the cracks"
> if it were the case, would it?
Or it might mean that the people that would otherwise do that packaging
instead simply copy the single file needed manually.
> Indeed I saw bzr-git that came from the Bazaar land packaged on the
> box I mentioned, and its description sounded like it is meant to
> work in such a way that allows Bazaar commits to be pushed to Git
> repositories using a bzr tool.
>
> By the way, I also saw git-mediawiki packaged from contrib/ in our
> tree. I found it not very credible to say "contrib/ is treated as a
> single ball of wax without much value by packagers, and we need to
> move the helpers up to core in order for them to be used more
> widely" after seeing that.
You are misconstruing what I said. I said *most* distributions treat
contrib as a ball of wax. And I said there were a few *exceptions* on
this ball of wax, like completions. remote-helpers are not part of these
exceptions (with the exception of git-bzr).
> *1* I saw you called them "wolves" at least twice recently---where
> does such a distrust come from?
It's a jungle out there, and it's every out-of-tree tool by itself. Most
of the tools on the contrib/ area would not survive if you throw them to
those "wolves", and you know it.
[1] https://wiki.archlinux.org/index.php/Arch_User_Repository
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >
> >> 2. add warning that is given every time the scripts are run and
> >> give the same instruction as in README.
> >>
> >> 3. (optional) cripple the script to make them always fail after
> >> showing the same warning as above.
> >
> > This is what I want, and I already sent the patches for; the scripts
> > will be stubs. At this point you would have effectively removed the
> > code, which what I want.
> >
> >> 4. Keep README and retire everything else.
> >
> > After you've removed the code, I don't care what you do, but I'd say you
> > should remove the stubs after a long period of time.
>
> Let's try this in a different way, as I sense there is a
> misunderstanding somewhere about your "wish".
>
> >> "that" does not refer to "remove them at v2.0 (unconditional)". It
> >> refers to "If Felipe really wants for the removal for v2.0, I would
> >> respect that". And I saw you said you did not want to disrupt v2.0.
> >>
> >> If the options I listed all meant removal at v2.0, then I would
> >> understand your complaints, but that is not the case, so I am not
> >> sure what to make of that.
> >
> > It is a weird choice of semantics then. You said you would "respect" my
> > wish, but your proposals did not "follow" my wish.
>
> I understand you do not want to disrupt v2.0. My assumption of that
> "not disrupting v2.0" has been "there still are git-remote-{hg,bzr}
> that work just like what they had in v1.9.x, perhaps with some
> enhancements and regressions you added in the meantime", and I
> understood Peff's comment "If Felipe wants the removal" to mean that
> kind of "disruption", i.e. "there is no git-remote-{hg,bzr} that
> work.", which would be either step 3 or 4.
>
> But your "After you've removed the code" comment above makes me
> wonder that perhaps your definition of "not disrupting" was
> different from ours (which is not good or bad, just different) and
> you consider that step 3. is "removal but not distupting v2.0"?
>
> If that is what you want in v2.0, then please say so, and I already
> said I am fine with that.
No, I already said I do not want the code removed from v2.0, that's why
I sent patches that simply added a warning, and I specifically said
those were for 2.0.
However, after seeing this commit:
10e1fee (Revert "Merge branch 'fc/transport-helper-sync-error-fix'")
Which is:
1) Inaccurate
2) A lie (*you* broke 2.0, not me)
3) A disservice to users
I therefore change my wish for you to remove all the remote helpers code
and a replace them with stubs (the patches I originally sent for
post-2.0).
It was a mistake from me to believe you would do the sensible thing for
2.0.
So to make it clear, I now request that you do:
1) Remove all the code.
Since my patches were removed from the list, here's an updated patch
that applies on top of 'master'
https://github.com/felipec/git/commits/up/remote/remove
2) Reapply d508e4a (Merge branch 'fc/transport-helper-sync-error-fix')
Since the code in question is no longer part of v2.0, a "possible
regression" that you aren't even sure of cannot be the rationale to
revert this code.
Your commit 10e1fee (Revert "Merge branch
'fc/transport-helper-sync-error-fix'") actively hurts the
out-of-tree tools, so I'll consider a failure to re-revert a hostile
action.
3) Update the release notes to mention these tools have been removed
Additionally, you might want to:
4) Re-add the following release note:
* "git push" via transport-helper interface (e.g. remote-hg) has
been updated to allow forced ref updates in a way similar to the
natively supported transports
I don't know why you removed it in the first place. Clearly you pay
no attention at all to these interfaces.
I expect you to do at the very least 1) and 2).
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty wrote: > On 05/19/2014 11:31 PM, Junio C Hamano wrote: >> Felipe Contreras writes: >>> Where is git-imerge packaged? >> >> I didn't see it on the archive the said Ubuntu box slurps from, but >> I did not check all the other distros. >> >> Michael, do you know what distro folks are doing with imerge? For >> the purpose of this thread, "I do not follow distros, and I do not >> know" is a perfectly acceptable answer, but it would be very >> relevant if your answer is "I suggested these distros to include it, >> but so far they have been uncooperative and I haven't had much >> success". > > I haven't heard of any Linux distros that have git-imerge packages. I > just searched the package archives for Debian, Fedora, Gentoo, and Arch > without finding it. FWIW; someone has made an AUR package (a user-contributed Arch package recipe) for git-imerge: https://aur.archlinux.org/packages/git-imerge-git/ ...Johan -- Johan Herland, www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
On 05/19/2014 11:31 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> Junio C Hamano wrote: >>> >>> After looking at the reverse-depends list of packages, my faith is >>> strengthened in that the Git ecosystem is truly maturing and useful >>> third-party plug-ins will be picked up by distro packagers. >> >> Where is git-imerge packaged? > > I didn't see it on the archive the said Ubuntu box slurps from, but > I did not check all the other distros. > > Michael, do you know what distro folks are doing with imerge? For > the purpose of this thread, "I do not follow distros, and I do not > know" is a perfectly acceptable answer, but it would be very > relevant if your answer is "I suggested these distros to include it, > but so far they have been uncooperative and I haven't had much > success". I haven't heard of any Linux distros that have git-imerge packages. I just searched the package archives for Debian, Fedora, Gentoo, and Arch without finding it. OTOH I haven't suggested it to any package maintainers nor done much to promote it after the initial flurry of publicity after GitMerge 2013 (blog posts, talk, and interview on GitMinutes). Oh yeah, there's also this animated GIF here [1] :-) Michael [1] https://github.com/blog/1691-michael-haggerty-is-a-githubber -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Felipe Contreras writes: > Junio C Hamano wrote: >> Junio C Hamano writes: >> >> > Felipe Contreras writes: >> > >> >> We could. Personally I don't see the point of making the warning any >> >> more annoying >> >> If we were giving the users a choice of "no thanks, I'll keep using >> the obsolete one", then trying to be a low key and giving them a way >> to squelch with an advice.* config might make sense, but if we plan >> to remove/stub at as early as v2.1, I think annoyance is very much >> what we want, actually, because it clearly is the case that we do >> prefer users switching instead of waiting for v2.1. >> >> How does this sound? > > The patch below assumes the user has ~/bin in his PATH, which might not > be the case. Personally I don't see the point of creating extra > annoyance with instructions that might not work. Yeah, I would be lying if I said that "that might not work" did not bother me, but I decided it would be on the good side of the borderline (it is better to be concise and slightly wrong than ultra-verbose and precise). As you may have guessed, they were stolen from your earlier message that shows what the site says after all ;-) I will probably tag -rc4 with the patch applied sometime tomorrow. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: > Junio C Hamano writes: > > > Felipe Contreras writes: > > > >> We could. Personally I don't see the point of making the warning any > >> more annoying > > If we were giving the users a choice of "no thanks, I'll keep using > the obsolete one", then trying to be a low key and giving them a way > to squelch with an advice.* config might make sense, but if we plan > to remove/stub at as early as v2.1, I think annoyance is very much > what we want, actually, because it clearly is the case that we do > prefer users switching instead of waiting for v2.1. > > How does this sound? The patch below assumes the user has ~/bin in his PATH, which might not be the case. Personally I don't see the point of creating extra annoyance with instructions that might not work. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Junio C Hamano writes:
> Felipe Contreras writes:
>
>> We could. Personally I don't see the point of making the warning any
>> more annoying
If we were giving the users a choice of "no thanks, I'll keep using
the obsolete one", then trying to be a low key and giving them a way
to squelch with an advice.* config might make sense, but if we plan
to remove/stub at as early as v2.1, I think annoyance is very much
what we want, actually, because it clearly is the case that we do
prefer users switching instead of waiting for v2.1.
How does this sound?
-- >8 --
From: Junio C Hamano
Date: Mon, 19 May 2014 16:05:34 -0700
Subject: [PATCH] remote-helpers: give short instructions to download the
latest
Signed-off-by: Junio C Hamano
---
contrib/remote-helpers/git-remote-bzr | 6 ++
contrib/remote-helpers/git-remote-hg | 6 ++
2 files changed, 12 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index be4b9a3..c0cb652 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -46,6 +46,12 @@ import atexit, shutil, hashlib, urlparse, subprocess
sys.stderr.write('WARNING: git-remote-bzr is now maintained independently.\n')
sys.stderr.write('WARNING: For more information visit
https://github.com/felipec/git-remote-bzr\n')
+sys.stderr.write('''WARNING: You can pick a directory on your $PATH and
download it, e.g.:
+WARNING: $ wget -O $HOME/bin/git-remote-bzr \\
+WARNING:
https://raw.github.com/felipec/git-remote-bzr/master/git-remote-bzr
+WARNING: $ chmod +x $HOME/bin/git-remote-bzr
+''')
+
NAME_RE = re.compile('^([^<>]+)')
AUTHOR_RE = re.compile('^([^<>]+?)? ?[<>]([^<>]*)(?:$|>)')
EMAIL_RE = re.compile(r'([^ \t<>]+@[^ \t<>]+)')
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 989df66..c07d1a5 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -28,6 +28,12 @@ import time as ptime
sys.stderr.write('WARNING: git-remote-hg is now maintained independently.\n')
sys.stderr.write('WARNING: For more information visit
https://github.com/felipec/git-remote-hg\n')
+sys.stderr.write('''WARNING: You can pick a directory on your $PATH and
download it, e.g.:
+WARNING: $ wget -O $HOME/bin/git-remote-hg \\
+WARNING: https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg
+WARNING: $ chmod +x $HOME/bin/git-remote-hg
+''')
+
#
# If you want to see Mercurial revisions as Git commit notes:
# git config core.notesRef refs/notes/hg
--
2.0.0-rc3-442-ga28c44b
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Felipe Contreras writes: >> We could add these two to the warning, then, to discourage people >> who see "please visit this URL" and say "Yuck, I have no time for >> that" without actually visiting. > > We could. Personally I don't see the point of making the warning any > more annoying. The instructiosn are just one click away, and if they > have no time for that, they can just ignore the warning. Yes, if they know a short-and-sweet instruction is at the top of the page, "just one click away" is a good justification, but the reason I suggested to add the instruction to the warning is because the URL alone does not tell them that there is a short and easy-to-follow instruction is behind it, not giving them enough clue to judge if they have time for that or not. > To me the endgame is that the code is removed, and only stubs remain. > ... > I meant I want 3. eventually, hopefully for v2.1. > ... > No, I don't want them crippled for v2.0. A warning should suffice. OK, I think I understand what you want, and I am fine with that timeline. I can start preparing -rc4 now, but it may slip into tomorrow. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: > Felipe Contreras writes: > > > Junio C Hamano wrote: > > > >> - The "always warn" does not force update at the point of use, but > >>it still does not help them to notice well before they try to use > >>it for the first time after update; > > > > I don't understand this sentence. They will see a big fat warning every > > time they run the tool, of course they'll notice. > > Let me ask one question first, in order to avoid miscommunication, > as I really want to get the first step for v2.0-rc4 in a concrete > shape tomorrow. Do you think gradual transition worth pursuing or > do you think it is a waste of time? If by "gradual transition" you mean place the contrib/remote-helpers in another directory before removing the code, I do think it's a waste of time, but I don't really care, as long as eventually stubs are put in place. > I do not think it matters that much, but since you said you do not > understand... > > What I meant was that when they update their Git (perhaps at the > beginning of the week), the won't know they will now be running > stale code. The warning comes only when they first run it (perhaps > at the end of the week) to do some real work with a remote hg > repository, which may not be a convenient time to do their sysadmin > task. And the next time when they update their Git, they may have > already forgotten about the warning. The ideal transition would be > to somehow let them notice when they are in sysadmin mode. You can add such change in the release notes. Other than that I don't see what we could do. > >> - "Break the build" attempts to help them notice when they try to > >>update, not when they need to use the updated one right at this > >>moment. > > > > This cannot be done. > > Renaming the directory will not "break at the build time" for those > who have already did "ln -s" these scripts, of course, but it will > "break at the build time" for others (i.e. those who "cp"), no? How many people copy the scripts every time they update Git? Not many I'd gather. > > They click that URL, and the are immediately greated with this: > > > > To enable this, simply add the git-remote-hg script anywhere in your > > $PATH: > > > > wget https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg > > -O ~/bin/git-remote-hg > > chmod +x ~/bin/git-remote-hg > > Perfect. I did check the page when double-checking the URL while > writing the README thing, and I did skim the page, but I must have > missed it. > > We could add these two to the warning, then, to discourage people > who see "please visit this URL" and say "Yuck, I have no time for > that" without actually visiting. We could. Personally I don't see the point of making the warning any more annoying. The instructiosn are just one click away, and if they have no time for that, they can just ignore the warning. > >> So to summarize, the following timeline is a full possibility: > >> ... > >> 2. add warning that is given every time the scripts are run and > >> give the same instruction as in README. > >> > >> 3. (optional) cripple the script to make them always fail after > >> showing the same warning as above. > > > > This is what I want, and I already sent the patches for; the scripts > > will be stubs. At this point you would have effectively removed the > > code, which what I want. > > I think explained why the step 3 would not help very much compared > to the "there is no script, only README remains" endgame (and that > is why it is marked as "optional"). Actually, you reminded me that > a very short and easy-to-follow instruction is on the page referred > to from README and the warnings, which means that this step would > make even less difference compared to the endgame. > > I don't think I saw you explain why that is not the case and why we > do want this step (and I cannot quite tell if you are aiming for > more gradual transition that wants this step, or an expedited one > that does not). I am fine with either way. To me the endgame is that the code is removed, and only stubs remain. What you do after that is up to you. > In any case, I'd ask another question to avoid wasting time on > miscommunication. By "This is what I want", do you mean you want > this step 3 also in v2.0, or do you mean you want 2 alone in v2.0 > then step 3 some time later? I meant I want 3. eventually, hopefully for v2.1. > You said your "wish" wasn't "respected" in another message, when I > explained that I thought you did not want to disrupt v2.0 by > insisting on removing these scripts and that was why I listed > options that did not involve removal of the scripts. Are you saying > that you wish you want to see them removed or crippled at v2.0? > Changing your mind after discussion is perfectly fine, by the way. You did not specify those were only for v2.0. No, I don't want them crippled for v2.0. A warning should suffice. -- Felipe Contreras -- To
Re: [PATCH] remote-helpers: point at their upstream repositories
Felipe Contreras writes:
> Junio C Hamano wrote:
>>
>> After looking at the reverse-depends list of packages, my faith is
>> strengthened in that the Git ecosystem is truly maturing and useful
>> third-party plug-ins will be picked up by distro packagers.
>
> Where is git-imerge packaged?
I didn't see it on the archive the said Ubuntu box slurps from, but
I did not check all the other distros.
Michael, do you know what distro folks are doing with imerge? For
the purpose of this thread, "I do not follow distros, and I do not
know" is a perfectly acceptable answer, but it would be very
relevant if your answer is "I suggested these distros to include it,
but so far they have been uncooperative and I haven't had much
success".
> Do you want to bet? Nah, you don't *ever* want to accept you were wrong,
> even you clearly where.
> ...
> This is what's going to happen: there won't be an official git-hg
> package for *years*, if there is ever one. That is my prediction based
> on all the available evidence, I am willing to stand by it and accept I
> was wrong if it proves otherwise.
>
> Are you willing to stand by your own decisions?
If I understand correctly, you have made and you do maintain some
packages and as an insider, you do not have to wait for "an
outsider" to step up to make remote-{hg,bzr} packages yourself. You
may already have done so for your own use and told other people
about them, and others may have chosen to wait for you to push them
to distros instead of championing these tools by packaging them
themselves.
When you have such an influence on the outcome either way of your
choice, I do not see much value in such a bet.
I do know enough to agree with you that there may be no committee,
packagers may scratch their own itches, and a program that is not
very useful for the packagers, especially the ones useful only for
non-technical niche audiences, may fall through the cracks.
But I actually think that "we package what we want to use" is a good
thing for programs whose primary audience is the software developer
types. The packagers are part of their audiences [*1*]. Because of
that, even if remote-{hg,bzr} do not get packaged for a long time, I
doubt that it tells us what you are stipulating. The only thing we
can infer would be that these programs did not interest the software
developer types to motivate them enough, and we wouldn't know why
they found the programs uninteresting. It may be because those who
have history in Hg prefer to interact with remote Git repositories
by pushing into and fetching from them using Hg tools than using Git
tools. It would not indicate "useful tools fall through the cracks"
if it were the case, would it?
Indeed I saw bzr-git that came from the Bazaar land packaged on the
box I mentioned, and its description sounded like it is meant to
work in such a way that allows Bazaar commits to be pushed to Git
repositories using a bzr tool.
By the way, I also saw git-mediawiki packaged from contrib/ in our
tree. I found it not very credible to say "contrib/ is treated as a
single ball of wax without much value by packagers, and we need to
move the helpers up to core in order for them to be used more
widely" after seeing that.
[Footnotes]
*1* I saw you called them "wolves" at least twice recently---where
does such a distrust come from?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Felipe Contreras writes:
> Junio C Hamano wrote:
>
>> 2. add warning that is given every time the scripts are run and
>> give the same instruction as in README.
>>
>> 3. (optional) cripple the script to make them always fail after
>> showing the same warning as above.
>
> This is what I want, and I already sent the patches for; the scripts
> will be stubs. At this point you would have effectively removed the
> code, which what I want.
>
>> 4. Keep README and retire everything else.
>
> After you've removed the code, I don't care what you do, but I'd say you
> should remove the stubs after a long period of time.
Let's try this in a different way, as I sense there is a
misunderstanding somewhere about your "wish".
>> "that" does not refer to "remove them at v2.0 (unconditional)". It
>> refers to "If Felipe really wants for the removal for v2.0, I would
>> respect that". And I saw you said you did not want to disrupt v2.0.
>>
>> If the options I listed all meant removal at v2.0, then I would
>> understand your complaints, but that is not the case, so I am not
>> sure what to make of that.
>
> It is a weird choice of semantics then. You said you would "respect" my
> wish, but your proposals did not "follow" my wish.
I understand you do not want to disrupt v2.0. My assumption of that
"not disrupting v2.0" has been "there still are git-remote-{hg,bzr}
that work just like what they had in v1.9.x, perhaps with some
enhancements and regressions you added in the meantime", and I
understood Peff's comment "If Felipe wants the removal" to mean that
kind of "disruption", i.e. "there is no git-remote-{hg,bzr} that
work.", which would be either step 3 or 4.
But your "After you've removed the code" comment above makes me
wonder that perhaps your definition of "not disrupting" was
different from ours (which is not good or bad, just different) and
you consider that step 3. is "removal but not distupting v2.0"?
If that is what you want in v2.0, then please say so, and I already
said I am fine with that.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Felipe Contreras writes: > Junio C Hamano wrote: > >> - The "always warn" does not force update at the point of use, but >>it still does not help them to notice well before they try to use >>it for the first time after update; > > I don't understand this sentence. They will see a big fat warning every > time they run the tool, of course they'll notice. Let me ask one question first, in order to avoid miscommunication, as I really want to get the first step for v2.0-rc4 in a concrete shape tomorrow. Do you think gradual transition worth pursuing or do you think it is a waste of time? I do not think it matters that much, but since you said you do not understand... What I meant was that when they update their Git (perhaps at the beginning of the week), the won't know they will now be running stale code. The warning comes only when they first run it (perhaps at the end of the week) to do some real work with a remote hg repository, which may not be a convenient time to do their sysadmin task. And the next time when they update their Git, they may have already forgotten about the warning. The ideal transition would be to somehow let them notice when they are in sysadmin mode. >> - "Break the build" attempts to help them notice when they try to >>update, not when they need to use the updated one right at this >>moment. > > This cannot be done. Renaming the directory will not "break at the build time" for those who have already did "ln -s" these scripts, of course, but it will "break at the build time" for others (i.e. those who "cp"), no? Again, not very important, as I too consider it optional. If you are shooting for an expedited transition, it is perfectly fine to drop it. > They click that URL, and the are immediately greated with this: > > To enable this, simply add the git-remote-hg script anywhere in your $PATH: > > wget https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg -O > ~/bin/git-remote-hg > chmod +x ~/bin/git-remote-hg Perfect. I did check the page when double-checking the URL while writing the README thing, and I did skim the page, but I must have missed it. We could add these two to the warning, then, to discourage people who see "please visit this URL" and say "Yuck, I have no time for that" without actually visiting. >> So to summarize, the following timeline is a full possibility: >> ... >> 2. add warning that is given every time the scripts are run and >> give the same instruction as in README. >> >> 3. (optional) cripple the script to make them always fail after >> showing the same warning as above. > > This is what I want, and I already sent the patches for; the scripts > will be stubs. At this point you would have effectively removed the > code, which what I want. I think explained why the step 3 would not help very much compared to the "there is no script, only README remains" endgame (and that is why it is marked as "optional"). Actually, you reminded me that a very short and easy-to-follow instruction is on the page referred to from README and the warnings, which means that this step would make even less difference compared to the endgame. I don't think I saw you explain why that is not the case and why we do want this step (and I cannot quite tell if you are aiming for more gradual transition that wants this step, or an expedited one that does not). I am fine with either way. In any case, I'd ask another question to avoid wasting time on miscommunication. By "This is what I want", do you mean you want this step 3 also in v2.0, or do you mean you want 2 alone in v2.0 then step 3 some time later? Unless you want 2 and 3 together at v2.0, we do not have to decide the merit of step 3 before v2.0-rc4; if you do want 2 and 3 together for v2.0, then your prompt answer matters a lot. You said your "wish" wasn't "respected" in another message, when I explained that I thought you did not want to disrupt v2.0 by insisting on removing these scripts and that was why I listed options that did not involve removal of the scripts. Are you saying that you wish you want to see them removed or crippled at v2.0? Changing your mind after discussion is perfectly fine, by the way. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: > My suggestion to rename the directory without smudging the scripts > was meant to be a step that can come before that step, and I think > its necessity is debatable. It depends on how gradual a transition > you want to give, and being always the more cautious type, > I think having such a step will give packagers who pay attention to > what they package and users who pay attention to what they install > without packaging an early chance to notice and prepare. Immaginary packagers. > - The "always warn" does not force update at the point of use, but >it still does not help them to notice well before they try to use >it for the first time after update; I don't understand this sentence. They will see a big fat warning every time they run the tool, of course they'll notice. > - "Break the build" attempts to help them notice when they try to >update, not when they need to use the updated one right at this >moment. This cannot be done. > But I am fine with an expedited transition schedule without the > "break the build" step. That was an optional first step, because > "warn but still work" state we must have before the endgame will > give the users the choice of when to adjust anyway. > > I also thought about adding an extra step to have even more gradual > transition, by the way. A step before the endgame will ship these > scripts without anything but "instruct and fail" (this is not "warn > and fail", as it is too late "warn", as the scripts are crippled not > to work at this point). > > That will still force the user to update at the point when the user > needs to use it, but seeing the instruction (e.g. "run this curl > command to fetch from this URL and store it in a file called > git-remote-xx on your $PATH") that is easy to follow immediately > would be better than seeing only a failure (i.e. "remote-hg not > found"), having to go fish the README, visiting the GitHub pages > and figuring out how to fetch and install the script, which would > be what the user will get with "README only, no scripts" endgame. I don't see what's so complicated about this: WARNING: git-remote-hg is now maintained independently. WARNING: For more information visit https://github.com/felipec/git-remote-hg They click that URL, and the are immediately greated with this: To enable this, simply add the git-remote-hg script anywhere in your $PATH: wget https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg -O ~/bin/git-remote-hg chmod +x ~/bin/git-remote-hg Clearly you haven't even bothered to visit the home pages of the projects you threw to the wolves. > So to summarize, the following timeline is a full possibility: > > 1. (optional) break the build by renaming directory and add > README. Include not just the repository URL but a blob URL > and instruction to download via wget/curl. That won't break the build. > 2. add warning that is given every time the scripts are run and > give the same instruction as in README. > > 3. (optional) cripple the script to make them always fail after > showing the same warning as above. This is what I want, and I already sent the patches for; the scripts will be stubs. At this point you would have effectively removed the code, which what I want. > 4. Keep README and retire everything else. After you've removed the code, I don't care what you do, but I'd say you should remove the stubs after a long period of time. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: > Felipe Contreras writes: > > >> > But that being said, this is Felipe's code. While we have a legal right > >> > to distribute it in v2.0, if he would really prefer it out for v2.0, I > >> > would respect that. > >> > >> I am fine with that. > > > > Are you? Because in two of the three options you list below you wouldn't > > be doing that. > > "that" does not refer to "remove them at v2.0 (unconditional)". It > refers to "If Felipe really wants for the removal for v2.0, I would > respect that". And I saw you said you did not want to disrupt v2.0. > > If the options I listed all meant removal at v2.0, then I would > understand your complaints, but that is not the case, so I am not > sure what to make of that. It is a weird choice of semantics then. You said you would "respect" my wish, but your proposals did not "follow" my wish. > > The fact of the matter is that users cannot depend on packages any more. > > Maybe they'll be packaged, maybe not. If they are it will take a long > > time before they do. In the meantime they'll have to manually install > > them all all out-of-tree tools. > > I have always thought that distro packagers are the biggest ally us > project leaders have. They locate useful pieces of software, > massage them into a shape that fit their distro well and deliver > what we write to their audience. Packaging stuff that are useful to > their end-users is what they do best, and not leaving useful stuff > unpackaged is in their best interest. Yet I bet a lot of open-source software is not actually packaged. That's the reason there's Python's pip, and Ruby gems. *If* your software is popular enough, then yes, packagers are your biggest allys, but if not, they aren't. > Your statement makes it sound like they are incompetent lazy fools > who do not know what is useful for their users. This sentence proves you have no idea how packaging is done. There is no comittee that hunts down packages that are "useful for their users" and assigns available packagers to those projects. Exactly the same way you don't assign Git developers tasks based on what is "useful for our users". Each packager decides what project they package, just like every Git developer decides on what feature they work on. An obscure package might be packaged because a prominent Debian package maintainer likes it, and a much more useful and popular project might not be packaged simply because no package maintainer is interested in it. Exactly the same happens in Git; people work on relatively obsucre features such as ref transactions, because they are interested in them, and features much more "useful for our" users get ignored, because there's nobody (of relevance) championing them. When a popular project that is "useful for the users" is neglected for too long, what usually happens is that an outsider steps up and does the packaging, which then goes through a review process, and that outsider might become an official maintainer, and maybe start to package other things too. That's how packagers join the project. But nothing gets done if no ousider steps up. Excatly the same happens in Git; when a feature has been neglected for too long, an outsider comes and tries to implement it, go through a review process, and eventually start fixing other things too. So no, there's no comittee that decides what should be packaged, just like there's no committe that decides what Git features should be developed. It's incredibly alarming that you would think packagers in open source distributions would work any other way. And it's incredibly funny that you would label people working on such model as "incompetent lazy fools" for "not knowing what is useful for their users", when it is *EXACTLY* the same thing you do in Git; you do not know what is useful for our users; you don't actually care; you just work on whatever you like to work on. It's even worst than that, because if somebody steps up to package a popular project, the package goes in, but when somebody steps up to implement a feature that improves our user-interface in Git; they get their knees shot. > I find it disturbing to see such a distrust. Or am I being too > naive to have too much faith in packaging folks? There is so much wrong with your mode of thinking and the blindness that you don't see what you yourself do that I don't even know where to begin. Yes you are too naive, on many levels. > I checked the list of packages that depend on "git" on one of my > boxes (it is a bit old Ubuntu). I of course expected that many of > them are what comes from our tree split into their own "niche tool" > packages (e.g. git-svn, git-gui, gitweb...), but I was pleasantly > surprised to see many that I haven't even aware of being packaged. > Of course, "tig" is among the packages that depend on us which I am > happy to see. > > There are things of somewhat questionable value I saw in the list, > of course. It is already 2014, and I fe
Re: [PATCH] remote-helpers: point at their upstream repositories
Felipe Contreras writes: >> > But that being said, this is Felipe's code. While we have a legal right >> > to distribute it in v2.0, if he would really prefer it out for v2.0, I >> > would respect that. >> >> I am fine with that. > > Are you? Because in two of the three options you list below you wouldn't > be doing that. "that" does not refer to "remove them at v2.0 (unconditional)". It refers to "If Felipe really wants for the removal for v2.0, I would respect that". And I saw you said you did not want to disrupt v2.0. If the options I listed all meant removal at v2.0, then I would understand your complaints, but that is not the case, so I am not sure what to make of that. > The fact of the matter is that users cannot depend on packages any more. > Maybe they'll be packaged, maybe not. If they are it will take a long > time before they do. In the meantime they'll have to manually install > them all all out-of-tree tools. I have always thought that distro packagers are the biggest ally us project leaders have. They locate useful pieces of software, massage them into a shape that fit their distro well and deliver what we write to their audience. Packaging stuff that are useful to their end-users is what they do best, and not leaving useful stuff unpackaged is in their best interest. Your statement makes it sound like they are incompetent lazy fools who do not know what is useful for their users. I find it disturbing to see such a distrust. Or am I being too naive to have too much faith in packaging folks? I checked the list of packages that depend on "git" on one of my boxes (it is a bit old Ubuntu). I of course expected that many of them are what comes from our tree split into their own "niche tool" packages (e.g. git-svn, git-gui, gitweb...), but I was pleasantly surprised to see many that I haven't even aware of being packaged. Of course, "tig" is among the packages that depend on us which I am happy to see. There are things of somewhat questionable value I saw in the list, of course. It is already 2014, and I feel fairly safe to feel that I can say without offending too many people that I doubt "git-arch" would be on such a list of packages distros offer to their users, if it were written as a third-party plug-in today. It is an (odd) example of a package that is still there mostly by inertia at this point, and that inertia comes from many things. It is in our tree outside contrib/, it was found useful once in the past and was packaged, the packager already has infrastructure to cut a separate package out of our tree, and it is more trouble to retire it and risk breaking minority users than just keep shipping it. But hg is not in a situation similar to tla, is it? I simply cannot imagine "there is no history worthwhile to salvage out of Mercurial repositories" coming anytime in the near future. After looking at the reverse-depends list of packages, my faith is strengthened in that the Git ecosystem is truly maturing and useful third-party plug-ins will be picked up by distro packagers. Am I delusional? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Jeff King writes: > My concerns were with people not noticing the README. Removing the code > entirely is the way I thought of to address that. Junio suggested > another way, which I would also be fine with. And it seems like a > friendlier way than removal to handle it for v2.0, if we are going to > remove the code entirely post-v2.0. > > As before, if your desire is to have the code out for v2.0, then say so. > I think we should respect such a request. OK. After thinking about it a bit more, I think renaming the directory at this point is not a "clearly superiour" option and the judgment largely depends on your philosophy on transition. Let me explain, backwards from the desired endgame. I think all of us (including Felipe) agree that in some future time [*1*], we won't have either of these two scripts in contrib/, but just like contrib/vim, we will leave a README to help those who read a stale page on the Web that says "remote-hg in contrib/ is the officially recommended tool to interact with Mercurial". The README will tell them that they read a stale page that is no longer true, and direct them to where they can grab remote-hg/bzr. We will need to keep contrib/remote-helpers in that endgame state for quite some time. If a user of 1.9.x updates to such an endgame version and then runs the same fetch from Hg, he will not just notice the breakage but is forced at that point to go to the GitHub URL and switch, but it may not be a convenient time for him to go through that process. To help these users, a step that ships the "stale but working" scripts that give warning is necessary before the endgame state, and Felipe's 77621193 (contrib: remote-helpers: add move warnings (v2.0), 2014-05-13) is such a change. My suggestion to rename the directory without smudging the scripts was meant to be a step that can come before that step, and I think its necessity is debatable. It depends on how gradual a transition you want to give, and being always the more cautious type, I think having such a step will give packagers who pay attention to what they package and users who pay attention to what they install without packaging an early chance to notice and prepare. - The endgame will force the user to update at the point when the user needs to use it for his real work, when he may not have time for sysadmin. - The "always warn" does not force update at the point of use, but it still does not help them to notice well before they try to use it for the first time after update; - "Break the build" attempts to help them notice when they try to update, not when they need to use the updated one right at this moment. But I am fine with an expedited transition schedule without the "break the build" step. That was an optional first step, because "warn but still work" state we must have before the endgame will give the users the choice of when to adjust anyway. I also thought about adding an extra step to have even more gradual transition, by the way. A step before the endgame will ship these scripts without anything but "instruct and fail" (this is not "warn and fail", as it is too late "warn", as the scripts are crippled not to work at this point). That will still force the user to update at the point when the user needs to use it, but seeing the instruction (e.g. "run this curl command to fetch from this URL and store it in a file called git-remote-xx on your $PATH") that is easy to follow immediately would be better than seeing only a failure (i.e. "remote-hg not found"), having to go fish the README, visiting the GitHub pages and figuring out how to fetch and install the script, which would be what the user will get with "README only, no scripts" endgame. For that matter, the warning message given by 77621193, also README added by f000c4e6 (remote-helpers: point at their upstream repositories, 2014-05-15) may want to mention not just the GitHub URL for the repository as the whole, but the URL to fetch the latest blob with curl/wget, if we really want to help users go back to their tasks at hand with minimum interruption. I know how to construct a URL to follow the tip of a specific branch and obtain a full .zip from a GitHub repository, but I do not know offhand if you can do the same for a single blob. If we can come up with one, we should add such a instruction to the warning message and README, as that instruction will be the only thing to help the users in the endgame state anyway. So to summarize, the following timeline is a full possibility: 1. (optional) break the build by renaming directory and add README. Include not just the repository URL but a blob URL and instruction to download via wget/curl. 2. add warning that is given every time the scripts are run and give the same instruction as in README. 3. (optional) cripple the script to make them always fail after showing the same warning as above. 4. Keep README and retire everything else.
Re: [PATCH] remote-helpers: point at their upstream repositories
Matthieu Moy wrote:
> Felipe Contreras writes:
>
> > % git fetch
> > WARNING: git-remote-hg is now maintained independently.
> > WARNING: For more information visit
> > https://github.com/felipec/git-remote-hg
> > searching for changes
> > no changes found
>
> I don't think the situation is as simple as you claim. In many cases,
> the first step before the ones you are mentionning are:
>
> cd $git/contrib/remote-helpers
> cp git-remote-{hg,bzr} somewhere/in/path
In many cases, but not all cases. In other cases they are:
ln -s $git/contrib/remote-helpers/git-remote-hg \
somewhere/in/path/git-remote-hg
Which has to be done only once, and not every time Git is updated.
> They produces no warning if git-remote-{hg,bzr} exist with the warning,
> but "no such file or directory: contrib/remote-helpers" if the directory
> has been renamed or removed.
So? They'll get the warning the next time they try to use it, and their
workflow won't be interrupted, and the warning will be more useful than
"No such file or directory".
> When git-remote-{hg,bzr} are installed with a package manager, the fact
> that they are part of Git's core or not is often irrelevant. For
> example, Debian splits the git.git source into many packages, so a
> Debian user will not see any difference between helpers included in
> git.git or outside (e.g. I have to install the package git-svn if I want
> to use git-svn).
Yet there is no git-hg. And I doubt Jonathan Nieder is going to package
the out-of-tree git-bzr, which as far as I know, is the only out-of-tree
package of these remote helpers in any distro.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Felipe Contreras writes:
> % git fetch
> WARNING: git-remote-hg is now maintained independently.
> WARNING: For more information visit https://github.com/felipec/git-remote-hg
> searching for changes
> no changes found
I don't think the situation is as simple as you claim. In many cases,
the first step before the ones you are mentionning are:
cd $git/contrib/remote-helpers
cp git-remote-{hg,bzr} somewhere/in/path
They produces no warning if git-remote-{hg,bzr} exist with the warning,
but "no such file or directory: contrib/remote-helpers" if the directory
has been renamed or removed.
When git-remote-{hg,bzr} are installed with a package manager, the fact
that they are part of Git's core or not is often irrelevant. For
example, Debian splits the git.git source into many packages, so a
Debian user will not see any difference between helpers included in
git.git or outside (e.g. I have to install the package git-svn if I want
to use git-svn).
That said, I'm fine with the "add a warning" option too.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
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. 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. > > > 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. > > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Jeff King wrote: > On Sat, May 17, 2014 at 12:25:30AM -0500, Felipe Contreras wrote: > > > > I agree with the line of reasoning you laid out in your email, > > > especially: > > > > What a shock. > > Please stop with these unproductive and rude comments. I am sorry, but the fact of the matter is that you *always* agree with Junio. > > > I hadn't thought of the rename idea, and it would address the concerns I > > > brought up. I do think "obsolete" is the wrong word, as it sends the > > > wrong message. The helpers are not obsolete; it is our _copy_ of them > > > that is. > > > > Originally you said you would respect if I wanted the code out > > for v2.0, I said I would like it out at some point, not necessarily in > > v2.0. Junio said he was fine with that, but the proposals above don't do > > that. > > > > Now it seems you are changing your mind and you are OK with the code > > remaining in. > > My concerns were with people not noticing the README. Removing the code > entirely is the way I thought of to address that. Junio suggested > another way, which I would also be fine with. And it seems like a > friendlier way than removal to handle it for v2.0, if we are going to > remove the code entirely post-v2.0. I don't see what is friendlier about this: % sudo pacman -Syu % cd ~/dev/my-hg-repo % git fetch fatal: Unable to find remote helper for 'hg' The users will scratch their heads, wonder what's going on, investigate themselves, and eventually they'll have to decide how to fix the issue properly, and how to report it. On the other hand: % git fetch WARNING: git-remote-hg is now maintained independently. WARNING: For more information visit https://github.com/felipec/git-remote-hg searching for changes no changes found You think that's less friendly? If you think so, I think you are totally biased towards whatever happens to be the opinion of one person. > As before, if your desire is to have the code out for v2.0, then say so. > I think we should respect such a request. As I said before, I do not wish the code to be removed for v2.0, I would like to have only a warning. Either way, do whatever you want for v2.0, it's your users you are hurting. But if I do not hear *from Junio* that the code will be removed entirely post-v2.0, hopefully replaced with stubs (which is obviously the most user-friendly thing to do), I'll do what I said I'll do. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
On Sat, May 17, 2014 at 12:25:30AM -0500, Felipe Contreras wrote: > > I agree with the line of reasoning you laid out in your email, > > especially: > > What a shock. Please stop with these unproductive and rude comments. > > I hadn't thought of the rename idea, and it would address the concerns I > > brought up. I do think "obsolete" is the wrong word, as it sends the > > wrong message. The helpers are not obsolete; it is our _copy_ of them > > that is. > > Originally you said you would respect if I wanted the code out > for v2.0, I said I would like it out at some point, not necessarily in > v2.0. Junio said he was fine with that, but the proposals above don't do > that. > > Now it seems you are changing your mind and you are OK with the code > remaining in. My concerns were with people not noticing the README. Removing the code entirely is the way I thought of to address that. Junio suggested another way, which I would also be fine with. And it seems like a friendlier way than removal to handle it for v2.0, if we are going to remove the code entirely post-v2.0. As before, if your desire is to have the code out for v2.0, then say so. I think we should respect such a request. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Jeff King wrote: > I agree with the line of reasoning you laid out in your email, > especially: What a shock. > > I would say that the options I see are these three, and I would rank > > the "warn every time" as less helpful to end-users: > > > > - rename contrib/remote-helpers to contrib/obsolete-remote-helpers > >and add README to point at the upstream. > > > > - remove contrib/remote-helpers scripts and add README. > > > > - warn every time the user runs the scripts. > > I hadn't thought of the rename idea, and it would address the concerns I > brought up. I do think "obsolete" is the wrong word, as it sends the > wrong message. The helpers are not obsolete; it is our _copy_ of them > that is. Originally you said you would respect if I wanted the code out for v2.0, I said I would like it out at some point, not necessarily in v2.0. Junio said he was fine with that, but the proposals above don't do that. Now it seems you are changing your mind and you are OK with the code remaining in. Do what you will, but I already told you what I will do in response. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
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. But that's a red herring. Even if was the worst packager in history, that doesn't make Junio's decision any more correct. > > 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? > 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. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
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. > 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. 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
On Fri, May 16, 2014 at 09:52:15AM -0700, Junio C Hamano wrote: > Or am I reacting to a typo and you meant to say "I would prefer not > to instrument"? Your "shipping the warnings to end users who did > not package the software will not help" was unclear if you meant the > README that has warning or warning message they have to see every > time from the instrumented code. Argh, yes, it is a typo. I had written "I would prefer _not_ to instrument the code with warnings...". While reading it back to myself, I thought "using underlining there is too argumentative", but somehow managed to delete the whole word rather than simply the "_" characters. I'm very sorry to have wasted people's time by accidentally making the opposite point. I agree with the line of reasoning you laid out in your email, especially: > I would say that the options I see are these three, and I would rank > the "warn every time" as less helpful to end-users: > > - rename contrib/remote-helpers to contrib/obsolete-remote-helpers >and add README to point at the upstream. > > - remove contrib/remote-helpers scripts and add README. > > - warn every time the user runs the scripts. I hadn't thought of the rename idea, and it would address the concerns I brought up. I do think "obsolete" is the wrong word, as it sends the wrong message. The helpers are not obsolete; it is our _copy_ of them that is. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: > Jeff King writes: > > > On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote: > > > >> Two announcements for their version 0.2 on the list archive are not > >> quite enough to advertise them to their users. > > > > I do not think this README nor a mention in the release notes will get > > their attention either, and many people (and packagers) will continue to > > use the stale versions forever until those versions go away. > > > > I would much rather _replace_ them with a README in the long run, and > > people will notice that they are gone, and then use the README to update > > their install procedure. > > > > For 2.0, I am hesitant to do that, though I do not have a problem with a > > README like this as a heads-up to prepare packagers for the future. I > > say hesitant because people may have been test-packaging 2.0.0-rc3 in > > preparation for release, and it will be annoying to them to suddenly > > switch. > > I share the latter two of the above three. I was giving distro > packagers a bit more credit for their diligence in knowing what they > are packaging than you seem to be in your first point, but I admit > that it is a blind faith. I don't see why anybody would think otherwise. There are dozens of tools in contrib/ many without documentation, or even a description of that whey do. I bet most Git developers don't know what half of them do (even a quarter), how are package maintainers supposed to know? All the packages I've seen stash everything into /usr/share/git, with a few exceptions, like shell completions. > > But that being said, this is Felipe's code. While we have a legal right > > to distribute it in v2.0, if he would really prefer it out for v2.0, I > > would respect that. > > I am fine with that. Are you? Because in two of the three options you list below you wouldn't be doing that. > > I would prefer to instrument the code with warnings, as that is the sort > > of thing a packager moving from -rc3 to -final might not notice, and > > shipping the warnings to end users who did not package the software in > > the first place will not help them. It is the attention of the packagers > > (and source-builders) you want to get. > > I do agree that a new warning every time it is run will be a more > likely to grab users' attention. The conclusion I draw from that > shared observation is that the user will be annoyed all the time, That's exactly what we do when anything gets deprecated. Try running Git with an empty configuration for a day and you'll see tons of warnings, often huge ones every time the user does common operations, like `git push`. Why is it OK to warn about minor behavior changes, but not when the whole code the user is exercising might be broken? At least the warning I proposed for the remote-helpers is small and to the point, unlike the warning of `git push` without refspec. > without having a power to do anything about the annoyance, until the > report s/he (or other users) Throw at the packager, even when the > version that was packaged hasn't diverged that much yet, which does > not help end users. What do you expect the packagers are going to do? They will simply ignore the report as it's not related to their package (git). I suspect this will continue for quite some time, and very likely these will not be packaged as part of the official distribution, but some user-based repository. In some distributions they might end up being unpackaged completely. Take git-imerge as an example, a very popular tool you yourself are very fond of. I don't see it packaged either in ArchLinux, Debian, or Fedora, and I don't think it will ever be packaged. So, yes, this will hurt our users, that's what every user of an out-of-tree tool must suffer, and that's what you unilaterally decided users of git-remote-hg/bzr should suffer. > I guess the ideal we want is to make sure their build break. We cannot make 'cp -r contrib /usr/share/git' fail, that's all packagers do. I already pointed to the fact that most of the tools in contrib shouldn't even be there, and that most of them should have tests. If there was a standardized way to tests contrib, we could make the build break. But you ignored my call of attention. > What if we do the README in addition to rename contrib/remote-helpers > to contrib/obsolete-remote-helpers (or s/obsolete/graduated/)? It > will give the packagers three choices and I think it hurts people much > less. > > * The packagers that dump the entirety of contrib/ to somewhere >without doing anything to expose the scripts to user's PATH do >not have to do anything. The users who chose to pick them up >from there notice the missing contrib/remote-helpers, notice >"obsolete" (or "graduated"), and read README. This is wrong. Users will not notice the missing contrib/remote-helpers. At least not initially. If they setup links to /usr/share, they'll just see: fatal: Unable to find remote helper fo
Re: [PATCH] remote-helpers: point at their upstream repositories
Jeff King writes: > On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote: > >> Two announcements for their version 0.2 on the list archive are not >> quite enough to advertise them to their users. > > I do not think this README nor a mention in the release notes will get > their attention either, and many people (and packagers) will continue to > use the stale versions forever until those versions go away. > > I would much rather _replace_ them with a README in the long run, and > people will notice that they are gone, and then use the README to update > their install procedure. > > For 2.0, I am hesitant to do that, though I do not have a problem with a > README like this as a heads-up to prepare packagers for the future. I > say hesitant because people may have been test-packaging 2.0.0-rc3 in > preparation for release, and it will be annoying to them to suddenly > switch. I share the latter two of the above three. I was giving distro packagers a bit more credit for their diligence in knowing what they are packaging than you seem to be in your first point, but I admit that it is a blind faith. > But that being said, this is Felipe's code. While we have a legal right > to distribute it in v2.0, if he would really prefer it out for v2.0, I > would respect that. I am fine with that. > I would prefer to instrument the code with warnings, as that is the sort > of thing a packager moving from -rc3 to -final might not notice, and > shipping the warnings to end users who did not package the software in > the first place will not help them. It is the attention of the packagers > (and source-builders) you want to get. I do agree that a new warning every time it is run will be a more likely to grab users' attention. The conclusion I draw from that shared observation is that the user will be annoyed all the time, without having a power to do anything about the annoyance, until the report s/he (or other users) Throw at the packager, even when the version that was packaged hasn't diverged that much yet, which does not help end users. I guess the ideal we want is to make sure their build break. What if we do the README in addition to rename contrib/remote-helpers to contrib/obsolete-remote-helpers (or s/obsolete/graduated/)? It will give the packagers three choices and I think it hurts people much less. * The packagers that dump the entirety of contrib/ to somewhere without doing anything to expose the scripts to user's PATH do not have to do anything. The users who chose to pick them up from there notice the missing contrib/remote-helpers, notice "obsolete" (or "graduated"), and read README. * The packagers that pick up from contrib/remote-helpers and arrange the scripts to be on user's PATH will find their build broken, because they are no longer where they expect them to be. They will notice "obsolete"(or "graduated"), and read README. - They can choose to pick them up from "obsolete", perhaps for expediency, perhaps for their change aversion, but that will not last once we grabbed their attention, and they will switch their upstream in some later release once such a choice makes them feel dirty enough. - They can choose to switch their upstream right now in response to the breakage. I would say that the options I see are these three, and I would rank the "warn every time" as less helpful to end-users: - rename contrib/remote-helpers to contrib/obsolete-remote-helpers and add README to point at the upstream. - remove contrib/remote-helpers scripts and add README. - warn every time the user runs the scripts. Or am I reacting to a typo and you meant to say "I would prefer not to instrument"? Your "shipping the warnings to end users who did not package the software will not help" was unclear if you meant the README that has warning or warning message they have to see every time from the instrumented code. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
(Sorry if you receive a dup; pobox.com seems to be constipated right now). Jeff King writes: > On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote: > >> Two announcements for their version 0.2 on the list archive are not >> quite enough to advertise them to their users. > > I do not think this README nor a mention in the release notes will get > their attention either, and many people (and packagers) will continue to > use the stale versions forever until those versions go away. > > I would much rather _replace_ them with a README in the long run, and > people will notice that they are gone, and then use the README to update > their install procedure. > > For 2.0, I am hesitant to do that, though I do not have a problem with a > README like this as a heads-up to prepare packagers for the future. I > say hesitant because people may have been test-packaging 2.0.0-rc3 in > preparation for release, and it will be annoying to them to suddenly > switch. I share the latter two of the above three. I was giving distro packagers a bit more credit for their diligence in knowing what they are packaging than you seem to be in your first point, but I admit that it is a blind faith. > But that being said, this is Felipe's code. While we have a legal right > to distribute it in v2.0, if he would really prefer it out for v2.0, I > would respect that. I am fine with that. > I would prefer to instrument the code with warnings, as that is the sort > of thing a packager moving from -rc3 to -final might not notice, and > shipping the warnings to end users who did not package the software in > the first place will not help them. It is the attention of the packagers > (and source-builders) you want to get. I do agree that a new warning every time it is run will be a more likely to grab users' attention. The conclusion I draw from that shared observation is that the user will be annoyed all the time, without having a power to do anything about the annoyance, until the report s/he (or other users) Throw at the packager, even when the version that was packaged hasn't diverged that much yet, which does not help end users. I guess the ideal we want is to make sure their build break. What if we do the README in addition to rename contrib/remote-helpers to contrib/obsolete-remote-helpers (or s/obsolete/graduated/)? It will give the packagers three choices and I think it hurts people much less. * The packagers that dump the entirety of contrib/ to somewhere without doing anything to expose the scripts to user's PATH do not have to do anything. The users who chose to pick them up from there notice the missing contrib/remote-helpers, notice "obsolete" (or "graduated"), and read README. * The packagers that pick up from contrib/remote-helpers and arrange the scripts to be on user's PATH will find their build broken, because they are no longer where they expect them to be. They will notice "obsolete"(or "graduated"), and read README. - They can choose to pick them up from "obsolete", perhaps for expediency, perhaps for their change aversion, but that will not last once we grabbed their attention, and they will switch their upstream in some later release once such a choice makes them feel dirty enough. - They can choose to switch their upstream right now in response to the breakage. I would say that the options I see are these three, and I would rank the "warn every time" as less helpful to end-users: - rename contrib/remote-helpers to contrib/obsolete-remote-helpers and add README to point at the upstream. - remove contrib/remote-helpers scripts and add README. - warn every time the user runs the scripts. Or am I reacting to a typo and you meant to say "I would prefer not to instrument"? Your "shipping the warnings to end users who did not package the software will not help" was unclear if you meant the README that has warning or warning message they have to see every time from the instrumented code. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Jeff King wrote: > On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote: > > > Two announcements for their version 0.2 on the list archive are not > > quite enough to advertise them to their users. > > I do not think this README nor a mention in the release notes will get > their attention either, and many people (and packagers) will continue to > use the stale versions forever until those versions go away. > > I would much rather _replace_ them with a README in the long run, and > people will notice that they are gone, and then use the README to update > their install procedure. > > For 2.0, I am hesitant to do that, though I do not have a problem with a > README like this as a heads-up to prepare packagers for the future. I > say hesitant because people may have been test-packaging 2.0.0-rc3 in > preparation for release, and it will be annoying to them to suddenly > switch. I agree, that's why I sent patches that: 1) Add a warning for v2.0 (which already has problems) So everything keeps working as well as in the release candidates, except a warning is introduced each time they do a fetch, push, or clone operation (use the remote-helpers) 2) Replace the tools with stubs So when they try to fetch, push, or clone, they get an error, and nothing else happens. There's an additional README for the people that want to read more, but if you don't put stubs, users might try to do what worked before: % git clone hg::http://selenic.com/repo/hello fatal: Unable to find remote helper for 'hg' It's much better to report: git-remote-hg is now maintained independently. For more information visit https://github.com/felipec/git-remote-hg > But that being said, this is Felipe's code. While we have a legal right > to distribute it in v2.0, if he would really prefer it out for v2.0, I > would respect that. That's right, you have the legal right to distributed it. It is not my wish to disrupt v2.0, so I think adding a warning should be sufficient. Eventually I would prefer if they were not distributed, and replaced with stubs, not just because it would help the out-of-tree projects gather more visibility, but also because users would be better served by not having poorly maintained or unsynchronized code. Hopefully for v2.1. > I would prefer to instrument the code with warnings, as that is the sort > of thing a packager moving from -rc3 to -final might not notice, and > shipping the warnings to end users who did not package the software in > the first place will not help them. It is the attention of the packagers > (and source-builders) you want to get. > > Of course that is all just my two cents, and is mostly predicated on > there _being_ packagers of the contrib/ tools. It looks like there is a > Debian package in RFP status, but I don't know if that is following the > new release closely. And I don't know about other systems. As far as I understand most distributions don't do anything special with contrib, they just put everything under /usr/share. It is unlikely packagers will notice any change in one of the dozens tools in contrib, so they'll make no changes to the packages. So if the user did: % ln -s /usr/share/git/remote-helpers/git-remote-hg ~/bin/git-remote-hg The expectation would be that this keeps working even if the package doesn't change (it just adds a warning). Eventually it will stop working with an error, but the package still won't change. The distributions that do something special about remote-helpers (AFAIK it's only debian's git-bzr) would need to change, and sooner or later they will if there's only stubs there. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
Paolo Ciarrocchi wrote: > On Fri, May 16, 2014 at 10:41 AM, Jeff King wrote: > > But that being said, this is Felipe's code. While we have a legal right > > to distribute it in v2.0, if he would really prefer it out for v2.0, I > > would respect that. > > My understanding is that Felipe would prefer to keep it _in_ the git.git > repository and eventually get it included in the core. That is correct. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
On Fri, May 16, 2014 at 10:55:54AM +0200, Paolo Ciarrocchi wrote: > On Fri, May 16, 2014 at 10:41 AM, Jeff King wrote: > > But that being said, this is Felipe's code. While we have a legal right > > to distribute it in v2.0, if he would really prefer it out for v2.0, I > > would respect that. > > My understanding is that Felipe would prefer to keep it _in_ the git.git > repository and eventually get it included in the core. Yes, sorry if I was unclear. I meant "...if we are going to remove it, and are considering leaving it in v2.0, we should respect his wishes to remove it earlier if he wants to". It is not his decision whether it stays in the core at all. That is Junio's decision. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
On Fri, May 16, 2014 at 10:41 AM, Jeff King wrote: > But that being said, this is Felipe's code. While we have a legal right > to distribute it in v2.0, if he would really prefer it out for v2.0, I > would respect that. My understanding is that Felipe would prefer to keep it _in_ the git.git repository and eventually get it included in the core. Regards, -- Paolo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote: > Two announcements for their version 0.2 on the list archive are not > quite enough to advertise them to their users. I do not think this README nor a mention in the release notes will get their attention either, and many people (and packagers) will continue to use the stale versions forever until those versions go away. I would much rather _replace_ them with a README in the long run, and people will notice that they are gone, and then use the README to update their install procedure. For 2.0, I am hesitant to do that, though I do not have a problem with a README like this as a heads-up to prepare packagers for the future. I say hesitant because people may have been test-packaging 2.0.0-rc3 in preparation for release, and it will be annoying to them to suddenly switch. But that being said, this is Felipe's code. While we have a legal right to distribute it in v2.0, if he would really prefer it out for v2.0, I would respect that. I would prefer to instrument the code with warnings, as that is the sort of thing a packager moving from -rc3 to -final might not notice, and shipping the warnings to end users who did not package the software in the first place will not help them. It is the attention of the packagers (and source-builders) you want to get. Of course that is all just my two cents, and is mostly predicated on there _being_ packagers of the contrib/ tools. It looks like there is a Debian package in RFP status, but I don't know if that is following the new release closely. And I don't know about other systems. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: > Two announcements for their version 0.2 on the list archive are not > quite enough to advertise them to their users. > > Signed-off-by: Junio C Hamano > --- > > * I am inclined to queue this for 2.0, and we would also need an >update to the release notes as well. > >I am undecided about the revert I sent earlier in $gmane/248937; >with or without it, that is just a contrib/ thing that is not >well maintained inside our tree anyway. > > contrib/remote-helpers/README | 11 +++ > 1 file changed, 11 insertions(+) > create mode 100644 contrib/remote-helpers/README NAK. > diff --git a/contrib/remote-helpers/README b/contrib/remote-helpers/README > new file mode 100644 > index 000..72a2df4 > --- /dev/null > +++ b/contrib/remote-helpers/README > @@ -0,0 +1,11 @@ > +The remote-helper bridges to access data stored in Hg and bzr will be They are called Mercurial and Bazaar. > +maintained outside the git.git tree in the repositories of its > +primary author at: > + > +https://github.com/felipec/git-remote-hg > +https://github.com/felipec/git-remote-bzr If this is formatted in asciidoc the links won't appear as links. Do it as I did: * https://github.com/felipec/git-remote-hg * https://github.com/felipec/git-remote-bzr > +As a convenience, copies of the last-bundled version of these two > +remote-helper bridges are kept here, but they may left stale. Users > +are encouraged to visit the above authoritative repositories for the > +latest versions to get involved in its further developments. 1) Most users will *never* see this README 2) Most packagers will never see this README 3) The people that do read this README will wonder *why* they are now maintained separately. Thanks for wasting all my hard work and sabotaging these projects. Just as a heads-up. I *will* complain about this publicly and my blog is visited by thousands of people. I am requesting one last time: 1) Add warnings *directly* into the tools themselves ASAP You didn't have any problems adding warnings for pre-v2.0 behavior that changed, nor did you have a problem adding the warning about the new zsh completion that moved out of the bash one. Why would you have a problem with this one? 2) Replace the tools with stubs that point to the right locations at the earliest convenience I already sent patches for both, and they were ignored. A failure to do both will result in a lack of visibility of the new projects, and a decrease in the quality the users of git.git contrib area's remote-helpers receive. I will consider that a deliberate attempt to make the new projects experience unnecessary hardship. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] remote-helpers: point at their upstream repositories
Two announcements for their version 0.2 on the list archive are not quite enough to advertise them to their users. Signed-off-by: Junio C Hamano --- * I am inclined to queue this for 2.0, and we would also need an update to the release notes as well. I am undecided about the revert I sent earlier in $gmane/248937; with or without it, that is just a contrib/ thing that is not well maintained inside our tree anyway. contrib/remote-helpers/README | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 contrib/remote-helpers/README diff --git a/contrib/remote-helpers/README b/contrib/remote-helpers/README new file mode 100644 index 000..72a2df4 --- /dev/null +++ b/contrib/remote-helpers/README @@ -0,0 +1,11 @@ +The remote-helper bridges to access data stored in Hg and bzr will be +maintained outside the git.git tree in the repositories of its +primary author at: + +https://github.com/felipec/git-remote-hg +https://github.com/felipec/git-remote-bzr + +As a convenience, copies of the last-bundled version of these two +remote-helper bridges are kept here, but they may left stale. Users +are encouraged to visit the above authoritative repositories for the +latest versions to get involved in its further developments. -- 2.0.0-rc3-431-gba4c34e -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
