> @@ -138,10 +138,10 @@ W: http://plugins.geany.org/geanyprj.html > S: Odd Fixes > > geanypy > -P: Lex Trotman <[email protected]> > -M: Lex Trotman <[email protected]>
> I like having separate repo/issues/build system, etc, which is why I kept > GeanyPy as external to Geany-Plugins. I don't think every plugin people write > should be forced to be in Geany-Plugins. Yes, definitely not forced but let's say "strongly suggested" because having a plugin in GP is nice both for users and developers. I don't think there's a problem in having a separate development repo - I think even with this it could be quite easy to copy-over the sources from the development repo to GP before a release with a simple commit message like "updates from upstream" (something similar to what happens when Scintilla gets updated in Geany). The question is what to do when someone makes a pull request to the plugin in GP - one option is to merge it in GP and apply it also upstream, the other is to reject the patch in GP and ask for submitting it upstream. > I don't mind formatting patches for changes to upstream so they can be > applied to the fork in Geany-Plugins, but it's going to get harder and harder > as the fork has diverged significantly from my repo (ex. the proxy plugin > stuff, the geany_functions commit, etc). That's real pity it became a real fork - any chance to get the implementations merged so there's just one geanypy? Which one contains what - the GP one contains the proxy plugin stuff and yours not or the other way round? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany-plugins/pull/435/files/e0d77167b2d9550fbd2e689347a80fb97371004b#r66634539
