First community release
Doron Fediuck
dfediuck at redhat.com
Wed Nov 30 07:14:56 UTC 2011
On Tuesday 29 November 2011 23:39:31 Yaniv Kaul wrote:
> On 11/29/2011 09:02 PM, Itamar Heim wrote:
> >
> >> -----Original Message-----
> >> From: arch-bounces at ovirt.org [mailto:arch-bounces at ovirt.org] On Behalf
> > Of Andrew Cathrow
> >> Sent: Tuesday, November 29, 2011 20:38 PM
> >> To: arch at ovirt.org
> >> Subject: Re: First community release
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Jon Choate"<jchoate at redhat.com>
> >>> To: arch at ovirt.org
> >>> Sent: Tuesday, November 29, 2011 1:32:27 PM
> >>> Subject: Re: First community release
> >>>
> >>> On 11/29/2011 12:58 PM, Barak Azulay wrote:
> >>>> On 11/29/2011 05:59 PM, Livnat Peer wrote:
> >>>>> On 11/07/2011 06:51 PM, Carl Trieloff wrote:
> >>>>>> At the workshop in the release / roadmap working session we
> >>>>>> agreed that
> >>>>>> around November 16th we see how all the distro's are making out
> >>>>>> in
> >>>>>> creating a release for oVirt and set the date for the first
> >>>>>> community
> >>>>>> release.
> >>>>>>
> >>>>>> Please have your comments / feedback for that time period, at
> >>>>>> which
> >>>>>> point I will start the release discussions.
> >>>>>>
> >>>>>> regards
> >>>>>> Carl.
> >>>>>> _______________________________________________
> >>>>>> Board mailing list
> >>>>>> Board at ovirt.org
> >>>>>> http://lists.ovirt.org/mailman/listinfo/board
> >>>>> Hi All,
> >>>>> Not sure where we stand with the first release but I think we
> >>>>> should
> >>>>> take into account the jboss version we use before releasing.
> >>>>>
> >>>>> We currently deploy on jboss as 5, but we started working on
> >>>>> deployment
> >>>>> on jboss as 7.
> >>>>> Releasing on AS 5 and then moving to AS 7 might require some
> >>>>> upgrade
> >>>>> path and it is a time consuming task to do that.
> >>>>>
> >>>>> Since we already started working on the deployment on jboss AS 7,
> >>>>> I
> >>>>> think it might worth holding back first 'formal' release until it
> >>>>> is
> >>>>> done. It will help us avoiding upgrade support and get all the
> >>>>> benefits
> >>>>> of using as7 (startup time, memory/cpu foot-print etc.) - get
> >>>>> better
> >>>>> reviews?
> >>>>>
> >>>>> Livnat
> >>>>
> >>>> I think we should aim for a fast first release, meaning ASAP on
> >>>> jboss 5
> >>>>
> >>>> The questions are:
> >>>>
> >>>> 1 - what is a release? a tag in all the repos to be picked up by
> >>>> each
> >>>> distro ?
> >>>> 2 - do we have any criteria on what is good enough for a release ?
> >>>> or
> >>>> any point in time that everybody feels ready?
> >>>>
> >>> I like to approach the idea in reverse:
> >>>
> >>> 1 - What is preventing us from releasing today?
> >>> 2- Are these really worth holding up the release?
> >>> 3 - What can we do today so that the issues in #1 are gone tomorrow?
> >>>
> >>> I too am unsure what a release really means when people can get the
> >>> code
> >>> any time that they want and we could declare a release whenever and
> >>> as
> >>> often as we want.
> >> A release should be easily installable by a non-developer.
> >> So in the case of RPM packaged content for Fedora that means yum install
> > ovirt.
> >> There's a lot of people who want to kick the tires but all the extra
> > command line hackery that they have to
> >> do scares them off and they may not return.
> >>
> >> Once we can do
> >> # yum install ovirt
> >> # ovirt-setup
> >>
> >> then it's ready to go.
> > I'd like to try and avoid the ovirt-setup step if possible, either via the
> > rpm or a service doing them.
>
> +1
>
> The whole simplified 'yum install ovirt' instead of 'yum install ovirt
> ovirt-backend ovirt-fronted ...' made few complications wrt package
> dependencies.
> I think we should revise this.
>
> > Per Jon's question, there are two main config items:
> > a. create/upgrade the db
> > this can be done manually today, but need to remember the next release
> > will need to be simple to upgrade to as well.
> > otherwise a user doing yum update will get a non-working system until they
> > will upgrade their db.
> >
> > b. configure the certificate
> > this can be done by the rpm, but will be based on the hostname, which
> > probably isn't always right. I think we can live with this if we let the
> > user to easily change it afterwards.
I agree w/ Itamar & Yaniv.
The 'yum install ovirt' is distro-specific. It's important we have it,
but we should leave enough room for other distro's to join in.
In that sense, as Carl suggested we should focus on a *stable* release of-
* Tagged source tarball allowing other distro's to fetch & build it.
* Latest binary tarball.
* A simplified RPM or make rpm script (Makefile based), along with DB and certificate creation scripts.
This should broaden the availability of oVirt to other Linux segments,
which find it hard to handle currently. As a hint take a look on the init-script
and networking thread we had in users and vdsm-devel lists.
--
/d
"Who's General Failure and why's he reading my disk?"
More information about the Arch
mailing list