[yocto] Minutes: Yocto Project 1.4 M4 release readiness discussion
Attendees: AlexG, ThaddeusL, Cristian, Dave, Richard, Jessica, Nitin, Song Release criteria review: Please see the wiki page: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status#Milestone_4https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status 1. All release criteria has been reviewed. M4 met all the criteria. 2. Highlights: a. 12% performance increase on overall build time. Cut the rootfs build time with sstate on by half. 3. Issues: a. The # of bugs seems high. Plan: Bug triage team is doing a round of triage for all medium+ and medium bugs to focus the team on fixing the right set of bugs. The team will focus more on bugs for the rest of the release. b. Dave: not enough CCB members present in this meeting. Cannot approve the release. Decision: Song will follow up with Dave and the CCB to get approval for the release. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project 1.4 M4 release readiness discussion
On Fri, Mar 01, 2013 at 08:01:17PM +, Liu, Song wrote: Attendees: AlexG, ThaddeusL, Cristian, Dave, Richard, Jessica, Nitin, Song Release criteria review: Please see the wiki page: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status#Milestone_4https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status 1. All release criteria has been reviewed. M4 met all the criteria. 2. Highlights: a. 12% performance increase on overall build time. Cut the rootfs build time with sstate on by half. 3. Issues: a. The # of bugs seems high. Plan: Bug triage team is doing a round of triage for all medium+ and medium bugs to focus the team on fixing the right set of bugs. The team will focus more on bugs for the rest of the release. b. Dave: not enough CCB members present in this meeting. Cannot approve the release. Decision: Song will follow up with Dave and the CCB to get approval for the release. I think it would be good to finish discussion in thread [OE-core] RFE: make the init manager an image feature (again) and resolve systemd situation asap, otherwise we're risking meta-openembedded release or quality of such release. meta-systemd is broken for month so people cannot even test it with current master and couple of important meta-oe developers are against changing meta-systemd so it gets compatible with current oe-core but breaks their use-case and also there is no plan for upgrade path from danny+meta-systemd to Yocto-Project_v1.4 release. Stalling that discussion till milestone 5 or 6 won't help resolving it to work for everybody. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project 1.4 M4 release readiness discussion
On 1 March 2013 21:53, Martin Jansa martin.ja...@gmail.com wrote: I think it would be good to finish discussion in thread [OE-core] RFE: make the init manager an image feature (again) and resolve systemd situation asap, otherwise we're risking meta-openembedded release or quality of such release. I'm working on a series that implements roughly what I proposed (systemd and sysvinit features not mutually exclusive, but no separate -sysv or -systemd packages) and hope to have it on the list next week - this week has been slow going as we've had a family cold do the rounds. Any contributions of coding are always welcome, obviously. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project 1.4 M4 release readiness discussion
On Fri, Mar 01, 2013 at 11:08:30PM +, Burton, Ross wrote: On 1 March 2013 21:53, Martin Jansa martin.ja...@gmail.com wrote: I think it would be good to finish discussion in thread [OE-core] RFE: make the init manager an image feature (again) and resolve systemd situation asap, otherwise we're risking meta-openembedded release or quality of such release. I'm working on a series that implements roughly what I proposed (systemd and sysvinit features not mutually exclusive, but no separate -sysv or -systemd packages) and hope to have it on the list next week - this week has been slow going as we've had a family cold do the rounds. Can you answer this http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/036223.html and how this solution helps with upgrade paths? Any contributions of coding are always welcome, obviously. Coding was contributed to meta-systemd which was working fine for both use-cases. Maybe explaining hidden benefits of not splitted packages would motivate some people.. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project 1.4 M4 release readiness discussion
On 1 March 2013 23:32, Martin Jansa martin.ja...@gmail.com wrote: Can you answer this http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/036223.html and how this solution helps with upgrade paths? Having split packages can break the upgrade path - say your distro goes from sysvinit to sysvinit rescue + systemd main. How does your foo-daemon package get the right init script package on upgrade? I proposed a solution for distributions that care - inject the migration path dependencies though meta-systemd. I still maintain that oe-core shouldn't have to bend over backwards to maintain compatibility with every recipe that migrates. Obviously we don't want to deliberately break where we have a choice but equally so Coding was contributed to meta-systemd which was working fine for both use-cases. Maybe explaining hidden benefits of not splitted packages would motivate some people.. The advantage of having init scripts in the daemon package is simplicity. For the cost of two init scripts (what, 1K between them?) you remove lots of complexity, including the upgrade path breakage I described above. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project 1.4 M4 release readiness discussion
On Fri, Mar 01, 2013 at 11:56:32PM +, Burton, Ross wrote: On 1 March 2013 23:32, Martin Jansa martin.ja...@gmail.com wrote: Can you answer this http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/036223.html and how this solution helps with upgrade paths? Having split packages can break the upgrade path - say your distro goes from sysvinit to sysvinit rescue + systemd main. How does your foo-daemon package get the right init script package on upgrade? By right RRECOMMENDS like meta-systemd did. Plus simple way to exclude some at image creation time with BAD_RECOMMENDATION or explicit entries pulled with packagegroup for each type of image. I proposed a solution for distributions that care - inject the migration path dependencies though meta-systemd. I still maintain that oe-core shouldn't have to bend over backwards to maintain compatibility with every recipe that migrates. Obviously we don't want to deliberately break where we have a choice but equally so http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/036222.html Coding was contributed to meta-systemd which was working fine for both use-cases. Maybe explaining hidden benefits of not splitted packages would motivate some people.. The advantage of having init scripts in the daemon package is simplicity. For the cost of two init scripts (what, 1K between them?) you remove lots of complexity, including the upgrade path breakage I described above. There is no upgrade path breakage and complexity is in postinst scripts which need to support both update-rc.d and systemctl calls. Lets discuss this in that oe-core thread so that other people not subscribed to yocto ML can also comment. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
