Any comment about upcoming Git Rev News edition 97
chriscool opened this issue · 29 comments
A currently mostly empty draft is there:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-97.md
Feel free to comment in this issue, suggest topics, suggest persons to interview, or use the edit button (that looks like a pen) to edit and create a pull request with the changes you would like.
Let's try to publish this edition on Wednesday March 29th 2023!
Thanks!
Is there a notability threshold for the 'Releases' section? https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-97.md#releases
FYI: As I'm away on a trip, unfortunately I'll not be able to contribute an interview for this edition either.
@hickford, @chriscool could answer yoir question about the notability requirements for the tool being mentioned in the "Releases" section.
Meanwhile, could you let us know which specific tool you have in mind?
@hickford Sorry for the late answer. It looks like your message fell into the cracks. Our main criteria is that the tool should be related to Git. We don't mind mentioning new tools or not well known ones, and we usually accept all PRs about this.
The reasons there are not so many tools mentioned are:
- we use a script (see https://github.com/chriscool/getreleases) customized for some of the tools we think are the most popular to generate most of this section, and
- we don't receive a lot of PRs to mention other tools.
So feel free to send a PR and we can discuss about the tool you have in mind there. You might even want to send a PR to improve https://github.com/chriscool/getreleases so that the new releases of your tool could be automatically added.
A few discussion that might be worth considering adding to this (or the next) Git Rev News:
- Question: How range-diff lapjv algorithm work
- git bug: Perl compatible regular expressions do not work as expected,
but I think it is not finished yet
@hickford Sorry for the late answer. It looks like your message fell into the cracks. Our main criteria is that the tool should be related to Git. We don't mind mentioning new tools or not well known ones, and we usually accept all PRs about this.
I have manually added Gitea 1.19.0 to this edition
This edition would most likely be a bit too late for Video conference libification eng discussion, this Thursday 16:30UTC (where "this Thursday" means 29.03.2023, and "video conference" means Google Meet.
But there are to be notes from the meeting, and the meeting is planned to occur every Thursday.
A few discussion that might be worth considering adding to this (or the next) Git Rev News:
@jnareb thanks for the suggestions. I will take a look at them for the next edition.
@jnareb thanks for your links!
And yeah I will try to mention the libification discussions.
I am again very late but I will send a draft later today...
A few discussion that might be worth considering adding to this (or the next) Git Rev News:
@jnareb thanks for the suggestions. I will take a look at them for the next edition.
The first link (Question: How range-diff lapjv algorithm work) is to quite short discussion, but the explanation how it the current state came to be is in my opinion quite interesting - maybe something to consider if you don't have any discussion for this edition already picked up, and maybe even written about...
Thanks but I have already something that I plan to push really soon now...
Just sent the draft: https://lore.kernel.org/git/CAP8UFD1fLOYpa85BmLfKgboFKs41ThzbH1gofhE3KwnwA1QnsA@mail.gmail.com/
Also added a link to an article by @pks-t about Git repo maintenance at GitLab in bfeb28b
@jnareb as you added a number of links about AI, you might want to also add some of the following GitLab related recent ones:
https://about.gitlab.com/blog/2023/03/23/ai-assisted-code-suggestions/
https://about.gitlab.com/blog/2023/03/16/what-the-ml-ai/
https://about.gitlab.com/blog/2023/02/23/machine-learning-and-devsecops/
and perhaps older ones from:
@jnareb as you added a number of links about AI, you might want to also add some of the following GitLab related recent ones:
All those links were about generating commit messages with Large Language Model; neither of those links is about this issue.
"GitLab’s AI Assisted Code Suggestions are available to select Ultimate customers in a closed beta."
Looks like something similar to (existing) GitHub Copilot, which uses OpenAI Codex, and is a paid service. The difference might be locally trained ML model. (GitHub also announced technical preview of GitHub Copilot X.)
On one hand, this has the chance of being more useful, assuming that the model is well trained, and that mechanism to exclude bad examples works correctly, than writing commit messages - where either the message is trivial, or it needs information which is not available in the changeset itself.
On the other hand, code completion and code suggestions is less connected to version control and Git than suggesting commit messages. The only connection is that this (and Copilot) code suggestion service is done by Git hosting service. But there exist other such solutions, like Tabnine, or no longer existing Kite.
That looks like a good suggestion. Beside the usual hype about use of AI / ML in software development, the article mentions 2 existing solutions, namely Suggested Reviewers and GitLab Code Suggestions (see previous link) - both available only to paid Ultimate users. It also mentions possible future ML related improvements.
I would very much like to know more details about the algorithm used for suggesting reviewers, beside "using the changes in a merge request and a project’s contribution graph".
This is also interesting article about problems specific to Machine Learning models, related to versioning the code and versioning the data. In this case, interaction with model registry (and deployment, and retraining after "data drift").
I'd like to take a wider look at the ML <-> GitDevOps ecosystem, including OctoML mentioned in linked article, and tools such as DVC, CML, MLEM, MLflow, Weights & Biases - many of which are unfortunately closed source paid services.
and perhaps older ones from:
I'll take a look, thanks.
That looks like a good suggestion. Beside the usual hype about use of AI / ML in software development, the article mentions 2 existing solutions, namely Suggested Reviewers and GitLab Code Suggestions (see previous link) - both available only to paid Ultimate users. It also mentions possible future ML related improvements.
I have added this link in 331831c
I would very much like to know more details about the algorithm used for suggesting reviewers, beside "using the changes in a merge request and a project’s contribution graph".
The related repos seem to be here: https://gitlab.com/gitlab-org/modelops/applied-ml/review-recommender/ I don't have much time to search them now though.
@jnareb thanks for adding the link about use of AI / ML in software development!
Thanks @mjaix !
I have doubts about the first change (shown using --word-diff) in the following sentences:
"Another possibility he mentioned was that the shortening
code, which [-used-]{+uses+} scanf(), was assuming that the resulting string
could not be longer than the input, but that this might be wrong
when some [-unicode-]{+Unicode+} normalization and locale [-are-]{+were+} used."
where you replaced "used" with "uses".
I thought it was better to put all the verbs in the past tense like what you did by replacing "are" with "were" at the end of the last sentence above.
This is especially true because the patches that will be developed and then merged will get rid of the scanf() call.
This edition would most likely be a bit too late for Video conference libification eng discussion, this Thursday 16:30UTC (where "this Thursday" means 29.03.2023, and "video conference" means Google Meet.
@jnareb I added links to the announce of the discussion and the email with the notes in 06f0dc1
But there are to be notes from the meeting, and the meeting is planned to occur every Thursday.
It would be nice if we could automatically report about such meetings, as well as the review club, and the resulting notes. When I get some time I might take a look at improving the "getrelease" script to do it.
Edition published and announced in: https://lore.kernel.org/git/CAP8UFD3adabbwdvaCmEXW9fQ88s6Zniim42vR3cT7VMobxFoQg@mail.gmail.com/
I would very much like to know more details about the algorithm used for suggesting reviewers, beside "using the changes in a merge request and a project’s contribution graph".
The related repos seem to be here: https://gitlab.com/gitlab-org/modelops/applied-ml/review-recommender/ I don't have much time to search them now though.
Actually, it looks like this links only to client, with actual processing on server. There supposed to be links to actual implementation, but they 404 or redirect back to client.
What I would like to see is references to original papers with the actual ML algorithm for recommending reviewers described (or the algorithm adapted to recommending reviewers), but I could not find it (though I didn't search too hard).
@jnareb There is just another (last) change which I would not like to apply without getting your opinion - it would be changing the sentence "Those tools, as far as I understand it, do not take information from an issue tracker ..." to use "we" instead "I" from an editorial point-of-view, as your perception is most probably unanimously shared by the whole team.
I'm all right with that change.