Missing minor tags in master

[Sylvain Rabot]

Hi,

I noticed inconsistencies with the tags present in the master branch:

$ git tag --merged origin/master | grep '^v2.\d\d'
v2.10.0
v2.10.0-rc.0
v2.11.0
v2.11.0-rc.0
v2.11.1
v2.12.0
v2.12.0-rc.0
v2.13.0-rc.0
v2.14.0
v2.14.0-rc.0

I understand patch version tags not being merged into master (v2.11.1 was for some reason) but minor versions being missing like v2.15.0 is troubling.

Regards.

--

Sylvain Rabot <syl...@abstraction.fr>

[Goutham Veeramachaneni]

Hi I did a clean pull right now and here is what I see with plain git tag:

v2.10.0
v2.10.0-rc.0
v2.11.0
v2.11.0-rc.0
v2.11.1

v2.11.2
v2.12.0
v2.12.0-rc.0
v2.13.0
v2.13.0-rc.0
v2.13.1
v2.14.0
v2.14.0-rc.0
v2.15.0
v2.15.0-rc.0
v2.15.1
v2.15.2

I am not sure what --merged master does tbh, but we should have them in master too. Could you suggest a change here in the RELEASE doc so that we always end up with tags in master too? https://github.com/prometheus/prometheus/blob/master/RELEASE.md#draft-the-new-release

Thanks,

Goutham.

[Sylvain Rabot]

I am not sure what --merged master does tbh

It shows tags contained in the specified branch and currently the last tag contained in master is v2.14.0 although v2.15.0 has been released.

If you do a git describe --tags on master it gives:

$ git describe --tags master
v2.14.0-191-gbab47b58

git describe outputs: <last-tag-contained-in-current-branch>-<#-of-commits-since-last-tags>-g<HEAD-commit-id>

Could you suggest a change here in the RELEASE doc so that we always end up with tags in master too?

I will.

Cheers.

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/bde48989-79ec-4462-82b7-190128432d2d%40googlegroups.com.

--

Sylvain Rabot <syl...@abstraction.fr>

[Bjoern Rabenstein]

On 15.01.20 02:21, Goutham Veeramachaneni wrote:
>
> I am not sure what --merged master does tbh,

It means to show only tags that are somewhere in the parents (and
grand-parents and so on) of the current state of master.

> but we should have them in master too.

Yes.

> Could you suggest a change here in the RELEASE doc so that we always end
> up with tags in master too? https://github.com/prometheus/prometheus/blob/
> master/RELEASE.md#draft-the-new-release

They are already there. The release shephard just hasn't followed them
(yet). See
https://github.com/prometheus/prometheus/blob/master/RELEASE.md#branch-management-and-versioning-strategy

More concretely, the current `release-2.15` branch still has to be
merged back into master. (And presumably, the same is true for some
older release branches. Just not sure we should do it now.)

--
Björn Rabenstein
[PGP-ID] 0x851C3DA17D748D03
[email] bjo...@rabenste.in

[Bjoern Rabenstein]

BTW, this merge is hard because commits got cherrypicked instead of
first doing bugfixes in the release branch and then merge it back into
master:

https://github.com/prometheus/prometheus/commit/000e306f2fbb373bc37fa8e710553b072fac71a1
vs.
https://github.com/prometheus/prometheus/commit/13e88e5a49d5179ea44a58a1f1f78cece657fb8f

https://github.com/prometheus/prometheus/commit/c2e083c30f2cf94bfb5bc8bdfcb27dafb37e2349
vs.
https://github.com/prometheus/prometheus/commit/3b8ef6386cdad088bf3b1940bb78e8d745bbcd73

Again, the instructions are fine, they just have to be followed.

[Bjoern Rabenstein]

On 15.01.20 12:03, Bjoern Rabenstein wrote:
>

> More concretely, the current `release-2.15` branch still has to be
> merged back into master. (And presumably, the same is true for some
> older release branches. Just not sure we should do it now.)

I have done it now for `release-2.13`. It was a zero-diff commit, but
it pulled in eight presumably cherry-picked commits that were never
merged back.

$ git tag -l --merged | grep -F v2.13
v2.13.0
v2.13.0-rc.0

Looking into other releases now.

[Bjoern Rabenstein]

On 15.01.20 12:45, Bjoern Rabenstein wrote:
> On 15.01.20 12:03, Bjoern Rabenstein wrote:
> >
> > More concretely, the current `release-2.15` branch still has to be
> > merged back into master. (And presumably, the same is true for some
> > older release branches. Just not sure we should do it now.)
>
> I have done it now for `release-2.13`. It was a zero-diff commit, but
> it pulled in eight presumably cherry-picked commits that were never
> merged back.
>
> $ git tag -l --merged | grep -F v2.13
> v2.13.0
> v2.13.0-rc.0

One more word about v2.13.1: Krasi somehow managed to tag it in a
branch that is by now deleted. The commits are still on GH, but they
cannot be retrieved (by any means I know). The release-2.13 branch in
different, and doesn't have the v2.13.1 tag, although it seems to have
the content. That happened with a force-push or something.

Evilness of force-pushing once more.

[Bjoern Rabenstein]

On 15.01.20 12:45, Bjoern Rabenstein wrote:
>

> Looking into other releases now.

release-2.11 merged back (only resulting diff is the missing
CHANGELOG.md entry, so this was kind of good to do).

This time, it's not Krasi to blame, but Frederic.
(I blame blamelessly, of course. :o)

$ git tag -l --merged | grep -F v2.11
v2.11.0
v2.11.0-rc.0
v2.11.1
v2.11.2

[Bjoern Rabenstein]

And finally v2.5 done.

Frederic to blame again.

$ git tag -l --merged | grep -F v2.5
v2.5.0
v2.5.0-rc.0
v2.5.0-rc.1
v2.5.0-rc.2

I'm not going before v2.0.0. All released tags are now in master,
except 2.13.1, which could only be rescued if the branch still exist
somewhere locally.

And to reiterate, the instructions are fine. Just follow them. And
avoid cherry-picking. And avoid force-pushing. All the usual git best
practices.

[Sylvain Rabot]

Thanks.

What about v2.15.x ?

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200115121952.GZ5133%40jahnn.

--

Sylvain Rabot <syl...@abstraction.fr>

[Bjoern Rabenstein]

On 15.01.20 13:22, Sylvain Rabot wrote:
> Thanks.
>
> What about v2.15.x ?

I would leave that to the current release shepherd. I don't want to
interfere with their doings. Perhaps they have already something in
the pipeline.

Paging Bartek (now in cc): The release-2.15 branch hasn't been merged
back into master. Note that the merge will be a bit hairy as the
bugfixes were first merged into master and then cherrypicked into the
release branch (rather than first merging into the release branch and
then do a proper merge into master without cherry-picking, as
recommended in the instructions). For details, see earlier in this
thread.

[Brian Brazil]

On Wed, 15 Jan 2020 at 12:26, Bjoern Rabenstein <bjo...@rabenste.in> wrote:

On 15.01.20 13:22, Sylvain Rabot wrote:
> Thanks.
>
> What about v2.15.x ?

I would leave that to the current release shepherd. I don't want to
interfere with their doings. Perhaps they have already something in
the pipeline.

Paging Bartek (now in cc): The release-2.15 branch hasn't been merged
back into master. Note that the merge will be a bit hairy as the
bugfixes were first merged into master and then cherrypicked into the
release branch (rather than first merging into the release branch and
then do a proper merge into master without cherry-picking, as
recommended in the instructions

Note the recommended, how the release person does this is a matter of personal preference rather than dictated by the project (it's not something we have consensus on, and the last time we had a consensus it was for doing cherrypicks from master).

Personally I prefer this situation, compared to the where the fix is only on a branch and merging it back is complicated/forgotten so we end up losing the fix. If it's difficult to merge one way, I'd also expect it would have been just as difficult in the other direction.

Brian

 

). For details, see earlier in this
thread.

--
Björn Rabenstein
[PGP-ID] 0x851C3DA17D748D03
[email] bjo...@rabenste.in

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200115122624.GA5133%40jahnn.

--

Brian Brazil

www.robustperception.io

[Bjoern Rabenstein]

On 15.01.20 12:49, Brian Brazil wrote:
>
> Note the recommended, how the release person does this is a matter of personal
> preference rather than dictated by the project (it's not something we have
> consensus on, and the last time we had a consensus it was for doing cherrypicks
> from master).

My memory about the consensus is the opposite. At least I know for
sure that I never consented with cherrypicks.

I see the consensus as what is documented, and what's documented is
pretty clear. Repeatedly advertising to not follow what's recommended
in the documentation is not exactly collaborative, and it sparks the
same discussion over and over again.

There is clearly no consensus to change the current documentation. If
you think we should change it anyway, please start a formal vote
instead of going against the spirit of what's documented.

[Brian Brazil]

On Wed, 15 Jan 2020 at 13:22, Bjoern Rabenstein <bjo...@rabenste.in> wrote:

On 15.01.20 12:49, Brian Brazil wrote:
>
> Note the recommended, how the release person does this is a matter of personal
> preference rather than dictated by the project (it's not something we have
> consensus on, and the last time we had a consensus it was for doing cherrypicks
> from master).

My memory about the consensus is the opposite. At least I know for
sure that I never consented with cherrypicks.

You weren't present at that particular dev summit. I was honestly surprised at how quickly and non-contentiously it was discussed, given that branch management is one of those topics that tend to get heated.

I see the consensus as what is documented, and what's documented is
pretty clear. Repeatedly advertising to not follow what's recommended
in the documentation is not exactly collaborative, and it sparks the
same discussion over and over again.

There is clearly no consensus to change the current documentation. If
you think we should change it anyway, please start a formal vote
instead of going against the spirit of what's documented.

 

That there isn't consensus to change a document doesn't mean that the document represents the consensus, and repeated discussions also indicate a lack of consensus. As far as I'm aware your standpoint has never had consensus.

As it stands this works out to be a personal preference. From my standpoint if you want to do your releases this way go ahead, but I don't believe everyone should be forced to do things in the particular way you advocate.

--

Brian Brazil

www.robustperception.io

[Bjoern Rabenstein]

On 15.01.20 15:20, Brian Brazil wrote:
> On Wed, 15 Jan 2020 at 13:22, Bjoern Rabenstein <bjo...@rabenste.in> wrote:
>
> My memory about the consensus is the opposite. At least I know for
> sure that I never consented with cherrypicks.
>
> You weren't present at that particular dev summit.

There are multiple points to this:

- A consensus at the dev summit doesn't equal a consensus within the
team.

- I cannot see this claimed consensus documented anywhere in
dev-summit notes. So even if there was a consensus at the
dev-summit, it was never documented outside of it.

> That there isn't consensus to change a document doesn't mean that the document
> represents the consensus, and repeated discussions also indicate a lack of
> consensus. As far as I'm aware your standpoint has never had
> consensus.

That might all be true. But even if it were, the fair and
collaborative way of dealing with that situation would be to create a
PR for changing the documentation instead of deliberately acting
against it.

"Repeated discussions" are mostly those that you start over and over
again, ignoring what he had discussed before and thus stealing
everybody's time. The latest discussion was happening here:
https://github.com/prometheus/prometheus/pull/5634#discussion_r290763970

That discussions clarified a few misunderstandings, but in the end of
the day, there was no doubt that the aspects you don't agree with were
documented quite long ago and never changed substantially over time.

> As it stands this works out to be a personal preference. From my standpoint if
> you want to do your releases this way go ahead, but I don't believe everyone
> should be forced to do things in the particular way you advocate.

This is not about forcing my own way of doing things to others. This
is about the value of keeping the release management consistent. I
believe there is a lot of value in that (and the confusion about the
lack of tags in master is more evidence for that). Several team
members have expressed that they would like to keep the release
management consistent. This desire is after all the reason why we
documented the procedure in the first place.

This is indeed the opposite of leaving it to personal preference.

You have all the right to disagree with the guideline. But again,
please play fair and file a PR to change it instead of acting
deliberately and repeatedly against it.