> > > > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
