I strongly support the merge into GNUstep, but would still suggest to remove the GUI extensions. There are two additional window flags for menus and I am almost sure that these could be handled just as well in the backend by checking other attributes on the menu window.
Fred > Am 12.12.2016 um 23:14 schrieb Ivan Vučica <i...@vucica.net>: > > Pulled, thanks. > > To check: Did you sign copyright assignment? If I get around to it, can I > import your work on the wayland backend? > > On Mon, Dec 12, 2016 at 11:37 AM, Sergio L. Pascual <s...@sinrega.org> wrote: > Hi Ivan, > > Sorry, I'm using Gogs as git server, and it dies from time to time > (still better than running that monstrosity named GitLab). It should be > up now. > > Sergio. > > > On Sun, 2016-12-11 at 01:34 +0000, Ivan Vučica wrote: > > Hey Sergio, > > > > I wanted to take a peek at this since a change in the bootloader (!) > > seems to have weirdly interacted with nvidia's drivers and gave me > > back the use of a framebuffer device. > > > > Was there any further progress here? Because the repos seem to be > > down, do you have a copy of this code somewhere else? Shall we work > > on upstreaming this? > > > > Thanks > > > > > > > > On Fri, Feb 19, 2016 at 2:29 PM Ivan Vučica <i...@vucica.net> wrote: > > > A very cursory look generally makes me happy (but it is indeed > > > dirty and requires cleanup). > > > > > > Thank you for your work! I'm looking forward to proper review of > > > the code (or using this code, reworking it for import). :-) > > > > > > > > > On Tue, Feb 16, 2016 at 11:38 PM, Sergio L. Pascual <s...@sinrega.or > > > g> wrote: > > > > Sorry, wasn't able to put any work on this for the past weeks. > > > > > > > > I've just created a pair of repos to hold the dirty > > > > implementation. You > > > > can take a look there, if you're willing to deal with extreme > > > > ugliness: > > > > > > > > - https://git.sinrega.org/slp/back-dirty > > > > - https://git.sinrega.org/slp/gui-dirty > > > > > > > > I expect to be able to start the clean implementation on the next > > > > week. > > > > > > > > Sergio. > > > > > > > > On Thu, 2016-02-11 at 01:58 +0000, Ivan Vučica wrote: > > > > > Hello, > > > > > > > > > > Any updates? > > > > > > > > > > Having something to start hacking on would be great. > > > > > > > > > > Thanks! > > > > > > > > > > On 25 Jan 2016, at 23:21, Ivan Vučica <i...@vucica.net> wrote: > > > > > > > > > > > I'd be happy to help -- but first there's a need to have > > > > something > > > > > > to help on :-) > > > > > > > > > > > > On Sun, Jan 24, 2016, 23:27 Sergio L. Pascual <s...@sinrega.or > > > > g> > > > > > > wrote: > > > > > > > In the next weeks, I'll be doing a clean implementation of > > > > the > > > > > > > changes, > > > > > > > in a sane way and following the coding style. Meanwhile, > > > > I've > > > > > > > initiated > > > > > > > the process to assign the copyright to the FSF. > > > > > > > > > > > > > > I also plan to publish the ugly, dirty code somewhere, so > > > > you can > > > > > > > take > > > > > > > an early look at it. > > > > > > > > > > > > > > On Sun, 2016-01-17 at 19:02 +0000, Ivan Vučica wrote: > > > > > > > > Please do let me know when you have something to review > > > > -- > > > > > > > thanks! :) > > > > > > > > > > > > > > > > On Fri, Jan 15, 2016 at 6:41 PM Ivan Vučica <ivan@vucica. > > > > net> > > > > > > > wrote: > > > > > > > > > On Thu, Jan 14, 2016 at 7:04 PM Sergio L. Pascual <slp@ > > > > sinreg > > > > > > > a.org> > > > > > > > > > wrote: > > > > > > > > > > On Thu, 2016-01-14 at 15:49 +0000, Ivan Vučica wrote: > > > > > > > > > > > I think it would be worth reviewing this code. If > > > > you > > > > > > > agree, > > > > > > > > > > I'd love > > > > > > > > > > > a patch series applied on top of a particular > > > > Subversion > > > > > > > commit > > > > > > > > > > > (possibly published as a series of Git commits on > > > > top of > > > > > > > a > > > > > > > > > > mirror > > > > > > > > > > > created by Gregory). Each patch should tackle one > > > > self- > > > > > > > > > > contained task > > > > > > > > > > > ("git add -i" is awesome). Alternatively, each Git > > > > branch > > > > > > > > > > should > > > > > > > > > > > tackle one task, and could be collapsed into a > > > > single > > > > > > > patch > > > > > > > > > > (i.e. > > > > > > > > > > > Subversion commit). > > > > > > > > > > > > > > > > > > > > I like the idea of linking git commits to self- > > > > contained > > > > > > > tasks. > > > > > > > > > > In > > > > > > > > > > fact, is the strategy I use for all my repos, both > > > > personal > > > > > > > and > > > > > > > > > > professional (in this case, we do SCRUM, and each > > > > commit > > > > > > > should > > > > > > > > > > reference a bug/task/improvement ticket). > > > > > > > > > This is an approach I'm fine with. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bundling a bunch of changes of a branch into a single > > > > one > > > > > > > doesn't > > > > > > > > > > sound > > > > > > > > > > as good, though. That could only mean that you have a > > > > > > > really > > > > > > > > > > broken > > > > > > > > > > commit policy for your git repo, and that you need > > > > this to > > > > > > > make > > > > > > > > > > some > > > > > > > > > > sense of it ;-) > > > > > > > > > This was mentioned having in mind the approach that > > > > people > > > > > > > might > > > > > > > > > have: commit possibly broken things as you go, keep > > > > them on a > > > > > > > > > branch, then consider the "pull request" (with 20, 30 > > > > smaller > > > > > > > > > commits) as the final product. For purposes of GNUstep, > > > > > > > however, > > > > > > > > > not a "pull request" but a "patch" should be considered > > > > the > > > > > > > final > > > > > > > > > product. This means "if you commonly do pull request, > > > > it'd be > > > > > > > > > preferable to squash it first". > > > > > > > > > > > > > > > > > > Why? Two reasons: > > > > > > > > > > > > > > > > > > - We still use Subversion > > > > > > > > > - your commits will spam watchers and history with > > > > many > > > > > > > commit > > > > > > > > > notifications (e.g. via email or RSS) > > > > > > > > > - or they will get squashed (which watchers will > > > > probably > > > > > > > prefer) > > > > > > > > > > > > > > > > > > - I would like to use Gerrit to review your changes. > > > > > > > > > - Gerrit has a concept of a 'change' (approximately, > > > > one > > > > > > > > > Subversion commit or > > > > Github/Bitbucket/pick_code_hosting_site > > > > > > > pull > > > > > > > > > request) > > > > > > > > > - Each change track the history of the change as it > > > > is > > > > > > > being > > > > > > > > > reviewed > > > > > > > > > - Each item in the history is called a 'patch set' > > > > > > > > > (approximately, full diff from the base commit -- think > > > > > > > 'squashed > > > > > > > > > development history') > > > > > > > > > > > > > > > > > > So it's a different workflow than I would use for a > > > > personal > > > > > > > small > > > > > > > > > project, which amounts to "record much of history so > > > > you can > > > > > > > > > revert! use branches to avoid breaking master!". > > > > > > > > > > > > > > > > > > I'd be fine with not using Gerrit to review, but we'll > > > > still > > > > > > > need > > > > > > > > > to deal with Subversion, which will lose much of the > > > > useful > > > > > > > > > metadata anyway (e.g. when was the commit made). > > > > > > > > > > > > > > > > > > So I'd still like to /kindly ask/ for medium-sized > > > > patches > > > > > > > amenable > > > > > > > > > to being submitted via Subversion -- or Git branches > > > > that are > > > > > > > > > squashable. :-) > > > > > > > > > > > > > > > > > > (I'm only kindly asking, because if this is not > > > > acceptable, I > > > > > > > don't > > > > > > > > > want procedure to prevent something as useful as this > > > > from > > > > > > > coming > > > > > > > > > in.) > > > > > > > > > > > > > > > > > > > That said, moving everything (repos, issue tracking, > > > > > > > milestone > > > > > > > > > > management and even CI) to a self-hosted Gitlab > > > > instance > > > > > > > (or some > > > > > > > > > > other > > > > > > > > > > similar, FOSS tool) would surely make the life of > > > > both > > > > > > > > > > maintainers and > > > > > > > > > > contributors a lot easier. I know is somehow > > > > inappropriate > > > > > > > to say > > > > > > > > > > this, > > > > > > > > > > being a newcomer, but hey, you asked :-P > > > > > > > > > We have a migration path to Git and it's going to be > > > > executed > > > > > > > Real > > > > > > > > > Soon Now. > > > > > > > > > > > > > > > > > > But, let's end the discussion here to avoid the > > > > occurrence of > > > > > > > > > another (sadly toxic) centithread. > > > > > > > > > > > > > > > > > > > > Additionally -- because reviewed code is easier to > > > > review > > > > > > > when > > > > > > > > > > > executed -- could you prepare setup instructions so > > > > I can > > > > > > > more > > > > > > > > > > easily > > > > > > > > > > > build and run this? My desktop is Ubuntu 14.04; my > > > > > > > > > > understanding is > > > > > > > > > > > that I will need to run Weston under X11 (Nvidia > > > > drivers > > > > > > > I use > > > > > > > > > > are > > > > > > > > > > > proprietary blobs; I haven't tried setting up X- > > > > less > > > > > > > Wayland > > > > > > > > > > thus > > > > > > > > > > > far). > > > > > > > > > > > > > > > > > > > > Weston has a variety of its own backends, so you can > > > > run in > > > > > > > under > > > > > > > > > > X11, > > > > > > > > > > directly on FB/DRM, or under another Wayland > > > > compositor. > > > > > > > > > > > > > > > > > > > > To run it you'll just need to build wayland-protocol, > > > > > > > wayland and > > > > > > > > > > weston (the forked one). Probably, there should a > > > > page in > > > > > > > the > > > > > > > > > > wiki > > > > > > > > > > explaining this, among some description of its design > > > > and > > > > > > > > > > internals. > > > > > > > > > I'm mainly requesting some tl;dr instructions to > > > > minimize > > > > > > > time > > > > > > > > > it'll take me to set up a development/review > > > > environment. > > > > > > > > > > > > > > > > > > I've only toyed with running Weston available under > > > > Ubuntu > > > > > > > 14.04, > > > > > > > > > so I have no experience building it (my understanding > > > > is that > > > > > > > I'll > > > > > > > > > need a patched version?), and I have no experience > > > > running > > > > > > > Wayland > > > > > > > > > apps. So if you can get me from "empty Ubuntu homedir" > > > > to > > > > > > > "gnustep > > > > > > > > > under wayland", that'd be great. > > > > > > > > > > > > > > > > > > (Of course, reasonable granularity of steps :-) I can > > > > > > > hopefully > > > > > > > > > quickly resolve some build issues as long as I have > > > > general > > > > > > > > > requirements and steps in front of me.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Have you filled copyright assignment forms with > > > > FSF? This > > > > > > > would > > > > > > > > > > be > > > > > > > > > > > necessary to import your code into GNUstep itself. > > > > > > > > > > > > > > > > > > > > Not yet, but I filled them in the past for other > > > > projects > > > > > > > (GNU > > > > > > > > > > Hurd, > > > > > > > > > > GNU Mach, and Glibc, I had a wild youth ;-), so this > > > > > > > shouldn't be > > > > > > > > > > a > > > > > > > > > > problem. > > > > > > > > > \o/ Excellent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > sent from phone > > > > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev