(Created page with "= Bootstrapping = * Obviously Stskeeps has started on the minimal Core, and started to identify Build (so it can be self-hosting) * Apps is already under formeego.org now * Commu...") |
(→The Plan) |
||
| Line 8: | Line 8: | ||
= The Plan = | = The Plan = | ||
| - | <blockquote>I don't think this is a case of pitching a proposal to Intel/LF. It won't work, it'll be ignored. This is a case of running a project how we think MeeGo should be run; and then letting it be folded back into MeeGo if it works (...and MeeGo's leadership want). | + | <blockquote>I don't think this is a case of pitching a proposal to Intel/LF. It won't work, it'll be ignored. This is a case of running a project how we think MeeGo should be run; and then letting it be folded back into MeeGo if it works (...and MeeGo's leadership want).<br><br> |
| - | Does that make it a fork? Does it matter? There's no governance in meego.com. Attempts to change it have failed. Architecture questions go unanswered. It's a broken project. | + | Does that make it a fork? Does it matter? There's no governance in meego.com. Attempts to change it have failed. Architecture questions go unanswered. It's a broken project.<br><br> |
| - | However, you keep the "fork" as closely aligned as possible; don't use names which are emotive and work with upstream together. Then, once it's proven to work, it merges back - like egcs, Xorg, ... | + | However, you keep the "fork" as closely aligned as possible; don't use names which are emotive and work with upstream together. Then, once it's proven to work, it merges back - like egcs, Xorg, ... <br><br> |
That's why it's a project called "blueprint.formeego.org". There is no way of doing this in a concrete way within the existing project at the moment. You consume MeeGo as upstream, but jiggle about who consumes what (i.e. a subset of OBS => Core, a subset of OBS => Tablet UX, lots of this gets put together => CE). You use the fact that formeego.org has already been signed off, so a name like "Blueprint for MeeGo" is a valid project name, and keeps associations with the older project. Demonstrate how it all can work and then merge back together. | That's why it's a project called "blueprint.formeego.org". There is no way of doing this in a concrete way within the existing project at the moment. You consume MeeGo as upstream, but jiggle about who consumes what (i.e. a subset of OBS => Core, a subset of OBS => Tablet UX, lots of this gets put together => CE). You use the fact that formeego.org has already been signed off, so a name like "Blueprint for MeeGo" is a valid project name, and keeps associations with the older project. Demonstrate how it all can work and then merge back together. | ||
</blockquote> | </blockquote> | ||
--Jaffa 13:44, 21 September 2011 (UTC)
I don't think this is a case of pitching a proposal to Intel/LF. It won't work, it'll be ignored. This is a case of running a project how we think MeeGo should be run; and then letting it be folded back into MeeGo if it works (...and MeeGo's leadership want).
Does that make it a fork? Does it matter? There's no governance in meego.com. Attempts to change it have failed. Architecture questions go unanswered. It's a broken project.
However, you keep the "fork" as closely aligned as possible; don't use names which are emotive and work with upstream together. Then, once it's proven to work, it merges back - like egcs, Xorg, ...
That's why it's a project called "blueprint.formeego.org". There is no way of doing this in a concrete way within the existing project at the moment. You consume MeeGo as upstream, but jiggle about who consumes what (i.e. a subset of OBS => Core, a subset of OBS => Tablet UX, lots of this gets put together => CE). You use the fact that formeego.org has already been signed off, so a name like "Blueprint for MeeGo" is a valid project name, and keeps associations with the older project. Demonstrate how it all can work and then merge back together.