Official IMPORTANT: Upcoming changes to the Graphics repository

Yeah basically what @sabojako is seeing is correct. There is no other commits for that specfic path yet. To see the past history, you have to look at the commits from the root folder or from commits prior this move. All history is there, this is just how it's presented on github.

 

@superpig For convenience, could you ask the team to create a branch from the commit before the folder move? Pretty please Like I said, nobody needs to maintain it, just don't delete it.

 

There's no need for separate branch, just checkout the commit before the move's commit. For example on master it's this:

https://github.com/Unity-Technologies/Graphics/tree/056eccb89d

 

This is more a Quality of life change request.
Please reduce size of HDRP 14,15 both API and library. This change will speed up library import and editor responsiveness.
When you are making new scripts and changing them oftenly, does HDRP packages affect script (re)compilation time?

 

So? Did they finally start mirroring? I see no major commit recently.

 

Hey I'm wondering about that invisible time gap between committing to master and being on a Unity build.

For instance we are waiting for this feature to be delivered. It was committed to master on this branch.
That was over 2 months ago. So what happens between that commit and a Unity release? Since releases happen every week we are confused as to why there have been 8 Unity releases and no delivery of said feature.

And the other thing that I would love to know is where features land. Meaning, Unity 2022.1, 2021.3, etc.

 

Afaik this feature shipped on URP 14 already. You can use it if you use latest 2022.2 alpha.

And here we get to that alpha again. Unity doesn't land features to already released versions. Unity gets to feature freeze stage at some point when the version is at beta and then only major / high prio feats can sneak in.

Unity doesn't typically backport features either, mainly SDK updates and bugfixes but there are some exceptions every now and then (for example we got FSR added just few weeks ago to 2021.2).

To answer to your main question. New features land to whatever version Unity is working towards on their internal trunk. The version they are working with is afaik few weeks ahead of the alphas we get - if there is public alpha available. If there's no alpha then chances are we are not getting the feat until there is.

Current 2021.3/staging etc branches are for maintaining the older versions, meaning we get the bugfixes and whatever gets backported to these and master is where the normal development is at.

 

You are correct, it's on URP 14 hidden in the changelog. Thanks!

It would be great to know which features will get backported (like the one you mentioned).
Because of course it's quite a huge risk to upgrade the project to an alpha/beta Unity build, and we need that feature quite badly (perhaps it seems like a small insignificant one but when you make a black & white game and all the sudden yellow pops out of nowhere then everything falls apart), so it would be much appreciated to know Unity's plan on everything or if we need to do something ourselves.

 

The safe assumption is that majority of the new features won't get backported. Knowing how little Unity wants to tell us when upcoming features will land, I seriously doubt they would be willing to start making promises of specific feature backports (which like mentioned are rare cases anyway).

Don't get me wrong, I'd LOVE to get more transparency on the feature roadmap ETAs myself. Unity used to give them but they got tons of backlash from the community when they didn't meet the targets - so it kinda makes sense that they don't tell specific ETAs anymore.

 

Im just sad I can no longer track the development of the gpudriven branch. In my opinion this was the most exciting feature to be developed for the srp's and can actually be a game changer. Im even more sad by the fact that it relies on some internal c++ side api's so I cant really pull it in and make it work for our case. I really hope this festure gets the love and attention it deserves.

 

It might be ahead of a patch release, but it's visible in the target branch to us a week later than it used to be for typical PRs (only a small percent of graphics PRs rely on separate Unity source changes).

And now overall visibility of any PR will happen significantly later than before, since a PR can take days, weeks, sometimes months before it's merged to a release branch.

And as mentioned above, a lot of work used to be visible that is now completely invisible to us, because experimental changes (such as the gpudriven branch) don't always have PRs. And we won't know to ask for visibility.

Do you have plans to address those issues with the new approach? It's really frustrating to lose things that were important factors in major choices we made.

 

It appears this hasn't happened yet. For example: https://github.com/Unity-Technologies/Graphics/commit/8c6a242300e292fd7e2e16f0d72b71b7a0b6de40

Is there an ETA for when that will be the case? How can I figure out the details of the intent of those linked changes? This type of thing is exactly what I was afraid of - it already sucks to lose the details of those fixes, so now the best I can hope for is it will be contained to commits made in the transition period rather than an ongoing issue.

 

I've seen more batched commits since my post a couple weeks ago - one had a collection of one-line descriptions (still not great but better than the earlier one I posted), and one didn't. I'll hold off on poking y'all about it until the end of May (if it's still happening by then), but since the repository isn't getting retroactive improvements to its commits, any commit with a usability problem adds a permanent usability problem to the repository. So the longer things are switched to the new process without being 'stabilized', the more issues the repo will have forever.

 

Bigger fear right now is - knowing past actions from Unity - is that they may just silently drop the whole thing. I don't want to jinx it but I have my concerns.

 

is there some reason why some packages got left behind in the root folder? this just makes the repo look messy now

 

3-4 months later, this doesn't appear to have materialized yet. The repo is several weeks out of date and doesn't seem to have some of the changes that are listed in the release notes of newly released versions of Unity.

Can you give us an updated ETA of when the Graphics repository mirroring step will have that 'days at most' timeframe? Even if you're still doing manual verification the several week delay is pretty extreme.

 

I was thinking the same, it's been a long while since the last mirror. Last one was over 15 days ago I believe.

 

last repo sync happened 17 days ago, commits here: https://github.com/Unity-Technologies/Graphics/pull/7453/commits

I think majority of 2022.2.0a16's commits are here @slime73 but I do agree it's not great sign to see just few merge attempts from internal repo since the announcement.

Would love to hear more comments from Unity staff what's the hold up and what's the CURRENT plan. Please don't tell you plan to sync the repo once a month now because we can already see it going to 2 months then, and then once half year etc.

All I take away from this is that this change just somehow makes it less convenient to merge internal branches when people at Unity is busy doing other things. By the sounds of it you are now doing this all manually but we all know that's not going to work in the long run. You should totally automate this as much as possible.

 

Thanks for updating the repo.

I think using averages for this sort of thing is kind of misleading, because a 7 day average doesn't communicate that half the commits will be visible 7-14 days late compared to if they were pushed immediately. i.e., max is a lot more useful here than average IMO.

Progress on mirroring speed is good to hear. The numbers and branch situation is a little confusing to me. Here's my understanding of how it was and how it is, let me know if I got anything wrong.

Previously:

• Non-public: Some experimental commits were made in the internal repos not visible to users.
• Public: Many experimental commits were pushed to publicly visible branches before any PR is made (between 0 days and several months before a PR is made).
• Public: A PR is made in the public repo with individual commit history within the PR and may be publicly visible for somewhere between a few days up to a few months before being merged.
• Release: After a PR is merged, it may take 1-3(?) weeks for a new Unity release that contains a version of HDRP/URP/etc with the change.

Currently:

• Non-public: Experimental commits are very rarely made public, if ever (a change may be majority-complete for several months before it's publicly visible).
• Non-public: A PR is made in the internal repo and may take between a few days up to a few months before being merged to the internal staging branch. A supposed goal of the current strategy is that this specific step may be a bit shorter than before.
• Non-public: The staging branch will only be merged into a release branch after some time has passed (a week? more?)
• Release: A new Unity release including the release branch changes may happen before some of the items below. because Unity releases and public repo syncs happen independently from each other.
• Non-public: Up to two weeks will pass after that merge.
• Public: The release branches will be pushed to the public repository after those delays.
• Release: Very recent changes that got pushed to the public repo will make it into a Unity release after that push.

Your potential future change:

• Non-public: Experimental commits are very rarely made public, if ever (a change may be majority-complete for several months before it's publicly visible).
• Non-public: A PR is made in the internal repo and may take between a few days up to a few months before being merged to the internal staging branch.
• Public: Some internal staging branch commits may be pushed to the public repository (at what cadence?)
• Non-public: The staging branch will only be merged into a release branch after some time has passed (a week? more?)
• Public: depending on push cadence, more staging branch commits may be mirrored to the public repository.
• Release: A new Unity release including the release branch changes will happen.
• Non-public: Up to two weeks will pass after that merge.
• Public: The release branches will be pushed to the public repository after those delays.

Again the wording has been a little confusing to me so I'm sure I got something wrong in that summary.

 

It's been 17 days since the last sync - will it be synced again soon?

 

Here's a new one https://github.com/Unity-Technologies/Graphics/pull/7521

 

@AljoshaD Is there any chance we could get access to ALL commits that get merged to master? For example on the last PR one of the commits was this https://github.com/Unity-Technologies/Graphics/commit/aee83ab636866275bf8edb3b16eb1489ea3b30fc which is just useless if you need to cherry-pick some individual fix from here. There's no way to separate the fixes anymore since the original commit history is gone.

I guess this would mean Unity also mirroring extra staging branches like in this case I assume we are missing the commits because these were staged at HDRP staging which isn't mirrored now.

 

What's happening with the mirroring process? It's been over a month since the master branch received anything from the internal repository.

Last post here was months ago. Any updates?

 

Some communication from earlier in this thread:

Spoiler

- Review stage for the "first months" has now been going on for 8 months
- 3 weeks for every review stage has slowly turned into 10 weeks per review stage
- "few weeks of testing" where Unity patch releases are ahead of the public repo has turned into 7 months
- PR's are not mirrored as single commits at all, but squashed together in a huge single commit
- Original PR description and messages are lost

The "few days at most" delay has turned into an unknown amount of time with no communication at all.

 

Though to be fair who could've seen this coming..!!

 

That's the issue, a lot of people in this thread were afraid of exactly this. Promises, then it all goes quiet. Everyone forgets about it, and no progress is made. Seems to be the case so far, it's been months since the first post, and months after the last post with seemingly no progress, in a way it's worse than before as the master branch received nothing for over a month now, not even manual commits from the internal repository.

 

Yeah. On the one hand I'm disappointed and not surprised, because it's a familiar thing across Unity.

On the other hand, this impacts my job quite heavily (I was at a point in my project the past few months where I didn't have to care about it very much, but that's changing). The way this has shaken out is honestly unacceptable for a professional tool and service like Unity.

EDIT: This was a pinned thread until recently, and now it's not despite major parts of the changes supposedly still being WIP. What is going on? Combined with everything else I'd almost think Unity is trying to bury it. I hope that's not true.

 

To think that without public repositories, we wouldn't have glorious commits like this...

 

Any news? Will the master branch be a part of the next mirror?

 

It's now been about 4 months since this update, 8 months since starting to move forward with the staging branch changes, and a whole year since the initial repository change.

The most recent two merges were over a month apart(!), and the staging branch change hasn't happened yet as far as I know.

Is there an update for when things will be at the level talked about last July? So far things have been slowly regressing more and more over the past year. The repository is getting less usable because of it. Some concrete plan updates for stopping and reversing those issues would be appreciated.

 

The time between reporting a bug and being able to grab & confirm a fix for people working actively with SRP has not improved due to this change either, it has actually gotten worse. I'm currently stuck in this process regarding a couple of bugs, and have enough first hand (pre-2022) experience to compare.

None of this would be a problem if things got actively used and tested internally, but we all know this is not the case. There are features that have landed in SRP, broken, and stayed broken for 1 to 2 years. Automated tests currently do not have enough coverage to rely on, so streamlining this process with the SRP community who actively use and test the product is critical.

Ignoring voices and concerns, no communication, false promises, introducing massive delays and obfuscation through squashing commits together is not the way things should be headed if there is genuine interest to improve the situation.