Re: Difficulties in advertising a new branch to git newbies

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

 



Hi,

On Wed, 31 Jan 2007, Carl Worth wrote:

> On Wed, 31 Jan 2007 14:13:42 +0100, "Guilhem Bonnefille" wrote:
> > If the user is not a developer and only interested in testing, what
> > about a simple snapshot tarball?
> > So, you prepare the fix and then you pack everything in a
> > myapp-timestamp.tar.gz and send this tarball to the user.
> 
> That's bad for all the same reasons we don't send tarballs around to 
> each other.

Well, that's not completely fair. Guilhem has a point here.

> 1. I want to be able to easily publicize a new branch with
>    instructions that anyone can use, (regardless of git experience).

How about gitweb, with a snapshot link? It's as easy as it gets. Even 
those Windows idio^H^H^H^Husers can unpack tar.gz files by now, and you 
send them just a link. They can even see what was fixed, and when, if they 
care enough.
 
> > 2. I've got the stuff available in a git branch already, and I don't
>    want to do any more work.

That is one of the lousiest excuses in this world. Unfortunately, I hear 
it very, very often. (I mean the second sentence.)

> 3. I want the exchange to be as efficient as possible, (I might send
>    multiple fixes in series to the user and it'd be really nice to
>    take advantage of git's efficiency here).

There's two kinds of efficient here. Efficient in the sense of network 
traffic, or in the sense of time spent talking back and forth, until the 
package is finally tested.

If the efficiency you are thriving for is network traffic, go a head, make 
the user use git.

However, if it is the other efficiency you want to achieve, stay away from 
git. Chances are that your user will never appreciate what git can to for 
her, and just wants to test the darned package, and be done with it, 
thank you very much.

> 4. I don't want to condemn the user to never being able to learn
>    git. If I make this easy for the user then I get a nice lead-in to
>    teach the user new things, (which is good for me since it helps me
>    if the user starts sending me git commits rather than random
>    patches without commit messages connected to who-knows-what
>    tar-file version of the software, etc.)

That's nice of you. But it might just be that you royally p*ss the 
customer off, because he does not have time for that game.

Ciao,
Dscho

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]