Re: Yocto Project and OE - Where now?

[C Michael Sundius <msundius@sundius.com>]

As with anything Balance and compromise is what make the best projects, I
don't think I'd want ever recipe to stay forever be not useful to anyone,
but I've appreciated the efforts that OE has made (since I've been using it)
to generally not break things for people who have invested time in using it.

On Wed, Jan 19, 2011 at 2:23 PM, Khem Raj <raj.khem@gmail.com> wrote:

> On Wed, Jan 19, 2011 at 1:55 PM, C Michael Sundius <msundius@sundius.com>
> wrote:
> > It seems to me that this is a bit of a battle between the package
> > maintainers and the distro maintainers.. Looking at this from my
> managements
> > side of things, we use OE as a tool and its really just a means to the
> end.
> > our customers demand that we do not change things (versions of software),
> > they demand stability and they view a change in busybox or anything else
> a
> > threat to stability. our management has also made an edict that we can
> not
> > use gplv3. For completely non technical reasons we simply cannot move to
> new
> > package versions without a substantial business justification. I suspect
> > that that there are many (more than you realize) folk out there who are
> > using OE for their own distro. If you simply whack package versions
> because
> > something newer came out you will have these people maintaining separate
> > recipes and we'll be swamped with the load and this tool will loose one
> of
> > its best attributes.
> >
> > The comment that disturbed me was that distros should just move ahead
> > "because its making things hard for the package maintainer". That doesn't
> > wash with me because if people are using your package then you should
> > support it or let someone else be the maintainer.
>
> I think keeping packages forever is not going to work either. If your
> customer is someone with EOL of 20 years
> OE should not keep versions you need just for you unless you invest
> efforts in keeping that packages uptodate
> thats why releases are for.
>
> In essence the distro's
> > use of that package are your customers and the reason you have a job. OE
> > does not exist as a product, rather a tool that enables customers, you
> can't
> > create this in a vacuum without understanding who is using it.
> >
>
> yes and assuming a package is being used by someone is also not the
> right thing. IMO for products you should
> base off on a release and maintain that for however long you wish and
> give some space to OE to develop. Extreme on
> both ends are unwanted thats why we are discussing what versions to
> keep. Keeping every possible version around has
> a cost and I believe if the recipe is not actively being tested its a
> bit-rot. So we are trying to reduce that burden on OE devs
> at the same time increase the quality of recipes.
>
> > distro maintainers are not all dumb and if they are they'll be the last
> > single one using an outdated version of the software. When that happens a
> > smart package maintainer will call it out leave out the old package.
> > Further, it would be nice for a warning to take place so that it might
> have
> > a "depracated" tag associated with the recipe for one release cycle to
> see
> > if anyone cribs.
>
>
> recipes move into obsolete/ or nonworking/ dirs thats enough of a warning
> imo
>
> >
> > So I'm standing with the guy w/ asbestos short on. I'd like to see that
> OE
> > err on the side of "do no harm" to existing users. Its hard enough to
> rally
> > the troops to move to updated packages much less updated meta without you
> > leaving perfectly reasonable versions of software out of oe-core.
> >
> > mike
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>