Best create a new one, as it has been quite some time and we probably don't want everyone have to read these 13 mails again.
(You have my +1) J Am Di., 13. Aug. 2019 um 14:48 Uhr schrieb julio cesar sanchez <jcesarmob...@gmail.com>: > > As it looks like we didn't agree in the squash + merge, can we agree now? > Or should I create a new thread to discuss it again? > > > El jue., 23 ago. 2018 a las 16:24, Jan Piotrowski (<piotrow...@gmail.com>) > escribió: > > > Here is the PR on GitHub templates, our usage of them and actual > > drafts for all templates: > > https://github.com/apache/cordova-contribute/pull/3 > > > > Please keep all further discussion on the issue and pull request > > template in this Pull Request. Thank you. > > Am Di., 21. Aug. 2018 um 20:21 Uhr schrieb <raphine...@gmail.com>: > > > > > > Sounds pretty good to me. A few thoughts: > > > > > > - The support question template should refer people to a proper support > > > site like Stack Overflow. > > > - Merge convention should be: if multiple commits make the history more > > > meaningful, do a merge commit, else squash and rebase. > > > - the templates will probably require different information to be > > provided, > > > depending on the repository. cordova-lib is usually platform independent, > > > for example. > > > > > > Shazron <shaz...@gmail.com> schrieb am Mi., 8. Aug. 2018, 06:52: > > > > > > > Agree with all 3 points by Jan. > > > > > > > > @Chris Brody I think we should make use of Github Milestones to track > > > > related issues. > > > > On Wed, Aug 8, 2018 at 6:59 AM Jan Piotrowski <piotrow...@gmail.com> > > > > wrote: > > > > > > > > > > Update to my initial email: > > > > > > > > > > I just noticed we actually _do_ have an issue template in use in the > > > > > cordovs-docs repository: > > > > > > > > > > > https://github.com/apache/cordova-docs/blob/master/.github/ISSUE_TEMPLATE.md > > > > > > > > > > J > > > > > > > > > > 2018-08-07 23:18 GMT+02:00 julio cesar sanchez < > > jcesarmob...@gmail.com>: > > > > > > I think us as committers should decide if the commits make sense to > > > > keep > > > > > > all of them or squash them into one. But bug fixes should usually > > be > > > > only > > > > > > one commit, and major refactors are not usually sent by non > > committers > > > > > > > > > > > > El El mar, 7 ago 2018 a las 23:02, Chris Brody < > > chris.br...@gmail.com> > > > > > > escribió: > > > > > > > > > > > >> > > I would favor a place where a contributor can mark if s/he > > would > > > > > >> > > recommend the committer should *not* use the squash option. > > > > > >> > > > > > > >> > That of course could be defined in the contributor guidelines > > or PR > > > > > >> > template (although there it might be a bit confusing to new > > users > > > > that > > > > > >> > don't know what this is talking about). Do you know how other > > > > project > > > > > >> > handle that? > > > > > >> > > > > > >> Haven't seen anything like this before. > > > > > >> > > > > > >> > In the end it is always the decision of the committer how > > > > contributed > > > > > >> > code makes it into the code base, so having good guidelines for > > us > > > > > >> > would probably be the best solution, right? > > > > > >> > > > > > >> Yes. General common sense may prove to be the major principle, as > > I > > > > > >> think it has in the past. For example: > > > > > >> * Someone raises a PR with bug fixes and major refactoring in > > separate > > > > > >> commits (should not be squashed) > > > > > >> * Someone else raises a PR with a single fix, but with extra > > commits > > > > > >> to fix issues with the first commit (*should* be squashed) > > > > > >> > > > > > >> I wonder if we can track these discussions in a better way, > > somehow. I > > > > > >> have no time to help with these things right now. I think better > > > > > >> tracking could help ensure these important tasks do not get > > forgotten. > > > > > >> > > > > > >> > > --------------------------------------------------------------------- > > > > > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > > >> For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > >> > > > > > >> > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
