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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
