Re: Heads up: Geary mainline development branch renamed to `mainline`



So hardcoding the name "mainline" to the list of branches that Damned Lies' looks up resolves the problem for you... and tomorrow another maintainer decides to rename it's master branch to whatever_non_offensive_name and DL breaks again until a patch is submited... no, sorry but this is not a solution for this.

GNOME's modules follow a standard nomenclature and it might be followed by all GNOME's modules. If you disagree with the naming policy you should open a thread, discuss it with the community and follow the final decission. It'ns not right to open the door to change master branches name freely, although Gitlab allows it (technical ability to change it doesn't give you the right to do it).

Since this is a not only i18n-related issue I'm Ccing Release Team and d-d-l to hear opinion from others, what I think you should have done before appliying this change (opening an issue in Gitlab is not enough... not every GNOME's member is subscribed to every proyect's notifications).

Really it is a big problem for you to have a branch called «master»? It's annoying for me spending time on this instead of working on real problems/tasks.

Regards

El mié., 24 abr. 2019 a las 13:17, Michael Gratton (<mike vee net>) escribió:
Hi Daniel,

On Wed, Apr 24, 2019 at 10:46, Daniel Mustieles García via gnome-i18n
<gnome-i18n gnome org> wrote:
> Great, but having modules with no standard name for
> master/trunk/whatever branch might break applications like Damned
> Lies, so this rename should be reconsidered, at least until we decide
> to rename the whole modulesed's master branch to another one.

The name of the mainline branch in git cannot be assumed to be "master"
since git allows it to be changed, and as of Git 1.8 the server sends
and the client looks for the name of the mainline branch when the repo
is being fetched (e.g. via a clone). Changing the name of the mainline
branch is easy to do, and in fact our Gitlab instance lets anyone with
appropriate privs for a project do just that from the project settings
UI.

So, Damned-Lies' current behaviour is broken because it makes the
assumption that the mainline branch is always named "master" (after
trying a few other hard-coded names), and so it breaks in situations
like this. However, I submitted a workaround that adds "mainline" to
that list, and that MR[0] has been merged. I'm not sure if it has been
deployed, but I think it may have been about a week ago.

Of course, this should be fixed properly to just ask the repo what the
right name is, and if there's interest in fixing it properly I'll
happily look into it and submit another MR. I've also worked with
Andrea to fix places in the sysadmin code (git hooks, GitLab
integration, etc) making the same assumption[1], and that's been
working fine for weeks.

Anyway, it should be fixed for Geary now, so if you're still having
problems with this as of this time last week, please let me know so I
can look into a fix.

> What would happen if every module maintainer decides to rename it's
> master branch? It will be a mess... I just think we should keep names
> homogeously, don't mind if it's called master, trunk... ;-)
>>

No, everything will work fine as long as people stop writing code that
(wrongly) assumes git's mainline branch is necessarily called "master".
:)

//Mike


[0] -
<https://gitlab.gnome.org/Infrastructure/damned-lies/merge_requests/18>
[1] -
<https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/127>

--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]