search

sailfishos / sailfish-utilities

Sailfish Utilities
GNU Lesser General Public License v2.1
23 stars 22 forks source link

[ui] added "Restart UI" control. Fixes MER#1129 #31

Closed Mikaela closed 9 years ago

deztructor commented 9 years ago

Please, check patch submission rules and other commits (as example): you should mention the bug number (currently - mer bug number) in the commit subject. In this case because it does not fix bug but contributes to it, it should contain "Contributes to MER#xxx", where xxx is the bug nr.

Mikaela commented 9 years ago

I don't understand.

I didn't see patch submission rules anywhere, you are missing CONTRIBUTING.md file.

I also don't know about any other bug than #25 at GitHub which is fixed by https://github.com/sailfishos/sailfish-utilities/pull/27 otherwise except removing the mentioning about keyboard restart fixing clipboard which as we know it doesn't do.

Mikaela commented 9 years ago

Is this better? The title is too long though and goes against best practices of git commit.

deztructor commented 9 years ago

These rules are common for Mer project, so no need to add it to each project. It was explained and link was send somewhere (mer and sfos mailing list?). I can try to find it but you can also dig MLs archives.

Mikaela commented 9 years ago

What if I only have issue with single app and am not going to go around the internet unless the rules are clearly stated or linked in README or CONTRIBUTING file?

deztructor commented 9 years ago

"[xxx] Fixes MER#YYY" or "[xxx] Contributes to MER#YYY" are used by integration automation. It'd be not only in the first subject line but anywhere there. There is Mer bugzilla http://bugs.merproject.org/ where are bugs end up now. And if you check commit message for the commit closing #27, you'll find the number of the bug ("[ui] added "Restart UI" control. Fixes MER#1129")

Mikaela commented 9 years ago

But this issue has nothing to do with MER#1129.

No fear of me ever trying to contribute to MER or Sailfish OS or similar.

deztructor commented 9 years ago

Each project has own contribution and acceptance policies. These policies are there for the non-bureaucratic reason - sake of integration and further maintenance needs. Changes could find a way to changelogs only if these rules are followed. Of course, such small change could go w/o it but release can't be tagged until there is a fixed bug could be referenced there.

Mikaela commented 9 years ago

Sorry, things that don't make any sense annoy me, but I will try again without making any sense.

Mikaela commented 9 years ago

and apparently I cannot reopen this pull request, because there was force-push.

deztructor commented 9 years ago

I just mentioned issue #27 you told about and corresponding mer bug. Rules are common and not established by me (while I understand the reasons) PR can be accepted when it is done right: after acceptance changes can't be amended later. BTW, this is changes in wording, and each wording has corresponding l10n record, so anyway it will go through the l10n process.

deztructor commented 9 years ago

To update PR you should not close it, just push force as you did.

Mikaela commented 9 years ago

To update PR you should not close it, just push force as you did.

How about you reopen this pull request then? I would happily do it by myself, but first I was given error message that I cannot reopen this as I have "force pushed or rebased". Now I again cannot reopen this, because there is already another open pull request, #33, should I close it?

deztructor commented 9 years ago

Not a problem, if you created another PR and closed this, it just becomes a history.