threads / discuss / 15264

Future suggestion's to assist with changes to git.

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

## tl;dr

10 messages between Aug 28, 2008 and Aug 29, 2008.

replies: 9people: 5as markdown or json

Boyd Lynn Gerber· Aug 28, 2008, 23:10 UTC · lore

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:
Show 19 quoted lines
> 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.

Show 8 quoted lines
> 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

Jeff King· Aug 28, 2008, 23:30 UTC · re: Boyd Lynn Gerber · lore

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

On Thu, Aug 28, 2008 at 05:10:53PM -0600, Boyd Lynn Gerber wrote:
Show 5 quoted lines
> 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
Boyd Lynn Gerber· Aug 28, 2008, 23:48 UTC · re: Jeff King · lore

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

On Thu, 28 Aug 2008, Jeff King wrote:
Show 10 quoted lines
> 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.

Show 10 quoted lines
>  - 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

Jeff King· Aug 28, 2008, 23:57 UTC · re: Jeff King · lore

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

On Thu, Aug 28, 2008 at 07:30:45PM -0400, Jeff King wrote:
Show 5 quoted lines
>   - 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
Gerrit Pape· Aug 29, 2008, 06:50 UTC · re: Jeff King · lore

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

On Thu, Aug 28, 2008 at 07:57:38PM -0400, Jeff King wrote:
Show 10 quoted lines
> 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.
Junio C Hamano· Aug 28, 2008, 23:59 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:
Show 22 quoted lines
> 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.

Jeff King· Aug 29, 2008, 00:06 UTC · re: Junio C Hamano · lore

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

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.

Show 5 quoted lines
> 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
Boyd Lynn Gerber· Aug 29, 2008, 00:11 UTC · re: Junio C Hamano · lore

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

On Thu, 28 Aug 2008, Junio C Hamano wrote:
Show 10 quoted lines
> 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.

Show 9 quoted lines
>>   - 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

Perry Wagle· Aug 29, 2008, 00:31 UTC · re: Boyd Lynn Gerber · lore

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

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
Boyd Lynn Gerber· Aug 29, 2008, 00:50 UTC · re: Perry Wagle · lore

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

On Thu, 28 Aug 2008, Perry Wagle wrote:
Show 6 quoted lines
> 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

← back to recent threads