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

Jeff King [off-list ref] writes:

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

quoted

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.

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

On Thu, 28 Aug 2008, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

    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.

quoted

  - 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 [off-list ref]
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047

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

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 [off-list ref]
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047