[LEDE-DEV] Release planning

[Daniel Golle]

Hi!

On Wed, Dec 21, 2016 at 08:13:00PM +0100, Jo-Philipp Wich wrote:
> ...
> # Open questions
> 
> - Are there any outstanding changes?
> 
>   Is there important changes we should wait for before branching the
>   release? Is there pending stuff in the staging trees which should
>   absolutely go into the first release?

I believe that all targets should at least use the new image building
code to the point that we can nuke the old (sub-)target profiles.

I've just now touched sunxi (backporting ~ 350 patches to get better
support for H3 and thus the NanoPi NEO board) and there is quite a lot
to do there:
 - convert target/sunxi/image/Makefile to new style and clean up
   board-naming mess, currently we got:
   * profile name = U-Boot name (e.g. orangepi_plus)
     This name is currently also used to name OpenWrt/LEDE images
   * DTS filename (e.g. sun8i-h3-orangepi-plus)
   * /proc/device-tree/model, /proc/device-tree/compatible
   * sunxi_board_name() (e.g. organgepi-plus)
   ## consistent board names are needed for future sysupgrade

 - rewrite SDcard generation to support dynamicly sized partitions
   instead of hard-coding the rootfs size. probably it makes sense to
   unify SDcard generation code from bcm2708, mxs, sunxi and other
   platforms with similar requirements into a shared script.
 - use single-partition rootfs-split like x86 does
   => unlocks F2FS overlay and factory reset support

For obvious reasons the sunxi target hasn't seen much love since the
fork, and the same might apply for other targets which are maintained
by OpenWrt/non-LEDE devs. With regard to the upcoming release, how
should we deal with that situation?
In the imho likely future re-merge of the LEDE and OpenWrt git trees,
all remaining OpenWrt devs will be given commit access which will allow
them to contribute and maintain things. However, I think we at least
need a dead-line for that to happen or ship the LEDE release either
without those targets or fix them up ourselves.

Apparently we already got quite a lot of different sunxi boards here at
the CCC in Hamburg, so maybe this could be a single evening
joint-effort to lift the target to use state-of-the-art image
generation and have the result tested on as much hardware as possible.

However, I'll mostly be focusing on getting the oxnas target fit for
release, the target is still stuck on kernel 4.1: currently, NAND
doesn't work on some devices on kernel 4.4 whereas the same driver
works great on kernel 4.1 -- the problem is most likely hiding
somewhere else, pinmux or even probe order... Fixing that for 4.4 would
allow to support all oxnas boards in the upcoming release.
Another way could be backporting the new oxnas support which recently
made it into the kernel and port the remaining drivers (ehci-glue,
stmmac-glue, sata, pmic/leon, ...) to work on top of that. This would
come with the advantage that most code is built so that it can be
shared and used also be used for the older ox810se, thus allowing to
support that subtarget in future in LEDE as well.

> 
> - When do we want to branch?
> 
>   Personally I'd like to branch before Christmas so that we can use the
>   free time for building images (it takes about 8 days and ~2TB of space
>   to build all targets and all packages).

Imho beginning of January, making it a 2017.01 is a good date for
branching.

> 
> - How do we want to code name the release?
> 
>   Imho we should avoid naming it the same as master ("Reboot") to
>   prevent future confusion. Maybe we could simply name it "Zero" or
>   "Debut" to underline the fact that it is the first release.

I don't care too much.

> 
> - Release branches in feed repos?
> 
>   What do we do if an external feed does not want to maintain a LEDE
>   specific release branch - shall we fork it instead and host the fork
>   our self?
> 
> - Who is willing to support the release branch?
> 
>   We will need one to two people to keep an closer eye on the release
>   branch and to fulfill back port requests, who is volunteering here
>   to serving as part of a maintainer group and as contact for release
>   specific issues?

I happily volunteer joining the backporting team.



Cheers


Daniel


> 
> 
> Please provide feedback so that we can agree on a definitive road map
> for branching and for starting the preparations.
> 
> Regards,
> Jo



> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev