* Feature Developement vs. Stablisation and Bug fixing
@ 2012-09-12 10:15 Richard Purdie
2012-09-12 10:25 ` Martin Jansa
2012-09-12 11:52 ` Vladimir Zapolskiy
0 siblings, 2 replies; 5+ messages in thread
From: Richard Purdie @ 2012-09-12 10:15 UTC (permalink / raw)
To: openembedded-core; +Cc: openembedded-devel
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?
Cheers,
Richard
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Feature Developement vs. Stablisation and Bug fixing
2012-09-12 10:15 Feature Developement vs. Stablisation and Bug fixing Richard Purdie
@ 2012-09-12 10:25 ` Martin Jansa
2012-09-12 12:17 ` Richard Purdie
2012-09-12 11:52 ` Vladimir Zapolskiy
1 sibling, 1 reply; 5+ messages in thread
From: Martin Jansa @ 2012-09-12 10:25 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-devel, openembedded-core
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
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?
Cheers,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Feature Developement vs. Stablisation and Bug fixing
2012-09-12 10:15 Feature Developement vs. Stablisation and Bug fixing Richard Purdie
2012-09-12 10:25 ` Martin Jansa
@ 2012-09-12 11:52 ` Vladimir Zapolskiy
2012-09-12 12:16 ` Richard Purdie
1 sibling, 1 reply; 5+ messages in thread
From: Vladimir Zapolskiy @ 2012-09-12 11:52 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-devel, openembedded-core
Hi Richard,
On 12.09.2012 13:15, 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?
>
do you expect to have a filed bug in Yocto's bugzilla to attract attention
to a problem, or published patchset with problem description and a fix is
sufficient?
With best wishes,
Vladimir
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Feature Developement vs. Stablisation and Bug fixing
2012-09-12 11:52 ` Vladimir Zapolskiy
@ 2012-09-12 12:16 ` Richard Purdie
0 siblings, 0 replies; 5+ messages in thread
From: Richard Purdie @ 2012-09-12 12:16 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: openembedded-devel, openembedded-core
On Wed, 2012-09-12 at 14:52 +0300, Vladimir Zapolskiy wrote:
> Hi Richard,
>
> On 12.09.2012 13:15, 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?
> >
>
> do you expect to have a filed bug in Yocto's bugzilla to attract attention
> to a problem, or published patchset with problem description and a fix is
> sufficient?
It doesn't have to have a bug number to be a fix to a valid problem so
as long as the problem is described in the patchset, that should be ok.
Cheers,
Richard
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Feature Developement vs. Stablisation and Bug fixing
2012-09-12 10:25 ` Martin Jansa
@ 2012-09-12 12:17 ` Richard Purdie
0 siblings, 0 replies; 5+ messages in thread
From: Richard Purdie @ 2012-09-12 12:17 UTC (permalink / raw)
To: Martin Jansa; +Cc: openembedded-devel, openembedded-core
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-09-12 12:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-12 10:15 Feature Developement vs. Stablisation and Bug fixing Richard Purdie
2012-09-12 10:25 ` Martin Jansa
2012-09-12 12:17 ` Richard Purdie
2012-09-12 11:52 ` Vladimir Zapolskiy
2012-09-12 12:16 ` Richard Purdie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox