Re: [Vala] The future of Vala

[Baptiste Gelez <gelezbaptiste openmailbox org>]

Le 2016-09-10 23:58, Evan Nemerson a écrit :
> On Sat, 2016-09-10 at 21:22 +0000, Ben Iofel wrote:
> > Sounds awesome. Even if we don't move to github, we should still
> > allow
> > people to submit pull requests on the mirror
> > (https://github.com/gnome/vala)
>
> I completely disagree.  There should be one place to somehow request a
> change in the code.  The only way we should accept pull requests
> through a GitHub *mirror* is if they are transparently mirrored to the
> canonical location, which is extremely non-trivial.
>
> Obviously, without automatic mirroring you're forcing the developers to
> monitor multiple channels, which sucks, but there are also other
> consequences.  If the PRs aren't mirrored automatically they won't
> properly interact with CI, which means they won't be properly tested.
>
> You would also have to mirror all comments in both directions;
> commenting on GitHub would have to result in a comment on the canonical
> location so developers see them, and if a developer comments on the
> canonical location it would have to be mirrored back to GitHub so the
> contributor sees it.  You might be able to get a bot account going for
> this, but then it's a poor experience for anything involving more than
> one person on each site.
>
> Even if you do mirror comments in both directions, you still couldn't
> handle things GitHub doesn't support (like real code review).
>
> Finally, I'm not sure it's fair to GNOME to accept PRs through GitHub.
> It would set a precedent for other projects which isn't fair for them,
> and likely end up making everyone more frustrated.
>
> As for moving to GitHub instead of just accepting PRs through the
> mirror, I really don't think that is the right answer here, and I say
> that as someone who does a decent amount of open source work on GitHub
> these days (see <https://github.com/nemequ>).  Off the top of my head,
> the pros are:
>
>  * Most developers already have a GitHub account and are already
>    comfortable with it.
>  * Travis CI only works with GitHub.
>
> Travis CI support doesn't really matter; there are lots of CI services
> which do work with non-GitHub projects.
>
> The cons, OTOH:
>
>  * The issue tracker is absolutely terrible.  It's easy to use, but
>    very limited.
>  * Code review support is a joke; it's a stretch to even say it exists.
>    It's really just an issue is opened, and you can add comments.
>  * It's proprietary. Given the choice, I'd rather use open source
>    software unless the proprietary stuff is *significantly* better.
>  * There is no way to fix bugs or add features, and relying on GitHub
>    doesn't work.  I've reported issues to them before and it has never
>    done any good.
>
> I could make that list a lot longer with a bunch of paper-cut type
> stuff, but the final bullet point covers a lot.  Besides, the first two
> issues negate a lot of the reason I think we should consider some
> infrastructure changes.
>
> Frankly, if the choice is between moving to GitHub and sticking to the
> current setup I'd prefer the latter.  IMHO the tighter integration with
> GNOME is more valuable than not making people sign up for another
> account to contribute.
>
>
> -Evan

I think Gitlab is a good solution (or at least a better solution than 
Github) :

- It's free/open-source software
- When you are comfortable with Github, Gitlab is easy to use
- You have got a good CI, with Gitlab CI
- Code review and issue tracker seems to be similar to Github's ones, 
but because it's open-source we could improve it, or send a request for 
it (Gitlab devs seems to be quite reactives to the feature requests). 
There is also a Bugzilla integration.
- We could also fix bugs if needed.
- You can log in with Github, if you don't want to create an account for 
a small contribution.

And if we don't want to depend of gitlab.com, we can host our own 
instance, perhaps on GNOME servers, if they want.

Baptiste