Re: Wayland backend design

[Sergio L. Pascual]

Yes, I already signed the copyright assignment (I think is my third one
with the FSF ;-).

This wayland backend implementation was a PoC that, almost
accidentally, it grew into a mostly functional implementation. Some
parts of it need to be rewritten/refactored before it can be applied to
upstream.

That said, I'd love to see this in upstream, and while I'd like to help
in this task, these days I'm barely able to find 2-3 hours per week for
coding, which is clearly insufficient for this job.

Sergio.


On Mon, 2016-12-12 at 22:14 +0000, Ivan Vučica wrote:
> 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 <address@hidden>
> 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 <address@hidden>
> > 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 <address@hidden
> > a.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 <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
> > a.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 <address@hidden
> > ica.
> > > > > 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
> > >
> > 
> > 
> > 
>