Comment 4 for bug 974382

> * marking it 'invalid' so it will magically go away isn't helpful for anyone

it's not marked "invalid", it's marked "incomplete" as "needs extra infos, we can't do a lot without that"

> * suggesting that I should log out of my currently running environment, and run valgrind on my system for the next 2 weeks because you find that unreasonable to do yourself is somewhat rude

assuming that others are lazy is somewhat rude, did you consider that maybe it's specific to your setups or that others don't get the issue and can't collect the infos from your system?

> * marking a memory leak of 420M over 3 weeks as 'low' is troubling.

well as said before some leaks got fixed since you opened your bug report so the number is likely to be lower, few users let their system run over 3 weeks without reboot (we usually get kernel updates that require a reboot at least once a month), and it's easy to "workaround" (the panel service is only a standalone service that can be restarted without closing your session or anything)

> You probably will get your desired result of making this bug go away, as I'm not likely to run my desktop under valgrind for a extended period of time.

did you read the code of conduct recently? what happened to assuming that people mean well?

> My currently running environment has unity-panel-service up for ~ 10 days and it has a footprint of 42M (per top) at the moment. I believe that likely there is still a leak shown there.

what number are we talking about in top? res? shr? yeah, it seems to leak 1mb a day, it's not perfect but it's barely a rc bug, knowing that it could well be that you use a non default indicator (do you run multiload, weather, or any indicator not installed by default?)