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. >> >> 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. > > 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 I think a script like that would be as easy as for i in gtk cairo; do cabal install; done If you think there should be something more elaborate, then you could add something to the repo. Cheers Axel ------------------------------------------------------------------------------ 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
