I did indeed forget to push :) But have done that now. So what should I aim to fix before the package can be merged? Or are we really a bit late in the cycle? Can the merge happen and then re-org afterwards? or should the re-org happen before the merge?
~Roman On Tue, Sep 15, 2009 at 1:05 AM, Dylan McCall <[email protected]> wrote: >> Thanks for making those changes. >> >> I am not keen on the approach of maintaining copies under kubuntu/ of >> only a slightly modified part of the javascript library, the rest of >> it completely unmodified, and some of the slides. If we make the >> smallest of changes, we have to make them in two places, and my >> experience with oem-config and ubiquity leads me to believe that we'll >> often forget. Can you not refactor this so the modification is >> layered on top of the common code, and that shared pages are generated >> in both build directories at build time? > > I'm concerned about this, too, staring at the branch again. It's > definitely a useful effort, but I think, right now, it feels like a > jumble in places. (And don't take that the wrong way; most of the > jumbliness is my own doing). On the one hand I can see the benefit of > having a shared source package, but on the other it's stretching in a > way that may be really tough to maintain. > > By refactoring it, we would probably kill the ability to preview a slide > without building anything, (so a "make test" command would be nice). > "slides/link" can go up a level, then a different slides directory can > exist for each variation and that can be duplicated without messing up > anything else. The build script could pick through them automatically, > instead of having a duplicate target for each one. > > We could bump into issues with different look & feel being pursued for > each distribution. If each variation of the slideshow shares resources > such as the icon decorating gimp-fu script, we'll end up with either one > script that has multiple options within (and a general.css with 4 > different versions of "#container") or each variation containing its own > slightly (but not quite) duplicate variety of each script, for example > to sharpen the reflections on icons. > However, if look & feel isn't going to be a concern and all that will > change ever is content, then this can be pretty easy. > > ...Which, to be honest, lands me back at a thought: /why not/ just > maintain a distinct branch / project for the kubuntu / xubuntu / etc. > versions? I suspect there is some history here that I am missing which > explains away this doubt of mine, though. I often put too much trust in > fancy gadgets :) > >> >> You're missing a copyright notice for the Kubuntu logo. > Roman, did you forget to push that? I only see the two revisions from > the merge request that was made a while ago. > >> >> Also, I would argue that we shouldn't keep the UI files in this >> package. It should simply be content viewable in a browser, not a >> special widget. Leave the task of creating a UI to ubiquity. > Those are for the preview script, I think. In my own branch of the > branch I moved them to a "test" directory to get things better > organized. > > > > Thanks, > Dylan > -- Ubuntu-installer mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-installer
