Closed Olf0 closed 2 years ago
@Olf0: I'll reply few days later, sorry. Will check the code as well
@Olf0:
1: yes, it is correct. Loop at https://github.com/sailfishos-chum/sailfishos-chum-gui/blob/main/src/chumpackage.cpp#L215 runs through {m_repo_url, m_url, m_packaging_repo_url}
and if m_repo_url
is not set it will try m_url
next. That URL is used in constructor for GitHub/GitLab projects (if they fit the scheme as tested by ::isProject
) and through that would support corresponding features (issues, releases)
2a,b: If any of the three is set ({m_repo_url, m_url, m_packaging_repo_url}
), developer name would be set from that if needed. Now, indeed, packager name is not currently set if we query m_packaging_repo_url
. Surely can be done, just wasn't as a part of the spec when I implemented it. Can be considered as a bug / missing feature
2c: We can consider doing it, indeed.
These were quick "few days" (just one)! :wink:
1: yes, it is correct.
Thank you for the clarification.
2a: If any of the three is set (
{m_repo_url, m_url, m_packaging_repo_url}
), developer name would be set from that if needed.
For me it seems to be not O.K. to extract the developer's name from the m_packaging_repo_url
, even as a second fallback.
2b: Now, indeed, packager name is not currently set if we query
m_packaging_repo_url
.
In contrast to the behaviour you described for 2a, this appears to be logical.
Surely can be done, just wasn't as a part of the spec when I implemented it. Can be considered as a bug / missing feature.
O.K. Which of the following two options do you prefer?
2c: We can consider doing it, indeed.
In general I do not like web-page "scraping", because web-pages are often altered. But in this case, I believe that the pretty name will very likely always be right below the avatar picture, so this is a sustainable solution.
Filed as issue #81.
@rinigus, before we get side-tracked into point 2c / issue #81 even more, the main open question for this PR is (WRT points 2a & 2b):
O.K. Which of the following two options do you prefer?
- Leave everything as it is (code and this PR), and mark this PR as "ready for review"?
- Address 2a & 2b in the code, while I extend this PR to cover this behaviour.
@Olf0: sorry for delays. I think it would make sense to proceed with as it is. In general, with Chum, we would have to work taking into account that Jolla can pull the plug on OBS in May. So, before we invest a lot of time into improvement of it, would be nice to get OBS status reaffirmed. On the other side, we shouldn't let it rot either as that would be a mistake as well. Would have to balance those aspects :)
@Olf0: sorry for delays. I think it would make sense to proceed with as it is.
O.K., done (sorry I had forgotten to do this).
In general, with Chum, we would have to work taking into account that Jolla can pull the plug on OBS in May.
Oh, I missed that. Where does that May deadline come from? I had the impression that (after the heated discussion at FSO) the Sailfish-OBS will be maintained until Jolla provides a viable alternative, which I expect to come in "Jolla time": years or never.
I found it. Thank you for posing the question to the IRC community meeting 2022-05-12.
Oh, I missed that. Where does that May deadline come from? I had the impression that (after the heated discussion at FSO) the Sailfish-OBS will be maintained until Jolla provides a viable alternative, which I expect to come in "Jolla time": years or never.
As expected, the answer is vague and tardy, but the undertone appears to be negative. :disappointed:
Indeed, no clear reply and we have to search for undertones without being given +/- and their contributions to decision.
Still …
Or is there anything holding you back from merging this (and also PR #79)?
@Olf0: sorry, just forgot to do so.
@rinigus,
Repo:
is not set or the metadata for SailfishOS:Chum is completely missing, the URL provided by theURL:
field in the spec file preamble is used instead." You wrote that the "RPM SPEC URL [is] used as a fallback for Url/Repo", but AFAICS inchumpackage.cpp
m_url
is preset with theURL:
field of the spec file preamble (in line 118) and then used as the default value for theHomepage:
field (in line 210). But them_repo_url
is left empty when not set (see line 203) before entering projectgithub.cpp or projectgitlab.cpp; what these two do is hard to grasp for me as a former Shell and C programmer.DeveloperName:
the comment statesIf not set, and a GitHub repository is set, then the name will be automatically retrieved. Note that such automatic retrieval is not supported for GitLab repositories.
Repo:
-URL, but with or without the fallback mechanism discussed in 1., above?DeveloperName:
, but not for the fieldPackagerName:
. I think they should be handled then same, i.e.,If not set, and a GitHub repository is set
as PackagingRepo:, then the name will be automatically retrieved. Note that such automatic retrieval is not supported for GitLab repositories.
Is this already the case?