gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Wayland backend design


From: Ivan Vučica
Subject: Re: Wayland backend design
Date: Fri, 19 Feb 2016 14:29:22 +0000

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 <address@hidden> 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 <address@hidden> 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 <address@hidden>
> > 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 <address@hidden>
> > > wrote:
> > > > > On Thu, Jan 14, 2016 at 7:04 PM Sergio L. Pascual <address@hidden
> > > 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.
> > > > >
> > > > >  
> > > > >
> > >


reply via email to

[Prev in Thread] Current Thread [Next in Thread]