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@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
