Project.refs format unclear when multiple sources used per element
- Dominant language
- Python
- Stars
- 140
- Forks
- 45
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 6
Description
[See original issue on GitLab](https://gitlab.com/BuildStream/buildstream/-/issues/1148)
In GitLab by [[Gitlab user @nanonyme]](https://gitlab.com/nanonyme) on Oct 1, 2019, 20:19
We bump during https://gitlab.com/freedesktop-sdk/freedesktop-sdk/merge_requests/1576/diffs#eb2b5a4de291ad913743f39160f765c432c94a33 to the issue that project.refs is quite unclear with multiple sources per element since there's insufficient context available to understand what each ref means. This makes reviewing changes quite hard when project refs are used and as a result freedesktop-sdk didn't take project.refs into use and gnome-build-meta is considering dropping project.refs.
The underlying idea of splitting the data that BuildStream actively modifies during track into a separate file is reasonable but current design doesn't seem to be sufficient for BuildStream projects.
Contributor guide
Research direction
Start with the linked GitLab issue and its referenced freedesktop-sdk merge request to understand how project.refs is represented when elements have multiple sources. Done requires an agreed project.refs format that provides enough context to identify each source and makes changes easier to review.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100