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

[Albert Astals Cid]

A Divendres, 3 de juliol de 2009, Chani va escriure:
> > > 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?

http://websvn.kde.org/trunk/kde-common/svn/hooks/

AFAIK pre-commit are
 acltest.pl: ACL, can possibly be done with gitorious admininstraion

 pre-commit.pl: not sure what it does, seems like making sure you don't commit 
things with conflict markers

 test-docbook.pl: checks people don't screw up when commiting to 
kdelibs/kdoctools/docbook

 test-eol-style.pl: checks eol is correct

 test-pofiles.pl: checks po files are valid

Albert