Hi Axel, Axel Simon <axel.si...@in.tum.de> writes:
> Hi Duncan, Andy, > > On Apr 1, 2010, at 12:35, Andy Stewart wrote: > >> Duncan Coutts <duncan.cou...@googlemail.com> writes: >> >>> On Sun, 2010-03-14 at 11:29 +0100, Axel Simon wrote: >>> >>>>> So we need *split* current darcs repository after convert all >>>>> libraries? >>>> >>>> Yes, I will probably make sense to split Gtk2Hs in many smaller darcs >>>> repositories. I might keep the just published packages in one >>>> repository, though. >>> >>> Axel, I would suggest not fully splitting the main gtk2hs repository. >>> For the core bits that have the same maintainers and release cycles >>> there is probably very little advantage to splitting. The disadvantage >>> would be that you could not do cross-cutting patches/changes. If you >>> still want to build them all together then you'd need extra management >>> scripts to get all the repositories (see for example the complexity the >>> ghc tree has to deal with by having independent libraries). >> I agree with Duncan. >> >> Like Duncan said, it's hard to do cross-cutting patches/changes after >> split repository, speical when upstream Gtk+ do a big change. > > Well, I would like to split off as many parts as possible and only keep > cairo, pango, glib and gtk > together in one repro. The reason is mainly that I want other people to take > over ownership of > these packages. There are many packages that I have never touched after > people have contributed > them to Gtk2Hs and I think that splitting these packages off makes more > sense. gtk, cairo, pango, glib, gio, those package must be in *one* repository. Otherwise, hard to debugging, because those pacakge reference each other. My worry is, current just *few* activate developer still on maintaining. If split to *many* smaller repository, perhaps author haven't time to maintain. And so many repositories is trouble to refactory code. More repositories need more time to test. >>> >>> That said, it may make perfect sense for some of the non-core parts that >>> have obvious maintainers and could have separate releases. Similarly >>> probably it makes sense not to aggregate even more components into the >>> main repo. >> IMO, don't split any component from main repo, because we don't know *split* >> component will failed when we break code in main repo, until we test it >> again. > > I don't see a relationship of packages being in the same repo and packages > breaking because of > interdependencies. > Even if all packages stay in the same repro, I don't normally work on a > machine that has all the > required libraries installed, so I wouldn't see these packages breaking. I always install all packages to avoid user compile failed. :) My mean is just keep *one* repository, we still can split gtk2hs repository with many smaller cabal packages. Author have ownership with his cabal package. One repository make all gtk2hs developers working together, if some package break, other developer can help to fix, even author haven't time. And permission is also a trouble, current, if anyone want to maintain gtk2hs, just need join `gtk2hs`, otherwise, we need join so many repository. Gtk2hs haven't so many developers like Gtk+ Team, maybe split repository not a good idea for current situation. What do you think? Cheers -- Andy ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
