Sebastian On 02/06/2018 08:34 AM, Sebastian Andrzej Siewior wrote: > On 2018-02-05 15:17:56 [-0600], Dan Murphy wrote: >> We are catching warnings and errors with these defconfigs. I have reported 2 warnings but >> I have not received a response. I guess I should report these to this list as opposed to the maintainers. > > You reported two warnings to my private address while I was traveling. > The usual workflow for reporting is to send this to the mailing list and > Cc the RT maintainer(s) (which would contain the email address I am > using right now). Agreed sorry for that. I sent the issues before I got the mail list information. > >> We have a "next" process that runs nightly that merges in the stable rc candidate into our branch >> so we can anticipate if the new stable or TI developer branches will cause a merge conflict when merged into our branch sets. >> >> For instance 4.14.17 stable rc caused a merge conflict in the hrtimer.c file. This became a known issue as soon as the stable rc was >> available. The RT 4.14 upstream branch is currently on 4.14.15 so now our RT branch is blocked from receiving a new stable until the >> RT upstream branch is updated. > > I usually do a new release once I have something in my pipe or if people > ask to update new stable due to $reason. > OK. I see the stable RT tree for 4.9 gets updated with every GKH stable release. Since RT touches kernel files would it be advantageous to keep the development branch up to date until especially if we still have RT patches? Or at the very least if there is an upcoming merge conflict to update and resolve on the RT development branch when we know? This is where we can put an automated job in place to merge GKH rc stable into the RT branch and report only upcoming merge conflicts. Then no one actually has to report or ask it would just be assumed? Dan >> Dan > > Sebastian > -- ------------------ Dan Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
