Re: Gitlab Migration

[Alexander Adolf]

dick <dick.r.chiang@gmail.com> writes:

> * Newcomer suggests PR-based workflow citing youth.  Check.
>
> * Veterans chime in, citing the obvious reasons-for and the
> political reasons-against.  Check.
>
> * EZ cites his *sui generis* argument that a web-based workflow is actually
> *more* work than mailing patches around.  Check.
>
> * Someone announces his intention to begin the necessary work.  Check.
>
> * Someone remarks how discussion on emacs-devel repeats itself.  Now checked.

Nice. Thanks for the laugh!

But back to serious business. This is a long thread (297 on m y machine
at the time of this writing), and - in all honesty - that's not entirely
unexpected.

There is merit in both, keeping long-timers happy, and in lowering the
perceived entry barriers for potential new contributors. I would assume
that the smallest common denominator, which we all can agree to, would
be: "must not alienate/deter neither long-timers, nor newbies".

Thus, the magic words would seem to be "backwards compatibility", and
"migration path".

"backwards compatibility" := Everything that works via email now, must
equally work via email with the new system.

"migration path" := It must be possible to try out one function on the
new system, whilst still using all other functions via email.

If the new system has more functions, or makes some things easier, then
there could even be an incentive for the long-timers to look into the
new system.

Finally, a remark on issue/bug tracking. I have used a great many
trackers, and debbugs and Bugzilla stand out from the crowd. By a huge
margin. The differentiating feature is blocks/depends-on. Many issue
trackers (including those in the various git hosting platforms) lack
this feature altogether. Those trackers who have it, often provide a
limited flavour, e.g. limiting it to one level (i.e. a bug that blocks
another bug, can itself not be blocked by other bugs), or make it
awkward to use (e.g. you have to create a new bug as a subtask of
an existing one, and existing bugs cannot be made into subtasks any more
once created).

Hence my plea: debbugs ought to remain part of whatever any new system
might be.

Just my two cents anyway.


Many thanks and looking forward to your thoughts,

  --alex