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

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)



On Wed, Jun 08, 2016 at 05:16:54PM +0100, Ian Jackson wrote:
> 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'm not asking anyone to pick a fight.  I'm asking for a transition plan (more
below).

If Alioth is no longer fit for purpose, then let's see if this is the
opportunity to find a replacement.

> 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.

A discussion between those proposing a new service and those currently
operating the current service doesn't need to be confrontational.

Asking for a conversation to develop a plan, if possible, should not be seen as
promoting a conflict.

Maybe the sole remaining administrator of Alioth is interested in making a
transition, also.

Maybe those proposing the new service can join the Alioth team to ease the
transition.

Maybe after gitlab is up, we give people six months to move off of Alioth.

Without additional people joining the Alioth team, that service is
under-resourced.  If the count of members reaches zero, then we will likely
consider the service abandoned, regardless of active user count.  (Maybe we
need to introduce RFH, RFA, O, etc. for services.)

Any new service transitioned to d.o needs to have a dedicated team to operate
it.  That's part of service planning.

> 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.

Try it and see means debian.net.  That's fine.  That's not the same as
debian.org.

> 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.

I don't view it as a conflict.  There is one remaining Alioth administrator; we
should ask him what he wants to do.

> 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.

Always.

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian


Reply to: