[oe] Plans for OE classic future

[Tom Rini]

On Sat, Nov 26, 2011 at 3:49 PM, Paul Menzel
<paulepanter at users.sourceforge.net> wrote:
> 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.

All sounds fine to me.

> 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.

So the question is, what is the long term plan for classic OE based
stuff?  The TSC has been saying, perhaps not with enough voice or
emphasis:
- 2011.03 is the last "release" of oe.dev (unless someone(s) step up
and wish to do another!)
- 2011.03-maintenance will be maintained as long as people are saying
they have a need for it.
- The master branch needs to go away somehow as the last step of
migration.  This is what I was trying to say below...

>> 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.

The analogy I'm trying to make between classic OE master branch and
behavior is that it wasn't "lets start from scratch with this new
repository and hope someday most people stop using the old tree" it
was "if we could cleanly do a 'git branch -m master legacy' and start
master as the new meta-oe repository, we would".

Now I'm going to make a Linux Kernel analogy.  The 2.4 series didn't
(nearly) go away for a long while after 2.6 came out, but after a
while the rules for what could go in got rather restrictive.

The direction the TSC has recommended for how to deal with classic OE
is to have the folks that can't yet move off of it be using the
maintenance branch.  It's not going to be pulled out from under
anyone.  It's just got rules about what kind of changes are allowed
in.  Today that's "must exist in relevant oe-core based layer or be
N/A in that world".  I can't imagine that changing until the user base
is small enough and themselves in a maintenance mode to be happy with
that too.

If anything it seems like there's an objection to switching classic OE
from "free for all" to the pull request (or patches posted) model
oe-core/meta-oe/etc are using.

[snip]
>> > 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.

I think this needs to happen, yes.  Thanks.

-- 
Tom