In reply to @emilazy:matrix.org
another con is that it's unintuitive for contributors

In reply to @emilazy:matrix.org
and it's harder to coordinate Haskell changes with stuff in the usual master/staging workflow

In reply to @maralorn:maralorn.de
Only for ones which already understand the staging workflow.

In reply to @emilazy:matrix.org
which AIUI is not good for Haskell even for changes that don't cause a lot of rebuilds?

In reply to @emilazy:matrix.org
I've definitely avoided touching Haskell stuff in the past because the procedures are different and unfamiliar and I've seen multiple others express the same sentiment

In reply to @emilazy:matrix.org
I've definitely avoided touching Haskell stuff in the past because the procedures are different and unfamiliar and I've seen multiple others express the same sentiment

In reply to @maralorn:maralorn.de

linj:
Cons:

• It costs considerable extra build time, which is a scarce resource, and honestly sometimes I think people are eyeing us whether that’s really necessary. It’s also a problem for us, because sometimes the hydra scheduler just lets us hanging dry for days.
• Whenever staging-next lands in master it gets merged into haskell-updates which basically always triggers a full rebuild of our package set effectively staling is for a few days.
• We need to be careful not to merge in those moments, because more generally it is our responsibility to only merge into master when the cache is already populated.

Pros:

• We have our own decoupled timing. We open a new branch, bump everything at the start, then we fix stuff and can merge at the end. We are heavily contributor time constraint and being able to set our own pace is super helpful.
• Also of course we can have lower roundtrip times until stuff reaches master.
• Having our own hydra jobset, which we can e.g. restart or cancel makes it much easier to have a well-defined workflow around our package set. We have e.g. tooling which currently heavily relies on that.
• I assume that in staging our dependencies would more often wait for rebuild or actually be broken, that are time windows in which we are flying blind and cannot fix stuff that easily.
• Related to that: If we added all our ci jobs to the staging test set, they would probably see more rebuilds and thus increase CI load the other way around. Hard to say which solution results in more builds, but it certainly wouldn’t speed up the already very work intensive staging cycle.

I have really never thought about this. To be honest I think it would not be impossible to integrate our workflow into the staging workflow, e.g. bumping the hackage snapshot regularly on staging and then stabilizing on staging-next, but it would be quite a lot upfront cost and probably more friction in the day-to-day.

In reply to @maralorn:maralorn.de
Well, we don’t generally forbid it, but it really helps our QA to only merge into haskell-updates, because then we always have the hydra check. Sometimes packages unexpectedly break a dependency. And ofc there is also merge conflicts …

In reply to @eldritchcookie:matrix.org
oh makes sense guess i just got salty that my fix took 2 weeks but i never had a contribution that wasn't merged on master rather than staging so

In reply to @emilazy:matrix.org
and you end up with an experience more like a multirepo

In reply to @maralorn:maralorn.de
That’s a bit sad. I promise it is totally fine to just open a PR and we will be very helpful in guiding people in the right direction, which is really not that complicated. And that quickly, easy PRs often get dealt with within a day because we have relatively clear responsibilities.

In reply to @emilazy:matrix.org
I do wonder if master/staging wouldn't be faster overall. staging would be slower, of course, but you can't get faster than merging directly into master when things don't cause a bunch of rebuilds