fitzgen / bugzilla-todos Goto Github PK

Right now, it opens a new chrome-less window. Maybe better to just open them up in Firefox? Or to do a slide-y sideways thing?

Under "To Check In (1)" it lists

904598 - WebRTC not working on Ubuntu and Mac OS X machines
patch by jib 14 days ago
patch by jib 12 days ago

but these patches are obsoleted and are no longer candidates for checkin. It would be nice if they weren't listed as TODOs since there's nothing to do.

STR:

1. http://www.bugmotodo.org/
2. Server not found

10:58:07.946 "Warning: Something is calling a React component directly. Use a factory or JSX instead. See: http://fb.me/react-legacyfactory" react-0.12.0.js:18087:6
10:58:07.946 "Warning: React.renderComponent will be deprecated in a future version. Use React.render instead." react-0.12.0.js:18087:6
10:58:07.948 "Warning: TodosApp is calling a React component directly. Use a factory or JSX instead. See: http://fb.me/react-legacyfactory" react-0.12.0.js:18087:6
10:58:07.952 "Warning: TodoTabs is calling a React component directly. Use a factory or JSX instead. See: http://fb.me/react-legacyfactory" react-0.12.0.js:18087:6
10:58:07.953 "Each child in an array should have a unique "key" prop. Check the render method of TabsNav. See http://fb.me/react-warning-keys for more information." react-0.12.0.js:9663:2
10:58:07.955 "Warning: TabsContent is calling a React component directly. Use a factory or JSX instead. See: http://fb.me/react-legacyfactory" react-0.12.0.js:18087:6
10:58:07.955 "Each child in an array should have a unique "key" prop. Check the render method of TabsContent. See http://fb.me/react-warning-keys for more information." react-0.12.0.js:9663:2
10:58:07.956 "Warning: PatchList is calling a React component directly. Use a factory or JSX instead. See: http://fb.me/react-legacyfactory" react-0.12.0.js:18087:6
10:58:07.956 "Warning: List is calling a React component directly. Use a factory or JSX instead. See: http://fb.me/react-legacyfactory" react-0.12.0.js:18087:6
10:58:07.957 "Warning: NagList is calling a React component directly. Use a factory or JSX instead. See: http://fb.me/react-legacyfactory" react-0.12.0.js:18087:6
10:58:07.958 "Warning: RespondList is calling a React component directly. Use a factory or JSX instead. See: http://fb.me/react-legacyfactory" react-0.12.0.js:18087:6
10:58:07.958 "Warning: BugList is calling a React component directly. Use a factory or JSX instead. See: http://fb.me/react-legacyfactory" react-0.12.0.js:18087:6

http://html5.validator.nu/?doc=https%3A%2F%2Fharthur.github.io%2Fbugzilla-todos%2F

Error: Stray end tag img.
From line 175, column 68; to line 175, column 73
Bugzilla"></img>↩

Error: Element form not allowed as child of element span in this context. (Suppressing further errors from this subtree.)
From line 179, column 11; to line 179, column 57
<form id="login-form" onsubmit="submitLogin()">↩

Error: Stray end tag span.
From line 184, column 7; to line 184, column 13
an>↩ </span>↩ <

Error: Bad value true for attribute hidden on element iframe.
From line 210, column 3; to line 210, column 64
</div>↩↩ <iframe id="submit-iframe" name="submit-iframe" hidden="true">↩ </i

1. Switching between the tab, '#' is appended to the url automatically.
   => http://harthur.github.io/bugzilla-todos/?email={bugzilla-email}#
2. Refresh the page. '#' is regarded as part of email. Then we get nothing for the result.

I have one bug that is closed, but which I recently (post closing) marked as "a?" to get uplift approval. It would be nice if, in this case, the "to nag" panel ignored the closed state and still displayed the bug.

I would prefer to have my reviews being shown from the oldest to the newest but I would understand that some people might prefer the opposite and depending on the tab and the number of items in the tab, users might want to ignore old requests. Maybe there should be an option for that?

If a review/feedback request is requested on an attachment, but that attachment does not have is_patch set, we still link to the Splinter page, even though Splinter does not support these attachments.

eg for a review request for bug 1046226, I had an entry on the bugzilla-todos "To Review" tab, which had the "review" button linking to:
https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1046226&attachment=8490180

Where Splinter shows the error:
"Attachment 8490180 is not an attachment to bug 1046226"
(I've filed bug 1068519 against Splinter to improve this error message)

In ascending order of preference, we should:
a) Hide the review button for !patch attachments
b) Link to the "Details" page for such attachments (eg https://bugzilla.mozilla.org/attachment.cgi?id=8490180&action=edit)
c) Do #b above but if the attachment has content type "text/x-github-pull-request" additionally link to the pull request on Github.

There are 5 Bugzilla queries and some of them take years. Should look into what could make them faster, and maybe offload some logic to the client-side.

It would be nice to see how old a needinfo request is, to see if I should indeed nag the person again :)

I can't fix them since they are blocked!

In issue #54, we throw when encountering err = "HTTP status 400", which can be caused by the bug being non-public (ie Access Denied). I'm going to file an issue against bz.js for making this case more identifiable, but for now we should handle these more elegantly.

The reason for looking at dependant bugs is to decide if the current bug is actionable, and so whether it should be excluded from the "to fix" list or not. In the case of access denied bugs (where we cannot know if they are open or resolved), we should treat them as resolved to be safe (and thus not be the cause for the current bug to be hidden, since we can't say whether it's blocked or not).

https://github.com/harthur/bugzilla-todos/blob/gh-pages/app/user.js#L316

I don't know if this is just the API latency (and query simplicity or lack thereof) making the queries slow, but it seems like "To Review" always loads first. It'd be nice if, should I have another tab loaded first, that one loaded before the others did

My "To Fix" list used to be pretty short, but yesterday or the day before it seems bugmotodo was updated and now it shows all the bugs I've fixed on the UX branch (which isn't merging for a little while...) and are marked as [fixed-in-ux]. This makes me sad because I can no longer distill a useful 'todo' list from it. :-(

I looked through the changes in the last 3 months but didn't see an explicit change in this filtering... maybe I missed it? Was this deliberate, and if so, could we (shudder) have an option to enable/disable this behaviour?

First, this app is amazingly useful, thank you for all the work on it!

Right now an item appears with a notification under "to-nag" when you make a needinfo request of someone. When they clear the flag, it just disappears.

It would be great if there was some indication that the needinfo had been cleared and that the bug was ready for another look.

I'm not sure exactly what this would be, but maybe just a list of all bugs you are mentoring that have a mentee assigned, so you can check up on them easily.

Thoughts?

I don't know much info the API gives out, but if a non-public bug is known to be awaiting my action, it would be nice if the bug number would at least be shown. Even if other data is missing.

I think this might go in all the bugs.forEach() calls (in user.js) but wasn't sure where this makes most sense for you, so I didn't take a stab at it.

In other words, if I have to review 7 patches contained in two bugs, my review tab will show "2" instead of "7". The same for all tabs I believe.

Today my bugmail inbox was heavy on unread stuff, so I needinfo'd myself on bugs I still need to respond to. I'm told I'm not the first one to be doing this.

They show up double, both in "to respond" and in "to nag". Ideally, they shouldn't be in "to nag", I think. :-)

Should switch order of To Fix and To Respond

Making changes to the source is scary without them :(

What testing lib are all the cool kids using these days?

After getting review in bug 1107523, it initially appeared on the "to check in" tab, as expected.

There's more work to be done in that bug apart from the first patch, so I marked the patch as checkin+, hoping the bug would move back to the "to fix" tab.

Instead, it now doesn't appear on any of the tabs. I've assumed that the sum of all the tabs should be a superset of all of my open assigned bugs, but it currently isn't.

See:
https://help.github.com/articles/securing-your-github-pages-site-with-https/

Thanks :-)

It would be quite nice if bugs in the "to check in" panel also showed a brief summary of the status of any try push for the bug. In particular it would be nice to see (1) if a try push has been done, (2) the %-completion of the run, and (3) have the summary be a link to the appropriate treeherder URL.

Currently I have a separate treeherder window open, but since I can't easily drop "uninteresting" builds from it, it's a bit of a pain; also it would be great to have one dashboard rather than two.

STR: (tried on mac, but I suspect the problem will be the same on other OS's)

• go on any view other than "to check in"
• select some text
• hit accel+c

Expected results: copy the text
Actual results: switch to the "to check in" view.

Depends on #39. Would be nice if we had a tab for all the bugs you are assigned to that are blocked on other bugs (instead of showing them in the "To Fix" tab, since you can't fix those yet!)

It's possible to attach (eg by "paste as attachment") a URL to a Github pull request, which auto-redirects to github but means you can set review flags etc.

These attachments are automatically given the mime type of "text/x-github-pull-request" but have "is patch" as false.

These need to be counted as patches, when considering whether to include the bug in "to fix" or {"to nag", "to checkin"}.

Blocked loading mixed active content "http://fonts.googleapis.com/css?family=Crete+Round:400,400italic"

Suggestion:
Use scheme-relative URI: i.e., //fonts.googleapis.com/css?family=Crete+Round:400,400italic"

I've noticed that sometimes the reported times are incorrect.

For example today I filed a bug. bugmotodo says it was changed "3 days ago" -- but that can't be, the bug is just hours old.

I love the new UI.

If I click on a tab, it turns bold. But in the new everything-always-visible scheme, it doesn't seem like clicking on a tab should do anything at all.

Feedback is important. At least as important as official reviews because it is often used as a preliminary sanity check. "Does this code look ok? Should I keep going with it?"

We should add Feedback requests to the To Review section.

would be cool if we could display bug priority and sort by it too

They shouldn't be listed under there because they aren't ready to be checked in until they get r+!

Needs a favicon so you can identify it in an app tab.

I have "To Check In 3" bugs, all of them oranges which had a shot-in-the-dark patch at some point. The patches were actually landed, however the bugs got reopened since the oranges persisted. I'm not assigned to them anymore, but they still appear in that tab.

I would assume that if I select the tab with the new activity, then the indicator would go away, but it doesn't go away until you focus a different tab after focusing that one.

No bugs load for me, I just get this enigmatic exception:

The app's icon is small resolution, probably the same as the favicon? Doesn't scale well to the OSX dock.

we started to use Autolander for gaia but bugzilla-todos doesn't handle it properly.

if I have a bug assigned to myself and Autolander creates the pull request, the bug disappears from the bugzilla todos app after r+, since it considers that Autolander is the responsible for doing the check-in - the correct behavior would be to keep the assignee as the responsible for the check-in.

Autolander documentation on MDN

edit: the bug does show up on "to nag" until reviewer r+ it.

If there is a kind of flag I don't want to nag about it is "in-testsuite" flags. It would be greate to not show them or have an option to hide them.

just cloned

tried to run server

don't have connect

do I install connect globally? what version?

etc etc

(Insert witty inception / "yo dawg we heard you like apps" comment here)

https://fitzgen.github.io/bugzilla-todos/[email protected]

The "To respond" column (currently) has enough items that the bottom item gets cut off, but there is no scrollbar.

The "To nag" column has so many items it has a really long scrollbar, but the bottom of the scrollbar is cut off by the footer of the page.

1. Go to http://harthur.github.io/bugzilla-todos/
2. Click install app
3. Launch app

Expected:
Page resembling http://harthur.github.io/bugzilla-todos/index.html

Actual:
"404 \n There isn't a github page here"

Broken in Nightly and Firefox for Android beta.

Guessing launch_path is incorrect here:
https://github.com/harthur/bugzilla-todos/blob/gh-pages/manifest.webapp#L4

Attempts to test adjusting it locally were unsuccessful, since the Firefox's MozApps.js doesn't seem to like installing from the local filesystem, even when adjusted for absolute paths. Testing from people didn't work either, with another set of unhelpful errors, sigh.

If you land a patch that fixes part of a bug, but not the whole thing, and keep the bug open via whiteboarding [leave-open], the bug stays in the "To Check In" section despite the patch already being checked in.

After a couple days, my bugzilla-todos tab sucks more than 100MB according to about:memory, while it takes 9MB after closing and reopening the tab.

When an open bug has patches with r+, but the bug has outstanding needinfo requests, the bug should appear in the "to nag" section, rather than the "to checkin in" section.