[LEDE-DEV] Release planning

Sat Dec 24 11:26:00 PST 2016

On 12/24/2016 03:40 PM, Daniel Golle wrote:
> 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

Another thing I noticed when I thought about converting sunxi to the new
build code a while ago (which I never actually did) is that the uboot
dependency handling is a mess. The different uboot builds are declared as
target packages, which are then pulled in by the profiles; the actual
packages are empty (but still appear in opkg as installed), they only exist
to trigger copying uboot to KERNEL_BUILD_DIR...

Matthias

> 
>  - 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
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20161224/a326087e/attachment.sig>