Hi Eduard.
Im speaking on create a temp branch for each MR from "outside", inside inkscape main repo. Maybe is a overloaded option, maybe too complex... Just a idea, I not a expert.
Regards.
On Sun, 2018-01-14 at 17:41 +0100, Eduard Braun wrote:
Hi Jabier,
I'm not sure I understand. Unless I'm missing something this is not really something we can fix but something AppVeyor needs to implement on their side.
The relevant bug / feature request is https://github.com/appveyor/ci/issues/651
Actually this is the only feature I like about GitLab so far: As CI is built directly into GitLab cloning the CI configuration when forking a repo is enough to enable CI in one's own repository. Then again this is also what makes CI builds for our first-time contributors fail: The default time of 60 min is not enough to complete a build and it seems there is no possibility to change this default from our side.
Regards, Eduard
Am 14.01.2018 um 17:25 schrieb Jabier Arraiza:
Hi Eduard and all.
This AppVeyor could be a problem :(, maybe this can be bypassed by a temporary intermediate branch between the user branch MR and master.
Cheers, Jabier.
On Sun, 2018-01-14 at 13:52 +0100, Eduard Braun wrote:
Am 14.01.2018 um 13:03 schrieb Jabier Arraiza:
Hi, in git time maybe is better 2 patches substituted by 2 merge request ¿aproved?.
Any user can do a fork, start coding and submit a MR to the proyect. with or without access rights.
This is, I think, the git way to it, instead patches.
Also I couldent find the way to get in sync automaticaly my inkscape personal repo with inkscape one.
If this can be done by default, we can sugest leave in forks master branch clean and work with personal branches and MR.
This also reduce the number of branches in master (they realy not removed anyway you press remove it after MR merge.)
Cheers, J.
Hi Jabier,
your mail arrived just as I sent mine - and I fully agree. The workflow you describe is also the one I prefer (I actually use it myself most of the time - at the very least for larger code changes that have a regression risk).
However it really seems we need to improve our git documentation. I wasn't aware many of our developers were not used to it. For me it always felt like the "natural" way to do stuff whereas bzr always bugged me - seems many people actually feel the other way round. Also I always felt git was well documented but apparently people are struggling nonetheless, so a "copy+paste"-like section in the Wiki with the basic git commands tailored to work for the Inkscape project might be helpful.
There's one technical issue for which I'm currently not unhappy with people committing to the main branch: Unfortunately AppVeyor (CI provider for Windows builds) does not support building of GitLab merge requests yet, so currently only branches in the main repository will be built (unless one creates an AppVeyor account and enables builds for one's own repository which is why my own MRs are checked even though they are always committed to my own repository).
Best Regards, Eduard