stable version of msysgit
csh
I want to use msysgit with tortoisegit in the company that I work for,
but I can't get an approval for msysgit since its version is preview.
What time can its stable version be released?
Johannes Schindelin
Git for Windows is free software. You have two options:
1) work on it yourself until it fulfills your quality criteria, or
2) pay somebody to get it there.
Specifically, if your goal is to remove the "-preview" from the package
name, you can
1) rename the file, or
2) state more clearly what your company deems stable enough, and hope that
somebody gives you an estimate how much it would cost to get it there.
Ciao,
Johannes
Volkan Orhan
The company I work for has very strict rules. Normally I already use
beta software personally. Of course my goal is not to remove "-preview",
but our software committee will review everything, and because of the
"preview" word on the version number, it may be rejected.
Isn't it possible for msysgit to be released as stable version?
Best regards,
Volkan Orhan
Erik Faye-Lund
While I agree with what you're saying here, perhaps we should consider
losing the "-preview"-suffix anyway? I mean, Git for Windows is the de
facto Git distribution for Windows, and I think it's closing in on
getting "stable enough" (a very subjective measure, I know). Quite a
bit of people seem to be confused by the naming already.
After all, removing the "-preview"-suffix won't make Git for Windows
unfree software. People will still have to pay or convince someone to
do work for them (unless they're willing to do it themselves), like
with most other free software...
If we decide to do this, I'd suggest doing it at the same time as
changing the naming for our packages as has been suggested before (if
we even end up deciding to do that as well, of course). I'd like to
see something like this:
Git-1.7.4-preview20110204.exe -> git-1.7.4.exe
PortableGit-1.7.4-preview20110204.7z -> git-1.7.4-portable.7z
msysGit-fullinstall-1.7.4-preview20110204.exe -> git-1.7.4.3-dev.exe (?)
I'm not so sure about the netinstall; why do we have new releases of
the netinstall with every release? Isn't it just cloning the
always-up-to-date repo on repo.or.cz? As long as we have tags for
every released versions, can't we just maintain one binary? Or is
there something I'm missing?
On Mon, Mar 28, 2011 at 7:12 PM, Volkan Orhan <volk...@gmail.com> wrote:
> Hi again,
>
> The company I work for has very strict rules. Normally I already use beta
> software personally. Of course my goal is not to remove "-preview", but our
> software committee will review everything, and because of the "preview" word
> on the version number, it may be rejected.
>
> Isn't it possible for msysgit to be released as stable version?
>
Changing the name won't make Git for Windows more or less stable. All
changing the name does is change people's expectations. I think
keeping expectations low is the reason we have the prefix in the first
place.
If the company you work for care about the name, then they aren't just
strict; they are impractical :P
Unfortunately, a lot of companies tend to be are just that...
Konstantin Khomoutov
Volkan Orhan <volk...@gmail.com> wrote:
> The company I work for has very strict rules. Normally I already use
> beta software personally. Of course my goal is not to remove
> "-preview", but our software committee will review everything, and
> because of the "preview" word on the version number, it may be
> rejected.
>
> Isn't it possible for msysgit to be released as stable version?
Come on, what do you want -- a mere label on a package or a confidence
that it works? If your company is so obsessed with its set of curious
rules as to even have a dedicated comittee, make that comittee perform
a thorough testing of the feature set your company actually needs.
Otherwise it will be mere bureaucracy.
If my point is not clear, look at this: for instance, your company
might not want git-svn and so you do not care how broken that part of
msysgit can potentially be--you just ignore it. Or consider support
for non-ASCII characters in file names, commit messages and system user
names: some people just cannot deploy msysgit because of these problems
while other people are happily using it because their setups and
workflows are unaffected by these problems.
There's no bug-free software, instead, there is software which works OK
within the set of particular requirements.
Volkan Orhan
training course to my colleagues (some of them aren't software
developer). In my presentation, I taught how to use tortoisegit with
msysgit. I requested license for tortoisegit, but when I wanted to
request license for msysgit, I saw "preview" word in its version number.
I know that every software has bugs, so I already use beta software
(even my linux is beta most of times). But our company will not want
everybody to use beta or preview software.
I wanted to compile git stable on msys using mingw, but I got an error
related to socklen_t. I didn't try to define it as int since socklen_t
should not be depended on the endiannes of the cpu architecture. It is
very difficult for me to compile git on msys since there is no bsd
sockets library that can be compiled on mingw. In addition, gnulib and
glibc also can't be compiled on mingw.
I will be glad so much if "preview" word is removed since it is stable
so much (the stable version even may be an old version). It is really
very excellent to use git everywhere and every time.
Best regards,
Volkan Orhan
On 3/28/2011 8:36 PM, Konstantin Khomoutov wrote:
> On Mon, 28 Mar 2011 20:12:45 +0300
> Volkan Orhan<volk...@gmail.com> wrote:
>
>> The company I work for has very strict rules. Normally I already use
>> beta software personally. Of course my goal is not to remove
>> "-preview", but our software committee will review everything, and
>> because of the "preview" word on the version number, it may be
>> rejected.
>>
>> Isn't it possible for msysgit to be released as stable version?
Erik Faye-Lund
people to follow the discussion.
On Mon, Mar 28, 2011 at 8:06 PM, Volkan Orhan <volk...@gmail.com> wrote:
> I am a software engineer. I already use msysgit. I presented a git training
> course to my colleagues (some of them aren't software developer). In my
> presentation, I taught how to use tortoisegit with msysgit. I requested
> license for tortoisegit, but when I wanted to request license for msysgit, I
> saw "preview" word in its version number.
>
Ah, you want commercial support? Unfortunately, I'm not aware of
anyone who provides that for Git for Windows...
> I know that every software has bugs, so I already use beta software (even my
> linux is beta most of times). But our company will not want everybody to use
> beta or preview software.
>
> I wanted to compile git stable on msys using mingw,
What do you mean by "git stable"? The code from git-scm.com (or
git.kernel.org)? That's no more stable than Git for Windows. In fact,
git-scm.com redirects to the msysGit project for Windows...
> but I got an error
> related to socklen_t. I didn't try to define it as int since socklen_t
> should not be depended on the endiannes of the cpu architecture. It is very
> difficult for me to compile git on msys since there is no bsd sockets
> library that can be compiled on mingw. In addition, gnulib and glibc also
> can't be compiled on mingw.
>
Even upstream-git has socklen_t defined for MinGW in compat/mingw.h,
that should be used automatically. How exactly are you trying to build
Git?
> I will be glad so much if "preview" word is removed since it is stable so
> much (the stable version even may be an old version). It is really very
> excellent to use git everywhere and every time.
>
This part I tend to agree with you on. I don't think we need to say
that we're a preview version anymore. Git for Windows works very well
for me, at least. Much better than any other non-preview version
control system I've ever used ;)
Volkan Orhan
> In the future, please quote in-line. This makes it much easier for
> people to follow the discussion.
>
> On Mon, Mar 28, 2011 at 8:06 PM, Volkan Orhan<volk...@gmail.com> wrote:
>> I am a software engineer. I already use msysgit. I presented a git training
>> course to my colleagues (some of them aren't software developer). In my
>> presentation, I taught how to use tortoisegit with msysgit. I requested
>> license for tortoisegit, but when I wanted to request license for msysgit, I
>> saw "preview" word in its version number.
>>
> Ah, you want commercial support? Unfortunately, I'm not aware of
> anyone who provides that for Git for Windows...
>
license (allowance) of our company.
>> I know that every software has bugs, so I already use beta software (even my
>> linux is beta most of times). But our company will not want everybody to use
>> beta or preview software.
>>
>> I wanted to compile git stable on msys using mingw,
> What do you mean by "git stable"? The code from git-scm.com (or
> git.kernel.org)? That's no more stable than Git for Windows. In fact,
> git-scm.com redirects to the msysGit project for Windows...
>
Of course msysgit is more stable on Windows, but I wanted to document
its version as stable because of rules.
>> but I got an error
>> related to socklen_t. I didn't try to define it as int since socklen_t
>> should not be depended on the endiannes of the cpu architecture. It is very
>> difficult for me to compile git on msys since there is no bsd sockets
>> library that can be compiled on mingw. In addition, gnulib and glibc also
>> can't be compiled on mingw.
>>
> Even upstream-git has socklen_t defined for MinGW in compat/mingw.h,
> that should be used automatically. How exactly are you trying to build
> Git?
>
error below:
configure: CHECKS for typedefs, structures, and compiler characteristics
checking for socklen_t... no
checking for socklen_t equivalent... configure: error: Cannot find a
type to use
in place of socklen_t
>> I will be glad so much if "preview" word is removed since it is stable so
>> much (the stable version even may be an old version). It is really very
>> excellent to use git everywhere and every time.
>>
> This part I tend to agree with you on. I don't think we need to say
> that we're a preview version anymore. Git for Windows works very well
> for me, at least. Much better than any other non-preview version
> control system I've ever used ;)
I agree with you, but there are rules on our company. If the preview
word is not removed for a long time, I will try to ask our company to
accept preview version.
Erik Faye-Lund
> On 3/28/2011 9:42 PM, Erik Faye-Lund wrote:
>>
>> In the future, please quote in-line. This makes it much easier for
>> people to follow the discussion.
>>
>> On Mon, Mar 28, 2011 at 8:06 PM, Volkan Orhan<volk...@gmail.com> wrote:
>>>
>>> I am a software engineer. I already use msysgit. I presented a git
>>> training
>>> course to my colleagues (some of them aren't software developer). In my
>>> presentation, I taught how to use tortoisegit with msysgit. I requested
>>> license for tortoisegit, but when I wanted to request license for
>>> msysgit, I
>>> saw "preview" word in its version number.
>>>
>> Ah, you want commercial support? Unfortunately, I'm not aware of
>> anyone who provides that for Git for Windows...
>>
> I didn't mean commercial support for now. The license I mean is internal
> license (allowance) of our company.
Aha, thanks for clarifying.
>>>
>>> I know that every software has bugs, so I already use beta software (even
>>> my
>>> linux is beta most of times). But our company will not want everybody to
>>> use
>>> beta or preview software.
>>>
>>> I wanted to compile git stable on msys using mingw,
>>
>> What do you mean by "git stable"? The code from git-scm.com (or
>> git.kernel.org)? That's no more stable than Git for Windows. In fact,
>> git-scm.com redirects to the msysGit project for Windows...
>>
> I downloaded git source codes from git-scm.com
> Of course msysgit is more stable on Windows, but I wanted to document its
> version as stable because of rules.
Aha, if you can somehow prove that msysGit is more stable than
upstream on Windows, then perhaps that is enough to get allowance?
>>>
>>> but I got an error
>>> related to socklen_t. I didn't try to define it as int since socklen_t
>>> should not be depended on the endiannes of the cpu architecture. It is
>>> very
>>> difficult for me to compile git on msys since there is no bsd sockets
>>> library that can be compiled on mingw. In addition, gnulib and glibc also
>>> can't be compiled on mingw.
>>>
>> Even upstream-git has socklen_t defined for MinGW in compat/mingw.h,
>> that should be used automatically. How exactly are you trying to build
>> Git?
>>
> I downloaded git-1.7.4.1, then run ./configure script on msys. I got the
> error below:
>
> configure: CHECKS for typedefs, structures, and compiler characteristics
> checking for socklen_t... no
> checking for socklen_t equivalent... configure: error: Cannot find a type to
> use
> in place of socklen_t
>
Aha. You don't need to run "./configure", it's only intended for
exotic Unices. Just run "make" (but be sure that you have no
config.mak.autogen left over from configure), and it should pick up
that you're building for MinGW from running uname.
>>> I will be glad so much if "preview" word is removed since it is stable so
>>> much (the stable version even may be an old version). It is really very
>>> excellent to use git everywhere and every time.
>>>
>> This part I tend to agree with you on. I don't think we need to say
>> that we're a preview version anymore. Git for Windows works very well
>> for me, at least. Much better than any other non-preview version
>> control system I've ever used ;)
>
> I agree with you, but there are rules on our company. If the preview word is
> not removed for a long time, I will try to ask our company to accept preview
> version.
>
I suspect that you'll have to go that path, but let's see if more
people agrees with us first.
Of course, if your company would be willing to invest some development
time into Git for Windows, that'd be a very effective way of getting a
stable release ;)
Pat Thoyts
Git for Windows is stock git from git-scm.com with a number of patches
to ensure that it operates properly on this platform. The intent is to
gradually push these patches upstream into the main project so that
ultimately we just provide the necessary runtime. Expecting stock git
to be more stable on Windows because it doesn't have a '-preview'
suffix is ridiculous. The 50 or so patches we currently apply onto
mainline git are there for a reason other than the developers idle
amusement.
In my opinion it is stable. I am quite content to loose the suffix. It
is that way at the moment because Johannes (and maybe other project
owners) wanted to indicate quite strongly that end users are expected
to fix problems and provide patches and not just issue complaints. I
happen to think thats misguided. People that are inclined to make
patches will do so. The others just issue so much hot air and can be
ignored or not as individual contributors desire.
As I see it - if the test suite passes tolerably as has been the case
for the last 4 or so releases that I've been involved with, then we
may as well issue it as a 'stable' release. It passed the tests -
there's not much more we can do to it to declare it more stable.
Pat Thoyts.
Volkan Orhan
license on license request system of our company. If I write "preview"
on version section, it will probably rejected. Even if it is accepted,
everybody will ask me why it is preview version. Since there are some
compliance rules related to software in our company, it is some risk for
me.
>>>> but I got an error
>>>> related to socklen_t. I didn't try to define it as int since socklen_t
>>>> should not be depended on the endiannes of the cpu architecture. It is
>>>> very
>>>> difficult for me to compile git on msys since there is no bsd sockets
>>>> library that can be compiled on mingw. In addition, gnulib and glibc also
>>>> can't be compiled on mingw.
>>>>
>>> Even upstream-git has socklen_t defined for MinGW in compat/mingw.h,
>>> that should be used automatically. How exactly are you trying to build
>>> Git?
>>>
>> I downloaded git-1.7.4.1, then run ./configure script on msys. I got the
>> error below:
>>
>> configure: CHECKS for typedefs, structures, and compiler characteristics
>> checking for socklen_t... no
>> checking for socklen_t equivalent... configure: error: Cannot find a type to
>> use
>> in place of socklen_t
>>
> Aha. You don't need to run "./configure", it's only intended for
> exotic Unices. Just run "make" (but be sure that you have no
> config.mak.autogen left over from configure), and it should pick up
> that you're building for MinGW from running uname.
>
32-bit mingw if you want)
CC daemon.o
In file included from git-compat-util.h:149,
from cache.h:4,
from daemon.c:1:
compat/mingw.h:8: error: conflicting types for 'pid_t'
c:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-mingw32/
include/sys/types.h:67: note: previous declaration of 'pid_t' was here
In file included from git-compat-util.h:149,
from cache.h:4,
from daemon.c:1:
compat/mingw.h:137:25: error: openssl/ssl.h: No such file or directory
>>>> I will be glad so much if "preview" word is removed since it is stable so
>>>> much (the stable version even may be an old version). It is really very
>>>> excellent to use git everywhere and every time.
>>>>
>>> This part I tend to agree with you on. I don't think we need to say
>>> that we're a preview version anymore. Git for Windows works very well
>>> for me, at least. Much better than any other non-preview version
>>> control system I've ever used ;)
>> I agree with you, but there are rules on our company. If the preview word is
>> not removed for a long time, I will try to ask our company to accept preview
>> version.
>>
> I suspect that you'll have to go that path, but let's see if more
> people agrees with us first.
>
> Of course, if your company would be willing to invest some development
> time into Git for Windows, that'd be a very effective way of getting a
> stable release ;)
In our team, most of the developers even don't know how to use git, so I
don't think that they will help for development of git. I can help for
the development of git if I can. I am a C++ developer, and mostly I
develop applications using object oriented development techniques, but I
don't do low level programming so much; instead, I design different
layers, and I do low level programming on the lowest level. If I can
help, of course I want to help development so much since I use open
source software every time and everywhere.
Volkan Orhan
can't ask a license for preview version. In case of a mistake of
anybody, some people will say that the cause of the problem is preview
version. You already know such situations.
> In my opinion it is stable. I am quite content to loose the suffix. It
> is that way at the moment because Johannes (and maybe other project
> owners) wanted to indicate quite strongly that end users are expected
> to fix problems and provide patches and not just issue complaints. I
> happen to think thats misguided. People that are inclined to make
> patches will do so. The others just issue so much hot air and can be
> ignored or not as individual contributors desire.
>
> As I see it - if the test suite passes tolerably as has been the case
> for the last 4 or so releases that I've been involved with, then we
> may as well issue it as a 'stable' release. It passed the tests -
> there's not much more we can do to it to declare it more stable.
>
> Pat Thoyts.
such cases I mentioned above, a stable version may be needed.
Best regards,
Volkan Orhan
Erik Faye-Lund
This is probably because you're using a different version of MinGW
than we are. Strangely enough, our /mingw/include/sys/types.h does
have a definition for pid_t:
$ grep -C3 pid_t /mingw/include/sys/types.h
#ifndef _PID_T_
#define _PID_T_
typedef int _pid_t;
#ifndef _NO_OLDNAMES
typedef _pid_t pid_t;
#endif
#endif /* Not _PID_T_ */
I'm not entirely sure why this doesn't get picked up when we compile.
You can probably just remove the definition locally.
> In file included from git-compat-util.h:149,
> from cache.h:4,
> from daemon.c:1:
> compat/mingw.h:137:25: error: openssl/ssl.h: No such file or directory
>
This is because Git depends on OpenSSL, so you either have to compile
and install it or add a line saying "NO_OPENSSL = YesPlease" to your
config.mak (create it if it doesn't exist) to build a stripped-down
version that doesn't use the features that require OpenSSL.
Volkan Orhan
>> In file included from git-compat-util.h:149,
>> from cache.h:4,
>> from daemon.c:1:
>> compat/mingw.h:137:25: error: openssl/ssl.h: No such file or directory
>>
> This is because Git depends on OpenSSL, so you either have to compile
> and install it or add a line saying "NO_OPENSSL = YesPlease" to your
> config.mak (create it if it doesn't exist) to build a stripped-down
> version that doesn't use the features that require OpenSSL.
solution.
The best solution would be to have msysgit without "preview" word. But
since we don't have it for now, and we have strict rules, I should
compile git to get a allowance from our company.
Best regards,
Volkan Orhan
Erik Faye-Lund
Actually it's picked up, but it's just a compatible definition here
(both define it to "int").
Simply removing the definition should be the trick. J6t, you added the
definition back in ancient times: Am I right in suspecting that older
MinGWs didn't supply pid_t, or do you think it might have simply been
a left-over from something?
It'd be nice if we could start preparing a bit more for MinGW-64
support, and I'm a little bit unsure how to do this - remove the
definition all together or guard it with a _PID_T_-check... The latter
would be the careful choice, I guess.
Volkan Orhan
endian and small endian systems write int differently. This may not be
problem for Windows, but git is multiplatform. I don't know how this
type is used in git codes, but I think that this may cause some problems
in the future.
Erik Faye-Lund
This definition is in compat/mingw.h, so it doesn't matter how
multi-platform git is, it will only be included when compiling on
Windows.
And even we did use this on a big-endian machine, it would still have
been correct (provided that the platform didn't provide a conflicting
definition). It's the in-memory representation that is different for
big-endian machines - an int is an int no matter what :)
Johannes Sixt
> On Mon, Mar 28, 2011 at 9:55 PM, Erik Faye-Lund <kusm...@gmail.com> wrote:
> > On Mon, Mar 28, 2011 at 9:30 PM, Volkan Orhan <volk...@gmail.com> wrote:
> >> When I run make firstly, I get more errors like below: (I can also try
> >> 32-bit mingw if you want)
> >> � �CC daemon.o
> >> In file included from git-compat-util.h:149,
> >> � � � � � � � � from cache.h:4,
> >> � � � � � � � � from daemon.c:1:
> >> compat/mingw.h:8: error: conflicting types for 'pid_t'
> >> c:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-
> >> was here
> >
> > This is probably because you're using a different version of MinGW
> > than we are. Strangely enough, our /mingw/include/sys/types.h does
> > have a definition for pid_t:
> >
> > $ grep -C3 pid_t /mingw/include/sys/types.h
> >
> > #ifndef _PID_T_
> > #define _PID_T_
> > typedef int � � _pid_t;
> >
> > #ifndef _NO_OLDNAMES
> > typedef _pid_t �pid_t;
> > #endif
> > #endif �/* Not _PID_T_ */
> >
> > I'm not entirely sure why this doesn't get picked up when we compile.
> > You can probably just remove the definition locally.
>
> Actually it's picked up, but it's just a compatible definition here
> (both define it to "int").
>
> Simply removing the definition should be the trick. J6t, you added the
> definition back in ancient times: Am I right in suspecting that older
> MinGWs didn't supply pid_t, or do you think it might have simply been
> a left-over from something?
I don't remember for sure, but I think that older MinGW did not define pid_t.
-- Hannes
Heiko Voigt
On Mon, Mar 28, 2011 at 11:07:13PM +0300, Volkan Orhan wrote:
> I will also add or compile openssl library. Thank you very much for the
> solution.
> The best solution would be to have msysgit without "preview" word. But
> since we don't have it for now, and we have strict rules, I should
> compile git to get a allowance from our company.
Why are you doing it the hard way? Just install the development
environment (msysgit installer).
1. Checkout the version you want to test whether its stable enough for
you.
2. Start msys.bat and make install
3. Verify whether its stable enough for you: i.e. run the testsuite
using /share/msysGit/run-tests.sh (Tip: disable any virus protection
because the slowlyness interferes with the test scripts)
4. Hack on things you do want/need to have fixed and send the patches to
this list.
5. Build your own installer: /share/WinGit/release.sh <versionnumber>
Now you should have your very own "stable" version.
Cheers Heiko
P.S.: Wasn't there a roadmap from Johannes somewhere which described
what would need to be done for the first stable release? I think "all
tests pass" was one item on there and thats what I would expect for a
publicly stable release.
Johannes Schindelin
On Mon, 28 Mar 2011, Erik Faye-Lund wrote:
> On Mon, Mar 28, 2011 at 5:53 PM, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
> > Hi,
> >
> > On Mon, 28 Mar 2011, csh wrote:
> >
> >> I want to use msysgit with tortoisegit in the company that I work
> >> for, but I can't get an approval for msysgit since its version is
> >> preview. What time can its stable version be released?
> >
> > Git for Windows is free software. You have two options:
> >
> > 1) work on it yourself until it fulfills your quality criteria, or
> >
> > 2) pay somebody to get it there.
> >
> > Specifically, if your goal is to remove the "-preview" from the
> > package name, you can
> >
> > 1) rename the file, or
> >
> > 2) state more clearly what your company deems stable enough, and hope
> > that �somebody gives you an estimate how much it would cost to get
> > it there.
>
> While I agree with what you're saying here, perhaps we should consider
> losing the "-preview"-suffix anyway?
I am strictly against that. Not only does it encourage companies' managers
to think about Git lowly (because it does not cost anything -- and I speak
very much from experience here), but it also would provide no respect for
the few faithful Git for Windows developers, such as you, Pat, Heiko &
Jens and the two Kirills (and a few others...).
Face it: companies can easily afford a couple of thousand Euros to get the
support they require. The rule of thumb is: 1000 EUR per freelancer per
day. A couple of thousand Euros here and there is not only reasonable to
ask for, it also does not hurt companies in the least.
IMO it is quite obvious that putting an effort to get Git for Windows to
-stable status for no money at all would be a lose-lose situation for all
parties involved: those developers who could maintain the -stable status
for a decent amount of time (read: more than a couple of days) would still
have to earn their living with different jobs, doing Git for Windows in
their precious free time. And companies who have a false impression of
saving money would lose out on high-quality maintenance, resulting in a
non-stable Git in the long run.
I do want to encourage Git for Windows contributors to think about their
incentives of working on Git. If it is for your own end, fine. If you
publish your changes, even better.
But if you work for somebody else's end, especially on Windows, which is a
thoroughly commercial system, you should consider asking yourself
what's in it for you, in the long run. To be able to sustain your
contributions.
After all, a high degree of intelligence and experience and persistence is
required to work on high-quality software. Which comes at a price.
> I mean, Git for Windows is the de facto Git distribution for Windows,
> and I think it's closing in on getting "stable enough" (a very
> subjective measure, I know). Quite a bit of people seem to be confused
> by the naming already.
That is a different issue altogether.
> After all, removing the "-preview"-suffix won't make Git for Windows
> unfree software. People will still have to pay or convince someone to do
> work for them (unless they're willing to do it themselves), like with
> most other free software...
It's not about making Git "free" or "unfree". Git -- and therefore also
Git on Windows -- _is_ free software. Free as in freedom. But that does
not mean that the developers pushing Git for Windows should try their best
to spend all their non-day job time to solve other people's problems for a
warm handshake instead of spending their time with their family and
friends. Because it _will_ wear them out.
> If we decide to do this, I'd suggest doing it at the same time as
> changing the naming for our packages as has been suggested before (if we
> even end up deciding to do that as well, of course). I'd like to see
> something like this:
>
> Git-1.7.4-preview20110204.exe -> git-1.7.4.exe
> PortableGit-1.7.4-preview20110204.7z -> git-1.7.4-portable.7z
> msysGit-fullinstall-1.7.4-preview20110204.exe -> git-1.7.4.3-dev.exe (?)
That is a good naming we could easily have with a -preview suffix until
the time that one or more companies compensate the top contributors of Git
for Windows for their efforts.
After all, the top two _Git_ developers were hired by Google, and are now
paid top dollar.
> I'm not so sure about the netinstall; why do we have new releases of the
> netinstall with every release? Isn't it just cloning the
> always-up-to-date repo on repo.or.cz? As long as we have tags for every
> released versions, can't we just maintain one binary? Or is there
> something I'm missing?
The reasoning was two-fold:
1) we had quite a few problems with older -netinstall not being able to
cope with newer developments, for example when we made 'devel' the
primary development branch (and it took an incredible amount of time
and patience and download quota to test and fix those things), and
2) Google (in the person of Shawn Pearce, #2 of the _Git_ developers) said
that we had a lot of quota and would get more when we need it, so there
was little point in saving on space with the net installers.
Just to clarify on my previous argument: there has been a _lot_ of time
invested in Git for Windows. Last time I calculated, I myself put in
easily a thousand hours of work just for the Windows port of Git. It is
only fair to expect something more than requests (to stabilize, to fix, to
support X, Y and Z) back. Be that code contributions, be that money.
You mentioned yourself a couple of times that it is dirt-easy to build
Git, and it is dirt-easy to build a Git installer.
These are not things that just happen, or for that matter, that are
provided in just a couple of free afternoon's time. These things cost
_real_ time. We're talking about weeks and months of dedicated work.
Git-svn alone (which still would offer the opportunity for at least 500
more hours to get to work properly) cost me several months of almost every
bit of my free, unpaid time, personally. Maybe I should not have been as
modest as I was when I wrote about this in the MsysGit Heralds.
In the upstream Git project, there seems to be no problem to find
contributors who make an immense initial effort worthwhile because you get
more back than you spent. For some reason, the same is not true in Git for
Windows (I can count the contributors with one hand, using the binary
system).
So, much as I respect Pat for what he did both with Tcl/Tk and Git for
Windows, I _do_ think that it would be a wise thing to put in all the
work to get Git for Windows into a shape competing with non-Windows
versions of Git, but _only_ if due respect is paid either by contributions
or in financial form.
Everything else would just elicit fully deserved ridicule by anybody
versed in the world of management and/or trading.
Ciao,
Dscho
P.S.: When I happened to stumble upon a project manager of a company back
last August who migrated his team to Git (for Windows) but had a number of
complaints about stability, my suggestion to hire somebody to fix things
was met with very wide eyes. He took Git for something God-given. But
then, he also did not realize that he was talking to the Git for Windows
maintainer. I fully believe that I deserve more respect (which equals
money in the corporate world) than that.
Johannes Schindelin
On Mon, 28 Mar 2011, Erik Faye-Lund wrote:
> It'd be nice if we could start preparing a bit more for MinGW-64
> support, and I'm a little bit unsure how to do this - remove the
> definition all together or guard it with a _PID_T_-check... The latter
> would be the careful choice, I guess.
Have you actually seen the work/w64 branch of 4msysgit.git? This is
something I started to work on a couple of months back, and am now picking
up again, as a company realized that you get kick-ass support if you pay
decent money for it.
Ciao,
Dscho
Johannes Schindelin
On Mon, 28 Mar 2011, Volkan Orhan wrote:
> The company I work for has very strict rules.
I understand that, as I am quite familiar with the corporate environment.
However, as you will certainly understand, such substantial demands can
only be met for an appropriate price.
> Normally I already use beta software personally. Of course my goal is
> not to remove "-preview", but our software committee will review
> everything, and because of the "preview" word on the version number, it
> may be rejected.
>
> Isn't it possible for msysgit to be released as stable version?
There is. But what your software committee needs is not a rename. Your
committee needs to have a guarantee. A guarantee which can only possibly
be met through a detailed audit. Which requires a service contract that
puts a large burden on the contractor guaranteeing stability.
I am sure that you understand that a fair contract to such an end would
need to be met with an appropriate financial investment, as only those
people would guarantee such a degree of stability for free (with
liability) who lack the intellectual capabilities to actually ensure that
degree of stability.
Ciao,
Johannes
Johannes Schindelin
On Mon, 28 Mar 2011, Volkan Orhan wrote:
> If I was a project manager, of course I would support both git and
> msysgit. I can't say that "we should take support for msysgit to have
> stable version of msysgit" because of my position. For now, I am only
> able compile git on mingw.
>
> I really want to support both git and msysgit, but I am not able to
> support both of them financially for now. I can spend my free times as I
> said before for both git and msysgit.
Thank you for the clarification.
Ciao,
Johannes
Volkan Orhan
msysgit. I can't say that "we should take support for msysgit to have
stable version of msysgit" because of my position. For now, I am only
able compile git on mingw.
I really want to support both git and msysgit, but I am not able to
support both of them financially for now. I can spend my free times as
I said before for both git and msysgit.
Best regards,
Volkan Orhan
On Mar 29, 3:42 am, Johannes Schindelin <Johannes.Schinde...@gmx.de>
> Hi,
>
>
>
> On Mon, 28 Mar 2011, Erik Faye-Lund wrote:
> > On Mon, Mar 28, 2011 at 5:53 PM, Johannes Schindelin
> > <Johannes.Schinde...@gmx.de> wrote:
> > > Hi,
>
> > > On Mon, 28 Mar 2011, csh wrote:
>
> > >> I want to use msysgit with tortoisegit in the company that I work
> > >> for, but I can't get an approval for msysgit since its version is
> > >> preview. What time can its stable version be released?
>
> > > Git for Windows is free software. You have two options:
>
> > > 1) work on it yourself until it fulfills your quality criteria, or
>
> > > 2) pay somebody to get it there.
>
> > > Specifically, if your goal is to remove the "-preview" from the
> > > package name, you can
>
> > > 1) rename the file, or
>
> > > 2) state more clearly what your company deems stable enough, and hope
tb
our case) and the socket layer.
It tells about the length of the address, not about the address itself.
The length we look at here has nothing to do with data exchanged on the
network. (Well it has, since e.g. IPV4 and IPV6 addresses have different
length).
But the length information in socklen_t is always in "machine endianes"
as all other ints in the world are.
/Torsten
Pat Thoyts
[snip]
I thought this was roughly your opinion which is one reason I've not
renamed anything myself when doing releases.
However, what you seem to be after is getting companies to contribute.
This is never going to happen as things currently stand. Companies
only talk to other companies. At the moment, if a manager is persuaded
that his developers should use git he can go online and buy a 20-seat
package from ....? Nowhere.
If we look at how this was done in one instance for CVS - look for CVS
for windows and we are quickly led to CVSNT and the march-hare site.
They took CVS and added a new NT specific extras and provided a few
integrated tools. A download package with bugzilla integration,
tortoise cvs and a repository browser. Most of this is open source and
can be obtained - but they've packaged it nicely. But mostly they also
sell it. And offer training and support. My manager or purchasing guy
can go there, order 10 copies of the CVS suite and be happy. It has
clear links to the support area where he can purchase a separate
support contract.
Another model I can see is Scott Chacon's - he's set up github and on
the bottom is a pretty easy to find link where we can get him in for
training (if we can afford it). It seems to me you need to setup
something like these - a Git for Windows company. At the moment, if I
put in "git for windows commercial support" into google - there is
nothing appropriate on the first page. At the bottom is a link to
github. Actually to correct myself - I see a link for "Clearvision
Support". First time I have heard of them, but there they are -
looking attractive to my manager.
On a more developmental note I did think up one thing that commercial
support could pay for: getting multilingual support fixed. I'm sure
some Russian or Japanese entities might like that fixed. But right now
they'd have to search the mailing lists to work out who to talk to.
Which is not something that is likely to happen in my experience.
I think if you are serious about wanting to get commercial input then
you have to setup a serious commercial entity to provide that service.
Not that I'm any kind of business wizard.
Pat.
Volkan Orhan
in the future since this application is developed constantly. For
example, somebody may save the data in binary format taken from
socklen_t. It may be used without any problem for now, but I think
that it should be fixed.
On Mar 28, 11:44 pm, tb <totte.e...@gmail.com> wrote:
> On 03/28/2011 10:22 PM, Volkan Orhan wrote:
>
>
>
>
>
>
>
> > On 3/28/2011 11:13 PM, Erik Faye-Lund wrote:
> >> wrote:
> >>> On Mon, Mar 28, 2011 at 9:30 PM, Volkan Orhan<volkan...@gmail.com>
Patrick Cornelißen
On 29 Mrz., 03:10, Johannes Schindelin <Johannes.Schinde...@gmx.de>
wrote:
> There is. But what your software committee needs is not a rename. Your
> committee needs to have a guarantee. A guarantee which can only possibly
> be met through a detailed audit. Which requires a service contract that
> puts a large burden on the contractor guaranteeing stability.
I don't think you got the point. The problem is the preview label
itself.
Every software has bugs, no matter if it's labeled stable or not. But
the
fact that the team labels it as preview communicates the notion that
the
team does not want you to use the project for something other than
playing
around with it. But msysgit seems to be stable and reliable, as Erik
stated
earlier. Of course there may be rough corners or maybe even broken
features,
but you can communicate that in the release notes. This way the people
who
are not affected by the bugs can use your software and provide bugs,
patches
or suggestion to improve the "product".
When the software committee needs a real guarantee then it's time for
some
contract negotiation with for example someone from the team. But most
developers don't need that. They can work around bugs themselves, they
just
need the approval of the managers that simply look at the version
number.
Patrick Cornelißen
I am a bit puzzled, please tell me if I have understood this wrong...
On 29 Mrz., 02:42, Johannes Schindelin <Johannes.Schinde...@gmx.de>
wrote:
> I am strictly against that. Not only does it encourage companies' managers
> to think about Git lowly (because it does not cost anything -- and I speak
> very much from experience here), but it also would provide no respect for
> the few faithful Git for Windows developers, such as you, Pat, Heiko &
> Jens and the two Kirills (and a few others...).
So, dropping the "-preview" from the name will lead to people thinking
lowly
about git and the git for W. devs won't get any credit?
I don't get it. Just because companies might consider using msysgit
after
the suffix is dropped does not mean at all that managers will think
badly of the
project. IMHO it is the other way around, because it's not a good sign
is the
preview label sticks in the software for that long.
Of course there is the notion of "costs nothing, so it's worth
nothing" in some
(old) manager heads, but this has absolutely nothing to do with the
preview label.
> Face it: companies can easily afford a couple of thousand Euros to get the
> support they require. The rule of thumb is: 1000 EUR per freelancer per
> day. A couple of thousand Euros here and there is not only reasonable to
> ask for, it also does not hurt companies in the least.
Why would they need support? Maybe the current version is sufficient,
but due
to oversimplified rules, the systems department refuses to install
software
that is not confident enough to call itself stable and has a preview
sticker
attached to it. They won't even try if it's sufficient or stable
enough.
And as such, there will be no hiring of a freelancer (not from this
team, nor
any other freelancers) to fill the gaps.
> IMO it is quite obvious that putting an effort to get Git for Windows to
> -stable status for no money at all would be a lose-lose situation for all
> parties involved: those developers who could maintain the -stable status
> for a decent amount of time (read: more than a couple of days) would still
> have to earn their living with different jobs, doing Git for Windows in
> their precious free time. And companies who have a false impression of
> saving money would lose out on high-quality maintenance, resulting in a
> non-stable Git in the long run.
So as a matter of fact you propose that the project requires ransom
money to
remove the preview label?
I am actively involved in open source software for almost 10 years now
and this
kind of foolish argumentation of new to me. How can you expect to be
treated
seriously with this kind of argumentation?
If the Devs only do this for the money, then they shouldn't have made
their
patches public and sell the sysmingw for money. If they do this
because they
need a windows version themselves, that's fine, but why should you
limit the
usefulness of the software by adding such a label?
No serious business will invest money just to have the label disappear
and
it will not motivate anyone to donate any money to the team.
> I do want to encourage Git for Windows contributors to think about their
> incentives of working on Git. If it is for your own end, fine. If you
> publish your changes, even better.
>
> But if you work for somebody else's end, especially on Windows, which is a
> thoroughly commercial system, you should consider asking yourself
> what's in it for you, in the long run. To be able to sustain your
> contributions.
You clearly don't understand the free software movement.
> After all, a high degree of intelligence and experience and persistence is
> required to work on high-quality software. Which comes at a price.
When you have a mind that is solely focused on commercial development,
then yes.
But in free software it's not all about money...
> It's not about making Git "free" or "unfree". Git -- and therefore also
> Git on Windows -- _is_ free software. Free as in freedom. But that does
> not mean that the developers pushing Git for Windows should try their best
> to spend all their non-day job time to solve other people's problems for a
> warm handshake instead of spending their time with their family and
> friends. Because it _will_ wear them out.
I am not aware that anyone ever has been forced by their users to do
something
on their projects. If you have time and motivation to do something,
fine, if not
then it can (and has to) wait.
> That is a good naming we could easily have with a -preview suffix until
> the time that one or more companies compensate the top contributors of Git
> for Windows for their efforts.
>
> After all, the top two _Git_ developers were hired by Google, and are now
> paid top dollar.
These are once in a lifetime chances and don't happen that often.
Don't start
a project just because you want this to happen, because especially
then it won't.
> Just to clarify on my previous argument: there has been a _lot_ of time
> invested in Git for Windows. Last time I calculated, I myself put in
> easily a thousand hours of work just for the Windows port of Git. It is
> only fair to expect something more than requests (to stabilize, to fix, to
> support X, Y and Z) back. Be that code contributions, be that money.
No one is demanding something. These are (reasonable) questions or
suggestions
and obviously this team has a pretty unique approach to deal with
them.
> You mentioned yourself a couple of times that it is dirt-easy to build
> Git, and it is dirt-easy to build a Git installer.
>
> These are not things that just happen, or for that matter, that are
> provided in just a couple of free afternoon's time. These things cost
> _real_ time. We're talking about weeks and months of dedicated work.
This is how open source development works. Most people do it because
they
want to, not because they expect to get the big bucks out of it.
(which
happens rarely)
> ...
> In the upstream Git project, there seems to be no problem to find
> contributors who make an immense initial effort worthwhile because you get
> more back than you spent. For some reason, the same is not true in Git for
> Windows (I can count the contributors with one hand, using the binary
> system).
Windows has another kind of community. It's just not common here to
contribute.
> So, much as I respect Pat for what he did both with Tcl/Tk and Git for
> Windows, I _do_ think that it would be a wise thing to put in all the
> work to get Git for Windows into a shape competing with non-Windows
> versions of Git, but _only_ if due respect is paid either by contributions
> or in financial form.
>
> Everything else would just elicit fully deserved ridicule by anybody
> versed in the world of management and/or trading.
>
> Ciao,
> Dscho
>
> P.S.: When I happened to stumble upon a project manager of a company back
> last August who migrated his team to Git (for Windows) but had a number of
> complaints about stability, my suggestion to hire somebody to fix things
> was met with very wide eyes. He took Git for something God-given. But
> then, he also did not realize that he was talking to the Git for Windows
> maintainer. I fully believe that I deserve more respect (which equals
> money in the corporate world) than that.
This lies in the nature of open source, that some people just use what
is
free and don't think about the team and whether they should contribute
resources or money. But there are people that understand this and you
can
teach people what you expect and what they can do to support the
project.
When you are lucky you get finally contributions, but many projects
simply
don't. If you can't live with that you are probably not suited for
open source
projects.
Sorry if this sounds harsh, but this kind of argumentation is in my
mind as
bad as the project manager you have described...
Bye,
Patrick Cornelißen