[Freeipa-devel] git branching after 4.0

[Petr Viktorin]

I'm afraid this mail is not very clear for people who didn't participate 
in discussions behind these plans.

The planning of future work is of course Red Hat specific -- we can't 
dictate how others spend their time. Read our plans as "here's roughly 
what we want to do, does it fit in with your plans?"

Let me provide a few links and clarifications so everyone can follow 
along or join in!


On 07/04/2014 05:26 PM, Martin Kosek wrote:
> When 4.0 releases, there will be several development trains that we will
> need to manage in our git:
>
> 1) FreeIPA 4.0 bugfixing - tickets in 4.0.1 milestone, will go to
> ipa-4-0 branch

Milestones are here: https://fedorahosted.org/freeipa/report/3

> 2) FreeIPA 4.1 "small" development - 4.1 will be just a short release
> for the summer focused on Views, full support of DNSSEC, OTP local high
> watermark, Backup and Restore and other small features (and possibly
> also CA management tool).
>
> 3) FreeIPA 4.2 big development - this is a longer, more in the future
> (read Fedora 22 time frame) development with major features going in -
> Vault, User provisioning, publishing CA certs to clients and many others
> stuff still being scoped. It will include for example big updates to
> installers which should not go to more stable 4.1/4.0.x releases.
>
> How to handle that in git repo? Given that we do not do merge commits, I
> think the easiest way would be to:
>
> - When 4.0 releases, create ipa-4-0 and ipa-4-1 branches. This will
> leave us with master, ipa-4-1, ipa-4-0 active branches
> - 4.2 team will commit their work to master only
> - 4.1 team will commit their work to master, ipa-4-1
> - 4.0.x bugfixing team will commit their work to master, ipa-4-1 and
> ipa-4-0

+1
We just need to make sure the work won't overlap too much.

> This may sound complicated, but with Petr's ipatool pushing to multiple
> branches should be easy. Our CI should guard at least ipa-4-0 and
> ipa-4-1 branches for the summer (instead of ipa-3-3 and master) to
> report failures early.

My ipatool is available here: https://github.com/encukou/ipa-tools/ -- 
it's automation for some of the processes described at and around 
http://www.freeipa.org/page/Contribute

"Our CI" here means a Jenkins instance in Red Hat's internal lab. We're 
sorry it's not visible yet -- too much other work to do :(
The configuration is available, though 
(https://github.com/encukou/freeipa-ci), and I'd be happy to help if 
you'd like to set up a CI machine.

> If there is a better idea, please propose it. But this plan seemed to me
> as the most straightforward.

-- 
Petr³