[Kde-scm-interest] Proposal: Migrating KDE to Git...orious.org

[Jeff Mitchell]

Albert Astals Cid wrote:
>> However, hosting Gitorious within KDE has some drawbacks. The most
>> egregious is that it places burden on our system administrators, mainly
>> by requiring constant merging of the Gitorious code to keep up-to-date.
> 
> You mean git pull --rebase is time consuming?

Plus any sql updates, template updates, etc.  Updating webapps is never
as simple as updating the source code.

>> A3) Developers use the same accounts when comitting code to KDE and
>> other (non-Qt) projects. This helps build community because it helps
>> build cross-references between KDE and other projects, and show
>> collaboration that is taking place.
> 
> There is really any significant project we could contribute to on gitorious 
> besides Qt? Having a look at active projects summary on gitorious seems not

"Significant" is in the eye of the beholder.  That being said, Gitorious
is small.  Many people just put up their own Git instance (like Gnome,
for instance) or use the non-free-but-oh-so-trendy GitHub (Ruby on Rails).

Qt and KDE both being on Gitorious.org could certainly help it on its
way towards critical mass.


>> A5) KDE and Gitorious (and Qt) benefit from cross-marketing and
>> promotion. We'd be the most visible project on the site (most likely
>> above Qt in terms of activity), and our involvement would help make
>> Gitorious more visible and legitimate.
> 
> That's not an advantage for us it's an advantage for gitorious.

How is being seen as the most active and visible project on the hosting
site not an advantage for us?

>> A6) It makes KDE development look more community-related and less of a
>> walled garden.
> 
> See my comment to A3, as there's not much big projects in gitorious other than 
> Qt and KDE it would just be a different walled garden.

See my comment to your comment.

Also, please explain how Gitorious is a walled garden at all.

Third, what is the advantage of hosting a Gitorious instance on our own,
in terms of your comments?  Then there would definitely be no other
projects to collaborate with, and it would definitely be a walled garden.

>> D2) "There is not much other reason than that we have the hardware and
>> the hosting, so we can do it."
>>
>> This is provided for completeness, but there isn't much discussion
>> necessary.
> 
> I agree with dirk, it's our code, let's be ourself that hosts it.

Please give some actual reasons why this is beneficial for us.  I
included that comment from Dirk for completeness, but it's a totally
silly comment.  I can drive my car off a cliff, so I might as well do
it, right?

>> "The easiest way would probably be to create one or more teams, such as
>> the one Thiago has created here: http://gitorious.org/+kde-developers
>> (or use that). That would allow anyone with an administrator role within
>> that team to add/remove/promote/demote members and all members would
>> have commits rights to any projects or repositories either owned by that
>> team, or where the team is added as committers to a repository. Whoever
>> has commits rights to repositories is entirely governed by the owner of
>> that repo, which can be either a single user or a team (in which case
>> the admins of that team would have the ability to do admin type things
>> on the repo or project)."
>>
>> To me, this sounds like an entirely reasonable method of managing
>> committers. Established KDE developers could be part of the
>> kde-developers group, SoC students could be part of a kde-soc-students
>> group while SoC is going on, and those that continue comitting could be
>> moved into kde-developers, etc.
> 
> Why give newbies less commit rights, kde has never worked this way. I like the 
> way we have now (with very few ACLs)

The suggestion above doesn't give anyone less commit rights, it just
helps avoid an explosion of people with commit rights, many of whom may
not have committed code for many years but no one removes because no one
is taking care of cruft.

It can also work the exact same way as now, with everyone in the
kde-developers group.

> What about pre-commit hooks? We have some of those i would not like to loose.

Good question.  I'd ask Johan about it at the BoF.

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090703/d2238b6e/attachment.sig