[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Boxer

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
> > 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



Reply to: