We are taking into account this too. Everything should work as expected,
after a few days of adjustments and figureing out the details.
I will update in here when we consider the projects completely moved and
that they should work as expected, so you can start raising issues (apart
of the ones
Hi.
On Di, 2017-06-27 at 14:23 +0100, Emmanuele Bassi wrote:
> Please, let's stop this fetish about non-ff merges.
Thanks for writing this.
I've been confused by people insisting on "linear history" and the
relatively strict configuration of GNOME's git servers.
I hope that modules will be able
Hi.
On Di, 2017-06-27 at 10:54 +0200, Carlos Soriano wrote:
> However, understand that participating in the pilot program means a
> commitment of moving to GitLab with your project for the time being
How does that affect translations?
Will the module not receive translations then?
Cheers,
Please, let's stop this fetish about non-ff merges.
If you like non-ff merges and linear history it's entirely up to your
taste. Nothing "gets confused" about merge commits, and if your
tooling gets confused then I strongly urge you to get better tools —
which is the whole point of switching to
Hey Michael,
Indeed, unfortunately the current production instance continues withouth ff
merge support (UI wise, UI hooks and feedback, etc.), and that will require
more discussion with the GitLab team.
In general, merges vs ff, I would leave that as a maintainer decision, but
as you mention most
On Tue, 2017-06-27 at 08:08 -0500, Michael Catanzaro wrote:
> On Tue, Jun 27, 2017 at 3:54 AM, Carlos Soriano
> wrote:
> > Expect Nautilus and librsvg (with Federico) to move to the pilot
> > program this week.
>
> Cool. I would just suggest making sure that your interns
On Tue, Jun 27, 2017 at 3:54 AM, Carlos Soriano
wrote:
Expect Nautilus and librsvg (with Federico) to move to the pilot
program this week.
Cool. I would just suggest making sure that your interns are careful
not to push a non-ff merge (i.e. not to use merge requests),
Hey Adrien,
It depends, I asked my interns and they wanted to move. Otherwise I
wouldn't, of course.
Keep in mind that this is an opt-in and small set of projects, no that we
are actively encouraging it to do so, quite the oposite. However during all
this process few maintainers were actively
Wouldn't it be better to avoid migrating projects with interns working
on them during the GSoC coding period?
Cheers,
Adrien Plazas
On mar., juin 27, 2017 at 10:54 , Carlos Soriano
wrote:
Hello all,
For a number of weeks we’ve been collecting feedback on our
proposal
Hello all,
For a number of weeks we’ve been collecting feedback on our proposal to
consider GitLab as our code hosting, reviewing and issue tracking tool.
First of all we would like to thank everyone who participated. We’ve been
collecting the feedback on this wiki page:
10 matches
Mail list logo