On 28/11/2017 14:03, Evgeny Kotkov wrote:
> Branko Čibej <brane_at_apache.org> writes:
>
>>> I know this has been discussed before, but it was never made reality.
>>> On last week's hackathon we also didn't come to a full consensus on
>>> various details. But I think we should simply work out those details,
>>> hopefully come to some compromise, and if so, JFD it.
>> It has been discussed before and for a while we even did it this way.
>> The problem is that we're again at the point where we have to find a
>> reluctant volunteer to RM any release we want to make. So ...
>>
>> "There's no 'we' in Team" :p Some individual has to step up and do
>> this. The sort of release train you describe needs someone to drive it,
>> to whit, a "permanent" release manager. No amount of documentation and
>> schedules and good intentions will make this happen all by itself.
> I concur that the time-based releases most likely won't happen just based
> on the agreement, and that there has to be a person driving them.
>
> Perhaps, we could try this approach by finding a volunteer responsible for
> RM-ing the 1.11 release — for example, right after 1.10 is released.
>
The principle idea as layed out in your initial post sounds fine with
me. But as Evgeny and Brane already pointed out, this requires a
dedicated person who's driving things. So if you (or anybody else
stepping up) is driving this, I'm all for giving this a try and will
also review my signing procedure to speed things up for signing releases
faster.
FWIW: I think the details still need to get refactored a bit, but this
is something which can also be done at the time it becomes apparent.
Namely I'm thinking here that the release process might still require a
few weeks buffer time before shipping a new release and this should be
accounted for in the release roadmap (f.e. branch of a new release every
6 months with the release of that version happening around 1-2 months
later (time for signing and possibly having one or two RCs as it
happened with the 1.10 alpha builds for instance)). For this to not have
a rippling effect on following release, that buffer time should not
impact the time the next release is branched of, of course.
I'm also a bit worried about the acceptance of faster releases (i.e.
once every 6 months). Maybe we'd simply send out a mail to maintainers
polling for which time line they'd prefer (i.e. 6, 9, 12, 24 months for
new releases)? Just for us to get some idea on what those people who'd
be directly impacted by our decision would think about before we are
making a call?
Regards,
Stefan
Received on 2017-11-28 15:01:50 CET