[vdsm] Keeping VDSM Compatible with Ubuntu

[Alon Bar-Lev]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: vdsm-devel at lists.fedorahosted.org, infra at ovirt.org
> Sent: Saturday, September 28, 2013 10:24:00 PM
> Subject: Re: [vdsm] Keeping VDSM Compatible with Ubuntu
> 
> On 09/27/2013 04:16 PM, Ewoud Kohl van Wijngaarden wrote:
> > On Fri, Sep 27, 2013 at 03:53:08PM +0800, Zhou Zheng Sheng wrote:
> >> Recently we merged some patches to make VDSM run on Ubuntu. We also have
> >> some packaging scripts in the debian/ sub-dir. You can either build .deb
> >> packages manually or find binary packages from VDSM PPA [1] on
> >> launchpad.net. Once you add that PPA, you can use apt-get to install
> >> VDSM and its dependencies.
> >>
> >> I'll setup a Jenkins on my laptop to test the master branch
> >> automatically by build and install VDSM on Ubuntu, then running unit and
> >> functional tests. I suggest when adding a new change, it's better to
> >> make sure it is covered by unit or functional tests. If you change the
> >> packaging code, for example adding new options to configure.ac, editing
> >> vdsm.spec.in, and changing VDSM daemon startup behavior, I am happy to
> >> be invited to review your patch.
> >>
> >> I'd also like to listen to your suggestions on this topic, thanks!
> >
> > I'd recommend getting in touch with infra to set up an ubuntu slave to
> > ensure compatibility. We have our CI infra almost in a shape where we
> > can easily add new slaves.
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >
> 
> +1 - if you can get to run some sanity tests per vdsm patch, you can
> prevent bad things from happening rather than chase things after they broke

Usually I am for defining levels of support for each distribution (downstream), each level can contain more than one.

1st tier - always stable and up.
2nd tier - in tree support but synchronized periodically.
3rd tier - out of tree support endorsed by upstream.
4th tier - out of tree support.

It is hard enough to properly support 1st tier.

Requiring all developers to understand and not break packaging is hard enough, multiple packaging technologies is something that beyond valid requirement.

The role of 2nd tier maintainer is periodically perform whatever is needed in order to sync up, and for larger changes work to integrate the requirement of other platforms into a solution.

Of course from rc and beyond all 1st and 2nd tiers should be stable, so having automation to validate that is good at these stages.

Regards,
Alon Bar-Lev.