Quoting Andreas Tille (2014-10-27 14:59:41) > I admit that I remain perplexed if running a GSoC project with the > goal to redesign a tool does not trigger any discussion since only an > alternative tool is worth discussing according your point of view (or > do I missunderstand it again?) Boxer is not a redesign of blends-dev, it is something else. Collaborating on driving a GSoC to redesign blends-dev is tied to blends-dev, at least as a starting point. > I'm just astonished / speachless / perlexed if people are not > communicating their feature requests. And I admit that the reason you > gave that communication only happens if there is an alternative > implementation makes me shaking my head even stronger than a simple > lack of interest / time. Not that communication *only* happens then, but that *more* communication happens then: I did not write "the" reason but "a" reason (i.e. my own, possibly shared by others). > On Mon, Oct 27, 2014 at 02:06:08PM +0100, Jonas Smedegaard wrote: >> Quoting Markus Koschany (2014-10-27 13:09:09) >>> However to start any kind of improvement you must be aware of that >>> something needs to be addressed. That's the simple quintessence of >>> the above paragraph. [...] >> If you mean to imply that that improvements on how to make blends is >> quintessential to discuss on this list, then I disagree. > > At least I'd regard it sensible to discuss on the list - which is what > I intended to say. I do not find it "quintessential" to "start" any kind of improvement by discussing on this list. I have ideas on concepts for managing blends which I have trouble expressing in words - even explaining that trouble to express my ideas before matured is evidently difficult for me to express clearly here. > 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 - and part conceptual - I want the tool centered around the process of composing¹ a blend rather than on fixating a blend once composed. ¹...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. 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. > 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 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 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> - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature