migrating KDE's main modules to git

Tom Albers toma at kde.org
Tue Aug 24 13:13:10 BST 2010

On Mon, 23 Aug 2010 18:06:02 -0700, "Aaron J. Seigo" <aseigo at kde.org>
> * Is the November 17th date a hard date requirement, or can we start
> moving 
> main modules into git.kde.org earlier if we are ready to do so? Why /
> not?

Without talking to the rest of the KDE sysadmin, I think we can facilitate
a move for the main modules on an earlier date. We can somewhat compact and
mix everything listed starting from september 29, but we do want to have
some room to do some testing with some smaller projects before we move main
modules, as the impact for that is many times bigger.

If there is a plan for the main modules to move say after October 15 or
so, I'm pretty sure we can facilitate that. We just want to know in time.

> * The projected delay is due to waiting on password->ssh account
> conversions; 
> can we get guidance on the nature of the delay? (e.g. latest date
> to 
> wait, or if sys admin is not willing to make that call and therefore KDE
> needs 
> to provide such a definition for sys admin to simply implement.)

The someone aggresive blog and recent mails did make some accounts switch.

We currently have around 20 passwd based accounts that have committed more
than 10 times this year. Tonight we will put in an ACL which prevent those
people from committing and ask to contact us instead, in the next week we
will probably catch some of those 20 remaining accounts with that.

In other words, I don't think there will be a delay in the schedule at
this point.

> Finally, we used to have a "TODO" tracker on the wiki here:
> 	http://techbase.kde.org/Projects/MovetoGit
> Obviously, this is pretty much out of date with regards to the current
> state 
> of things. Can someone with the knowledge of what's happening update the
> times 
> of ites that the sys admin plans have taken care of?

Will do.

> the people on the scm interest are the best equipped to come up with
> answers, as you have the knowledge. please come up with a recommendation
> (or a 
> limited set of competing recommendations for KDE to chose from, if
> not 
> possible) in written form. include the workflow, benefits and
> include what new efforts, if any, are needed to achieve the

Although this is an item for the scm-interest people, I would like to give
an heads-up that the people behind the sysadmin team are preparing a
document which will exactly cover this. It will include an *advise* only,
as the scm-interest list should decide, but in any case, this document
could (and should) easily be rewritten with the final outcome of that

I can almost hear everyone *sigh*-ing that there will be another upcoming
discussion about all this, but I would like to have a discussion based on a
document which lists advantages and disadvantages and within that document
describes the consequences for all the affected systems we will be using.
It's not just the layout of git.kde.org, but also reviewboard, gosa and
redmine are involved. We will give an overview about the consequences for
all these systems and will present some practical problems we are running
into and ask for help resolving those. 

I hope this discussion will be done objectively and with renewed eyes from
everyone, iow, don't hold firmly to the previous positions you have taken,
but be open to look at, and consider, alternatives and work productively to
the solution that is best for KDE.

> Can you please provide k-c-d with a firm time commitment as to when this

> document will be delivered so that we can track its progress along with
> all 
> the other bits that are flying about? It's not so important if it takes
> one 
> week or three weeks, we just need (and deserve!) to know when to expect
> this 
> guidance so we can start crafting migration rules that follow this.

The people behind the sysadmin team will bring out the advise somewhere in
the next 2 weeks. We'll do our best to do it asap.

Tom Albers
KDE Sysadmin

More information about the kde-core-devel mailing list