On Thu, Jun 4, 2020 at 1:30 AM Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > > On Fri, 2020-05-22 at 00:23 +0000, Mittal, Anuj wrote: > > On Thu, 2020-05-21 at 17:05 -0700, Khem Raj wrote: > > > On Thu, May 21, 2020 at 4:49 PM Mittal, Anuj <anuj.mit...@intel.com > > > > > > > wrote: > > > > On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote: > > > > > On Thu, May 21, 2020 at 6:16 PM Khem Raj <raj.k...@gmail.com> > > > > > wrote: > > > > > > Now that they uses -mcpu, its better to have tune specific > > > > > > build > > > > > > directories, since aarch64 wont be appropriate any longer > > > > > > > > > > I agree with Steve that this is a bit invasive for stable > > > > > branch, > > > > > but > > > > > on the other hand it's long overdue and if we don't improve it > > > > > in > > > > > LTS > > > > > branch then many people will need to carry local work arounds > > > > > for > > > > > multi-machine builds. +1 from me. > > > > > > > > > > > > > But this is against the LTS/Stable branch policy. What is the > > > > point > > > > of > > > > having a policy if we are going to keep making exceptions? > > > > There'd > > > > be > > > > other changes as well for which people might be carrying work- > > > > arounds. > > > > Would we be willing to make exceptions for all? > > > > > > > > > > Thanks for bringing this up. Policy exceptions are not common but > > > they > > > > That's two exceptions in a week. > > > > I am not against the change but I think the policy document should be > > modified to define how exceptions should/will be handled. > > > > > are not absent either > > > hence context is important for such changes, I am definitely > > > interested to hear > > > about how it is going to affect arm64 users at this early stage of > > > release. > > > > The release has been made and I think the branch is assumed to be > > stable from the time it was released and policy should be applied? > > There's no early release stage defined where-in such changes would be > > acceptable. > > This series doesn't have a decision on it yet. If an exception were > made, it would be two exceptions in the lifetime of the LTS so far, not > just a week. The fact we'd like to make a point release is focusing the > fact we need to make some decisions rather than a sudden stream of > policy exceptions. > > I'd also note its most likely we'd find issues just after release as > people start using things, over time it becomes much less likely. > > If such issues are identified, particularly now as people start using > it, the question is what we do about it. If we can fix things to > improve things for users and the risk is either low, or managed to a > specific subset of users who can benefit, that does seem like a > sensible thing to do. > > I guess I'd hoped we could all be sensible about these things, the LTS > policy is there as a set of 'guide rails' to make decisions against but > as a maintainer, I know that not everything that makes sense neatly > fits within a written set of rules. The LTS maintainer does need to > have some ability to make decisions and I've always thought it was > clear the TSCs are the ultimate decision makers for any technical > decision the project faces should there not be consensus.
downstream distros will require such things for supporting their products, in past it was done on their chosen release and they stayed with that release with their own delta, the hope is that they will use LTS and just from LTS to LTS in product cycles. IMO LTS will have to considerate to this fact, if we do not want downstream distros to diverge significantly and if we want to put hard conditions early on release then I guess users will have to devise their own plans regardless of LTS. e.g. See the delta between ubuntu LTS first point release ( 20.04 and 20.04.1 ), most users wait for first point release to migrate to next LTS there is a reason for that. There is quite a bit of stabilization that happens early on in LTS life. > > In the case of these patches I'm not seeing anyone arguing against them > on technical grounds or saying they don't make sense other than some > things I've said to Steve! The complaint is that they break policy. > > I will discuss making a escalation and final decision path clearer with > the YP TSC (who wrote/maintain the policy). > > Cheers, > > Richard > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139236): https://lists.openembedded.org/g/openembedded-core/message/139236 Mute This Topic: https://lists.openembedded.org/mt/74379085/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
