Hi Jonas, On Mon, Oct 27, 2014 at 04:16:51PM +0100, Jonas Smedegaard wrote: > > We all are keen on learning what the problem is that boxer solves but > > blends-dev not. > > My reason for creating boxer from scratch rather than extending > blends-dev is part practical - Python is too alien for me
Current blends-dev is written in Perl and sh. There would have been a time to rise your voice about this once GSoC was started. While there has been a preference for Python nobody in the team has ever questioned this. This is what I mean by communication failure. :-( > - and part > conceptual - I want the tool centered around the process of composing¹ a > blend rather than on fixating a blend once composed. This somehow smells like DebTags ... just guessing since your statementes are a bit vague. Since I bring in this term: I confirm that I was a long time thinking about involving DebTags into the Blends framework until I had a talk with Enrico 'DebTags-Master' Zini at DebConf 13. He quite clearly declared that tasks are something else that you definitely *should* fix them and DebTags fits a different purpose. Well, this does not really draw me away from the DebTags idea but it not the right method to create metapackages. > ¹...and other aspects than composing too: deploying - in particular > deploying from one architecture (amd64) targeting another (armel) - was > the focus of previous drafts implementations, for use with FreedomBox. Interesting: One major feature of the GSoC project was to have architecture dependant metapackages (since not all dependencies are existing on al arches). > Here's what boxer can do - have done - as developed so far: > > Boxer composes blends from class definitions. > > DebianParl blend took ~6 months to compose (after ~3 years of drafting > its concept), as basically a slim Xfce desktop with few refinements and > a few specific packages added. > > Debian Design took 2 days to compose (after ~8 months of drafting its > concept), as the already refined and tested Xfce classes of DebianParl + > a few specific pakcages added. > > Onwards, refinements of DebianParl will also refine Debian Design. > > Anyone can benefit from same refinements by use of the boxer-data > package - if agreeing with its implicit choices favoring lightweight > over heavy and GTK+ over Qt. Or use only the boxer tool, developing an > independent set of classes with other choices. I need to have a look into debian-parl and debian-design source to understand things better. In any case I'd suggest you should add these two Blends to http://blends.debian.org/ to let users know about these new Blends. > > May be more Blends developers do have the same problem or might run > > into it later. Was there any chance to solve this problem in the GSoC > > project? etc. So I keep on failing to understand what exactly was > > stoping you to drop a note here about what you are doing. > > What stopped me was lack of ability to express what boxer was in my head > back then and (even more) lack of ability to describe what boxer has > become so far. > > No doubt that GSoC could have been better if I was not me but someone > else with different capabilities and visions. :-P I usually like your visions. ;-) > I never had a vision for GSoC to help improve current tools in this > team. So please do not put it on me how that turned out. I do not put in on you since in free software world you can never blame anybody for not doing a certain thing. I simply was astonished what reason you gave for what I personally would call a failure of communication. > > I tried to find some documentation about boxer but did not found > > anything which makes it clear to me what problem it solves and how it > > compares to blends-dev. Could you please be so kind to enlighten the > > list about this? > > Boxer is young, has radically shifted form during its 3 years of > evolution, and I am lousy at documentation. > > Here are some pointers: > > <https://wiki.debian.org/Boxer> > <https://metacpan.org/pod/distribution/Boxer/bin/boxer> > <https://anonscm.debian.org/cgit/boxer/boxer-data.git/tree/README> > > Here's the more elaborate README from initial draft, more about the > deployment features not yet re-implemented in current codebase: > <https://anonscm.debian.org/cgit/boxer/boxer.git/tree/README> Ahh, you moved away from $ apt-cache showsrc boxer | grep ^Vcs Vcs-Browser: https://anonscm.debian.org/cgit/pkg-perl/packages/boxer.git Vcs-Git: git://anonscm.debian.org/pkg-perl/packages/boxer Before I clone from the new location: Is there any reason not to use git://git.debian.org/git/blends ? I'm just wondering ... Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
