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. > > 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. It's easier to debugging just *single* repository. Gtk2hs user just need cabal package to install easily. So my point is: "One darcs repository for developer, many smaller cabal package for user". We can add script that rebuild cabal package automatically. Example, have four subdir under repository: gtk, cairo, webkit, vte And it's cabal package is: gtk-0.1, cairo-0.1, webkit-0.1, vte-0.1 If developer change code of `gtk` and `webkit`, the script will rebuild cabal package: gtk-0.2, webkit-0.2 -- 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
