Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
Luca Filipozzi writes ("Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)"):
> On Wed, Jun 08, 2016 at 03:19:09PM +0000, Felipe Sateler wrote:
> > That speaks more to the need of actually dropping the not-shiny-anymore
> > services rather than block adding a new service.
>
> We aren't saying 'no'; we're saying 'please have a transition plan'.
>
> Dropping a not-shiny-anymore service without a transition plan to
> move users of the service off is not great. That said, maybe that's
> what we do. Announce a date and move on.
We have a situation where someone thinks the existing services are
poor, and wants to set up what they think is an improved one.
Presumably they hope that lots of people will use it.
But what you are saying is that they must, right away, pick a fight
with the administrators and users of the existing services. They have
to declare their intent to obsolete it and write out a detailed plan
on how everyone will have to change.
I think that this would be very aggressive and harmful behaviour. You
can see in this thread the kind of (very measured, under the
circumstances) responses from people who have qualms about such a
plan.
Requiring this requires those who want improvement to (a) enter into a
political battle (b) make explicit and public their criticisms of
the existing setups (c) "win" against the now-"enemies" who support
the existing services.
It is bad enough that it is sometimes thought acceptable to aggressive
declare someone else's project obsolete. Encouraging this behaviour,
which is what you are doing, is (I'm sorry to say) very bad indeed.
Also, from a practical point of view, this is an impractical way of
carrying on change. We don't know, in general, whether the new thing
will indeed be better. The best way is to try it and see.
We happily have some people who want to do the work of setting it up.
They should be encouraged and supported. They should not be set up in
some kind of manufactured conflict with existing services.
If the new thing really is great then we can think about what other
things it might have obsoleted. That would principally be a decision
for those who are supporting and using the services which might be
withdrawn.
And, that would be the time to think about firming the thing up - for
example, by transitioning to a .org name on a DSA-owned machine.
For now I would advise the people who want to try gitlab to _consider
in advance_[1] that transition, but to feel free to set something up
outside DSA control for now.
[1] I'm sure DSA and others will be happy to advise on how to make
choices which make moving to DSA infrastructure easier rather than
harder.
Ian.
Reply to: