Also called the Git workflow, I am quite confused of how the process works. There is a guide and even following it, I am more confused than before since there are missing pieces and information about this workflow even though each step looks "straight-forward".
Honestly, I don't have issues if this new git workflow was communicated well to volunteers and packagers, alike. I actually see potential in it but I also see potential problems with it assuming this will become the main workflow in the future.
Firstly, the lack of information on what Git config to have. When I tried it for the first time, Git LFS needs to be enabled. What's interesting is Git LFS by nature is slow as indexing and tracking large files can really slow down uploads and downloads of package sources. As a volunteer living in the Philippines, in a city with at least "okay-ish" internet, it took me at least 30 minutes to download the LFS "objects" for the vendored tarball for rusty v8.
Secondly, after I was able to push the Git sources to my fork, I performed a PR but here are other things that got me confused.
- There are two git branches,
develvsfactoryin https://src.opensuse.org/javascript/rusty_v8. - As mentioned in the guide, you have to make a PR to the
factorybranch. But isn't the point ofdevelin the old workflow to attempt building the project before pushing it to Factory as part of the checks? - The scm-staging-bot was not present even after the PR was approved.
Lastly, there should be some form of CI but maybe the build runs on OBS through the scm-staging-bot š. But there was none present.
The new workflow is such a blocker because, for example, as of writing, there is a need to update deno as mentioned in here. Knowing that, I also searched and found that there were some that shared my frustration or confusion with the move to git workflow in here.
Overall, this is still a developing issue, so I might update this post after some things are cleared up? Yeah...