From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A0B1D1382C5 for ; Tue, 20 Mar 2018 04:33:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 15020E0924; Tue, 20 Mar 2018 04:33:49 +0000 (UTC) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AF331E0904 for ; Tue, 20 Mar 2018 04:33:48 +0000 (UTC) Received: by mail-vk0-x234.google.com with SMTP id g192so180591vkd.3 for ; Mon, 19 Mar 2018 21:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scriptkitty-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=UpJ2FlcT7n/CjTiOwkv6EI6XM2kNWhQr23rPsyEcHbc=; b=TwCPNXw4r/vE4TppORtMqlwJGOVFG8OreOH+ZDe9htIm50CXRcZNYAbKTDmw3VKdVU D4ueu10tJvheLwPNPVnckb130qxebkduTUAs27TSVRaI6whSU0LFWZ1Wn0VtYet35qqo o1MHvIx6FFpeyYbWVTTOzVzla9TYl5MSEzuAMIqbieRLSUP/rEfhfYNk9Qxb/6OgLts+ EhyvMAHPvSUaH2wZP44U9VZxwNdDBR71ZOlZ/vpY1YojA6ELpSgF90ozBmwYudYrT3oL sZt6wmQHLigeU5UXOkIgG5FTtJW9pixjNR+oYkmouYUklvcH3CvYFeh6IAerKAGdCPDI gItA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=UpJ2FlcT7n/CjTiOwkv6EI6XM2kNWhQr23rPsyEcHbc=; b=mTtd10NvFmbd0yW04QoQbTL2TjBwXHmhymtLXf39WByap605d0hElbaLT1yCAzVH2G fSIloiQqIZZLwLftVKt/MWP5NJfFGxYbdSQYNV/dCLaz43H1QFM5hlk1OQO0fte8FLf9 snAQbJ7mBOu0GgPBHO9OOAk0Ley5Okj/H3wzlKeW0u7tcaAJz++kEjOIZCRIWWKv4Pb5 4fBs/kUr8eCK9iluIbY2DQYOy8oTmwbK7ILXNX2lgawwYMx4eYwqVqzV/h0V1yhd7czV bPPrl8qcO0E6IieOysifEsODmx5fCEjJc78Xu5zjuZgAnU6XDooWELDtangHPnP+Ac6N cCvw== X-Gm-Message-State: AElRT7HL5T5RjSrOaDP9UFoEeew3ISp6bqsOmYgFBblQORrN9p264ilE sn754pTcwYI88mbmyZTrAdFk8QJhm/h+u+VLHgldRQ== X-Google-Smtp-Source: AG47ELvBJPBvZgyTKRYWDk+WFk6Ok8sOd2hrRjMZAjD9BSvPUIbh8Pu6imnaOXcPcY1dDdPGefoeQHykF7HZg2ziy1o= X-Received: by 10.31.194.3 with SMTP id s3mr9501733vkf.118.1521520427288; Mon, 19 Mar 2018 21:33:47 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Sender: antarus@scriptkitty.com Received: by 10.176.85.80 with HTTP; Mon, 19 Mar 2018 21:33:46 -0700 (PDT) X-Originating-IP: [98.116.189.160] In-Reply-To: <20180320172451.34e031cb@katipo2.lan> References: <1f457642-b419-7398-db92-366f4908fbab@gentoo.org> <20180320172451.34e031cb@katipo2.lan> From: Alec Warner Date: Tue, 20 Mar 2018 00:33:46 -0400 X-Google-Sender-Auth: 4qzMoL5aG01MOClgxvcbT2EtnyI Message-ID: Subject: Re: [gentoo-dev] bug queue size over time To: Gentoo Dev Content-Type: multipart/alternative; boundary="001a1139c6749662680567d094ac" X-Archives-Salt: 9337a15f-3125-46dc-8379-017db13501a0 X-Archives-Hash: b2697fe9c80247575eb0fef0d75ec750 --001a1139c6749662680567d094ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 20, 2018 at 12:24 AM, Kent Fredric wrote: > On Mon, 19 Mar 2018 19:33:11 -0700 > "Pawe=C5=82 Hajdan, Jr." wrote: > > > Is it possible to get graphs of bugs.g.o bug queue size for certain > > query (e.g. by assignee) over time? > > > > Best, > > Pawe=C5=82 > > > > The *data* is there to do it, but its a bit of a pain, you have to > extract all the individual "changed" events and then use that to reason > about each individual bugs state at a given time, and use *that* to > deduce how many open bugs there *were* at a historical moment. > > And that's a lot of painful queries for the REST API. > I'd avoid the REST API here. If you want this data; I'd consider filing a bug. Infra can do stuff like run nightly reports for this information and hang them off of endpoints you can access. This works well for public bugs; and not well for private ones. > > I've done something like this before with Perl bugs[1], but again, very > painful, slow and time consuming. > > This sort of thing would be *much* easier if we could have direct bulk > access to the underlying MYSQL store, but that's a tricky thing to do > because: > > 1. Its MySQL > 2. Some bugs have visibility restrictions that have to be factored for > In this way, you can download the (likely hundreds of megs) of JSON or whatever, and do the sorting / filtering / timeseries work on the client end? Its not great I suspect, but it saves everyone hamming the database. -A > > ---- > > Note: these pages are very browser taxing: > > 1: https://docs.google.com/spreadsheets/d/1mm8iYE77SRh- > q2jOfKNSWHUetswEABJawp-94UyTHio/edit?usp=3Dsharing > > > > > > --001a1139c6749662680567d094ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Mar 20, 2018 at 12:24 AM, Kent Fredric <kentnl@gentoo.org&= gt; wrote:
<= div class=3D"h5">On Mon, 19 Mar 2018 19:33:11 -0700
"Pawe=C5=82 Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:

> Is it possible to get graphs of bugs.g.o bug queue size for certain > query (e.g. by assignee) over time?
>
> Best,
> Pawe=C5=82
>

The *data* is there to do it, but its a bit of a pain, you have= to
extract all the individual "changed" events and then use that to = reason
about each individual bugs state at a given time, and use *that* to
deduce how many open bugs there *were* at a historical moment.

And that's a lot of painful queries for the REST API.
<= div>
I'd avoid the REST API here. If you want this data; = I'd consider filing a bug. Infra can do stuff like run nightly reports = for this information and hang them off of endpoints you can access.
This works well for public bugs; and not well for private ones.
=C2=A0

I've done something like this before with Perl bugs[1], but again, very=
painful, slow and time consuming.

This sort of thing would be *much* easier if we could have direct bulk
access to the underlying MYSQL store, but that's a tricky thing to do b= ecause:

1. Its MySQL
2. Some bugs have visibility restrictions that have to be factored for
<= /blockquote>

In this way, you can download the (likely h= undreds of megs) of JSON or whatever, and do the sorting / filtering / time= series work on the client end?

Its not great I sus= pect, but it saves everyone hamming the database.

= -A=C2=A0

----

Note: these pages are very browser taxing:

1: https://docs.google.com/spreadsheets/d/1mm8iYE77SRh-q2jOfKNS= WHUetswEABJawp-94UyTHio/edit?usp=3Dsharing






--001a1139c6749662680567d094ac--