Release frequency and active versions

[Jens Geyer <je...@hotmail.com>]

Hi,

this is to continue the slightly offtopic discussion that emerged on 
https://github.com/apache/thrift/pull/2785

 > > > You can still keep up the latest version in any release series 
that you consider "currently active". Accumulo has the latest 1.10.x and 
2.1.x right now. Hadoop has the latest 3.3.x, 3.2.x, and 2.10.x. 
ZooKeeper has 3.5.x, 3.6.x, 3.7.x, and 3.8.x (they might have a few 
extra that they need to remove, as per that INFRA policy, though). The 
Thrift PMC could make a similar decision to consider certain versions as 
"currently active", even if they are only active for critical fixes.

 > > But that's what we do. The most recent one.

 > Maybe I wasn't clear enough. What I was trying to say is that you 
could have more than one release series considered "currently active" 
and leave up the most recent of each series. That would still be 
compatible with INFRA release distribution policy.

I understood that. But that's the current policy anyways: We only have 
one active version. Of course PMC can change it, but then PMC should 
also come up with more people to actually do these releases. Because I 
won't.

Have fun,

JensG

Re: Release frequency and active versions

[Jens Geyer <je...@hotmail.com>]

 > put it up on the website in the developer section

We have this, maybe not overly perfect:

https://thrift.apache.org/docs/committers/ReleaseManagement.html

A lot of things have been effectively moved out and linked only during 
the last CMS switch. We in fact had the contents pulled in from SVN/Git 
in earlier versions, but that doesn't work so well with the current 
system, at least that's what I understood.

JensG



Am 27.04.2023 um 23:42 schrieb Christopher:
> On Thu, Apr 27, 2023 at 3:54 PM Jens Geyer <je...@hotmail.com> wrote:
>> Hello,
>>
>>
>>> For what it's worth, you don't actually need to release more frequently to
>>> declare additional versions as current or active. You could still make that
>>> rare, and only do it for very critical issues.
>> When there is opportunity people will use it, I'd guess.
>>
>>
>>> There still might be value
>>> in declaring some specific earlier releases as stable and current so people
>>> who have specific requirements (like a specific older GCC version or older
>>> Java version) know which versions are appropriate to use.
>> +1 I'm personally fine with that. Under the premise that I don't get
>> more work as a result, of course.
>>
>>
>>> Sometimes just
>>> opening the door for users a bit more can help grow the contributor base
>>> that will eventually help with releasing.
>> Not sure I can follow. Could you explain that a bit more? I somehow miss
>> the connection between "we now have two more branches actively
>> maintained" and the unleashed stream of contributions we should expect
>> as a result. I mean, I would love to see that happen, that's for sure.
> You said it better than I did above: "When there is opportunity people
> will use it, I'd guess."
> The idea is that if you create the opportunity to contribute to those
> branches, that helps attract contributors. But I would not expect an
> "unleashed stream". Maybe a very slight trickle. :)
>
>>
>>> Related: is the release prep/staging process automated or documented at all?
>> Sure. Pretty good actually thanks to Jim King.
>>
>> https://github.com/apache/thrift/blob/master/doc/ReleaseManagement.md
>>
>> That was the only documentation I had when I took over that task (more
>> or less by accident) and I somehow managed to get it done. So that
>> document can't be too bad :-)
> That's a pretty good document. I think it might be good to put it up
> on the website in the developer section
> https://thrift.apache.org/developers . I can also see some places that
> could be automated a bit more. But there's also some gaps (like
> publishing libthrift jars to Maven Central through
> repository.apache.org). I'm somewhat interested in contributing to
> this, but don't want to create JIRA issues for everything, as that
> feels like double the work and my time is very limited. I'd rather
> just do PRs. I wonder if that is preventing other contributors from
> contributing more also.
>
>>
>> Have fun,
>>
>> JensG
>>
>>

Re: Release frequency and active versions

[Christopher <ct...@apache.org>]

On Thu, Apr 27, 2023 at 3:54 PM Jens Geyer <je...@hotmail.com> wrote:
>
> Hello,
>
>
> > For what it's worth, you don't actually need to release more frequently to
> > declare additional versions as current or active. You could still make that
> > rare, and only do it for very critical issues.
>
> When there is opportunity people will use it, I'd guess.
>
>
> > There still might be value
> > in declaring some specific earlier releases as stable and current so people
> > who have specific requirements (like a specific older GCC version or older
> > Java version) know which versions are appropriate to use.
>
> +1 I'm personally fine with that. Under the premise that I don't get
> more work as a result, of course.
>
>
> > Sometimes just
> > opening the door for users a bit more can help grow the contributor base
> > that will eventually help with releasing.
>
> Not sure I can follow. Could you explain that a bit more? I somehow miss
> the connection between "we now have two more branches actively
> maintained" and the unleashed stream of contributions we should expect
> as a result. I mean, I would love to see that happen, that's for sure.

You said it better than I did above: "When there is opportunity people
will use it, I'd guess."
The idea is that if you create the opportunity to contribute to those
branches, that helps attract contributors. But I would not expect an
"unleashed stream". Maybe a very slight trickle. :)

>
>
> > Related: is the release prep/staging process automated or documented at all?
>
> Sure. Pretty good actually thanks to Jim King.
>
> https://github.com/apache/thrift/blob/master/doc/ReleaseManagement.md
>
> That was the only documentation I had when I took over that task (more
> or less by accident) and I somehow managed to get it done. So that
> document can't be too bad :-)

That's a pretty good document. I think it might be good to put it up
on the website in the developer section
https://thrift.apache.org/developers . I can also see some places that
could be automated a bit more. But there's also some gaps (like
publishing libthrift jars to Maven Central through
repository.apache.org). I'm somewhat interested in contributing to
this, but don't want to create JIRA issues for everything, as that
feels like double the work and my time is very limited. I'd rather
just do PRs. I wonder if that is preventing other contributors from
contributing more also.

>
>
> Have fun,
>
> JensG
>
>

Re: Release frequency and active versions

[Jens Geyer <je...@hotmail.com>]

Hello,


> For what it's worth, you don't actually need to release more frequently to
> declare additional versions as current or active. You could still make that
> rare, and only do it for very critical issues.

When there is opportunity people will use it, I'd guess.


> There still might be value
> in declaring some specific earlier releases as stable and current so people
> who have specific requirements (like a specific older GCC version or older
> Java version) know which versions are appropriate to use.

+1 I'm personally fine with that. Under the premise that I don't get 
more work as a result, of course.


> Sometimes just
> opening the door for users a bit more can help grow the contributor base
> that will eventually help with releasing.

Not sure I can follow. Could you explain that a bit more? I somehow miss 
the connection between "we now have two more branches actively 
maintained" and the unleashed stream of contributions we should expect 
as a result. I mean, I would love to see that happen, that's for sure.


> Related: is the release prep/staging process automated or documented at all?

Sure. Pretty good actually thanks to Jim King.

https://github.com/apache/thrift/blob/master/doc/ReleaseManagement.md

That was the only documentation I had when I took over that task (more 
or less by accident) and I somehow managed to get it done. So that 
document can't be too bad :-)


Have fun,

JensG

Re: Release frequency and active versions

[Christopher <ct...@apache.org>]

Definitely off topic there (sorry!). Thanks for changing the venue for this
discussion.

I have never looked up who is on the Thrift PMC, so I don't even know who
is part of that and who isn't. But I wonder if there might be an issue of
not a large enough PMC if there isn't enough people on it willing to help
releases through. Regular committers can prepare/stage release candidates
but can't vote on releases, so there isn't really much incentive to
initiate them, and the may not feel empowered to help with releases.
Releases are primarily a PMC responsibility. So if more releases are
desired, there might be a need for more PMC members, or for the current PMC
to be more explicit about how non-PMC folks can participate in the release
workflow (other than testing and providing non-binding votes). Just
something to consider.

For what it's worth, you don't actually need to release more frequently to
declare additional versions as current or active. You could still make that
rare, and only do it for very critical issues. There still might be value
in declaring some specific earlier releases as stable and current so people
who have specific requirements (like a specific older GCC version or older
Java version) know which versions are appropriate to use. Sometimes just
opening the door for users a bit more can help grow the contributor base
that will eventually help with releasing.

Related: is the release prep/staging process automated or documented at all?

On Wed, Apr 26, 2023, 16:32 Jens Geyer <je...@hotmail.com> wrote:

> Hi,
>
> this is to continue the slightly offtopic discussion that emerged on
> https://github.com/apache/thrift/pull/2785
>
>  > > > You can still keep up the latest version in any release series
> that you consider "currently active". Accumulo has the latest 1.10.x and
> 2.1.x right now. Hadoop has the latest 3.3.x, 3.2.x, and 2.10.x.
> ZooKeeper has 3.5.x, 3.6.x, 3.7.x, and 3.8.x (they might have a few
> extra that they need to remove, as per that INFRA policy, though). The
> Thrift PMC could make a similar decision to consider certain versions as
> "currently active", even if they are only active for critical fixes.
>
>  > > But that's what we do. The most recent one.
>
>  > Maybe I wasn't clear enough. What I was trying to say is that you
> could have more than one release series considered "currently active"
> and leave up the most recent of each series. That would still be
> compatible with INFRA release distribution policy.
>
> I understood that. But that's the current policy anyways: We only have
> one active version. Of course PMC can change it, but then PMC should
> also come up with more people to actually do these releases. Because I
> won't.
>
> Have fun,
>
> JensG
>
>
>
>
>
>