Future suggestion's to assist with changes to git.

Future suggestion's to assist with changes to git.

[Boyd Lynn Gerber]

I would like to have a positive outcome of all the theaded emails.  So 
this is an attempt to create a new thread that may focus on what can be 
done in the future.

>From other threads, this was very note-able and I think it is a good 
start for this new thread...

On Thu, 28 Aug 2008, Jeff King wrote:
> On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote:
>> But, my problem is not git<DASH> vs git<SPACE>, but the slap-dash way 
>> upward compatibility was broken and the "water over the dam" slippery 
>> slope rationalizations that refuse to consider reverting.  "You" will 
>> do it again in the future since you are declaring success here.  And 
>> "you" have likely done it in the past 6 months.
>
> I don't think Junio is declaring success. In fact, I think he has sent
> several messages saying (paraphrasing of course):
>
>  - this was obviously not done in the best manner possible, because of
>    the number of people complaining
>
>  - we will try to do better about notification next time such a change
>    is made. Please make suggestions about how to do so.
>
>  - since we have already released and already broken everybody, and
>    these people are now complaining on the list, there is not much
>    point in trying to notify people of _this_ change now

Maybe on item could be on the git web site news items could be created to 
announce backward compatibility changes.  I think most people do visit the 
main website to look for information.  Having these changes posted there 
or linked from the main page could be a positive method so something like 
this will not happen in the future.

> Junio (and others) have tried to be very careful about breaking
> backwards compatibility, especially for scripting interfaces. We thought
> sufficient steps were taken this time, but clearly some disagree.

+1, I am very grateful for the effort of all that try to keep this and the 
positive things done with git.  I really appreaciate what Junio does to 
notify every one on the email list.  What we learned is not everyone reads 
the changes being made with the announcements.  So maybe making a visible 
link or announcements on the main web page could assist with the 
notification and prevent future issues.

> So please stop making specious claims that there are crazy 
> backwards-incompatibility bugs lurking throughout new versions of git. 
> If there are, then please find and name them. If not, then I think the 
> git community would welcome suggestions about how better to notify users 
> about the rare changes like this one.
>
>
> -Peff

+1  So let's make constructive suggestions so we can prevent this in the 
future.

BTW, I dropped all the CC's to make sure this starts fresh.

Thanks,

--
Boyd Gerber <gerberb@zenez.com>
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047

Re: Future suggestion's to assist with changes to git.

[Jeff King]

On Thu, Aug 28, 2008 at 05:10:53PM -0600, Boyd Lynn Gerber wrote:

> Maybe on item could be on the git web site news items could be created to  
> announce backward compatibility changes.  I think most people do visit the 
> main website to look for information.  Having these changes posted there  
> or linked from the main page could be a positive method so something like  
> this will not happen in the future.

Do they? I haven't been to the git web site in quite a long time. Nor
have I been to (for example) the vim web site. The two things I would
personally notice are:

  - a note during upgrade of my system's packages. And this is going to
    be dependent on the packaging system used. 1.6.0 hasn't hit many
    distributions yet, so maybe there is still time for this. Gerrit,
    do you mind putting something into NEWS.Debian about the drop of
    "git-*" so that people with apt-listchanges will see it?

    For people building from source, we have the Release Notes, but
    beyond that, I don't know where to put it (and I don't meant the web
    site is a bad place -- the more places the better, but there is no
    catch-all place).

  - the command complaining that my use of it is deprecated. In
    retrospect, we probably should have done this.

-Peff

Re: Future suggestion's to assist with changes to git.

[Boyd Lynn Gerber]

On Thu, 28 Aug 2008, Jeff King wrote:
> On Thu, Aug 28, 2008 at 05:10:53PM -0600, Boyd Lynn Gerber wrote:
>> Maybe on item could be on the git web site news items could be created to
>> announce backward compatibility changes.  I think most people do visit the
>> main website to look for information.  Having these changes posted there
>> or linked from the main page could be a positive method so something like
>> this will not happen in the future.
>
> Do they? I haven't been to the git web site in quite a long time. Nor
> have I been to (for example) the vim web site. The two things I would
> personally notice are:

I only look at the web after reading the release notes.  But I think that 
if the web site had the notice then there could be no excuse about not 
having made it public.  Sure some people do not read the Release notes or 
follow the email lists, but maybe we could get those that miss the release 
notes or new users, a place to look in addition to the email list.  I know 
that it is hard to follow all the mails on the git list.

>  - a note during upgrade of my system's packages. And this is going to
>    be dependent on the packaging system used. 1.6.0 hasn't hit many
>    distributions yet, so maybe there is still time for this. Gerrit,
>    do you mind putting something into NEWS.Debian about the drop of
>    "git-*" so that people with apt-listchanges will see it?
>
>    For people building from source, we have the Release Notes, but
>    beyond that, I don't know where to put it (and I don't meant the web
>    site is a bad place -- the more places the better, but there is no
>    catch-all place).

+1.  I know that I expect break-eges on X.Y for many things.  So maybe a 
note on the website that git uses the second Y for compatiability changes 
could assist some users.

>  - the command complaining that my use of it is deprecated. In
>    retrospect, we probably should have done this.

I really want to make it possible to avoid any of these complaints in the 
future.  I knew it was comming and had to change my scripts, but I am just 
trying to provide further methods to announce changes that some may notice 
that miss the email list message.

I personally look at the change logs and release notes.  If something in 
them makes me really want more information then I go to the project web 
site to look.  I think new users would notice something on the web site 
and then could realise that maybe some example in old documents could have 
problem.  Just my outloud thinking.

Thanks,

--
Boyd Gerber <gerberb@zenez.com>
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047

Re: Future suggestion's to assist with changes to git.

[Jeff King]

On Thu, Aug 28, 2008 at 07:30:45PM -0400, Jeff King wrote:

>   - a note during upgrade of my system's packages. And this is going to
>     be dependent on the packaging system used. 1.6.0 hasn't hit many
>     distributions yet, so maybe there is still time for this. Gerrit,
>     do you mind putting something into NEWS.Debian about the drop of
>     "git-*" so that people with apt-listchanges will see it?

Oops, I meant to cc this originally to Gerrit. Gerrit, I am adding you
mid-discussion, so if you have missed the giant flamewar about "git-*",
I can fill you in. :)

-Peff

Re: Future suggestion's to assist with changes to git.

[Gerrit Pape]

On Thu, Aug 28, 2008 at 07:57:38PM -0400, Jeff King wrote:
> On Thu, Aug 28, 2008 at 07:30:45PM -0400, Jeff King wrote:
> >   - a note during upgrade of my system's packages. And this is going to
> >     be dependent on the packaging system used. 1.6.0 hasn't hit many
> >     distributions yet, so maybe there is still time for this. Gerrit,
> >     do you mind putting something into NEWS.Debian about the drop of
> >     "git-*" so that people with apt-listchanges will see it?
> 
> Oops, I meant to cc this originally to Gerrit. Gerrit, I am adding you
> mid-discussion, so if you have missed the giant flamewar about "git-*",
> I can fill you in. :)

Yes, I chose to miss it ;).  I'll put an entry into NEWS.Debian with the
next Debian package upload.

Regards, Gerrit.

Re: Future suggestion's to assist with changes to git.

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Thu, Aug 28, 2008 at 05:10:53PM -0600, Boyd Lynn Gerber wrote:
>
>> Maybe on item could be on the git web site news items could be created to  
>> announce backward compatibility changes.  I think most people do visit the 
>> main website to look for information.  Having these changes posted there  
>> or linked from the main page could be a positive method so something like  
>> this will not happen in the future.
>
> Do they? I haven't been to the git web site in quite a long time. Nor
> have I been to (for example) the vim web site. The two things I would
> personally notice are:
>
>   - a note during upgrade of my system's packages. And this is going to
>     be dependent on the packaging system used. 1.6.0 hasn't hit many
>     distributions yet, so maybe there is still time for this. Gerrit,
>     do you mind putting something into NEWS.Debian about the drop of
>     "git-*" so that people with apt-listchanges will see it?
>
>     For people building from source, we have the Release Notes, but
>     beyond that, I don't know where to put it (and I don't meant the web
>     site is a bad place -- the more places the better, but there is no
>     catch-all place).

That would help compared to doing nothing, but many people who complained
in the first thread (this is the third one, by the way) was k.org users
who used a machine somebody else installs the software for them.  Messages
during installation would not help those people.

>   - the command complaining that my use of it is deprecated. In
>     retrospect, we probably should have done this.

This is arguable.  People would have get annoying messages thrown into
their mailbox from their cron jobs, even before the switchover happened,
which effectively means that we move the whining period from now back to
the beginning of the deprecation period -- it won't reduce the amount of
actual whining.

Re: Future suggestion's to assist with changes to git.

[Jeff King]

On Thu, Aug 28, 2008 at 04:59:17PM -0700, Junio C Hamano wrote:

> That would help compared to doing nothing, but many people who complained
> in the first thread (this is the third one, by the way) was k.org users
> who used a machine somebody else installs the software for them.  Messages
> during installation would not help those people.

I think this can be generalized to "messages from the maintainer of your
systems". In the case of single-user installs, a message from the
package maintainer is appropriate. For a multi-user system, I would
expect a message from the admin to all of the users of the software.

> This is arguable.  People would have get annoying messages thrown into
> their mailbox from their cron jobs, even before the switchover happened,
> which effectively means that we move the whining period from now back to
> the beginning of the deprecation period -- it won't reduce the amount of
> actual whining.

Personally, I would rather have my task succeed with a little extra spew
to stderr than to fail completely. And that would get the people who
were against the change involved in the discussion at a much earlier
point.

-Peff

Re: Future suggestion's to assist with changes to git.

[Boyd Lynn Gerber]

On Thu, 28 Aug 2008, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>>     For people building from source, we have the Release Notes, but
>>     beyond that, I don't know where to put it (and I don't meant the web
>>     site is a bad place -- the more places the better, but there is no
>>     catch-all place).
>
> That would help compared to doing nothing, but many people who complained
> in the first thread (this is the third one, by the way) was k.org users
> who used a machine somebody else installs the software for them.  Messages
> during installation would not help those people.

Sorry, about that but I was starting to loose things with all the gigantic 
... thread.  I wanted to be able to see some things happen, from the long 
thread and felt that having the CC list as long as it was was not 
assisting in getting a resolution.

>>   - the command complaining that my use of it is deprecated. In
>>     retrospect, we probably should have done this.
>
> This is arguable.  People would have get annoying messages thrown into
> their mailbox from their cron jobs, even before the switchover happened,
> which effectively means that we move the whining period from now back to
> the beginning of the deprecation period -- it won't reduce the amount of
> actual whining.
>

I prefered the way it was done.  I would have hated the messages in my 
cron jobs.  Some of my cronjobs have everything going to /dev/null  When I 
am unable to convice the project to eliminate things like the above, I am 
forced to /dev/null them to be able to use them in a way that is not to 
annoying for me.  I really liked the way things were done with the 
exception of maybe a bit better communication.  But there will always be 
whiners.  Just want an other way to emphazise that things are going to 
change.  Maybe it will stop a few.

Thanks again for the good work done by all in the community.

--
Boyd Gerber <gerberb@zenez.com>
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047

Re: Future suggestion's to assist with changes to git.

[Perry Wagle]

Here's my relevant paragraph from the other thread:

I think the lesson here, however, it that the correct way to have done  
this is to first remove all the git<DASH>'s from the source, demos,  
sample, documentation, etc.  Second, BIG PAUSE (full minor version  
release cycle?) Then, third, get rid of git<DASH> in <prefix>/bin.

-- Perry

Re: Future suggestion's to assist with changes to git.

[Boyd Lynn Gerber]

On Thu, 28 Aug 2008, Perry Wagle wrote:
> Here's my relevant paragraph from the other thread:
>
> I think the lesson here, however, it that the correct way to have done this 
> is to first remove all the git<DASH>'s from the source, demos, sample, 
> documentation, etc.  Second, BIG PAUSE (full minor version release cycle?) 
> Then, third, get rid of git<DASH> in <prefix>/bin.

Thanks, I think having all the suggestions in one place without having to 
go through the long thread is a good idea.

Thanks,

--
Boyd Gerber <gerberb@zenez.com>
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047