All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Orling <timothy.t.orling@linux.intel.com>
To: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] Yocto Project Status WW12’18
Date: Tue, 20 Mar 2018 14:08:15 -0700	[thread overview]
Message-ID: <655551A1-982B-4AF5-BA38-E122543A0DB0@linux.intel.com> (raw)
In-Reply-To: <a73785d4-f3fb-374d-3a54-3ea97e85b41f@linux.intel.com>


> On Mar 20, 2018, at 11:00 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
> 
> On 03/20/2018 05:59 PM, Richard Purdie wrote:
>>>> How long does a single run take, and why not run it every month?
>>> Just a bit longer than a day, maybe 30 hours, if it needs to update
>>> the
>>> typical amount of 100-150 packages. I'll shift it to monthly then.
>> Personally I'm leaning to every couple of weeks...
> 
> My worry is that shorter AUH periods will lead to reminder fatigue. Also the period between submitting the updates, and having them show up in master is sometimes less than ideal, even when the freeze is not in effect.
> 

I agree with both of you. I guess that makes me a transistor that can’t decide which path to choose :)

For meta-perl and meta-python, I am striving to run once a week, but that isn’t intended to send email out to any maintainers, it is just for my own accounting. It gets very messy with in-flight patches, which I hope to fix by using git-pw to not include packages that already have an upgrade in review. It is also optimistic for me to personally fix the 20+ packages that need updates at any given moment. This is why I need run time testing to give me better confidence in auto-upgraded recipes. Working on it :)

> Alex
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



WARNING: multiple messages have this Message-ID (diff)
From: Tim Orling <timothy.t.orling@linux.intel.com>
To: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Subject: Re: [yocto] Yocto Project Status WW12’18
Date: Tue, 20 Mar 2018 14:08:15 -0700	[thread overview]
Message-ID: <655551A1-982B-4AF5-BA38-E122543A0DB0@linux.intel.com> (raw)
In-Reply-To: <a73785d4-f3fb-374d-3a54-3ea97e85b41f@linux.intel.com>


> On Mar 20, 2018, at 11:00 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
> 
> On 03/20/2018 05:59 PM, Richard Purdie wrote:
>>>> How long does a single run take, and why not run it every month?
>>> Just a bit longer than a day, maybe 30 hours, if it needs to update
>>> the
>>> typical amount of 100-150 packages. I'll shift it to monthly then.
>> Personally I'm leaning to every couple of weeks...
> 
> My worry is that shorter AUH periods will lead to reminder fatigue. Also the period between submitting the updates, and having them show up in master is sometimes less than ideal, even when the freeze is not in effect.
> 

I agree with both of you. I guess that makes me a transistor that can’t decide which path to choose :)

For meta-perl and meta-python, I am striving to run once a week, but that isn’t intended to send email out to any maintainers, it is just for my own accounting. It gets very messy with in-flight patches, which I hope to fix by using git-pw to not include packages that already have an upgrade in review. It is also optimistic for me to personally fix the 20+ packages that need updates at any given moment. This is why I need run time testing to give me better confidence in auto-upgraded recipes. Working on it :)

> Alex
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



  reply	other threads:[~2018-03-20 21:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-19 15:45 Yocto Project Status WW12’18 Jordan, Robin L
2018-03-19 19:22 ` [OE-core] " akuster808
2018-03-19 19:22   ` akuster808
2018-03-19 20:07   ` [OE-core] " Burton, Ross
2018-03-19 20:07     ` Burton, Ross
2018-03-20 10:07     ` [OE-core] " Alexander Kanavin
2018-03-20 10:07       ` [yocto] " Alexander Kanavin
2018-03-20 10:52       ` [OE-core] " Burton, Ross
2018-03-20 10:52         ` [yocto] " Burton, Ross
2018-03-20 11:26         ` [OE-core] " Alexander Kanavin
2018-03-20 11:26           ` [yocto] " Alexander Kanavin
2018-03-20 15:59           ` [OE-core] " Richard Purdie
2018-03-20 15:59             ` [yocto] " Richard Purdie
2018-03-20 18:00             ` [OE-core] " Alexander Kanavin
2018-03-20 18:00               ` [yocto] " Alexander Kanavin
2018-03-20 21:08               ` Tim Orling [this message]
2018-03-20 21:08                 ` Tim Orling
2018-03-21 22:54               ` [OE-core] " Richard Purdie
2018-03-21 22:54                 ` [yocto] " Richard Purdie
2018-03-21 14:24           ` [OE-core] " Philip Balister
2018-03-21 14:24             ` [yocto] " Philip Balister
2018-03-21 14:31             ` [OE-core] " Alexander Kanavin
2018-03-21 14:31               ` [yocto] " Alexander Kanavin
2018-03-21 14:40               ` [OE-core] " Burton, Ross
2018-03-21 14:40                 ` [yocto] " Burton, Ross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=655551A1-982B-4AF5-BA38-E122543A0DB0@linux.intel.com \
    --to=timothy.t.orling@linux.intel.com \
    --cc=alexander.kanavin@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.