Skip to content
  • Kian Paimani's avatar
    Introduce Polkadot-Sdk `developer_hub` (#2102) · eaf1bc56
    Kian Paimani authored
    
    
    This PR introduces the new crate `developer_hub` into the polkadot-sdk
    repo. The vision for the developer-hub crate is detailed in [this
    document](https://docs.google.com/document/d/1XLLkFNE8v8HLvZpI2rzsa8N2IN1FcKntc8q-Sc4xBAk/edit?usp=sharing).
    
    <img width="1128" alt="Screenshot 2023-11-02 at 10 45 48"
    src="https://github.com/paritytech/polkadot-sdk/assets/5588131/1e12b60f-fef5-42c4-8503-a3ba234077c3">
    
    
    Other than adding the new crate, it also does the following: 
    
    * Remove the `substrate` crate, as there is now a unique umbrella crate
    for multiple things in `developer_hub::polkadot_sdk`.
    * (backport candidate) A minor change to `frame-support` macros that
    allows `T::RuntimeOrigin` to also be acceptable as the origin type.
    * (backport candidate) A minor change to `frame-system` that allows us
    to deposit events at genesis because now the real genesis config is
    generated via wasm, and we can safely assume `cfg!(feature = "std")`
    means only testing. related to #62.
    * (backport candidate) Introduces a small `read_events_for_pallet` to
    `frame_system` for easier event reading in tests.
    * From https://github.com/paritytech/polkadot-sdk-docs/issues/31, it
    takes action on improving the `pallet::call` docs.
    * From https://github.com/paritytech/polkadot-sdk-docs/issues/31, it
    takes action on improving the `UncheckedExtrinsic` docs.
    
    ## Way Forward
    
    First, a version of this is deployed temporarily
    [here](https://blog.kianenigma.nl/polkadot-sdk/developer_hub/index.html).
    I will keep it up to date on a daily basis.
    
    ### This Pull Request
    
    I see two ways forward: 
    
    1. We acknowledge that everything in `developer-hub` is going to be WIP,
    and merge this asap. We should not yet use links to this crate anywhere.
    2. We make this be the feature branch, make PRs against this, and either
    gradually backport it, or only merge to master once it is done.
    
    I am personally in favor of option 1. If we stick to option 2, we need a
    better way to deploy a staging version of this to gh-pages.
    
    ### Issue Tracking
    
    The main issues related to the future of `developer_hub` are: 
    
    - https://github.com/paritytech/polkadot-sdk-docs/issues/31
    - https://github.com/paritytech/polkadot-sdk-docs/issues/4
    - https://github.com/paritytech/polkadot-sdk-docs/issues/26 
    - https://github.com/paritytech/polkadot-sdk-docs/issues/32
    - https://github.com/paritytech/polkadot-sdk-docs/issues/36
    
    
    ### After This Pull Request
    
    - [ ] create a redirect for
    https://paritytech.github.io/polkadot-sdk/master/substrate/
    - [x] analytics 
    - [ ] link checker
    - [ ] the matter of publishing, and how all of these relative links for
    when we do, that is still an open question. There is section on this in
    the landing page.
    - [ ] updated https://paritytech.github.io/
    
    ---------
    
    Co-authored-by: default avatarLiam Aharon <[email protected]>
    Co-authored-by: default avatarJuan Girini <[email protected]>
    Co-authored-by: default avatarbader y <[email protected]>
    Co-authored-by: default avatarSebastian Kunert <[email protected]>
    Co-authored-by: default avatarJames Wilson <[email protected]>
    Co-authored-by: default avatarMichal Kucharczyk <[email protected]>
    eaf1bc56