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
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
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
"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.
Freeipa-devel mailing list