Best, Thomas Boerger On 06/06/2016 05:11 PM, Marguerite Su wrote:
Hi,
I've been AFKed for a while so didn't catch up with the fork and recent commits.
I'm ok with the fork, it gives me access to openSUSE organization.
But actually I'm a little mad with the package updates...someone has brought this kind of behavior on ML once...while I am the author of a project and the only maintainer for a package, suddenly I see my release schedule, versioning scheme and control over my package was totally altered by just leaving a note, from upstream to downstream.
YES, I didn't reply in time. But in that hurry? better not. it's not urgent security updates, but some cleaning work (I doubt). I didn't see any respect and open discussion here actually. Newbies for go still have their rights to go, gentlemen.
Complaint is over. Bad things just happen everyday. Let's go back to the codes to carry on.
Hi, I am sorry you feel this way. I appreciate, and I am sure a lot of other people do too, your work and your efforts on maintaining these go packages. Your packages are being used by other people and I think we should all make an effort to manage the conflicts that have and will arise. github and open build service gives us tools to create small changes and discuss on them: Pull Requests and Submit Request. What about we all use these tools from now on to prevent future situations like this? What about we follow this rule: "If one wants to add new things, creates a Pull Request in github/openSUSE/golang-packaging" "Then, someone else who is maintainer of the package, has to review and accept this request." We could use http://lgtm.co which will enforce it. If we do that in github, then I think we could use a _service file in obs that can get the code automatically, without further revision. Will that work for you? Will that work for everybody else?
While I think I knew golang libraries are statically built when I introduced those runtime requirements. (The commit message makes me feel I didn't write main function in a 10-line C program)
It was not to bring go itself in (although there was such side effect) but for ABI consistency.
Back when I updated golang from 1.3 to 1.4, I noticed those:
OBS will not rebuilt all golang stuff after the main go's version bumps.
From time to time there're failed states in openSUSE:Factory for 3rd-party golang libraries. If A depends on B, when B is updated, A will not get rebuilt, not like the standard behavior for C/C++. So I have to update A too to fix the failure which can be resolved by an automatical rebuild.
So this is it: if golang updates to 1.7, all 3rd-party golang libraries will still explicitly require golang 1.6 in my design.
Then when you build another golang programs depend on one of those libraries.
It will get an "unresolvable" error. Very Clear. Instead of processing the build and failing somewhere random because of using go 1.7 and some go libraries built against go 1.6.
Unless we can get a solution, either to fix from OBS side or prevent those situations better, we can not just omit the codes I wrote.
I think we should find another way to fix this. What about using "BuildRequires: go". Wouldn't that retrigger a build? jordi
Marguerite
-- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org