Ελεγχος προαπαιτούμενων και υποστήριξη macos

[drpaneas]

• Υποστήριξη Macos
• Ελεγξε όλα τα binaries
• Βγάλε τον έλεγχο των req εκτος loop
• Ελεγχος αρχείου σταθμών FM
• Διόρθωση bash coding style

Fixes #13

[cerebrux]

Ευχαριστούμε αλλά ο κώδικας πάνω στον οποίο δούλεψες είναι ο Master και όχι το develop.

Δες αν μπορείς να είσαι up to date με τον κώδικα που στέλνεις διότι αυτό δεν μπορώ να το κάνω merge στο master :)

https://github.com/CerebruxCode/shelldio/tree/develop

[drpaneas]

Ευχαριστούμε αλλά ο κώδικας πάνω στον οποίο δούλεψες είναι ο Master και όχι το develop.

Προφανώς αν το PR μου βασιζόταν στο develop branch θα έστελνα PR στο develop branch, και όχι στο master :)

Εχω κάνει δεκάδες συνεισφορές στο open-source και το πιο κλασσικό github workflow λέει ότι ο κώδικας που δουλεύεις πρέπει να βασίζεται στο latest master branch και να μην έχει merge conflicts με αυτό. Από αυτό κάνεις branch και δουλεύεις σε ένα bug fix/feature, και όταν είναι έτοιμο το στέλνεις πίσω στο master:

• https://guides.github.com/introduction/flow/
• https://github.com/firstcontributions/first-contributions
• https://opensource.com/article/19/7/create-pull-request-github

δεν μπορώ να το κάνω merge στο master :

"Τεχνικά" μιλώντας μια χαρά merge μπορείς να το κάνεις, στέλνω αλλαγές στο master και είμαι update με το master, δεν υπάρχει κανένα conflict και αυτό φαίνεται και από την CI. Αν ήμουν up to date με το develop branch και έστελνα αλλαγές στο master, τότε στην ουσία θα σου έκανα rebase το develop στο master.

Δες αν μπορείς να είσαι up to date με τον κώδικα που στέλνεις

Εξηγήσε μου με ποιο branch πρέπει να είμαι up to date για να στείλω PR στο master branch; Η κοινή λογική θα έλεγε: με το master branch, με το οποίο είμαι.

Φαντάζομαι ότι αυτό που κάνεις είναι να κρατάς frozen/locked το master branch και να δέχεσαι PRs στο develop branch. Συνεπώς ακόμα και να ήμουν 100% up to date με το develop branch, πάλι θα μου έκλεινες το PR, γιατί δεν δέχεσαι PR στο master.

Αρα στην ουσία το πρόβλημα δεν νομίζω να είναι αυτό που περιγράφεις. Το πρόβλημα είναι (ίσως?) ότι δεν δέχεσαι PRs στο master branch.

Για να μην αφήνουμε πράγματα όμως στην φαντασία του καθενός, θα σου πρότεινα να φτιάξεις ένα CONTRIGUTING.md

• https://github.blog/2012-09-17-contributing-guidelines/
• https://en.wikipedia.org/wiki/Contributing_guidelines

Σε αυτό το εγγραφο μπορείς να εξηγήσεις πώς μπορεί να συνεισφέρει κάποιος open-source developer στο συγκεκριμένο project. Διαφορετικά, χωρίς να υπάρχει αυτό το έγγραφο, γίνεται ζημιά και στις δυο πλευρές, στην "υγεία" της κοινότητας του Cerebrux, και στον προσωπικό χρόνο που σπατάλησε άδικα ο εθελοντής contributor.