Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Ben Armstrong]

On 04/25/2013 09:40 AM, Andreas Tille wrote:
> There are actually users who do not "see" the system but just the
> topping.

Yes, but I don't think we should encourage any users in this skewed view
of the system.

> I would never try to blame the user about this.

Nor would I. However, I would not use this as an excuse not to educate them.

> For my father
> it is even easier to understand what I'm doing in Debian because I spend
> most of my time with leaf packages (if I do not care for Blends
> infrastructure stuff).  So telling him "Debian is an app store and my
> work on it is adding apps to the store" this is an very easy to
> understand explanation which leaves out the part that is not
> understandable to him: What is an operating system.  (Hey, also Windows
> is no operating system - it is just a kick-starter for Windows, Excel, a
> browser and a mail client, right?)

I understand using app store as an analogy, as long as it is explained
as such, and qualified as being an imperfect analogy. But the common
conception of an "app store" as involving you solely as consumer and not
as participant in the free software ecosystem encourages poor
relationship between users and producers (or distributors) of free
software. So long as users continue to see themselves as a tiny,
insignificant recipient at the end of the production of the software
with no input into the system, you've stripped them of the power to
change the software to meet their needs. So using the "app store"
analogy is walking the fine line and really needs to be qualified to
avoid doing damage to the user's relationship to the community.

> If you do not like the selling part:  Store in the sense of some
> "storage of goods" is not necessarily about bying (at least of my
> understanding).  Or tweak it like this:  We are selling our stuff but
> the price tag says 0€/$.  Feel free to blame me about oversimplification

Honestly, I don't think the selling part is the most offensive part of
the concept of an "app store". It's the one-way nature of the
transactions carried out with them.

Ben


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51792a53.7080...@sanctuary.nslug.ns.ca

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Andreas Tille]

On Thu, Apr 25, 2013 at 02:40:38PM +0200, Andreas Tille wrote:
> understandable to him: What is an operating system.  (Hey, also Windows
> is no operating system - it is just a kick-starter for Windows, Excel, a
> browser and a mail client, right?)

s/for Windows, Excel/for Word, Excel/ 

Kind regards

   Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425125614.gb7...@an3as.eu

Re: Upstream packaging

[Gergely Nagy]

Clint Byrum  writes:

>> Also if people thought that distributions are unneeded, then the
>> amount
>> of them would reflect that, or start decreasing, which I'm not seeing.
>> Distributions will exist as long as there's FLOSS, because by its
>> decentralized nature, there's no single coordination point; people
>> who are distraught by the amount of distributions or by their mere
>> existence might probably only be able to find peace in closed-systems
>> instead, with their centralized control points.
>>
>
> Nobody is distraught. The problem statement was something like
> "distributions lag upstreams, how can we solve this?" and I'm
> suggesting that its kind of already solved with upstreams who use
> their native packaging format (i.e., autotools, pypi for python, or
> maven for java). Its just that Debian has such strong policies that we
> are unable to consume said packaging, because the upstream packaging
> is less expressive. So, we have to lag while we QA all of our
> specialness.

There's so much more to packaging and *maintaining* a debian package
than wrapping whatever upstream has in a .deb, even if we apply very
few (or none at all) changes during the process.

Just because something uses autotools, it will not mean you can
trivially package it, or upgrade from one version to the other. There
are a million things that can - and sooner or later, will - break even
if upstream only uses standard tools. A new dependency, a new configure
option, changing defaults, and all kinds of incompatible changes make
maintainance neccessary and far more effort than you seem to imply.

Most of these are things upstream do not have to care about: they'll
document it in an UPGRADING file or similar, and delegate the task to
their users. A distribution will most likely wish to automate most of
that in a straightforward and safe manner.

>>> Where Debian's efforts should be focused is on things like license
>>> verification and helping bug reports and fixes get to upstream.
>>
>> So basically, getting rid of most of the fun stuff and turning it into
>> a lawyerish play-ground and support center... I'd venture to say, not
>> the most attractive work for most people here if it was the only
>> thing to be done, which we do because we think it's important non the
>> less.
>>
>
> I am suggesting that there are a lot of things that are much more fun
> than conforming software to Debian policy.

Wouter said it very well, that the Policy is not a goal, but a tool to
achieve a goal: that of an integrated system. Making packages conform to
policy is pointless, if it is not done to achieve the goal. Creating a
well integrated system on the other hand *is* fun, and something that
can't be delegated to upstream, or anywhere else but the distribution
itself.

> I'm also suggesting that these things don't need to happen in the
> context of Debian.

Where else? Upstreams should not be concerned about integrating their
software into distributions. That's what package maintainers are for:
they know the distribution better, they have the skills and resources to
do the neccessary integration work, they know how their distribution
handles upgrades, and so on and so forth.

Upstreams should provide the tools and documentation to make integration
possible and smooth, but that's where it should end.

As an upstream, I do not wish to care about any single distribution.
I'll provide ample documentation, scripts and whatever else they need,
but I do not wish to play the integrator role. If I start to do that for
one distribution (wit my upstream hat on), I'll have to do it for the
rest too. No, thank you, that is as far from fun as it can ever be.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwsm7pgx.fsf@algernon.balabit

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Andreas Tille]

Hi,

On Thu, Apr 25, 2013 at 12:00:11PM +0200, Jonas Smedegaard wrote:
> Quoting Andreas Tille (2013-04-25 09:20:59)
> > I honestly wonder if there is some more general definition for the 
> > term "app store" besides what according to[1] certain companies have 
> > made out of it.  Following the logic that "app store" is crap because 
> > some companies provide it as such we are terribly lucky that they did 
> > not choose the term "distribution" for their crap.  I personally can 
> > not find something wrong in a *generic* term "application store" and I 
> > would not seriously object if someone would call Debian an app store 
> > done the right way.
> 
> If by "not seriously object" you mean that you would object but with a 
> smile and continue your great meal together, rather than leave the 
> party and file a lawsuit, then I agree with you...

It depends with whom I share that great meal.  If it is my father I
would simply say "yes".  If it is my son I would mind explaining the
difference.  Rationale:  I have installed Debian on my fathers box and
told him how he can install additional applications.  Once you have a
basic system running the Debian mirror serves as an app store and it
makes actually the point for this kind of user (and a lot of other users
as well).

> To me, calling Debian an "app store" would be only misleading.

Yes.  That's why I would not call Debian an "app store" to *you*.

> To me an 
> "app store" is for "topping op" a system, not the system itself.

There are actually users who do not "see" the system but just the
topping.  I would never try to blame the user about this.  For my father
it is even easier to understand what I'm doing in Debian because I spend
most of my time with leaf packages (if I do not care for Blends
infrastructure stuff).  So telling him "Debian is an app store and my
work on it is adding apps to the store" this is an very easy to
understand explanation which leaves out the part that is not
understandable to him: What is an operating system.  (Hey, also Windows
is no operating system - it is just a kick-starter for Windows, Excel, a
browser and a mail client, right?)

> Debian is no app store: content is not only apps nor app-centric, and 
> aim is not to archive nor to sell, but to streamline and distribute.

If you do not like the selling part:  Store in the sense of some
"storage of goods" is not necessarily about bying (at least of my
understanding).  Or tweak it like this:  We are selling our stuff but
the price tag says 0€/$.  Feel free to blame me about oversimplification

> When I need an alternative term to describe what "distribution" means, I 
> use "library": Like librarians we care not only about the individual 
> "books" of software, and not only about the "novels", but about 
> long-term cohesive structure of the library as a whole.
> 
> Libraries also has the connotation of "collecting dust" which arguably 
> is descriptive for (stable) Debian as well ;-)

Nice alternative explanation.

Kind regards

 Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425124038.ga7...@an3as.eu

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Wouter Verhelst]

On 25-04-13 10:50, Clint Byrum wrote:
> On 2013-04-24 12:43, Guillem Jover wrote:
> All of the things you mention are huge accomplishments, but the scope is
> what I am suggesting has gotten out of hand. Do we really need "a high
> level view" and "QA of the entire system" for MongoDB?

We don't need it for MongoDB, but we do need it for Debian.

The difference might seem to be minor, but it isn't.

> It is a daemon
> and some client tools. If I install it from tarball, I know this is
> shocking, but it actually works fine and doesn't interfere with anything
> else.

That's fine, great, and dandy. But it's besides the point.

I would hope that all upstream software "works fine" and "doesn't
interfere with anything else" if installed from tarball. If it doesn't,
they seriously need to check what they're doing.

But Debian packages go beyond "work fine". They are integrated. If there
are other packages out there that do similar functionality to whatever
it is that "MongoDB" does (I don't have a clue, but it doesn't matter
for this discussion; I guess it's some sort of database), then it's
reasonable to expect that a MongoDB package would need to behave
similarly to those other packages.

For a database server, this could include things like:
- making sure the data is stored in the right location in the file
system; e.g., postgresql upstream assumes all its stuff (binaries,
configuration, data files) are stored in a single directory. Given their
background (they support way more systems than we do; e.g., they also
support Windows) this makes sense, but that doesn't mean we should, too.
- If it's an SQL database, integrating everything with dbconfig-common.
This is a Debian-specific thing to make installing database-using
packages easier; it makes no sense whatsoever to push this upstream.
- ... probably others, but I'm not very fluent in packaging of database
systems.

> If it does, I will complain to upstream. My suggestion is not to
> stop packaging, but to shift focus from "make an awesome package" to
> "make an awesome upstream" that results in an automatically generated
> awesome package. Debhelper and many of the other tools definitely help
> with this, but we can do more.

Yes, we do have a guideline that says you should push improvements
upstream if and when they make sense there, and that is more often the
case than you'd think if you were just looking at the number of patches
that flow upstream.

But making a distribution is so much more than just checking licenses
and converting source into installable packages.

Take, for instance, the apache packages. If you were to just take the
upstream source, compile, and install it, then it would also Just Work.
But it wouldn't have the same flexibility that the Debian packages have.
On Debian, you can just install some libapache-mod-foo package, and due
to how the configuration files are arranged, it will simply work. This
kind of integration isn't something that can (or should!) be done
upstream; it's squarely inside the realm of what a distribution does.

The amount of such integration is part of what makes a distribution
unique; some distributions tend to do this more than others, and at one
extreme of this are Arch and Slackware, who make it a policy to ship
upstream source as pristine as possible. Debian is clearly not at that
extreme, and it should not be, IMO; the high level of integration, the
expectation that I can have from the behaviour of a package that's part
of Debian is what attracted me to Debian in the first place, and if we
ever lose that I'll probably start looking for a different distribution.

>> And all this, upstream will never be able to provide (at least not as
>> defaults), because each distribution has its own policies, some are
>> better, some are worse, and some are just different. In general I'd
>> never trust the packaging produced by an upstream for a distribution
>> they are not involved in. But most of the time there will be no such
>> packages for the desired distribution anyway.
>>
> 
> Debian wants to provide end-to-end generalized tight integration. Thus
> packages lagging behind upstream. I'm suggesting that this tight
> integration ideal actually *limits* the scope of Debian.

Sometimes packages are lagging behind, yes, and that's a problem; but I
don't agree that the tight integration lies at the root of that problem.
When done right, this kind of integration consists of just a few files
inside a debian/ directory; they should not interfere with packaging a
new upstream version.

Yes, there are exceptions, and we should strive to eliminate such cases.
Sometimes this is because upstream is no longer active; sometimes this
happens because the maintainer isn't doing a good (enough?) job.
Whatever the reason, it's something we should try to fix. But just
throwing our hands up in the air and saying that we should therefore
give up on trying to integrate isn't the right way forward, I'd say.

[...]
>> Although there's been

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Jonas Smedegaard]

Quoting Andreas Tille (2013-04-25 09:20:59)
> On Wed, Apr 24, 2013 at 09:43:48PM +0200, Guillem Jover wrote:
> > ...
> > A distribution (any, most) is the gel that binds and gives an unified
> > and coherent shape to the software ecosystem.
> 
> +1 (to everything even the cutted part)
> 
> > An app store is just like a scrapyard, you might find magnificent 
> > and isolated gems there, but most of it will probably be junk, or 
> > not combine with the other scrap parts.
> 
> I honestly wonder if there is some more general definition for the 
> term "app store" besides what according to[1] certain companies have 
> made out of it.  Following the logic that "app store" is crap because 
> some companies provide it as such we are terribly lucky that they did 
> not choose the term "distribution" for their crap.  I personally can 
> not find something wrong in a *generic* term "application store" and I 
> would not seriously object if someone would call Debian an app store 
> done the right way.

If by "not seriously object" you mean that you would object but with a 
smile and continue your great meal together, rather than leave the 
party and file a lawsuit, then I agree with you...

To me, calling Debian an "app store" would be only misleading. To me an 
"app store" is for "topping op" a system, not the system itself.

Debian is no app store: content is not only apps nor app-centric, and 
aim is not to archive nor to sell, but to streamline and distribute.

When I need an alternative term to describe what "distribution" means, I 
use "library": Like librarians we care not only about the individual 
"books" of software, and not only about the "novels", but about 
long-term cohesive structure of the library as a whole.

Libraries also has the connotation of "collecting dust" which arguably 
is descriptive for (stable) Debian as well ;-)


 - Jonas

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

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425100011.12767.1...@bastian.jones.dk

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Charles Plessy]

Le Thu, Apr 25, 2013 at 01:50:58AM -0700, Clint Byrum a écrit :
> 
> My suggestion is not to stop packaging, but to shift focus
> from "make an awesome package" to "make an awesome upstream" that
> results in an automatically generated awesome package. Debhelper and
> many of the other tools definitely help with this, but we can do
> more.

Hi Clint,

indeed, we do more:

http://wiki.debian.org/UpstreamGuide

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425094629.gf21...@falafel.plessy.net

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Clint Byrum]

On 2013-04-24 12:43, Guillem Jover wrote:

Hi!

On Sat, 2013-04-20 at 11:05:29 -0700, Clint Byrum wrote:

[...]. IMO this is why upstream packaging should be
embraced and enhanced rather than focusing on dpkg.


I'm not sure if you refer to the tool here, or to the packaging work,
doesn't change much anyway.



I'm referring to delivering software in general, most of which falls 
into a few categories which are not "a programming language", 
"plumbing", and "system development tools".



I once worked on the 'pkgme' project for Ubuntu and there have been
others, but never followed through. The idea was just to build
debian source packages from upstream sources. Upstreams should be
able to release a package which serves their needs, and Debian
should be able to consume these almost directly.


Respectfully, I think you've entirely missed the point of a 
distribution

(and sadly I'm seeing this trend more often than before now, with all
the hype around app stores and similar...). Packaging and maintaining 
a

consistent and unified distribution cannot be delegated to upstreams
(and I'm talking as an upstream developer here too), because that 
entails
a bit more than slapping some files somewhere, tarring the thing up 
and

calling it a day.



Indeed, there is a great deal of hard work in putting together an 
operating system. But for the bulk of software, things like MongoDB 
included, I see very little point in distributions spending a lot of 
time tweaking and poking and prodding the software to work into a grand 
policy.


For the most part, developers ship and test a good tarball that builds 
with some pretty standard and easy to detect options. The bits where 
that doesn't work ought be fixed upstream, and I know sometimes they 
are, but in the mean time, the distribution maintainers (myself 
included) spend their precious time conforming to the broken upstream, 
instead of the other way around.



Building a nice distribution requires a high-level view and QA of the
entire system; requires curating sane namespaces, be them on the
package/project names, on the version strings, on the filesystem (by
avoiding file collisions, using alternatives or diversions), on 
exposed

programming interfaces, etc; requires making sure a diverse set of
programs interact correctly with each other; performing security
updates; ideally keeping single runtime versions; doing global
transitions to use other or newer runtimes, programs, libraries or
packages; an unified way to build from sources to cope with the 
endless

and interesting different upstream build systems; porting and building
for different binary architectures, not just what upstream might have
around; documentation; translation; tagging stuff with metadata to
allow for easy searches; excision of the embedded code copies cancer;
even stuff like how the Delete and Backspace keys should behave;
sets a qualify bar for upstream projects, stuff of low quality will
not be accepted most of the time; license checks; etc, etc...



All of the things you mention are huge accomplishments, but the scope 
is what I am suggesting has gotten out of hand. Do we really need "a 
high level view" and "QA of the entire system" for MongoDB? It is a 
daemon and some client tools. If I install it from tarball, I know this 
is shocking, but it actually works fine and doesn't interfere with 
anything else. If it does, I will complain to upstream. My suggestion is 
not to stop packaging, but to shift focus from "make an awesome package" 
to "make an awesome upstream" that results in an automatically generated 
awesome package. Debhelper and many of the other tools definitely help 
with this, but we can do more.



And all this, upstream will never be able to provide (at least not as
defaults), because each distribution has its own policies, some are
better, some are worse, and some are just different. In general I'd
never trust the packaging produced by an upstream for a distribution
they are not involved in. But most of the time there will be no such
packages for the desired distribution anyway.



Debian wants to provide end-to-end generalized tight integration. Thus 
packages lagging behind upstream. I'm suggesting that this tight 
integration ideal actually *limits* the scope of Debian.



Although there's been work on creating distribution-neutral specs that
some upstreams have picked up, there's always going to be something 
new,

the specs will just not cover all needed things, the specs might not
be liked by some/many people, or might not have been fully adopted by
all upstreams.



Right, and Debian maintainers can, and will keep bending over backward 
to get all the upstreams into Debian. That doesn't mean its a good use 
of someone's time.



A distribution (any, most) is the gel that binds and gives an unified
and cohe

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Andreas Tille]

On Wed, Apr 24, 2013 at 09:43:48PM +0200, Guillem Jover wrote:
> ...
> A distribution (any, most) is the gel that binds and gives an unified
> and coherent shape to the software ecosystem.

+1 (to everything even the cutted part)

> An app store is just like
> a scrapyard, you might find magnificent and isolated gems there, but most
> of it will probably be junk, or not combine with the other scrap parts.

I honestly wonder if there is some more general definition for the term
"app store" besides what according to[1] certain companies have made out
of it.  Following the logic that "app store" is crap because some
companies provide it as such we are terribly lucky that they did not
choose the term "distribution" for their crap.  I personally can not
find something wrong in a *generic* term "application store" and I would
not seriously object if someone would call Debian an app store done the
right way.

> > Where Debian's efforts should be focused is on things like license
> > verification and helping bug reports and fixes get to upstream.
> 
> So basically, getting rid of most of the fun stuff and turning it into
> a lawyerish play-ground and support center... I'd venture to say, not
> the most attractive work for most people here if it was the only
> thing to be done, which we do because we think it's important non the
> less.

+1

Kind regards

   Andreas.

[1] http://en.wikipedia.org/wiki/App_Store 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425072059.gd23...@an3as.eu

Re: Upstream packaging

[Russ Allbery]

+1 to everything Guillem said.  I particularly want to emphasize this
part:

Guillem Jover  writes:
> On Sat, 2013-04-20 at 11:05:29 -0700, Clint Byrum wrote:

>> Where Debian's efforts should be focused is on things like license
>> verification and helping bug reports and fixes get to upstream.

> So basically, getting rid of most of the fun stuff and turning it into a
> lawyerish play-ground and support center... I'd venture to say, not the
> most attractive work for most people here if it was the only thing to be
> done, which we do because we think it's important non the less.

Doing the work of a distribution -- integration, coherence, high-level
analysis, and fitting pieces together so that they work as a user would
have expected even if they were developed separately -- is *fun*.  It's
why I'm here contributing to this project.  Shuffling bug reports around
and verifying licenses are chores that have to get done in order to create
the system that I want to use, but it's in areas like integrating properly
into a new Apache module management infrastructure, making desktop files
that work properly with the desktop menu systems, or packaging language
extensions so that they just seamlessly work for users of those languages
in Debian that the creativity, design, and enjoyment come in for me.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zjwnsn1n@windlord.stanford.edu

Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Guillem Jover]

Hi!

On Sat, 2013-04-20 at 11:05:29 -0700, Clint Byrum wrote:
> [...]. IMO this is why upstream packaging should be
> embraced and enhanced rather than focusing on dpkg.

I'm not sure if you refer to the tool here, or to the packaging work,
doesn't change much anyway.

> I once worked on the 'pkgme' project for Ubuntu and there have been
> others, but never followed through. The idea was just to build
> debian source packages from upstream sources. Upstreams should be
> able to release a package which serves their needs, and Debian
> should be able to consume these almost directly.

Respectfully, I think you've entirely missed the point of a distribution
(and sadly I'm seeing this trend more often than before now, with all
the hype around app stores and similar...). Packaging and maintaining a
consistent and unified distribution cannot be delegated to upstreams
(and I'm talking as an upstream developer here too), because that entails
a bit more than slapping some files somewhere, tarring the thing up and
calling it a day.

Building a nice distribution requires a high-level view and QA of the
entire system; requires curating sane namespaces, be them on the
package/project names, on the version strings, on the filesystem (by
avoiding file collisions, using alternatives or diversions), on exposed
programming interfaces, etc; requires making sure a diverse set of
programs interact correctly with each other; performing security
updates; ideally keeping single runtime versions; doing global
transitions to use other or newer runtimes, programs, libraries or
packages; an unified way to build from sources to cope with the endless
and interesting different upstream build systems; porting and building
for different binary architectures, not just what upstream might have
around; documentation; translation; tagging stuff with metadata to
allow for easy searches; excision of the embedded code copies cancer;
even stuff like how the Delete and Backspace keys should behave;
sets a qualify bar for upstream projects, stuff of low quality will
not be accepted most of the time; license checks; etc, etc...

And all this, upstream will never be able to provide (at least not as
defaults), because each distribution has its own policies, some are
better, some are worse, and some are just different. In general I'd
never trust the packaging produced by an upstream for a distribution
they are not involved in. But most of the time there will be no such
packages for the desired distribution anyway.

Although there's been work on creating distribution-neutral specs that
some upstreams have picked up, there's always going to be something new,
the specs will just not cover all needed things, the specs might not
be liked by some/many people, or might not have been fully adopted by
all upstreams.

A distribution (any, most) is the gel that binds and gives an unified
and coherent shape to the software ecosystem. An app store is just like
a scrapyard, you might find magnificent and isolated gems there, but most
of it will probably be junk, or not combine with the other scrap parts.

Also if people thought that distributions are unneeded, then the amount
of them would reflect that, or start decreasing, which I'm not seeing.
Distributions will exist as long as there's FLOSS, because by its
decentralized nature, there's no single coordination point; people
who are distraught by the amount of distributions or by their mere
existence might probably only be able to find peace in closed-systems
instead, with their centralized control points.

> Where Debian's efforts should be focused is on things like license
> verification and helping bug reports and fixes get to upstream.

So basically, getting rid of most of the fun stuff and turning it into
a lawyerish play-ground and support center... I'd venture to say, not
the most attractive work for most people here if it was the only
thing to be done, which we do because we think it's important non the
less.

Regards,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130424194348.ga32...@gaara.hadrons.org