Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Marijn
    @marijns95:matrix.org
    [m]
    Not afraid for backports anyway, once we cut a new release we can just do non-breaking followup releases with new nonbreaking features
    But we generally haven't needed those, it's not like any release really broke
    It's only for the odd case where someone really insists on needing a certain fix/feature on a specific version because they can't upgrade to the newer ash, but that has never happened thus far
    Ralith
    @ralith:ralith.com
    [m]
    I mean as a matter of routine practice, we could consider master to always be the next breaking release, and also merge non-brekaing PRs to the latest backport branch
    Marijn
    @marijns95:matrix.org
    [m]
    Not sure how I feel about preliminary picking of non-breaking changes to a backport branch
    In any case, my worry was more about doing lots of breaking releases in quick succession, but I think we can do one now
    But yes, maintaining a backport branch and eagerly merging breaking changes to master would alleviate that somewhat... 🤔
    Ralith
    @ralith:ralith.com
    [m]
    higher constant overhead, lower per-PR overhead, unclear where we're at on that axis
    have seen it work well for really really big repos but we arguably are not there yet
    just food for thought
    so long as you're the one keeping track of what needs to be merged I'm not gunna complain :D
    Marijn
    @marijns95:matrix.org
    [m]
    :P
    Yeah I definitely hope we're not big enough for that :D
    I guess I'll just go start merging PRs then
    Shall we get MaikKlein/ash#597 in first and keep that as the last non-breaking commit in the event that we'd like some backports?
    Ralith
    @ralith:ralith.com
    [m]
    sgtm
    Marijn
    @marijns95:matrix.org
    [m]
    You'll probably have to rebase your PR a bit then, new functions and all...
    Perhaps @MaikKlein should change the PR settings to require everything to be based off of main before we can click merge
    (That should also automatically show an "update branch" button in GH UI)
    Because then at least we'll have the CI - in particular the generator run - against main always
    Otherwise it'll only start erroring about missed generated changes after being squash-merged on top
    And so I saw the wrong 1.3.207 title (should have been .208) as I clicked merge
    Oh well :D
    Ralith
    @ralith:ralith.com
    [m]
    close enough >_>
    Marijn
    @marijns95:matrix.org
    [m]
    Happens too often tbh 😂
    Ralith
    @ralith:ralith.com
    [m]
    rebased 599, and added a second commit with some cosmetic internal cleanup
    Marijn
    @marijns95:matrix.org
    [m]
    Nice touch, did I really go against the status quo and use the function call for 1.3 only?
    I only see .fp_v1_3() calls, nothing else 🙈
    Marijn
    @marijns95:matrix.org
    [m]
    I think we've got everything. 592 is not ready (your input is appreciated there too Ralith) and 595 can land another time for ash-window
    I'll try to publish a new release tomorrow unless anything else comes up
    Ralith
    @ralith:ralith.com
    [m]
    sgtm
    Marijn
    @marijns95:matrix.org
    [m]
    Also just dropped some branches related to bors or associated with a closed PR. @MaikKlein Anything else we can remove from https://github.com/MaikKlein/ash/branches/all?
    Ralith
    @ralith:ralith.com
    [m]
    there's a toggle to auto-delete branches, very nice to enable
    Marijn
    @marijns95:matrix.org
    [m]
    Would be great to have for the merged PRs indeed
    Is a blessing on some other repos
    Ralith
    @ralith:ralith.com
    [m]
    opened KhronosGroup/Vulkan-Docs#1803 for the upstream issue
    fewer cases than I'd feared
    Marijn
    @marijns95:matrix.org
    [m]
    That's manageable
    Looks like it didn't make it into the .209 update this morning though :)
    Ralith
    @ralith:ralith.com
    [m]
    -Z time-passes output items more than 100ms:
    time:   0.104; rss:  695MB ->  696MB (   +1MB)    crate_lints
    time:   0.107; rss:  457MB ->  483MB (  +25MB)    coherence_checking
    time:   0.109; rss:  817MB ->  822MB (   +6MB)    partition_and_assert_distinct_symbols
    time:   0.171; rss:   43MB ->   93MB (  +50MB)    total
    time:   0.177; rss:  696MB ->  697MB (   +0MB)    privacy_checking_modules
    time:   0.178; rss:  892MB ->  895MB (   +4MB)    encode_query_results
    time:   0.195; rss:  255MB ->  290MB (  +35MB)    late_resolve_crate
    time:   0.195; rss:  892MB ->  894MB (   +2MB)    incr_comp_serialize_result_cache
    time:   0.195; rss:  892MB ->  894MB (   +3MB)    incr_comp_persist_result_cache
    time:   0.195; rss:  892MB ->  894MB (   +3MB)    serialize_dep_graph
    time:   0.199; rss:  695MB ->  696MB (   +1MB)    lint_checking
    time:   0.202; rss:  549MB ->  557MB (   +8MB)    item_types_checking
    time:   0.231; rss:  608MB ->  611MB (   +3MB)    match_checking
    time:   0.237; rss:  252MB ->  290MB (  +38MB)    resolve_crate
    time:   0.318; rss:  608MB ->  613MB (   +5MB)    misc_checking_2
    time:   0.381; rss:  393MB ->  412MB (  +18MB)    misc_checking_1
    time:   0.413; rss:  412MB ->  457MB (  +45MB)    type_collecting
    time:   0.511; rss:   56MB ->  252MB ( +196MB)    expand_crate
    time:   0.511; rss:   56MB ->  252MB ( +196MB)    macro_expand_crate
    time:   0.515; rss:  290MB ->  407MB ( +117MB)    hir_lowering
    time:   0.662; rss:  800MB ->  817MB (  +17MB)    monomorphization_collector_graph_walk
    time:   0.685; rss:  682MB ->  697MB (  +15MB)    misc_checking_3
    time:   0.781; rss:   52MB ->  290MB ( +238MB)    configure_and_expand
    time:   0.805; rss:  483MB ->  549MB (  +66MB)    wf_checking
    time:   0.861; rss:  824MB ->  894MB (  +70MB)    codegen_to_LLVM_IR
    time:   1.636; rss:  697MB ->  824MB ( +127MB)    generate_crate_metadata
    time:   1.885; rss:  557MB ->  608MB (  +51MB)    item_bodies_checking
    time:   2.233; rss:  613MB ->  680MB (  +67MB)    MIR_borrow_checking
    time:   3.466; rss:  412MB ->  608MB ( +196MB)    type_check_crate
    time:   3.678; rss:  872MB ->  894MB (  +22MB)    LLVM_passes(crate)
    time:   4.033; rss:  824MB ->  894MB (  +70MB)    codegen_crate
    time:  14.673; rss:   40MB ->  102MB (  +62MB)    total
    interesting that codegen is so large, given the general absence of meaningful logic in ash
    Marijn
    @marijns95:matrix.org
    [m]
    Thats's really curious
    And macro expansion is relatively cheap
    Anyway, shall we get 0.37 out the door and start looking more into these?
    Ralith
    @ralith:ralith.com
    [m]
    sgtm
    Marijn
    @marijns95:matrix.org
    [m]
    Heh, just as you approve I find some more noise in the changelog
    Here goes the CI again...
    And more...
    If it wasn't for a handwritten changelog being a bit easier to redact (ie. omit internal changes, clean up PR titles), I'd go for GH automatically generating it from commits when "publishing" a release on a tag
    Ralith
    @ralith:ralith.com
    [m]
    yeah, mixed bag