Description & Summary errors

[keith]

I think the errors such as:

- WARN  | The description should end with proper punctuation.

Should be removed from CocoaPods. I think all these do is make people spend unnecessary brain cycles on something that is really a non issue. If we wanted to impose some sort of stylistic constraints I think time would be better spent with the order of attributes in specs not just whether or not some fields end with a period. What are your thoughts?

[orta]

I have been thinking abut this lately, but my thoughts have been towards encouraging people to write both the tweetable description and to do a longer summary, the new pod spec create [x] stuff doesn't let you know that summary is optional. ( It is still optional )

[orta]

I think the description not having a full stop a the end is probably something we can live without, the summary though I'm don't think I agree with.

CocoaPods/Specs#3263

[keith]

I like the idea of short summaries but I don't see how ending it in a period changes anything. And as we know well what typically happens is people are unaware of this and they submit a spec with this as a single issue, which just isn't worth any of our time to deal with.

[fabiopelosin]

@Keithbsmiley Good points. To shed some context on the check, it was introduced before the linting process would leverage xcodebuild, so at the time ensuring the correctness of the podspec was an error prone and tricky process. In this regard it helped to fight some contributors which just wanted to use a lib would submit a very messy spec. However the primary reason to introduce the check was to avoid to add normalization logic in clients (I don't like when the search results are not consistent - either from the command line or from a website). It also served as an experiment to test wether a strict approach to validation was feasible. I was expecting a strong backslash which didn't materialize even though some complaints were expressed; as @alloy never expressed to be against it, I just left it there. This test gave me the confidence to introduce the version-tag checks for git sources, as I noticed that the community would accept them as they are already used to a benevolent dictator (Apple).

I don't have strong feelings about it, so if you guys think that it should go, just let me know.

[orta]

I'm inclined to believe that the further we get with automation, the less friction this will be.

At the minute the worst affected are the ones most likely to get hit anyway; new people, because they can't go through pod push or rake release to get the advantage of a full lint there and then. Instead they wait for an email from Travis / Keith. I agree that sometimes it can be a bit over pedantic but the CocoaPods Specs repo isn't just a collection of data specifically for CocoaPods. It's an open data-set of all of the libraries available for Obj-C, and once you perceive it as something that will get used outside of just what we're doing then it starts to make sense to be a little bit more vigilant towards our normalisation.

With luck & maybe sending @alloy some booze we will get the auth that means this sort of problem isn't an issue. Till then my vote is on keeping the punctuation. I dunno if we allow !s but I can see a point towards keeping them.

[fabiopelosin]

I agree with @orta. Regarding the push service my vote is the take it online even without the access control list as that project otherwise risks of being jeopardized and it would allow us to start testing the YAML stuff in the meanwhile.

@orta we even allow the ? 😄

[alloy]

I think the punctuation check can go.

[fabiopelosin]

The results are:

• 2 for removing the check (@Keithbsmiley, @alloy)
• 1 for keeping it (@orta)
• 1 without strong opinions (me)

So unless stopped I plan to remove it in the next round of patches 🍻

[orta]

I love a democracy 🍻

Yeah, it's cool with me.