From: Martin Jansa <martin.jansa@gmail.com>
To: Laszlo Papp <lpapp@kde.org>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-qt5] Update to 5.1.1?
Date: Tue, 8 Oct 2013 15:58:42 +0200 [thread overview]
Message-ID: <20131008135842.GD2872@jama> (raw)
In-Reply-To: <CAOMwXhOwkTL7KbGcvDrtaBru7Se4hpQpVZ91L2yj7Q15xZcg7g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3158 bytes --]
On Tue, Oct 08, 2013 at 02:50:59PM +0100, Laszlo Papp wrote:
> On Tue, Oct 8, 2013 at 2:39 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>
> > On Tue, Oct 08, 2013 at 02:30:05PM +0100, Laszlo Papp wrote:
> > > On Tue, Oct 8, 2013 at 2:26 PM, Denys Dmytriyenko <denis@denix.org>
> > wrote:
> > > > Since Dora is a branch of meta-qt5, I don't understand your statements
> > > > about
> > > > being orthogonal and not integrated...
> > > >
> > >
> > > You will be able to use *any* meta-qt5 on top of Dora, just as you can
> > use
> > > meta-qt5 on top of denzil nowadays. The "dora branching" sounds like red
> > > herring to me. The dependencies in Dora will be good enough for 1-2
> > years,
> > > if not much more.
> >
> > That's not true, we were just lucky that there weren't any incompatible
> > changes in oe-core, but as soon as 1.6. brings e.g. new cmake, master
> > branch will work only with master and dora only with dora (because of
> > .bbappend).
> >
>
> I am not sure who it is not true. Qt has been working for me, and even if
> there are small quirks, they community can and will provide changes. Even
> if they could not, they can use .bbappend, and custom changes for any
> recipes. That is the strength of open embedded after all. It is very
> unlikely that everyone will always like every package.
That's basically what I said, if they use unsupported combination, they
can expect that they will maybe need to resolve some quirks on their
own.
> So the same branch names are the only supported combination, if you want
>
> > to use meta-qt5/master with oe-core/dylan then you're on your own. It
> > works now, but only because we're lucky.
> >
>
> IMO, this is unreasonable. It will cause additional overhead and looking at
> the manpower behind this layer, I am not really sure it is worth it.
> Quality should be over quantity. Maintaining several branches rather than
> just having one and well-qualified branch for starter would be more
> fruitful in my opinion.
Everything goes to master first, bugfixes can go also to release
branches which track older oe-core releases, the same rules which apply
to meta-oe and other layers apply here.
> > > 5.2 comes with several fundamental improvements. I would not personally
> > > recommend Qt 5.1 to anyone in about two months time when the release can
> > > happen. :)
> >
> > There are companies still using 5.0.0 just because they fear to upgrade
> > or because newer qt versions were released to late for their release
> > cycle of real hw products. I agree that it would be nice for everybody
> > to just use latest, but there are still meta-qt5 users which cannot do
> > that.
> >
>
> So what? They can always use bbappend, own packages, old branches, etc.
> That should be in no way obstacle for new innovation.
Yes, that's why meta-qt5 will exist in "old branch" for each oe-core
release and such branches will get only bug fixes, because people who
cannot upgrade oe-core to latest probably don't want to upgrade qt5 to
latest as well.
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
next prev parent reply other threads:[~2013-10-08 13:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-07 18:01 [meta-qt5] Update to 5.1.1? Denys Dmytriyenko
2013-10-07 18:29 ` Eric Bénard
2013-10-07 18:37 ` Denys Dmytriyenko
2013-10-07 18:57 ` Eric Bénard
2013-10-07 19:33 ` Martin Jansa
[not found] ` <CAOMwXhNV3q5P_+kCZtnDNUpZpG-OvMoe7Rem=cw86Z6vx8WmbA@mail.gmail.com>
2013-10-07 19:49 ` Denys Dmytriyenko
2013-10-07 20:15 ` Martin Jansa
2013-10-07 20:23 ` Denys Dmytriyenko
[not found] ` <CAOMwXhMpx8KjDyq_4fD949owFWE8r1O61E7D085+U31=fR5kNg@mail.gmail.com>
2013-10-07 20:35 ` Denys Dmytriyenko
2013-10-08 0:57 ` Trevor Woerner
2013-10-08 1:03 ` Denys Dmytriyenko
2013-10-08 1:03 ` Otavio Salvador
[not found] ` <CAOMwXhORbuT7J8B6evLhcJSx2Z8BUCoAeXKGDe=twQsuY-wtOQ@mail.gmail.com>
2013-10-08 13:21 ` Denys Dmytriyenko
[not found] ` <CAOMwXhN4C=Lob8ow9utU6hnqDOUjpt=PGj+Rp6W-pbnY5uky1g@mail.gmail.com>
2013-10-08 13:26 ` Denys Dmytriyenko
[not found] ` <CAOMwXhP_EobkzYT91BQGLjqWWOtsvTwzYSPk9MJHsMRm1q7otQ@mail.gmail.com>
2013-10-08 13:39 ` Martin Jansa
[not found] ` <CAOMwXhOwkTL7KbGcvDrtaBru7Se4hpQpVZ91L2yj7Q15xZcg7g@mail.gmail.com>
2013-10-08 13:58 ` Martin Jansa [this message]
2013-10-08 14:16 ` Denys Dmytriyenko
2013-10-08 15:47 ` Trevor Woerner
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=20131008135842.GD2872@jama \
--to=martin.jansa@gmail.com \
--cc=lpapp@kde.org \
--cc=openembedded-devel@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox