* branch inclusion request @ 2018-10-26 15:19 Sasha Levin 2018-10-26 16:34 ` [kernelci] " Guillaume Tucker 0 siblings, 1 reply; 4+ messages in thread From: Sasha Levin @ 2018-10-26 15:19 UTC (permalink / raw) To: kernelci Hi all, Right now I'm pushing stable patches to Greg for his weekly releases, and for those branches I only do basic cross-compilation and no boot/functional testing at all. I'd like to modify my process to rely on KernelCI testing instead. This means I'd like to include my branches (one for each stable kernel) into the build system. These branches get pushed a few times per week, and sometimes a few times a day, so this will generate a fair amount of builds. OTOH, I don't really need to keep the build results for too long as I try to address any issues that come up the same day. -- Thanks, Sasha ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [kernelci] branch inclusion request 2018-10-26 15:19 branch inclusion request Sasha Levin @ 2018-10-26 16:34 ` Guillaume Tucker 2018-10-29 15:35 ` Kevin Hilman 0 siblings, 1 reply; 4+ messages in thread From: Guillaume Tucker @ 2018-10-26 16:34 UTC (permalink / raw) To: kernelci [-- Attachment #1: Type: text/plain, Size: 1547 bytes --] Hi Sasha, On Fri, Oct 26, 2018 at 5:08 PM Sasha Levin <sashal@kernel.org> wrote: > Hi all, > > Right now I'm pushing stable patches to Greg for his weekly releases, > and for those branches I only do basic cross-compilation and no > boot/functional testing at all. > > I'd like to modify my process to rely on KernelCI testing instead. This > means I'd like to include my branches (one for each stable kernel) into > the build system. > > These branches get pushed a few times per week, and sometimes a few > times a day, so this will generate a fair amount of builds. OTOH, I > don't really need to keep the build results for too long as I try to > address any issues that come up the same day. > This sounds like a good idea in principle, but what is the actual gain given the extra load it would take to build and test all these branches? Of course it's very important to test stable releases, but they typically show very few build or test failures and there is already stable-rc to catch any of these. It seems to me that development branches are where extra testing efforts would be required the most, to catch issues earlier. If adding your stable branches to KernelCI would save you a lot of manual effort, then yes I guess that would probably be a good reason. If you'll still be doing the same manual builds and checks before pushing your branches, then I'm not really sure it's worth adding them to KernelCI as it currently stands. Let's see what others think the priorities should be wrt adding more branches. Guillaume > > [-- Attachment #2: Type: text/html, Size: 2330 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [kernelci] branch inclusion request 2018-10-26 16:34 ` [kernelci] " Guillaume Tucker @ 2018-10-29 15:35 ` Kevin Hilman 2018-11-09 16:26 ` Guillaume Tucker 0 siblings, 1 reply; 4+ messages in thread From: Kevin Hilman @ 2018-10-29 15:35 UTC (permalink / raw) To: kernelci On Fri, Oct 26, 2018 at 9:35 AM Guillaume Tucker <guillaume.tucker@gmail.com> wrote: > > Hi Sasha, > > On Fri, Oct 26, 2018 at 5:08 PM Sasha Levin <sashal@kernel.org> wrote: >> >> Hi all, >> >> Right now I'm pushing stable patches to Greg for his weekly releases, >> and for those branches I only do basic cross-compilation and no >> boot/functional testing at all. >> >> I'd like to modify my process to rely on KernelCI testing instead. This >> means I'd like to include my branches (one for each stable kernel) into >> the build system. >> >> These branches get pushed a few times per week, and sometimes a few >> times a day, so this will generate a fair amount of builds. OTOH, I >> don't really need to keep the build results for too long as I try to >> address any issues that come up the same day. > > > This sounds like a good idea in principle, but what is the actual > gain given the extra load it would take to build and test all > these branches? > > Of course it's very important to test stable releases, but they > typically show very few build or test failures and there is > already stable-rc to catch any of these. It seems to me that > development branches are where extra testing efforts would be > required the most, to catch issues earlier. > > If adding your stable branches to KernelCI would save you a lot > of manual effort, then yes I guess that would probably be a good > reason. If you'll still be doing the same manual builds and > checks before pushing your branches, then I'm not really sure > it's worth adding them to KernelCI as it currently stands. > > Let's see what others think the priorities should be wrt adding > more branches. IMO, since we're trying to make stable rock solid, this is a good addition. Also, since Sasha is also helping with build horsepower, I think we should add these trees. Kevin ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [kernelci] branch inclusion request 2018-10-29 15:35 ` Kevin Hilman @ 2018-11-09 16:26 ` Guillaume Tucker 0 siblings, 0 replies; 4+ messages in thread From: Guillaume Tucker @ 2018-11-09 16:26 UTC (permalink / raw) To: kernelci [-- Attachment #1: Type: text/plain, Size: 2201 bytes --] On Mon, Oct 29, 2018 at 3:35 PM Kevin Hilman <khilman@baylibre.com> wrote: > On Fri, Oct 26, 2018 at 9:35 AM Guillaume Tucker > <guillaume.tucker@gmail.com> wrote: > > > > Hi Sasha, > > > > On Fri, Oct 26, 2018 at 5:08 PM Sasha Levin <sashal@kernel.org> wrote: > >> > >> Hi all, > >> > >> Right now I'm pushing stable patches to Greg for his weekly releases, > >> and for those branches I only do basic cross-compilation and no > >> boot/functional testing at all. > >> > >> I'd like to modify my process to rely on KernelCI testing instead. This > >> means I'd like to include my branches (one for each stable kernel) into > >> the build system. > >> > >> These branches get pushed a few times per week, and sometimes a few > >> times a day, so this will generate a fair amount of builds. OTOH, I > >> don't really need to keep the build results for too long as I try to > >> address any issues that come up the same day. > > > > > > This sounds like a good idea in principle, but what is the actual > > gain given the extra load it would take to build and test all > > these branches? > > > > Of course it's very important to test stable releases, but they > > typically show very few build or test failures and there is > > already stable-rc to catch any of these. It seems to me that > > development branches are where extra testing efforts would be > > required the most, to catch issues earlier. > > > > If adding your stable branches to KernelCI would save you a lot > > of manual effort, then yes I guess that would probably be a good > > reason. If you'll still be doing the same manual builds and > > checks before pushing your branches, then I'm not really sure > > it's worth adding them to KernelCI as it currently stands. > > > > Let's see what others think the priorities should be wrt adding > > more branches. > > IMO, since we're trying to make stable rock solid, this is a good > addition. Also, since Sasha is also helping with build horsepower, I > think we should add these trees. > Sounds like the overal consensus is to enable them. Sasha, could you please provide the list of the branch names and send a PR with the URL of your tree in kernelci-core-staging? Guillaume [-- Attachment #2: Type: text/html, Size: 3037 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-11-09 16:26 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-10-26 15:19 branch inclusion request Sasha Levin 2018-10-26 16:34 ` [kernelci] " Guillaume Tucker 2018-10-29 15:35 ` Kevin Hilman 2018-11-09 16:26 ` Guillaume Tucker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox