Re: Commit process to source tree on github

[Ivan Vučica]

>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.)

How about we try with PRs for these (incl for trivial changes) and
then look at flipping the permissions switch for you?

Once again, thank you for offering these patches!

On Sat, Mar 23, 2019 at 9:52 PM Sergii Stoian <address@hidden> 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 <address@hidden> 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 <address@hidden>:
>>
>> 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
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
>
> --
> Sergii Stoian,
> ProjectCenter lead developer
> NEXTSPACE owner, lead developer
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev