Yocto Project 1.4 Planning Process
Whilst I appreciate people are concentrating on 1.3, we do also need to think about planning 1.4.
https://wiki.yoctoproject.org/wiki/Yocto_1.4_Features
is seeded with the 1.4/Future targeted enhancement requests from the bugzilla. This is currently unsorted/unprocessed other than some guesses from the triage team and I doubt we can actually do everything listed there but there are plenty of good ideas.
If people can see anything that is missing from those lists which they think is something we should consider working on in 1.4, I'd recommend filing enhancement requests in the bugzilla so they're included in the list.
In about a week's time, I'll be sitting down with this list and talking with the project stakeholders about what resources are available and which tasks we could use those resources on and generally figure out what we're going to target in 1.4. If there are resources available I'm unaware of, please do talk to me btw! :)
Equally, I'd also ask that if there are things you're planning to do in the 1.4 timescale, please indicate this with an entry in the bugzilla which you take ownership of, give a rough time estimation/ETA of and set the status to ACCEPTED. This tells others that you're working on something and gives us an idea of what changes to expect and when. This is useful for planning things like demos and the beta testing.
Questions are more than welcome, as is feedback about this process.
Cheers,
Richard
W dniu 03.10.2012 17:03, Richard Purdie pisze:
Quoted 4 lines
Whilst I appreciate people are concentrating on 1.3, we do also need to think about planning 1.4.
Questions are more than welcome, as is feedback about this process.
Before adding it to bugzilla or wiki I would like to list few things which would be usable during adding new architecture (maybe missed them).
1. A way to automatical upload logs after build - selection all/failed one would be extra.
2. A way to collect preprocessed files in case of gcc ICE.
3. Option to automatically rebuild ICEd recipe with PARALLEL_MAKE disabled so it is easier to notice where it ICEd.