Overview
Request 735125 superseded
- Created by seife
- In state superseded
- Supersedes 734953
- Superseded by 746077
- Open review for openSUSE:Factory:Staging:A
Request History
seife created request
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
dimstar_suse set openSUSE:Factory:Staging:A as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:A"
dimstar_suse accepted review
Picked openSUSE:Factory:Staging:A
dimstar declined review
Really - I detest the way you try to sabotage openSUSE - this does not add simplicity in the way the package is maintained. It actually makes things more complicated and this only for your personal gain of 'not having to follow rules' - the silliest of arguments ever. Declining
dimstar declined request
Really - I detest the way you try to sabotage openSUSE - this does not add simplicity in the way the package is maintained. It actually makes things more complicated and this only for your personal gain of 'not having to follow rules' - the silliest of arguments ever. Declining
superseded by 746077
Using a personal repo for maintaining patches? C'mon Stefan, you must be kidding us. I for one am not willing to accept this into the distro. It does not make maintenance of the package for the wide community easier
Version 2 (see home:seife/bluez, where I'm hashing out the details) contains everything including spec&co in git https://github.com/seifes-opensuse-packages/bluez.
Like every git repo this can be easily moved somewhere else if necessary. In a personal repo, it is just easiest to set up.
Pull requests work for personal repos on github as well as for all others (nonwithstanding the fact, that for now the services are to be run manually/locally and thus there is no "seife is on vacation, so nobody else can fix anything if he does not accept the PR on github"-problem.
So I really don't see the problem. If in the future someone else wants to maintain bluez, they can just change the _service file to point to another git repo location.
BTW: The main complaint from the SUSE community is always that tracking patches is hard. Putting them into git makes tracking patches much easier. Once OBS gets a decent source management, this can be reverted, but we are waiting for many years for that with no hope of it happening anytime soon.
I like the spirit, though I am also eagaerly awaiting devs to realize that having two SCMs adds to the tracking difficulty. Basically, there are only stupid options right now. Which is stupid :-p
I realize this, but until OBS develops into a usable SCM, I'll take that "another level of indirection" (RFC 1925) over "having no usable SCM at all".
I use a similar setup as https://github.com/seifes-opensuse-packages/bluez (but with server-side services) on my private OBS / Github Enterprise instances at work with the added benefit that users do not even need to know anything about OBS, they just commit their code to github and packages are "magically" built for them. (I usually help them with the initial spec file though).
If anything goes wrong with a package, nobody even needs to look in OBS for the changes, they just check their "git log" output for the fubar that broke it.
@seife Please just fix the patch name in the changes file, your changes don't need a GitHub repo. This is not kernel source.