Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Applets updates #267

Merged
merged 6 commits into from
Apr 2, 2017
Merged

Applets updates #267

merged 6 commits into from
Apr 2, 2017

Conversation

Odyseus
Copy link
Contributor

@Odyseus Odyseus commented Apr 1, 2017

Custom Cinnamon Menu (0dyseus@CustomCinnamonMenu) update

  • Updated help file.

Desktop Handler (0dyseus@DesktopHandler) update

  • Updated help file.

Extensions Manager (0dyseus@ExtensionsManager) update

  • Updated help file.

Popup Translator (0dyseus@PopupTranslator) update

  • Updated help file.

Quick Menu (0dyseus@QuickMenu) update

  • Updated help file.

Window list (Fork By Odyseus) (0dyseus@window-list-fork) update

  • Updated help file.

@brownsr
Copy link
Member

brownsr commented Apr 1, 2017

@Odyseus Would it be possible to submit one PR for each applet ? We would prefer changes to be made against one applet/desklet/extension at a time. That way it avoids the risk of reverting changes to multiple spices if an error is found.

I've just updated the guidelines for contributing to make the reason for asking for PRs against one applet at a time clearer.

@Odyseus
Copy link
Contributor Author

Odyseus commented Apr 1, 2017

Hello, @brownsr

Would it be possible to submit one PR for each applet? [...] That way it avoids the risk of reverting changes to multiple spices if an error is found.

Sorry but, no. Your argument for requesting such thing is reasonable and I follow that reasoning on every pull request that I make. If you look at this particular pull request itself, there is nothing that would ever require to be reverted nor to even be reviewed. That is why I created this pull request with several commits for several xlets grouped and another separated pull request with just one commit for one individual xlet.

@NikoKrause
Copy link
Member

NikoKrause commented Apr 2, 2017

Just a little note:
Looking at the overview of the commit history of your applets, it's meaningless.
Every commit title says: OdyseuesApplet: update
E.g.
https://github.com/linuxmint/cinnamon-spices-applets/commits/master/0dyseus@CustomCinnamonMenu

Just saying.

I closed this PR for now, because of invalid title of the PR.
Something like OdyseusesApplets: Update helpfile

@Odyseus
Copy link
Contributor Author

Odyseus commented Apr 2, 2017

Hello, @NikoKrause.

Looking at the overview of the commit history of your applets, it's meaningless.

The title that I give to my commit messages follow the guidelines that you are enforcing. And if you really look at the commit history, more than 50% of my commits were made to accommodate my xlets to your guidelines. The people that RTFM (the only ones that I take into account) already have the real full changelog on every single README of my xlet's Spices page.

The title of a pull request has nothing to do with the commits history. And the title of this pull request reflects exactly its content.

@clefebvre @collinss @JosephMcc

Can someone bring some common sense into this? All this micro managing has become annoying to the point of intolerable and it's starting to become a huge waste of time.

Reviewers should be focusing on security and instead are wasting their time (and mine) on enforcing guidelines that were edited on the fly after I created this pull request in question.

This isn't the first pull request that I created with this exact same format (#176, #170, #161, #52, #36, #17, #13 and #3). I'm becoming intelligent enough to know when to create a pull request for several xlets and when not to. This pull request as it is can't possibly have any negative impact anywhere nor can contain an error that would require a revert of its merging.

The reasoning given by @brownsr in the newly edited guidelines shouldn't even be taken into account if the pull request was done by an author and the review process was done properly before merging. It's obvious that all this was triggered by this pull request, a pull request that never should have passed revision if the guidelines that you are enforcing on me had been followed by the reviewer himself.

Being subjected to the current guidelines and enforce them as rules written on stone is ridiculous. Especially considering that the four Spices repositories have totally different guidelines.

If my contributions aren't welcome anymore, just let me know. You all must have better things to do with your time, and so do I.

@NikoKrause
Copy link
Member

I don't know about the general opinion, but I don't mind having multiple commits in one PR.

I also don't mind your commit messages. Just saying that the title could be more informative, not that it should.

But I stick to my opinion, that the title of the PR should mention, which applet/s is/are updated.

Looking at closed PR, I can see by a glance, which applets are affected by the PR. It would suffice to write Odyseus Applets: helpfiles update

@NikoKrause NikoKrause reopened this Apr 2, 2017
@JosephMcc
Copy link
Contributor

I personally have taken a step back from being involved in the spices handling. We have a small group that does this and I actually feel like having too many people handling it is just as bad as not enough.

That being said I don't see the problem with this PR personally. The title of the PR doesn't mean much. It's the individual commits that matter. They look to me like they follow the guidelines: one commit per spice with the title properly mentioned. The way it is done here allows a single commit to be reverted if there was a need. Each commit also contains a small blurb saying what it does and it is coming from the actual author.

@brownsr brownsr merged commit d83835f into linuxmint:master Apr 2, 2017
@Odyseus Odyseus deleted the general branch May 7, 2017 09:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants