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.org> 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 <i...@vucica.net> wrote: >> > > On Thu, Jan 14, 2016 at 7:04 PM Sergio L. Pascual <s...@sinrega.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. >> > > >> > > >> > >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev