On 03.02.2016 22:19, Ruediger Meier wrote:
BTW what I really don't like is that a maintainer can just commit without branching/sr'ing at all. Some people just commit (even without any commit message) and they would never sr at all. That's the most annoying thing. You don't even get a message that somebody did something.
Well, the "no/bad commit message" is obviously bad. But there are sometimes fixes that are just too trivial (SPDX license string fix, really trivial specfile fixes / cleanups, ...) to warrant the whole fork, build, ... cycle, so I also sometimes just commit the fix in the devel package.
And last but not least ... the submitter should not be allowed to accept his own request accept he _owns_ the project (e.g. his own home:USER).
And also there are exceptions to the rule IMO. Example: bluez package is really maintained in home:seife:testing. home:seife:testing is enabled and used on all my machines (13.2, 42.1, Factory). So once I have decided to submit bluez to Base:System, the only thing someone could improve by having a second look is to fix style issues in the spec file ("missing patch tag" is one of those i especially like, but it's not enforced in Base:System AFAICT). So usually I submit it to Base:System, just to immediately accept and forward it to Factory. Where it will be looked at anyway and it will undergo scrutiny in staging, which would not have happened in Base:System anyway. Add to that, that bluez upstream is extremely reliable IMHO, means: they do not break compatibility without announcing it, their announce mails for new versions can be put 1:1 into the rpm changelog and are a useful sumkmary etc, so the risk of an bluez update breaking things is low. (No, they are not perfect, yes, there have been bugs exposed by staging or obs tests, but usually a version update is extremely painless). I certainly would usually not accept my own submitrequest against a package which is not maintained and tested by me, but where I just made a build fix and submitted that to get dependencies fixed again. But even there it depends. If it is some pacakge where lots of stuff depends upon (and which thus blocks a rebuild) and where I just had to do a trivial buildfix which "surely does not break anything" (famous last words, I know), then I might be tempted to just speed things up by self-accepting / forwarding things if I'm in a position to do that (co-maintainer of the project) Applying common sense is certainly helpful :-) The above things written about bluez and home:seife:testing can be applied to the vdr packages and home:seife:vdrdevel, too. I'm self-accepting all the submissions in the vdr repo also. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org