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
