On Sat, 26 Nov 2016 17:32:02 -0600
William Hubbs wrote:
> Listing the architectures seems redundant if they are also in the cc:
> field. In your example above, why would you need arm in the cc: field
> for app-foo/bas-2.3.4?
Often, the required work for "lists of keywords/stabilizations" has
i
On Fri, Nov 25, 2016 at 06:41:20AM +1100, Michael Palimaka wrote:
> As I am sure everyone is aware by now, stabilisation requests on many
> architectures take a long time to be actioned. There are many factors
> contributing to this, but today I'd like to address three specific
> problems that unne
On Fri, 25 Nov 2016 14:40:36 +0800
Jason Zaman wrote:
> One way would be to use a plain text attachment with a standardized
> filename. If there are updates to the list then the new should obsolete
> the old and the script can pull non-obsoleted ones.
> The problem then is how do you search for t
On Fri, Nov 25, 2016 at 06:41:20AM +1100, Michael Palimaka wrote:
> As I am sure everyone is aware by now, stabilisation requests on many
> architectures take a long time to be actioned. There are many factors
> contributing to this, but today I'd like to address three specific
> problems that unne
On Fri, Nov 25, 2016 at 05:54:41PM +1300, Kent Fredric wrote:
> On Fri, 25 Nov 2016 06:41:20 +1100
> Michael Palimaka wrote:
>
> > Example atom list from a bug with amd64, arm, and x86 in CC:
> >
> > =app-foo/bar-1.2.3 # will be stabilised on amd64, arm, and x86
> > =app-foo/baz-2.3.4
On Fri, 25 Nov 2016 17:54:41 +1300
Kent Fredric wrote:
> Content-Transfer-Encoding: quoted-printable
Ugh. I attached that so wrong and it is unreadable.
How does one "reply to X" and "attach other email Y" in claws without cocking it
up entirely.
"message/rfc822" as an attachment encoding type
On Fri, 25 Nov 2016 06:41:20 +1100
Michael Palimaka wrote:
> Example atom list from a bug with amd64, arm, and x86 in CC:
>
> =app-foo/bar-1.2.3 # will be stabilised on amd64, arm, and x86
> =app-foo/baz-2.3.4 amd64 x86 # will be stabilised on only amd64 and x86
I was doing this in th
On 24/11/16 19:41, Michael Palimaka wrote:
> As I am sure everyone is aware by now, stabilisation requests on many
> architectures take a long time to be actioned. There are many factors
> contributing to this, but today I'd like to address three specific
> problems that unnecessarily delay develop
As I am sure everyone is aware by now, stabilisation requests on many
architectures take a long time to be actioned. There are many factors
contributing to this, but today I'd like to address three specific
problems that unnecessarily delay developers actioning those requests.:
1. There's no easy
