I usually create a fork if I need a PR. By the way, maybe I misunderstood; if you do have push access already and you think something is really, really trivial, go ahead and push small changes. :-)
On Sun, Mar 24, 2019, 01:18 Sergii Stoian <stoyan...@gmail.com> wrote: > Hi Ivan, > > On Sun, Mar 24, 2019 at 2:34 AM Ivan Vučica <i...@vucica.net> wrote: > >> From experience outside GNUstep: I don't think it's necessarily a bad >> practice to do code review on every commit going in (including >> trivial), even among core devs. It's perhaps a shame we're not >> enforcing code review for /every/ submission. >> >> Anyway, I think each of the improvements sounds good -- I think it's >> very good to upstream your changes, so thank you for doing this. They >> do sound like something where it might be a good idea for a second eye >> to take a quick look? (I know I wouldn't mind having someone take a >> look at my changes, when I make them, as even trivial ones could break >> things.) >> > I understand your concerns absolutely. Everybody make a mistakes. :) > Although there are some corner cases were I'll take a courage to commit > directly. > For example, Ukrainian translation file. Is it OK? > >> >> How about we try with PRs for these (incl for trivial changes) and >> then look at flipping the permissions switch for you? >> > It's good if it's make GNUstep code quality better. > I'm a GNUstep developer since 2001, if I recall correctly (including paper > signing from FSF). > Moreover, I'm a perfectionist for quality in code and feel of a UI/UX. > I don't know if somebody else here is everyday user of GNUstep codebase as > me (I use NEXTSPACE as production environment for a several months). > If something goes wrong I'll see it immediately. :) > > Anyway, I'll agree with you and will start creating PRs. > Do I need to create branch or fork? What would your recommend? > >> >> Once again, thank you for offering these patches! >> >> On Sat, Mar 23, 2019 at 9:52 PM Sergii Stoian <stoyan...@gmail.com> >> wrote: >> > >> > Hi Fred, >> > >> > Thank you. As I've replied to David, I tend to push trivial patches >> directly to HEAD. More complex I'll create as a pull request so we can >> discuss details before merge. >> > >> > Answering your last question: I have a set of tested changes to older >> GNUstep release (you may find them here >> https://github.com/trunkmaster/nextspace/tree/master/Libraries/gnustep). >> > I want to include these changes into current release of GNUstep. The >> main areas are: >> > - focus management and window manager interaction (hide application, >> minimize window), mouse click on titlebar, appicon, inside window; >> > - mouse properties: configurable double-click time, line scroll >> multiplier, left/right menu button (some details: >> https://github.com/trunkmaster/nextspace/issues/8); >> > - applications "-autolaunch" behaviour: do not show menus and do not >> steal focus; >> > - mouse cursors: I've created a cursor theme which is fully compatible >> to Awaita (standard `de facto` I guess). You may find my thoughs here: >> https://github.com/trunkmaster/nextspace/wiki/Mouse-Cursors; >> > >> > Also I have several trivial patches: >> > - prevent blinking of appicon on focus switch/appicon double-click. >> It's quite noticable with cairo backend; >> > - Font panel weird look and feel on WM (no resize bar, items must be >> clicked higher then it drawn) >> > - use title image in miniwindow >> > - etc. >> > >> > In long-term I want to adopt cairo backend as default for NEXTSPACE. I >> want to move some functionality from ART backend. >> > For example, I'd like to have an option and support of font packages >> (.nfont). >> > I want to polish UI: some elements draw lines as gray instead of black >> (I know about half-pixel problem). >> > I'd like to test and enhance NSBrowser behavior. I want to implement >> display resolution changes adoption at backend level. May high DPI some >> day... >> > >> > On Sat, Mar 23, 2019 at 12:05 PM Fred Kiefer <fredkie...@gmx.de> wrote: >> >> >> >> Hi Sergii, >> >> >> >> having a pull request to review and approve is always the nicer way to >> work with patches. But if this is too much hassle for you feel free to do a >> direct commit or even to send a patch file to the mailing list. Which area >> are you planing to work on? >> >> >> >> Cheers, >> >> Fred >> >> >> >> On the road >> >> >> >> Am 23.03.2019 um 01:42 schrieb Sergii Stoian <stoyan...@gmail.com>: >> >> >> >> Hello everybody, >> >> >> >> I plan to commit some changes/fixes to GUI and Back. >> >> My last GNUstep commit was long time ago to SVN at gna.org. I'm >> familiar with git and github. >> >> >> >> My question is: what is the correct way to submit patches/fixes? >> >> Should it be a pull request for approval? >> >> May I commit directly to the source tree on github? >> >> >> >> -- >> >> Sergii Stoian, >> >> ProjectCenter lead developer >> >> NEXTSPACE owner, lead developer >> >> >> >> _______________________________________________ >> >> Gnustep-dev mailing list >> >> Gnustep-dev@gnu.org >> >> https://lists.gnu.org/mailman/listinfo/gnustep-dev >> > >> > >> > >> > -- >> > Sergii Stoian, >> > ProjectCenter lead developer >> > NEXTSPACE owner, lead developer >> > _______________________________________________ >> > Gnustep-dev mailing list >> > Gnustep-dev@gnu.org >> > https://lists.gnu.org/mailman/listinfo/gnustep-dev >> > > > -- > Sergii Stoian, > ProjectCenter lead developer > NEXTSPACE owner, lead developer >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
