[PATCH v2] vim: update to 8.1.1097

[PATCH v2] vim: update to 8.1.1097

[Oleksandr Kravchuk]

Signed-off-by: Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>
---
 .../vim/{vim-tiny_8.1.1017.bb => vim-tiny_8.1.1097.bb}          | 0
 meta/recipes-support/vim/{vim_8.1.1017.bb => vim_8.1.1097.bb}   | 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-support/vim/{vim-tiny_8.1.1017.bb => vim-tiny_8.1.1097.bb} (100%)
 rename meta/recipes-support/vim/{vim_8.1.1017.bb => vim_8.1.1097.bb} (98%)

diff --git a/meta/recipes-support/vim/vim-tiny_8.1.1017.bb b/meta/recipes-support/vim/vim-tiny_8.1.1097.bb
similarity index 100%
rename from meta/recipes-support/vim/vim-tiny_8.1.1017.bb
rename to meta/recipes-support/vim/vim-tiny_8.1.1097.bb
diff --git a/meta/recipes-support/vim/vim_8.1.1017.bb b/meta/recipes-support/vim/vim_8.1.1097.bb
similarity index 98%
rename from meta/recipes-support/vim/vim_8.1.1017.bb
rename to meta/recipes-support/vim/vim_8.1.1097.bb
index 7627d2844b..4de1bc3807 100644
--- a/meta/recipes-support/vim/vim_8.1.1017.bb
+++ b/meta/recipes-support/vim/vim_8.1.1097.bb
@@ -13,7 +13,7 @@ SRC_URI = "git://github.com/vim/vim.git \
            file://vim-add-knob-whether-elf.h-are-checked.patch;patchdir=.. \
            file://0001-src-Makefile-improve-reproducibility.patch;patchdir=.. \
 "
-SRCREV = "493fbe4abee660d30b4f2aef87b754b0a720213c"
+SRCREV = "4fc8e2f8bb3eb42df0f72cfcc1f8f8e567e7ce4f"
 
 S = "${WORKDIR}/git/src"
 
-- 
2.17.1

Re: [PATCH v2] vim: update to 8.1.1097

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

On Sun, Mar 31, 2019 at 05:50:12PM +0200, Oleksandr Kravchuk wrote:

> Signed-off-by: Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>
> ---
>  .../vim/{vim-tiny_8.1.1017.bb => vim-tiny_8.1.1097.bb}          | 0
>  meta/recipes-support/vim/{vim_8.1.1017.bb => vim_8.1.1097.bb}   | 2 +-
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-support/vim/{vim-tiny_8.1.1017.bb => vim-tiny_8.1.1097.bb} (100%)
>  rename meta/recipes-support/vim/{vim_8.1.1017.bb => vim_8.1.1097.bb} (98%)
> 
> diff --git a/meta/recipes-support/vim/vim-tiny_8.1.1017.bb b/meta/recipes-support/vim/vim-tiny_8.1.1097.bb
> similarity index 100%
> rename from meta/recipes-support/vim/vim-tiny_8.1.1017.bb
> rename to meta/recipes-support/vim/vim-tiny_8.1.1097.bb
> diff --git a/meta/recipes-support/vim/vim_8.1.1017.bb b/meta/recipes-support/vim/vim_8.1.1097.bb
> similarity index 98%
> rename from meta/recipes-support/vim/vim_8.1.1017.bb
> rename to meta/recipes-support/vim/vim_8.1.1097.bb
> index 7627d2844b..4de1bc3807 100644
> --- a/meta/recipes-support/vim/vim_8.1.1017.bb
> +++ b/meta/recipes-support/vim/vim_8.1.1097.bb
> @@ -13,7 +13,7 @@ SRC_URI = "git://github.com/vim/vim.git \
>             file://vim-add-knob-whether-elf.h-are-checked.patch;patchdir=.. \
>             file://0001-src-Makefile-improve-reproducibility.patch;patchdir=.. \
>  "
> -SRCREV = "493fbe4abee660d30b4f2aef87b754b0a720213c"
> +SRCREV = "4fc8e2f8bb3eb42df0f72cfcc1f8f8e567e7ce4f"
>  
>  S = "${WORKDIR}/git/src"

Looks better, thanks.  Is there a particular fix / change you're doing
this for?  I ask since every commit is a version bump we might want to
set a guideline of once a month or so for bumping vim to the latest.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2] vim: update to 8.1.1097

[Alexander Kanavin]

On Sun, 31 Mar 2019 at 22:12, Tom Rini <trini@konsulko.com> wrote:
> Looks better, thanks.  Is there a particular fix / change you're doing
> this for?  I ask since every commit is a version bump we might want to
> set a guideline of once a month or so for bumping vim to the latest.

It's a bit insane upstream is doing that.
Should we set PV to something like PV = "8.1+git${SRCPV}"? That way
devtool/AUH/RRS will not be reporting a new version for each commit,
and will only do that when 8.2 is out.

Alex

Re: [PATCH v2] vim: update to 8.1.1097

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

On Sun, Mar 31, 2019 at 10:19:51PM +0200, Alexander Kanavin wrote:
> On Sun, 31 Mar 2019 at 22:12, Tom Rini <trini@konsulko.com> wrote:
> > Looks better, thanks.  Is there a particular fix / change you're doing
> > this for?  I ask since every commit is a version bump we might want to
> > set a guideline of once a month or so for bumping vim to the latest.
> 
> It's a bit insane upstream is doing that.
> Should we set PV to something like PV = "8.1+git${SRCPV}"? That way
> devtool/AUH/RRS will not be reporting a new version for each commit,
> and will only do that when 8.2 is out.

No, we should follow what upstream does for version numbers, it's what
other distros do.  And on the related topic of "is it a stable branch?",
it does seem like yes, it is.  We should just remember to not update it
more often than say the first of the month, without a specific reason.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2] vim: update to 8.1.1097

[Paul Barker]

On Sun, 31 Mar 2019, at 21:56, Tom Rini wrote:
> On Sun, Mar 31, 2019 at 10:19:51PM +0200, Alexander Kanavin wrote:
> > On Sun, 31 Mar 2019 at 22:12, Tom Rini <trini@konsulko.com> wrote:
> > > Looks better, thanks. Is there a particular fix / change you're doing
> > > this for? I ask since every commit is a version bump we might want to
> > > set a guideline of once a month or so for bumping vim to the latest.
> > 
> > It's a bit insane upstream is doing that.
> > Should we set PV to something like PV = "8.1+git${SRCPV}"? That way
> > devtool/AUH/RRS will not be reporting a new version for each commit,
> > and will only do that when 8.2 is out.
> 
> No, we should follow what upstream does for version numbers, it's what
> other distros do. And on the related topic of "is it a stable branch?",
> it does seem like yes, it is. We should just remember to not update it
> more often than say the first of the month, without a specific reason.

When I've done vim updates in the past I aimed for once every 3 months. I also looked at Debian/Fedora/etc to find a version that someone else has already tested in a distribution - with vim having so many "releases" you have the same issue you'd get from picking a random commit off the master branch from another project. Matching against a version used somewhere else gives us something to compare to when we hit a bug.

Thanks,

-- 
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd

Re: [PATCH v2] vim: update to 8.1.1097

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

On Sun, Mar 31, 2019 at 06:28:31PM -0400, Paul Barker wrote:
> On Sun, 31 Mar 2019, at 21:56, Tom Rini wrote:
> > On Sun, Mar 31, 2019 at 10:19:51PM +0200, Alexander Kanavin wrote:
> > > On Sun, 31 Mar 2019 at 22:12, Tom Rini <trini@konsulko.com> wrote:
> > > > Looks better, thanks. Is there a particular fix / change you're doing
> > > > this for? I ask since every commit is a version bump we might want to
> > > > set a guideline of once a month or so for bumping vim to the latest.
> > > 
> > > It's a bit insane upstream is doing that.
> > > Should we set PV to something like PV = "8.1+git${SRCPV}"? That way
> > > devtool/AUH/RRS will not be reporting a new version for each commit,
> > > and will only do that when 8.2 is out.
> > 
> > No, we should follow what upstream does for version numbers, it's what
> > other distros do. And on the related topic of "is it a stable branch?",
> > it does seem like yes, it is. We should just remember to not update it
> > more often than say the first of the month, without a specific reason.
> 
> When I've done vim updates in the past I aimed for once every 3
> months. I also looked at Debian/Fedora/etc to find a version that
> someone else has already tested in a distribution - with vim having so
> many "releases" you have the same issue you'd get from picking a
> random commit off the master branch from another project. Matching
> against a version used somewhere else gives us something to compare to
> when we hit a bug.

That's also a good idea, yes.  My only concern is finding something
moving forward otherwise quickly enough, but Fedora might do well for
that.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2] vim: update to 8.1.1097

[Oleksandr Kravchuk]

On 01/04/2019 00:31, Tom Rini wrote:
> On Sun, Mar 31, 2019 at 06:28:31PM -0400, Paul Barker wrote:
>> On Sun, 31 Mar 2019, at 21:56, Tom Rini wrote:
>>> On Sun, Mar 31, 2019 at 10:19:51PM +0200, Alexander Kanavin wrote:
>>>> On Sun, 31 Mar 2019 at 22:12, Tom Rini <trini@konsulko.com> wrote:
>>>>> Looks better, thanks. Is there a particular fix / change you're doing
>>>>> this for? I ask since every commit is a version bump we might want to
>>>>> set a guideline of once a month or so for bumping vim to the latest.
>>>> It's a bit insane upstream is doing that.
>>>> Should we set PV to something like PV = "8.1+git${SRCPV}"? That way
>>>> devtool/AUH/RRS will not be reporting a new version for each commit,
>>>> and will only do that when 8.2 is out.
>>> No, we should follow what upstream does for version numbers, it's what
>>> other distros do. And on the related topic of "is it a stable branch?",
>>> it does seem like yes, it is. We should just remember to not update it
>>> more often than say the first of the month, without a specific reason.
>> When I've done vim updates in the past I aimed for once every 3
>> months. I also looked at Debian/Fedora/etc to find a version that
>> someone else has already tested in a distribution - with vim having so
>> many "releases" you have the same issue you'd get from picking a
>> random commit off the master branch from another project. Matching
>> against a version used somewhere else gives us something to compare to
>> when we hit a bug.
> That's also a good idea, yes.  My only concern is finding something
> moving forward otherwise quickly enough, but Fedora might do well for
> that.

I think it is indeed a good idea for maintainers to look up for stable
projects, e.g Debian.

It would be nice to have those guidelines set and clear though.