[oe] Plans for OE classic future

Sat Nov 26 22:49:02 UTC 2011

Am Samstag, den 26.11.2011, 15:33 -0700 schrieb Tom Rini:
> On Sat, Nov 26, 2011 at 3:01 PM, Paul Menzel wrote:
> > Am Samstag, den 26.11.2011, 14:36 -0700 schrieb Tom Rini:
> >> On Sat, Nov 26, 2011 at 8:49 AM, Frans Meulenbroeks wrote:
> >> > 2011/11/26 Tom Rini
> >> >
> >> >> On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson wrote:
> >> >> > On 2011-11-25 23:04, Tom Rini wrote:
> >> >> >>
> >> >> >> On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks wrote:
> >> >> >>
> >> >> >>> After all, isn't one of the purposes of OE to promote information
> >> >> >>> sharing,
> >> >> >>> cooperation and the use of openembedded technology (and not make things
> >> >> >>> harder).
> >> >> >>
> >> >> >> One of the points of making master read-only would be to ensure that
> >> >> >> changes aren't lost.
> >> >> >>
> >> >> >> Perhaps the transition needs to be:
> >> >> >> - master is as it is today
> >> >> >> - master becomes oe-core backport || master-only bugfixes only
> >> >> >> - master becomes read only.
> >> >> >>
> >> >> >> And we go from the first step to the second step sometime sooner
> >> >> >> rather than later.  The top of my head date would be before the
> >> >> >> paid-developers go on end of year breaks to try and make sure all the
> >> >> >> hobbyist folks start their hacking with oe-core+etc rather than master
> >> >> >> and risk getting caught later.  I'm open to arguments on why that's
> >> >> >> exactly backwards...
> >> >> >>
> >> >> >
> >> >> > Won't it be a problem for existing projects, if you cannot add fixes to
> >> >> cope
> >> >> > with new host OS versions.
> >> >> >
> >> >> > At the moment, openembedded-classic does not build properly with Ubuntu
> >> >> > 11.10 .
> >> >>
> >> >> Won't what be a problem?  Either oe-core+meta-oe+etc fails on 11.10
> >> >> (so, fix it there first then backport changes) or it's fine and you
> >> >> can either find the relevant changes there and move them or it's a
> >> >> oe.dev-only bug and just needs to be fixed, under my proposal (until
> >> >> we reach the point where everyone is OK calling it r/o).
> >> >>
> >> >> And part of this is to say that yes, existing projects external to
> >> >> oe.dev need to move to oe-core(+meta-oe+whatever else) (where layers
> >> >> should be making their life easier or again, there's problems we're
> >> >> unaware of and need to be made aware of) or explain why they can't
> >> >> ever move (and are forking the project?).
> >> >
> >> > See the message on NIOS that I just posted.
> >>
> >> Addressed there :)
> >>
> >> > Also I am not opposed to making oe classic master the place where patches
> >> > may land before they end up in the maintenance thread, but I am strongly
> >> > opposed to making OE classic read only on short notice (which as suggested
> >> > by Koen earlier).
> >>
> >> I believe master needs to go read-only, or at least
> >> backport||master-only-problems bugfix only, sooner rather than later.
> >>
> >> The arguments seem to be:
> >> - Some people or projects use master and can't move
> >> * So don't move, but do expect to need to either migrate to
> >> 2011.03-maintenance or carry more fixes locally.
> >
> > This is still not understandable. I understand that you want developers
> > to move to OE-core and meta-oe. But trying to force people by making
> > master read-only is the wrong way. It just arbitrarily puts a burden on
> > current users. You can advertise prominently that OE-core and meta-oe
> > should be used. Over the time people will move and a lot of people have
> > expressed their willingness to move in the future.
> 
> Well, on this side of the fence I think we're unclear what more needs
> to be said.

Like Frans and Bernhard wrote, for new users a README on OE-classic
would be nice and the Wiki needs to be updated. Maybe also a deprecation
notice when pulling from the master branch.

For old users as also written no further comments are needed. They are
experienced enough and have heard your arguments. Now you should let
them make their own decisions even if you do not like it.

> In my mind, we couldn't do a technical branching of the repository, we
> made a new one. But people are still working off of a branch made
> against an 8 month old snapshot.  We really want to encourage this to
> stop.  If we were all in one repository still, it would be people
> saying "don't make legacy/main read-only!  I still want to add things
> to it!".

I did not understand that paragraph. Sorry.

> >> With my
> >> 2011.03-maintenance hat on, if someone says for my project to move I
> >> need N patches moved from master to maintenance, I'm fine reviewing
> >> that pull request.
> >
> > I thought that was always possible in the past.
> 
> It always has been, but since there's been confusion apparently about
> what can and cannot happen with the branch today, I want to spell it
> out.  I would be very happy to review whatever changes need to come in
> from master that would make $project be able to say "OK, I can use the
> maintenance branch until we have the time to move to oe-core/etc".
> 
> >> - There's concern that $something won't be able to work with oe-core+meta-oe+etc
> >> * These are problems that either need to be fixed or assumptions that
> >> aren't correct.
> >>
> >> - Lack of recipes in meta-oe
> >> * The recipes people need have been moved, stuff that isn't can be
> >> when someone needs it.  id3lib was mentioned as an example of why
> >> there might be problems getting things moved to meta-oe.  I can't help
> >> but notice it's also been moved into meta-oe.
> >
> > As Bernhard noted in this reply. OE-Core and meta-oe seriously lack
> > documentation. And if it is just that our Wiki currently is still based
> > on OE-classic. And in my experience not a lot of people put effort
> > behind it and just neglect it.
> >
> > (New users will search for tutorials and help on the WWW and there
> > currently a lot is dealing with OE-classic.)
> 
> Yes, and this is why I can understand wikihate.  So, consider this a
> beg for help, from anyone that likes wiki editing.  There's content to
> be updated, people that will answer questions when it's not clear, but
> just can't get into the groove on editing the wiki.

A lot of developers do not like to document things or to use a Web-Wiki.
I can understand the Wiki part because in my opinion a Web editor is
just unusable.

In my opinion the the community should seriously think about if a
MediaWiki setup has proven successful and if they think not first think
about if a Wiki is needed at all, secondly what should be documented and
lastly what tools developers might use.

There are a lot of Wiki setups maintained in a repository like ikiwiki
[1]. Adding a requirement to the guidelines that documentation also has
be updated would be a feasible solution in my opinion developers could
also live with since it is all managed in one repository.

There has been a thread about this in the past I think. So please open a
new thread if you put that up on the agenda.

Thanks,

Paul

[1] http://ikiwiki.info/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20111126/fdd152a1/attachment-0002.sig>