[Freedombox-discuss] Report third hackfest

Tue Mar 8 20:50:15 UTC 2011

On Tue, Mar 08, 2011 at 02:16:48PM -0500, Les Orchard wrote:
>On 3/8/11 1:09 PM, Jonas Smedegaard wrote:
>>That may speed up some kinds of development, yes.
>>
>>In my experience, esp. with Skolelinux and Sugarlabs, such creation of 
>>an own distribution framework - even if intended to sync tightly with 
>>another "real" distribution - ends up stealing too much time, focus, 
>>and is thus more damage than good IMO.
>Well, really, speeding up FreedomBox product development and 
>considering new software not yet in Debian is the only reason I'd see 
>for a FreedomBox-specific distro.
>
>My ignorance shows here, since I've only ever been a Debian user and 
>never developed a package. Maybe the way I should really consider 
>"FreedomBox" is as just a Debian preseed for a plug computer.

You "should" draw your own conclusion.  But yes, when trying to follow 
how _I_ think about this, you got it almost right:

To me FreedomBox is software + hardware + design + dreams.  And the 
software part is a Debian w/ preseed.

Important difference is the "just" in your sentence.  I don't see it as 
simple to reach that goal.  But when there, it should be rock solid.

...which means it is dead simple to later create Freedom* flavors, e.g. 
FreedomPhone, FreedomCloud, FreedomDesktop and FreedomSatellite.

You may think that it is also easy to fork based on Ubuntu which is a 
fork of Debian.  Detail there is that Ubuntu has commercial backing that 
can help them hire hardware, developers or whatever eases making forks 
of their distro.  Yes, Eben has some money now, but don't count on that 
to last long.

>>It is no doubt great fun and a good learning experience to try setup 
>>and maintain a distribution - just mind you that this is what it is!
>Yeah, I'm all for learning experiences, but not in this case. I think 
>learning how Debian does things would be better for me. :)

I suggest to not learn Debian packaging.  Leave even that to others.

I suggest to learn how to interact with Debian _without_ packaging 
youself.

Before packaging there are tasks related to figuring out what is 
relevant to package.  Simplest form of this is filing so-called [RFP] 
bugreports and put the resulting bugreport numbers at our wiki.  More 
advanced could be to engage in discussions at various lists to try get a 
feeling what is more relevant to get packaged.  Even more advanced could 
be to maintain a structured tracking of what might potentially be useful 
- like the one my fellow Debian Pure Blend preacher, Andreas Tille, have 
been maintained for years at http://blends.debian.net/ - perhaps someone 
would be interested in maintaining such data tracking for FreedomBox?

After packaging there are tasks related to use of the packages.  
Figuring out exactly what needs to be configured after install for it to 
work sensibly for our purpose - and how much of that customization that 
could maybe be integrated with the packaging itself: File wishlist 
bugreport and engage in discussions with the package maintainers on what 
would be sensible to automate and have them adopt the maintainance of.

And there are the tasks of "deploying" - i.e. getting an install ontp 
the hardware and personalized.

And the tasks surrounding UX (as I just learned on this list is its 
acronym: user experience design).

Consider yourself leader of your own FreedomBox project!  As the fine 
leader you are, you don't do the actual work yourself (because then you 
get lost in the details, loose sight of the overview, and cannot lead!), 
and also you don't command (because all here are volunteers not liking 
to be thrown orders at).  You do _some_ work yourself at whatever of the 
tasks at hand that you feel somewhat competent in already (to not burden 
others, and as much as possible develop your own personal opinion on 
where you are heading with this) and then _inspire_ others to help you 
do all the things that you can't do yourself (because you are not clever 
at those other tasks and because you are busy standing on your hilltop 
leading your FreedomBox project).

[RFP]: http://www.debian.org/devel/wnpp/#l1

>>I strongly, very very strongly, recommend to use Debian: get all code 
>>packaged rather than seek ways to circumvent that,
>I think I'm just unclear on the term "packaged"—sounds like more than 
>just producing a .deb.

"Packaged" is a bad term, really. "Maintained" more accurately says what 
tasks it contains: Yes, initially it is about proucing a proper .deb, 
but then it is about continuously ensuring that it plays well with its 
surroundings in the Debian environment.

>>Feel free to play with upstream code e.g. to figure out it suitable at 
>>all to waste any more time on packaging and integrating with 
>>FreedomBox, but throw away such premature testing - don't try 
>>encapsulate it at stuff it into FreedomBox - that is A Bad Way!
>That's really what I'm after here: A way to play with upstream code and 
>get it into installable packages if/when it looks like a good addition 
>to FreedomBox.
>
>But, I think what you're saying is: If it's a good addition for 
>FreedomBox that's not in Debian already, get it into Debian. A special 
>case distro for FreedomBox is just asking for trouble.

Correct - we are _not_ talking about the same here.

I am talking about trying out the funky tools at the shop but then go 
somewhere else to buy it if you still like it.

You seem to want to stay in the shop and pay them an hourly fee for 
playing with their funky tool right there at the shop, not even take it 
home with you.

Sorry - maybe that image was more confusing than helping :-)

Let me try again:

   * Try out e.g. Pagekite as downloaded from their website
   * Delete what you tried out!!!
   * File an RFP bugreport
   * Convince someone else(!) to package and maintain pagekite
   * Try out pagekite package with Debian unstable
   * File bugreports on things you discover as broken
   * File wishlist bugreports on config you'd like debconf handled
   * Convince me to backport pagekite to Debian stable
   * Convince some of your friends to test it with Debian stable
   * Help your friends file bugreports on their discoveries
   * Suggest FreedomBox to include the well-tested pagekite package
   * Enjoy!

so no, only use your initial tests to better understanding what it is 
you want others to package for Debian.  Use only Debian in FreedomBox.

>>Congratulations!
>>I was wondering when someone used my own praching against me. You did 
>>it! :-)
>Well, I'm not looking to catch you out on anything or make work for 
>you! I'm just an over-enthusiastic newb, here.

Aren't we all.

I was _not_ ironic - I really did notice recently that with WebID I 
acted how I've been discouraging others to do.  And I really enjoy that 
you used an argument very much looking like my own, against me!

>>Yes, I totally agree: WebID needs to be packaged too before it is 
>>sensible to consider it concretely for inclusion into FreedomBox.
>So, by "packaged", you mean accepted as part of Debian proper? (As 
>opposed to .deb's sitting in some random guy's repository?)

Yes.

I mean "officially packaged".  Sorry - I got sloppy and didn't write it 
clearly everywhere I meant that.  Cool that you spotted it.

>>So all in all this is very much a good demonstration of how things 
>>are _not_ ready when they themselves are ready.
>>
>>Similarly I will expect Pagekite and all other wonderful yet 
>>unpackaged technologies to take _more_ time to be usable for 
>>FreedomBox even _after_ being production quality as upstream 
>>projects and _after_ being officially packaged into Debian.
>So, a piece of software could be production quality in isolation. 
>But, once it's wrapped up in a .deb, it has to be tested alongside 
>the rest of Debian and found not to break anything before it's 
>brought into the official Debian fold. Do I have that right?

Yes!

Each code project can be unstable or stable, as can a distro suite.

"Debian unstable" is a huge pile of _stable_ code projects wrapped as 
"packages".  The packages frequently change, making the _mixture_ a.k.a. 
the suite unstable.

When a package have not changed for 10 days, and its dependencies also 
have not, and noone have filed serious bugs against it, then the package 
enters a staging area called "Debian testing".  Debian testing ideally 
is a releaseable distro, but in reality it takes lots of hard work - 
stability cannot be automated, that "10 days" rule only weeds out the 
worst of the noise but still it takes a few years(!) for the distro to 
mature, and then typically takes 6 months(!) working only on getting it 
ready for release (i.e. completely blocking the flow of new packages 
dripping in from unstable).

>There is / will be software that could be very useful for FreedomBox, 
>but is new with respect to Debian. If it takes years to get that 
>software into Debian, and subsequently into FreedomBox, that seems 
>problematic for the notion of moving fast on FreedomBox.

Indeed.

Some feel that we therefore need to set aside the "laws of Debian" right 
there at the beginning, because they are hindering a fast enough 
development.

I feel that we should keep sane "law and order" by default, and only 
eventually, when closer to a releasable material, perhaps cheat and not 
follow the logic of Debian.

I believe that the places we set aside the (to me) sensible albeit 
painfully slow logics of Debian, those places will come back to haunt us 
later on.  So we should do it as minimally as possible - ideally not at 
all.  Certainly we should not _initially_ develop scary monster code!

>>But heck - I am biased, being a Debian Developer. So it might be 
>>that those wanting to bypass Debian with their pet projects do not 
>>concider my opinion relevant either :-P
>I think the pet projects are things that might be novel solutions to 
>the issues FreedomBox is meant to address. Maybe some of them are way 
>too experimental, and better addressed using packages already in 
>Debian.

Many of those issues are not possible to solve with current stable 
Debian packages.

But some are.  We should not ship code that is unstable in itself. 
Neither should we ship code that is unstable in a _distro_.  We should 
ship rock stable stuff - i.e. things already in Debian.

Get stuff invented fast.  So it can be coded fast.  So it can be 
packaged for Debian fast.  So it can be included in FreedomBox fast.

...and while we wait for that chain, we release what is already invented 
AND coded AND packaged - and stable at all those areas.

FreedomBox != Titanic

  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110308/aac864fe/attachment.pgp>