emacs-devel
[Top][All Lists]
Advanced

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

Re: [RFE] Migration to gitlab


From: Konstantin Kharlamov
Subject: Re: [RFE] Migration to gitlab
Date: Sun, 17 Mar 2019 17:06:40 +0300



В Вс, мар 17, 2019 at 4:49 ПП (PM), Tadeus Prastowo <address@hidden> написал:
On Sun, Mar 17, 2019 at 2:23 PM Konstantin Kharlamov <address@hidden> wrote:



 В Вс, мар 17, 2019 at 4:14 ПП (PM), Tadeus Prastowo
 <address@hidden> написал:
> IMO, I feel more comfortable with the current Emacs model because I
 > see less noise in the interface.  Furthermore, the current model
 > allows me to do my own way of automation against a stable simple
 > interface (plain-text e-mails and textual command lines have been
> around for a long time). This may not be welcoming to newcomers, but
 > I once was a newcomer in the Linux kernel dev but found nothing so
 > difficult about it.

 The automation sounds a bit abstract,

The automation of copying and pasting message-id and the like.

 but I guess you still can do it
if gitlab have enabled replying/opening of merge requests through mails.

As you wrote in the initial e-mail, e-mails are not the primary means
of gitlab model, and so, how far it can be stretched and how long it
will keep being supported remain to be seen.  Seeing the stretching is
rather easy because it can be done now.  But, it is impossible to see
how long it will keep being supported in the gitlab model.

Sure this part is just a contemplation, but I think that usage of emails was added to gitlab in the first place to keep workflow of peoples who got used to mailing lists. In that case I'd expect this to be enhanced rather than removed in the future (of course in the end this depends on demand or contributions from other peoples. And you are a creator of that demand).

Also, Linux kernel and git has "patchwork" site that essentially tracks
 open patch-series, versions of patches, comments to them, allows to
 download latest series… It is more advanced than just the mailing
 list as GNU Emacs has.

Yes, as you pointed out in the initial e-mail, a mailing list itself
is not enough.  That causes the chore of copying and pasting and the
like, which can be automated, especially if Emacs is used.  The
perspective that I support is that of heterogeneity.  IMO, the gitlab
model is into homogeneity: one uniform system for everything, but that
sacrifices flexibility.

I just don't see how could gitlab workflow interfere with that. If anything, it helps automating the chore of copying and pasting, because now you can get someone's series by a simple `git fetch remote branch`.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]