Hello,
Any updates?
Having something to start hacking on would be great.
Thanks!
I'd be happy to help -- but first there's a need to have something to help on :-) 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>
> > 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.
> >
> >
> >
|