launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Sat, Feb 11, 2012 at 9:51 AM, Guilherme Salgado
<guilherme.salgado@xxxxxxxxxx> wrote:
> Hi there,
>
> As part of our work to teach Launchpad about work items we need to find
> some way to offset the maintenance costs introduced with our changes.
> While looking at some bugs (before the LOC policy was put in place) that
> we could fix to offset that, we came across
> https://bugs.launchpad.net/bugs/735970 and realized that +specworkload,
> for a person, shows exactly the same things you see on
> blueprints.lp.net/~person. The only difference is for teams, as
> +specworkload shows (with an awful layout[1]) all specs that have any
> member of the team as assignee/drafter/approver, whereas
> blueprints.lp.net/~team only shows the specs that have the team itself
> as drafter/assignee/approver.
>
> After grepping through the logs I found that there were only 115
> requests (after excluding the ones that came from google searches for
> things seemingly unrelated to LP) for a +specworkload page in January
> (see the attached script for the details). So, given that it's not much
> used, doesn't serve any purpose for an IPerson and times out for an
> ITeam, I believe Launchpad would benefit from having it removed
> altogether. Any objections?

None from me; though perhaps it is a project manager tool - 'what are
the members of this team responsible for?' (vs what stuff is a team
responsibility waiting for assignment.

I will forward your mail, and a request for input from the
stakeholders, to -stakeholders : if none of the stakeholders are
actively using it, I think removing it becomes a no-brainer.

 It is doing classic late evalution:
'40 	4418 	110 	4308 	SQL-main-slave 	

SELECT $INT FROM
  (SELECT Specification.appr'...

I generated a user OOPS -
https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-8576f92dc3de4bc3d45e5d0e64a09738
if you want to poke yourself.

If we do need this functionality, another way would be to delete
+specs and instead make +specworkload sane; it should be able to be
fast fairly easily.

> PS: Robert, notice that the total of requests I found from grepping the
> logs is almost half of the # of requests on ppr for the same month, so I
> may have missed some logs there, although I don't think that'd make a
> significant difference to the trend we see here

Agreed; its definitely a low use page (compared to the millions of
renders we do *a day*) it is at least two orders of magnitude less
used than the rest of the system.

> PPS: It'd probably be nice to have something similar to what I did
> running continuously to detect pages that are not used much and then
> consider killing them or combining with others

+1!

-Rob