Draft of Git Rev News edition 1

Draft of Git Rev News edition 1

[Christian Couder]

Hi,

A draft of Git Rev News edition 1 is available here:

https://github.com/git/git.github.io/blob/master/rev_news/draft/edition-1.md

Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub issue:

https://github.com/git/git.github.io/issues/17

You can also reply to this email.

I tried to cc the persons who appear in the edition but maybe I missed
some, sorry about that.

Thomas and myself plan to publish this edition on Wednesday the 25th of March.

We call it an "edition" instead of an "issue" to avoid confusion with
GitHub issues.

Thanks,
Christian

Re: Draft of Git Rev News edition 1

[David Kastrup]

Christian Couder <christian.couder@gmail.com> writes:

> Hi,
>
> A draft of Git Rev News edition 1 is available here:
>
> https://github.com/git/git.github.io/blob/master/rev_news/draft/edition-1.md
>
> Everyone is welcome to contribute in any section either by editing the
> above page on GitHub and sending a pull request, or by commenting on
> this GitHub issue:
>
> https://github.com/git/git.github.io/issues/17
>
> You can also reply to this email.

I've seen

    David Kastrup (dak at gnu.org) previously reimplemented significant
    parts of "git blame" for a vast gain in performance with complex
    histories and large files. As working on free software is his sole
    source of income, please consider contributing to his remuneration
    if you find this kind of improvements useful.

Thank you very much for this heads-up.  However, I'd replace
"previously" with "as of version 2.1.0".  That's where the big
difference is, so if people actually are impacted they'll know whether
and what to benchmark and/or upgrade.

-- 
David Kastrup

Re: Draft of Git Rev News edition 1

[Christian Couder]

On Sun, Mar 22, 2015 at 12:21 PM, David Kastrup <dak@gnu.org> wrote:
> I've seen
>
>     David Kastrup (dak at gnu.org) previously reimplemented significant
>     parts of "git blame" for a vast gain in performance with complex
>     histories and large files. As working on free software is his sole
>     source of income, please consider contributing to his remuneration
>     if you find this kind of improvements useful.
>
> Thank you very much for this heads-up.  However, I'd replace
> "previously" with "as of version 2.1.0".  That's where the big
> difference is, so if people actually are impacted they'll know whether
> and what to benchmark and/or upgrade.

Ok, there is now "as of version 2.1.0".

Re: Draft of Git Rev News edition 1

[Thomas Ferris Nicolaisen]

On Sun, Mar 22, 2015 at 12:21 PM, David Kastrup <dak@gnu.org> wrote:
>     David Kastrup (dak at gnu.org) previously reimplemented significant
>     parts of "git blame" for a vast gain in performance with complex
>     histories and large files. As working on free software is his sole
>     source of income, please consider contributing to his remuneration
>     if you find this kind of improvements useful.
>
> Thank you very much for this heads-up.

Do you have a link to where people can go to donate/contribute? I
searched around a bit but couldn't find anything.

Re: Draft of Git Rev News edition 1

[David Kastrup]

Thomas Ferris Nicolaisen <tfnico@gmail.com> writes:

> On Sun, Mar 22, 2015 at 12:21 PM, David Kastrup <dak@gnu.org> wrote:
>>     David Kastrup (dak at gnu.org) previously reimplemented significant
>>     parts of "git blame" for a vast gain in performance with complex
>>     histories and large files. As working on free software is his sole
>>     source of income, please consider contributing to his remuneration
>>     if you find this kind of improvements useful.
>>
>> Thank you very much for this heads-up.
>
> Do you have a link to where people can go to donate/contribute? I
> searched around a bit but couldn't find anything.

My Email address is linked at PayPal.  However, it's the more affordable
option in the Euro zone (which most definitely does not include GB) to
ask me for my bank account data: SEPA-region transfers are by EU law
required not to differentiate between in-country or cross-country
payments.

I don't maintain a personal home page or a blog or similar, so there is
really not much to point people to than my Email address.

-- 
David Kastrup

Re: Draft of Git Rev News edition 1

[Junio C Hamano]

Thanks.

The most important question I would ask you is this:

Did you two enjoy writing it?

That ends up counting the most, as it affects the quality of the
end result (readers would enjoy reading it and feel the love you
put into its production), and also its longer term relevance (if it
gets to be more burden than enjoyment to you, it won't last).

And I hope the answer is a resounding yes ;-)

A few comments:

 - Some might be a bit too detailed. Because each header is
   a pointer to the list archive, picking only the points that you
   found are the most thought-provoking may be a good way
   to shorten it (and readers interested in the topic can follow
   the link). Another would be to drop the mention like "Junio
   also reviewed..." that does not say what was said in the
   review. If a review did not have much thought-provoking
   value to deserve a summary, perhaps it is enough only to
   leave it to be discovered by readers who are so interested
   to follow the link to find the full discussion.

 - You do not list your own contribution to the discussions,
   but you should. Of course it would take some discipline
   to prevent the newsletter from appearing to have a self-
   promoting agenda, but I think you two are adult enough
   to be capable of handling that ;-)

 - As a periodical, you would want to have "This edition covers
   period between these two dates" at the beginning of each
   and every edition. Publication date may serve as the upper
   bound of the range, but for an inaugural one, it is essential
   to have the date the coverage begins.

 - As an inaugural edition, we may want to have a word on
   the purpose of the publication. Perhaps a sentence or two
   to declare what the publication is about in the "Welcome to"
   section is good. I would imagine that the primary purpose
   is to cover the discussions on the list (but don't call that
   "the list" in this paragraph, but spell it out to help readers,
   as "the Git mailing list") that is not visible in the "git log"
   output from my tree.

 - As an inaugural edition, we may want to have a word on
   how it came in existence by covering the discussion that
   led to its birth. Perhaps the discussion that led to the
   publication should be made into as an item on its own,
   next to "make git-pull a builtin", "Forbid log --graph..." etc.
   Because it is neither a review nor a support discussion,
   "Reviews & Support" heading may want to become
   "Discussions". I think that is a better title for the section
   anyway, if its purpose is "what happened on the list that
   are not visible from "git log", as I expect future editions
   to cover design discussions that advanced the shared
   understanding of a problem but not quite solidified to
   become a patch series.

> Thomas and myself plan to publish this edition on Wednesday the 25th of March.
>
> We call it an "edition" instead of an "issue" to avoid confusion with
> GitHub issues.

Good thinking.

Thanks again.

Re: Draft of Git Rev News edition 1

[Thomas Ferris Nicolaisen]

On Sun, Mar 22, 2015 at 7:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thanks.
>
> The most important question I would ask you is this:
>
> Did you two enjoy writing it?

To be clear, apart from some minor wording and nitpicking, I only
contributed the links from outside the list. This is an activity I
mostly do regardless, either on Twitter or at Google+. Gathering the
links in Git Rev News just means I collect them in a central place
instead of sporadically posting on social media. So I think I can keep
it up for an extended period, and if I ever get fed up, there are
hopefully others who can keep that part going.

Refining list activity into headlines, like Christian did, is a bigger
challenge in my eyes. I think this depends on having someone active on
the list, who also has time for producing this reader's digest.

I guess the long term success depends, as with any volunteer effort,
on how many others join in the fun, and how popular it gets outside
the list.

>  - As a periodical, you would want to have "This edition covers
>    period between these two dates" at the beginning of each
>    and every edition. Publication date may serve as the upper
>    bound of the range, but for an inaugural one, it is essential
>    to have the date the coverage begins.

Good point. There hasn't been a decision on frequency. Weekly is a
good rhythm for publications seeking readership, but that's a lot of
work. My vote is we should first aim for a monthly consistent release.
I'll try working this into the draft, and Christian may change as he
sees fit.

>  - As an inaugural edition, we may want to have a word on
>    the purpose of the publication. Perhaps a sentence or two
>    to declare what the publication is about in the "Welcome to"
>    section is good. I would imagine that the primary purpose
>    is to cover the discussions on the list (but don't call that
>    "the list" in this paragraph, but spell it out to help readers,
>    as "the Git mailing list") that is not visible in the "git log"
>    output from my tree.

Noted. I'l try working this in as well.

>  - As an inaugural edition, we may want to have a word on
>    how it came in existence by covering the discussion that
>    led to its birth. Perhaps the discussion that led to the
>    publication should be made into as an item on its own,
>    next to "make git-pull a builtin", "Forbid log --graph..." etc.
>    Because it is neither a review nor a support discussion,
>    "Reviews & Support" heading may want to become
>    "Discussions". I think that is a better title for the section
>    anyway, if its purpose is "what happened on the list that
>    are not visible from "git log", as I expect future editions
>    to cover design discussions that advanced the shared
>    understanding of a problem but not quite solidified to
>    become a patch series.
>

I hope it's OK that I leave this bit to Christian.

Thanks for the feedback!

Re: Draft of Git Rev News edition 1

[Junio C Hamano]

Thomas Ferris Nicolaisen <tfnico@gmail.com> writes:

> Good point. There hasn't been a decision on frequency. Weekly is a
> good rhythm for publications seeking readership, but that's a lot of
> work. My vote is we should first aim for a monthly consistent release.
> I'll try working this into the draft, and Christian may change as he
> sees fit.

I agree weekly would be too much for any hobbist, given how
high-volume our list has, but I probably shouldn't have said
"periodical".  Surely, aiming for consistent update is a very good
thing to gain reader trust if anything else, but it is OK if it were
"we will see a new release when enough interesting things happen",
too.

The primary reason I suggested to explicitly state the beginning of
coverage is to set and manage the expectation of the readers.  I
think the current draft roughly covers 1/4 - 1/3 of discussions that
happened in the month of March 2015 and nothing earlier than that,
so "This issue covers what happened in March" or something would be
appropriate.  I'll throw a pull-request.

>>  - As an inaugural edition, we may want to have a word on
>>    how it came in existence by covering the discussion that
>>    led to its birth. Perhaps the discussion that led to the
>>    publication should be made into as an item on its own,
>>    next to "make git-pull a builtin", "Forbid log --graph..." etc.
>>    Because it is neither a review nor a support discussion,
>>    "Reviews & Support" heading may want to become
>>    "Discussions". I think that is a better title for the section
>>    anyway, if its purpose is "what happened on the list that
>>    are not visible from "git log", as I expect future editions
>>    to cover design discussions that advanced the shared
>>    understanding of a problem but not quite solidified to
>>    become a patch series.
>>
>
> I hope it's OK that I leave this bit to Christian.

I took a stab at this myself, and threw another pull-request.

Thanks.

Re: Draft of Git Rev News edition 1

[Christian Couder]

On Mon, Mar 23, 2015 at 5:49 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Thomas Ferris Nicolaisen <tfnico@gmail.com> writes:
>
>> Good point. There hasn't been a decision on frequency. Weekly is a
>> good rhythm for publications seeking readership, but that's a lot of
>> work. My vote is we should first aim for a monthly consistent release.
>> I'll try working this into the draft, and Christian may change as he
>> sees fit.
>
> I agree weekly would be too much for any hobbist, given how
> high-volume our list has, but I probably shouldn't have said
> "periodical".  Surely, aiming for consistent update is a very good
> thing to gain reader trust if anything else, but it is OK if it were
> "we will see a new release when enough interesting things happen",
> too.

Yeah, I prefer not to commit to a specific frequency...

> The primary reason I suggested to explicitly state the beginning of
> coverage is to set and manage the expectation of the readers.  I
> think the current draft roughly covers 1/4 - 1/3 of discussions that
> happened in the month of March 2015 and nothing earlier than that,
> so "This issue covers what happened in March" or something would be
> appropriate.  I'll throw a pull-request.

... but I agree that we should say what we cover.

>>>  - As an inaugural edition, we may want to have a word on
>>>    how it came in existence by covering the discussion that
>>>    led to its birth. Perhaps the discussion that led to the
>>>    publication should be made into as an item on its own,
>>>    next to "make git-pull a builtin", "Forbid log --graph..." etc.
>>>    Because it is neither a review nor a support discussion,
>>>    "Reviews & Support" heading may want to become
>>>    "Discussions". I think that is a better title for the section
>>>    anyway, if its purpose is "what happened on the list that
>>>    are not visible from "git log", as I expect future editions
>>>    to cover design discussions that advanced the shared
>>>    understanding of a problem but not quite solidified to
>>>    become a patch series.
>>>
>>
>> I hope it's OK that I leave this bit to Christian.
>
> I took a stab at this myself, and threw another pull-request.
>
> Thanks.

Thank you for your pull requests.
They are all merged and your name is in the Credits section at the end.

Thanks,
Christian.