Not sure what this is supposed to mean...
If you dont provide any info, this is not valid...

well, there are many :)
But please, you have to report this in a way we have a chance to look at this / reproduce this

@Frank (Ottovan) : sorry I couldnt help further, but may I ask why this is resolved/invalid for you now?
[if there is something you've done to make it work, please let us know -- as others might benefit from your findings as well...]

Hi, for buerocratic reasons, I'll change this to TODO, and would kindly ask @Sybren A. Stüvel (sybren) to share his wisdom? [I havent been through setting this up here myself...]

Soo, looked into this a bit further and it seems like PROP_POINTER buttons indeed dont get undo pushes.
For a little detour: these are not flagged with UI_BUT_UNDO because they are of type UI_BTYPE_SEARCH_MENU (when they get defined via uiDefAutoButR)
Code is explicitly stating (here) that

https://www.blender.org/download/releases/
http://download.blender.org/release/

Oh, @Brecht Van Lommel (brecht) was quicker :) [phab hung here for a bit, so my comment came late...]

Can confirm this,

Please dont claim these yourself, someone will pick it up.

Thanx for spotting this.
Made a differential in D3487

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

This is CLIP_MT_camera_presets vs CAMERA_MT_presets.
Former stores presets in the scripts/presets/tracking_camera folder, later in scripts/presets/camera.

Not sure what the current status of interop with other software is, would kindly ask @Kévin Dietrich (kevindietrich) to also have a look...

Thank you for the report.
Currently we are aware of many issues in 2.8 and actively working to fix them.
But since replying to reports takes time, we have decided to limit bug reports to module team members for the time being.

oops, @Brecht Van Lommel (brecht) was quicker...

Hm, like @Geraldine Chua (gschua) said, blenders vdb import is not really meant to use vdbs generated in other software (yet).

havent hunted down the related commit, but this seems to be resolved in master?

Looks like its working fine, but one of your propellor wings has duplicated geometry...

Not sure I am misunderstanding something, but this doesnt seem to be a bug report?

Putting this on normal (so it doesnt appear untriaged...) because there is an issue [but only with old dependency graph...]

Ahh, get it, thanx @Bastien Montagne (mont29)!

Hm, looking at this part of the code, I can observe:

Thanx for reporting -- it's still a little early though to accept bug reports for 2.8 due to following policy:

@Bastien Montagne (mont29): you mean truncation like you did already in rB66aa4af836 [but more verbose? (how? printf/warn about truncation?)]

not an issue if you use the new dependency graph
(run blender from the commandline with the --enable-new-depsgraph option)

D3486 should fix it

Afraid we need a little bit more information here:

Cannot reproduce with current master (on linux)

Thank you for the report.
Currently we are aware of many issues in 2.8 and actively working to fix them.
But since replying to reports takes time, we have decided to limit bug reports to module team members.

Hi, while we love to hear these ideas, this is not the right place for them.
This website is mainly used to track bug reports and not feature requests.
But luckly, there are some other nice solutions you can take, so please use one of the other forms of communication listed below:

Note: we are getting two undo pushes with this operator [same for box mask btw.]

I'm afraid this is how Undo works in blender.
Not aware of any workaround other than disabling "Draw Waveform".
[patching like you did will work fine if you use the same sound, but will fail to draw the correct waveform if you actually load a new file into the same sound datablock...]

Unfortunately I cannot reproduce the issue (on linux).

Cannot reproduce in master and 2.79b on linux.

reg. [1]: to be precise, the Properties Editor main view is indeed a region, but of RGN_TYPE_WINDOW, the "tabs" you are talking about are usually of type RGN_TYPE_UI or RGN_TYPE_TOOLS.
When it comes to theme colors (and especially the titles) this then gets switched depending on region type here, so when we are in a RGN_TYPE_WINDOW it will end up being the Titles theme setting, when we are RGN_TYPE_UI or RGN_TYPE_TOOLS it will end up being Region Text Titles... Wording might be a bit confusing, but it makes sense, no?

Glad to hear! Closing then...

Though there indeed seems to be a refresh issue of some sort, it is still a little bit early to report those bugs for 2.8 due to following policy:

Cannot reproduce with a NVidia 970m (driver 390.59) on linux, automatic still working fine here...

There was also T55452, but it was fixed already in rBec4ce908db61 :)
So master shouldnt crash anymore (or try a new build from https://builder.blender.org/download -- note: Windows builds there are still from June12, so fix is not in afaict...)

ffmpeg setup in blender seems OK, pCodec is set to jpeg2000 correctly.
anim->pCodecCtx->pix_fmt is AV_PIX_FMT_RGB48LE
anim->pCodecCtx->bits_per_raw_sample is 16
anim->pCodecCtx->bits_per_coded_sample is 8

causes T55478

This doesnt happen if you use Global Undo, so only the combination of Enter Editmode ON and Global Undo OFF

changed between 2.77a and 2.78
rBe3841c91f9, rBf08018f92868, T42526

Looks like this is resolved.

Well, if it is the same object [and this same object is just on multiple layers] then renaming this single object for sure is reflected on every layer it is on.
This is quite expected. If you want different names, you have to duplicate your object.

I'm afraid I cannot reproduce / we need a little more information here.

Ah, missed that actually, sorry. Thx for reporting back.
I'll leave this open though, maybe this should be supported nevertheless... [just saying because it wasnt a problem for carve...]

You could just drag and drop the blender.exe into the command promt and add --debug-cycles to the end

Can confirm this.

Hm, just a shot in the dark:

Can confirm the issue.
this was also true in 2.79b though [if bmesh was used as a solver there -- carve was doing fine, but that was removed since 2.79b].
This adds up to T47030, wasnt sure if this particular report could be merged to any other cases mentioned there, so leaving this open and adding the parent task...

Confirmed (caused by recent clickdrag changes), fix coming shortly...

Can confirm the issue.

Seems I cannot reproduce this (I know you've mentioned it only happens after a while of working, but I did quite a bit of assigning/removing, obmode/editmode switching to no avail...)

causes T55462, possible fix in that task...

bisected down to rB1cddab18ded9

Can confirm, crash in master, worked in 2.79b, having a closer look now

Cannot confirm (checked master, 2.79b and 2.79) on linux

Can confirm this.
Caused by G.main removal in rBd0956e9cb307, rB7b6af843c2bd

Marking as incomplete until we have an answer

Can confirm the issue though my assumtion is that this will end up in a "wont-fix" situation...
Reason being that viewport drawing got a complete overhaul in 2.8 in this wont be an issue there anymore...
(quickly checked this in blender2.8 branch and while there are remaining issues in dupli-drawing there, it is not the case that something is displayed in black there...)

could you launch blender with the --debug-events option [assume your 'pressure' is always 0.0?]

Seems like GPU only then.
Could it be that you are running out of GPU memory?
(if I look at my NVIDIA Server Settings I have it peaking at a little less than 2 GIGs -- which might be a little too much for the GTX 650 Ti...)