>>>> Foreman 1.10
>>>> ============
>>>> Foreman 110 Schedule - Foreman
>>>>
>>>> Based on a mid August release of 1.9.0, I set the anticipated 1.10.0
>>>> date to the start of December. Branching will be mid-October, so we are
>>>> 1.5 months into the 3.5 month development period.
>>>
>>> I was wondering what folks think about this pace. Is this too fast, too
>>> slow? Are folks skipping version upgrades to lower amount of production
>>> upgrades?
>>
>> The data from the survey early this year was pleasantly surprising:
>> http://blog.theforeman.org/2015/02/foreman-community-survey-results.html
>>
>> "1.7.x was around for about one month and a half at the time the survey
>> was released. We support the two latest minor versions (1.7 and 1.6 in
>> this case) so 86% of the installations are officially supported"
>>
>> Though it's likely IMHO that the survey respondents weren't
>> representative of the entire population.
>>
>> I generally think it's a pretty aggressive schedule for a large piece of
>> software, but one that is working OK. I think we have a reasonable
>> balance between the sizes of the releases, the effort going into RCs and
>> maintenance.
>>
>> Moving to some sort of smaller (to 1/3 or 1/4 of the size), monthly
>> release schedule is quite tempting to me too. In particular, I'd like
>> to reduce the number of release candidates as that's a lot of extra work.
>
> Less than 3 months makes it harder for any substantial plugin. The way
> it is now, when you all merge a change that affects foreman_salt, I'll
> get notified by the weekly Jenkins test (hopefuly) and I know I can fix
> it somewhat at my leisure in time for the RC's.
>
> Then I spin up the first RC and test the plugin to see if the tests
> missed something, and fix it if needed (e.g. they didn't catch select2
> broke the JS).
>
> That pace works really well for me to maintain a plugin on the side. I
> feel like monthly releases would put an extra time pressure and I'd
> struggle to keep up.
>
> If Foreman adopted monthly releases, with a long-term supported release
> (6-12 month), then that would be ok and I could target LTS, but I'm not
> sure that'd solve anything.
Sure, you hit the nail on the head with one of the potential problems.
Sorry, I hadn't intended it as a serious proposal.
I would however like to avoid making the development period much longer,
as the releases increase in size and risk.
> Another thought, why are the RC's so much work? Is it possible to
> automate more? I know Katello is slightly different, but the release
> process for 2.3 was not really ideal, and I spent a lot of time trying
> to figure out all these manual steps. I know Eric is working on
> more automation, but this again seems to be a case where the two
> projects could benefit from efficiencies of working together.
>
> Why can't Jenkins create the first RC including branch structure, Koji
> tags, etc for Katello and Foreman with one button?
Branching happens 3-4 times a year and can be spread over a couple of
weeks as different subprojects become ready, so isn't something that I
think warrants full automation now, especially in Jenkins. It also
changes slightly on every release, which would make it harder to
maintain (steps are kept on Release_Process today). Some of it's
scripted, but generally it touches on a load of different things.
RCs are simply another minor release, it follows the same process.
During one major release, there will be around 6-9 RC+minor releases, so
cutting down that number saves time. Each RC/minor release takes up to
half a day's work, including cherry picking, tagging, running the
automation, updating packaging, verifying the automation, writing
releases notes etc.
I automated a lot of the packaging, test and release process a while
ago, and will continue to work on optimising bits of it as and when I can.
I'd like to continually build stable branches in the same way we do with
nightlies, but that requires some thought about how to do versioning and
tagging.
···
On 12/08/15 18:25, Stephen Benjamin wrote:
> On Wed, Aug 12, 2015 at 04:08:32PM +0100, Dominic Cleal wrote:
>> On 12/08/15 15:53, Lukas Zapletal wrote:
–
Dominic Cleal
Red Hat Engineering
