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

[Chani]

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

yeah, that argument doesn't seem to hold water :) I think the bigger burden 
will be setting it up, dealing with whatever goes wrong over time, fixing 
bugs...

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

maybe not now, but perhaps some would move there (kdesupport?) :) or perhaps 
kde devs would start non-kde projects there. or find new little ones that sound 
promising and contribute to them.
I don't see any downside to being 'closer' to other projects. :)

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

well, if you only look at *big* projects, of course.... but surely there are 
little ones there. and there'll be more in the future.

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

well, if dirk is happy to do all the work...

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

yeah, I don't think we should have a separate group for soc people. besides, a 
good number of our soc students already have accounts anyways. :)

gitorious does make it possible to have the same commit-rights policy as we 
had in svn. it also makes it possible to experiment with new things... but for 
now I think the current system works well.

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

good point.
what pre-commit hooks do we have?

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090703/e99e46e3/attachment.sig