All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Philip Balister <philip@balister.org>
Cc: Tom Rini <trini@ti.com>, meta-ti@yoctoproject.org
Subject: Re: release branch for meta-ti?
Date: Sat, 31 Mar 2012 16:38:47 +0100	[thread overview]
Message-ID: <1333208327.18082.237.camel@ted> (raw)
In-Reply-To: <4F771465.7030708@balister.org>

On Sat, 2012-03-31 at 10:27 -0400, Philip Balister wrote:
> On 03/30/2012 06:17 PM, William Mills wrote:
> > On 03/30/2012 06:09 PM, Koen Kooi wrote:
> >>
> >> Op 19 mrt. 2012, om 14:05 heeft Tom Rini het volgende geschreven:
> >>
> >>> On Mon, Mar 19, 2012 at 05:02:47PM -0400, Denys Dmytriyenko wrote:
> >>>> On Mon, Mar 19, 2012 at 01:58:54PM -0700, Tom Rini wrote:
> >>>>> On Mon, Mar 19, 2012 at 01:58:36PM +0100, Koen Kooi wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Any volunteers for maintaining a releasebranch that matches the
> >>>>>> upcoming oe-core release in ~4 weeks?
> >>>>>
> >>>>> If Denys or Chase don't step-up, I'll do it.  As qualification, I do
> >>>>> such a thing for oe-classic currently :)  But if either of them would
> >>>>> rather, I'll defer to them.
> >>>>
> >>>> We'll probably need to set meta-oe-maintenance up anyway for
> >>>> meta-arago to
> >>>> work with, rather than chasing changes in the master...
> >>>
> >>> Yes, meta-oe will also need a maintenance release to match
> >>
> >> meta-oe branch is really close to having a maintainer, what's the
> >> (final) word on the meta-ti branch?
> > 
> > I have no objection to the branch to ensure the current working
> > functionality remains working with yocto maintenance releases.
> > 
> > However, I don't think we should actively maintain new features on both
> > branches.
> > 
> > So what is the goal of the branch?
> 
> People that ship OE based stuff to customers hate basing stuff that goes
> to customers based on layers that are under active development. We are
> much happier with layers that are getting fixes for existing problems only.

I'd echo this. Whilst its nice for developers to just keep iterating on
continual development, it doesn't actually work for users and having
some kind of release/stable branch helps a lot.

This is why the Yocto Project is having releases and those releases are
being maintained with point releases containing fixes. We don't add new
features in the release branches.

I'd strongly encourage this model to various layers. I appreciate its
not the way OE has worked in the past and it takes a bit of work to
change developer mindset on this though.

Cheers,

Richard





  reply	other threads:[~2012-03-31 15:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-19 12:58 release branch for meta-ti? Koen Kooi
2012-03-19 20:58 ` Tom Rini
2012-03-19 21:02   ` Denys Dmytriyenko
2012-03-19 21:05     ` Tom Rini
2012-03-19 21:13       ` Koen Kooi
2012-03-19 21:29         ` Denys Dmytriyenko
2012-03-30 22:09       ` Koen Kooi
2012-03-30 22:17         ` William Mills
2012-03-31 14:27           ` Philip Balister
2012-03-31 15:38             ` Richard Purdie [this message]
2012-04-09  2:18               ` Denys Dmytriyenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1333208327.18082.237.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=meta-ti@yoctoproject.org \
    --cc=philip@balister.org \
    --cc=trini@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.