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, 15 Jan 2016 18:41:13 +0000

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