From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: openembedded-devel <openembedded-devel@openembedded.org>,
openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: Feature Developement vs. Stablisation and Bug fixing
Date: Wed, 12 Sep 2012 13:17:40 +0100 [thread overview]
Message-ID: <1347452260.11710.3.camel@ted> (raw)
In-Reply-To: <20120912102508.GB8268@jama.jama.net>
On Wed, 2012-09-12 at 12:25 +0200, Martin Jansa wrote:
> On Wed, Sep 12, 2012 at 11:15:16AM +0100, Richard Purdie wrote:
> > Hi,
> >
> > I know in the past this has taken some people by surprise. Both OE-Core
> > and the Yocto Project are aiming at release points every six months,
> > roughly October and April. In order to prepare for those there is a
> > period of 6-8 weeks beforehand which is aimed at stabilisation and bug
> > fixing.
> >
> > We are now entering that window where we need to heavily taper off new
> > features and concentrate on the quality and stability of the release
> > which is scheduled for mid October. I'm not saying no new feature
> > patches will get taken but I will be asking questions like "why is this
> > being worked on?" and "shouldn't this wait until after release?". I'd
> > really like to see effort being focused on bugs now, not enhancements.
> >
> > I know there are a couple of things which have been worked on for a
> > while and have been slightly delayed which I'd probably lean towards
> > taking (some offline postinstall work spring to mind). I was asked
> > whether I'd take a binutils update in a couple of weeks and the answer
> > is no, I'd very likely not as we're at the point we need to lock in on
> > the toolchain now (and major kernel version).
> >
> > Does anyone have any questions?
>
> Is stuff discussed in thread:
> ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te?
> considered new feature or bug?
>
> In other words: should I try to test and send my proposed changes soon,
> or keep that for next cycle and just stop building qemuarm?
I'd consider this a bugfix but one we probably need to figure out sooner
than later...
Cheers,
Richard
WARNING: multiple messages have this Message-ID (diff)
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: openembedded-devel <openembedded-devel@openembedded.org>,
openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] Feature Developement vs. Stablisation and Bug fixing
Date: Wed, 12 Sep 2012 13:17:40 +0100 [thread overview]
Message-ID: <1347452260.11710.3.camel@ted> (raw)
In-Reply-To: <20120912102508.GB8268@jama.jama.net>
On Wed, 2012-09-12 at 12:25 +0200, Martin Jansa wrote:
> On Wed, Sep 12, 2012 at 11:15:16AM +0100, Richard Purdie wrote:
> > Hi,
> >
> > I know in the past this has taken some people by surprise. Both OE-Core
> > and the Yocto Project are aiming at release points every six months,
> > roughly October and April. In order to prepare for those there is a
> > period of 6-8 weeks beforehand which is aimed at stabilisation and bug
> > fixing.
> >
> > We are now entering that window where we need to heavily taper off new
> > features and concentrate on the quality and stability of the release
> > which is scheduled for mid October. I'm not saying no new feature
> > patches will get taken but I will be asking questions like "why is this
> > being worked on?" and "shouldn't this wait until after release?". I'd
> > really like to see effort being focused on bugs now, not enhancements.
> >
> > I know there are a couple of things which have been worked on for a
> > while and have been slightly delayed which I'd probably lean towards
> > taking (some offline postinstall work spring to mind). I was asked
> > whether I'd take a binutils update in a couple of weeks and the answer
> > is no, I'd very likely not as we're at the point we need to lock in on
> > the toolchain now (and major kernel version).
> >
> > Does anyone have any questions?
>
> Is stuff discussed in thread:
> ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te?
> considered new feature or bug?
>
> In other words: should I try to test and send my proposed changes soon,
> or keep that for next cycle and just stop building qemuarm?
I'd consider this a bugfix but one we probably need to figure out sooner
than later...
Cheers,
Richard
next prev parent reply other threads:[~2012-09-12 12:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 10:15 Feature Developement vs. Stablisation and Bug fixing Richard Purdie
2012-09-12 10:25 ` Martin Jansa
2012-09-12 10:25 ` [OE-core] " Martin Jansa
2012-09-12 12:17 ` Richard Purdie [this message]
2012-09-12 12:17 ` Richard Purdie
2012-09-12 11:52 ` Vladimir Zapolskiy
2012-09-12 12:16 ` Richard Purdie
2012-09-12 12:16 ` [OE-core] " Richard Purdie
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=1347452260.11710.3.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=openembedded-devel@openembedded.org \
/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.