ShiftPlusOne wrote: ↑Sat Feb 23, 2019 11:02 pm
Sorry I was a bit vague there.
I've got permission to add your kernel and userland packages to the official repo, so yeah there's no problem with that. If you're okay with it, that's the plan.
If I try to push it further and integrate it into raspi-config or other packages it starts to involve more people.
No problem, getting a version of this into the official repo is a fantastic opportunity in any event!
And a significant responsibility. On reflection, I think you're probably right that this needs to support multiple guest images, so the core design issue to be solved for the first 'real' release is how best to 'un-hardcode' to achieve that, allowing users to add/publish their own OS images for use with it, without getting sucked into something so complex people may as well use docker ^-^
I'm keen that the design process for this is a) time bounded and b) happens in the open, since the basis for this project so far has really been ideas from others in the community, rather than something I've come up with myself, and all the better for that.
So, how does the following rough schedule sound?
Next few days: I'll publish some high-level project goals / scope / principles for review in this thread; comments and suggestions from all actively invited. Next couple of weeks these can then be honed (and I can get the next
gentoo-on-rpi3-64bit release out of the way, to free up some bandwidth).
Fri Mar 8: Goal review period ends. Hopefully also we'd be in a position where the current three demo deb packages were available as a baseline 'show me':
- The 64-bit kernel package - which seems to be in a pretty good shape right now and probably won't have to change that much - hopefully by this point getting auto-generated as required, via cron/hook?
- The debian-stretch-64 userland image package is just an untar, so hopefully not too complex to package (obviously, dealing with this properly for multiple images, versioning of images etc. will be something to deal with for the actual end system, but not required for the demo).
- And for the raspbian userland support package, I could provide a script to install to $DESTDIR or whatever, basis the GitHub source release tarball, if that would help.
Just to reiterate, I realize you're doing this in your own time, and so the demo packaging might not be possible by Fri 8. Absolutely no problem if so! I really appreciate the effort you're putting into this - thank you. Also, if you need to send any out-of-band comments, just ping me an email: [email protected].
Fri Mar 22: I'll post a more fully written up design spec to this thread for review. Comments and suggestions actively invited. The spec will primarily be a concrete proposal walking through how the
current, functioning approach will be generalized to work with multiple OS images, potentially simultaneously, what it would take to add an image to the system, guest package installation / removal and effects on the Raspbian desktop menu, how available images would be 'published' (Gentoo overlay-style perhaps?), updated, and withdrawn, what one would need to do to a baseline OS image to prepare it for use (hopefully, not much!) etc.
Fri Apr 5: Spec review period ends (initial spec locked off).
Fri Apr 26: I'll try to put out an image (with any required supporting infrastructure) implementing the target design. This (apart from the kernel) will probably
not be deb-packaged, but will (as the current
raspbian-nspawn-64 image is) be a concrete, runnable system. Comments invited.
Fri May 31: Image review period ends. On the basis of 'plan to throw one away, you will anyhow', I'll then put together a tweaked version of the image, incorporating comments.
Fri Jun 14: Tweaked image version released for final review.
Fri Jun 28: Updated image review period ends. Initial packaging for upstreaming begins.
Fri Jul 26: First cut upstream packaging complete - alpha release for testing and review. At least one demo 32-bit and 64-bit container image available.
Fri Aug 30: Formal beta. With hopefully a few more, community contributed OS container images available.
Fri Sep 27: Lock off "1.0" packages and release to live tree.
I appreciate this is a bit finger-in-the-air, particularly towards the end, but does that sort of schedule seem realistic to you? Clearly, the final decision as to
whether the components were stable enough to upstream would rest with you. And real-world constraints may intervene (work-wise, May is looking particularly horrible for me atm). Plus there may be some argument to release the 64-bit kernel package earlier than the others. TBD. But roughly-roughly sane?
Best,
sakaki