Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Philip Hands]

Hi Marco,

Marco d'Itri  writes:
> On Aug 10, Roger Leigh  wrote:
>
>> In the case of OpenRC, it has the potential to be a drop-in replacement
>> for sysv-rc (note that it uses base sysvinit still underneath that).
> So do the other init systems.
> The point is what they can do which sysvinit (and openrc) cannot.

You may have noticed that despite your incessant attempts to shout this
effort down, they went ahead and did it anyway.

Now that they've done the bulk of the effort, do you really expect them
to simply discard their work because you tell them to?

You might not like it, and you might even think they've been wasting
their time, but unless you can come up with a demonstration that
allowing this in will cause actual damage to the distribution you might
as well shut up.

As a largely disinterested observer, it seems that this might at least
provide a route to being able to provide enough support of the the
features that make the systemd/upstart folk dizzy with excitement, such
that non-linux platforms don't end up acting as a blocker for one of
those two to be adopted for linux, while OpenRC covers non-linux enough
so that init-agnostic start-up scripts can work anywhere.

If it only results in some more effort being applied to coming up with
that agnostic solution, then the rest of us can then get on with life
while the upstart and systemd folk take chunks out of one another for a
decade or so.

So, please tell us about the corrosive harm that you think is going to
result from this being allowed into the archive (in detail, with
references), or let them get on with it.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpgEFIgWdDXc.pgp
Description: PGP signature

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Martin Wuertele]

* Josselin Mouette  [2012-08-10 01:06]:

> Le jeudi 09 août 2012 à 23:53 +0200, Carlos Alberto Lopez Perez a
> écrit : 
> > What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to 
> > work.
> 
> Please explain again why we should cripple the Linux port for the sake
> of toy ports?

Please explain why adding another sysv-rc drop-in replacements cripples
the Linux port.

Thanks, Martin


--
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/20120810072322.gc10...@anguilla.debian.or.at

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Martin Wuertele]

* Josselin Mouette  [2012-08-09 23:15]:

> And no, choice between multiple broken implementation is NOT added
> value. Linux is not about choice.

Luckily that is not everyones opinion.

Martin


-- 
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/20120810072558.gd10...@anguilla.debian.or.at

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Josselin Mouette]

Le vendredi 10 août 2012 à 09:23 +0200, Martin Wuertele a écrit :
> Please explain why adding another sysv-rc drop-in replacements cripples
> the Linux port.

Because being able to choose between alternatives for core features such
as the init system only brings more bugs and no added value.
http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html

-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1344585409.4874.20.camel@tomoe

Re: Bug#684396: ITP: openrc -- alternative boot mechanism

[heroxbd]

Dear Guys,

Thanks a lot for the input from Marco d'Itri, Holger Levsen and Thomas
Goirand, as well as Aron Xu off list.

m...@linux.it (Marco d'Itri) writes:

> openrc was recently discussed on debian-devel@ and there was a large 
> consensus that it is not a credible alternative to upstart and systemd.

I think you are referring to this thread

  http://lists.debian.org/debian-devel/2012/04/msg00547.html

> We do not need to be able to choose among multiple init
> implementations.

Holger Levsen  writes:

> while we (thankfully) have 42++ window managers in Debian, we only
> have 5 (or so) init systems and certainly more alternatives will be
> welcomed by many people, thriving to develop the best OS... whatever
> that means ;-)

The topic of if OpenRC suits Debian is still controvasial. That's
understandable. Besides, even in Gentoo community, there is voice
doubting if OpenRC suits Gentoo.

Debian is about the freedom to choose.

I am aware of systemd, upstart, and our good plain sysv-rc as well as
file-rc. People in the last thread already debated about which is the
best for Debian. Personally I like the unix way[1] of OpenRC to do
things, and I want to let people understand my opinion by inviting
Debian users to use, evaluate and criticize it.

Cool jobs are done in Redhat community/enterprise, in Ubuntu
community/enterprise. Thanks to them we have many choices to suit our
needs. OpenRC from Gentoo community would like also serve as your
choice, with a different styple: just do one thing and do it right, not
about revolution to blow your mind.

Thanks Marco d'Itri, I have carefully reflected whether introducing
OpenRC to Debian really worth my time and effort. And I decided to do
so. 

Let's have fun guys ;)

Yours,
Benda

1. http://en.wikipedia.org/wiki/Unix_philosophy


pgpoTX6slbbn7.pgp
Description: PGP signature

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Martin Wuertele]

* Josselin Mouette  [2012-08-10 10:12]:

> Le vendredi 10 août 2012 à 09:23 +0200, Martin Wuertele a écrit :
> > Please explain why adding another sysv-rc drop-in replacements cripples
> > the Linux port.
> 
> Because being able to choose between alternatives for core features such
> as the init system only brings more bugs and no added value.
> http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html

And that really explains why there is a choice for core functions like 
kernel event handler: udevd, hotplug2, mdev
c library: glibc, eglibc, dietlibc

er no, it doesn't.

Yours Martin


--
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/20120810084843.gg10...@anguilla.debian.or.at

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Marco d'Itri]

On Aug 10, Philip Hands  wrote:

> Now that they've done the bulk of the effort, do you really expect them
> to simply discard their work because you tell them to?
I really do not care about what the openrc developers will do, my 
interest is in what Debian developers will do.

> So, please tell us about the corrosive harm that you think is going to
> result from this being allowed into the archive (in detail, with
> references), or let them get on with it.
There are two main issues with trying to support multiple init systems.
The first one is the time needed to do it. The second and more important 
one is being limited by the features of the less capable implementation, 
which would be a disgrace.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#684467: ITP: TuxFight -- Fighting game between tuxes in the style of Street Fighter/King of Fighters

[Wilson Foo Yu Kang]

Package: wnpp
Severity: wishlist
Owner: Wilson Foo Yu Kang 

* Package name: TuxFight
  Version : 0.1a
  Upstream Author : Wilson Foo 
* URL : http://www.sourceforge.net/projects/tuxfight
* License : GPL v3
  Programming Lang: C++
  Description : Fighting game between tuxes in the style of Street
Fighter/King of Fighters


-- 
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/20120810091149.13559.63808.reportbug@walfin-desktop

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Marco d'Itri]

On Aug 10, Martin Wuertele  wrote:

> > http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html
> And that really explains why there is a choice for core functions like 
> kernel event handler: udevd, hotplug2, mdev
> c library: glibc, eglibc, dietlibc
They exist, and guess what? We do not allow Debian users to choose 
among them. Good point.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Martin Wuertele]

* Marco d'Itri  [2012-08-10 11:27]:

> On Aug 10, Martin Wuertele  wrote:
> 
> > > http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html
> > And that really explains why there is a choice for core functions like 
> > kernel event handler: udevd, hotplug2, mdev
> > c library: glibc, eglibc, dietlibc
> They exist, and guess what? We do not allow Debian users to choose 
> among them. Good point.

We do not have them in the archive does not mean we did not allow users
to chose if we had them. 

That we do no longer have glibc in the archive and we had a transition
to eglibc was an understandable maintainer decision.

How is core funcionality defined anyways?  If network is considered a
core function and then we have net-tools and iprout, ifupdown,
network-manager, wicd, ethtool, mii-diag, and users do have a
choice.

We do not yet have mdev in the archive but I hope that changes with the
next release.

Yours Martin.


-- 
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/20120810095617.gi10...@anguilla.debian.or.at

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Josselin Mouette]

Le vendredi 10 août 2012 à 11:56 +0200, Martin Wuertele a écrit : 
> That we do no longer have glibc in the archive and we had a transition
> to eglibc was an understandable maintainer decision.

glibc/eglibc is not comparable to the other alternatives, the
differences are extremely tiny.

> How is core funcionality defined anyways?  If network is considered a
> core function and then we have net-tools and iprout, ifupdown,
> network-manager, wicd, ethtool, mii-diag, and users do have a
> choice.

And this leads to poor user experience because none of these
alternatives offers everything we expect from the networking system.

> We do not yet have mdev in the archive but I hope that changes with the
> next release.

I can’t wait to see the brokenness it will bring.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1344597000.4958.13.camel@tomoyo

Re: Bug#684396: ITP: openrc -- alternative boot mechanism

[Josselin Mouette]

Le vendredi 10 août 2012 à 17:04 +0900, hero...@gentoo.org a écrit : 
> Debian is about the freedom to choose.

No, it is not.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1344597072.4958.14.camel@tomoyo

Re: Bug#684396: ITP: openrc -- alternative boot mechanism

[Andrew Shadura]

Hello,

On Fri, 10 Aug 2012 13:11:12 +0200
Josselin Mouette  wrote:

> Le vendredi 10 août 2012 à 17:04 +0900, hero...@gentoo.org a écrit : 
> > Debian is about the freedom to choose.

> No, it is not.

No, it is.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: Bug#684396: ITP: openrc -- alternative boot mechanism

[Ben Hutchings]

On Fri, 2012-08-10 at 17:04 +0900, hero...@gentoo.org wrote:
> Dear Guys,
> 
> Thanks a lot for the input from Marco d'Itri, Holger Levsen and Thomas
> Goirand, as well as Aron Xu off list.
> 
> m...@linux.it (Marco d'Itri) writes:
> 
> > openrc was recently discussed on debian-devel@ and there was a large 
> > consensus that it is not a credible alternative to upstart and systemd.
> 
> I think you are referring to this thread
> 
>   http://lists.debian.org/debian-devel/2012/04/msg00547.html
> 
> > We do not need to be able to choose among multiple init
> > implementations.
> 
> Holger Levsen  writes:
> 
> > while we (thankfully) have 42++ window managers in Debian, we only
> > have 5 (or so) init systems and certainly more alternatives will be
> > welcomed by many people, thriving to develop the best OS... whatever
> > that means ;-)
> 
> The topic of if OpenRC suits Debian is still controvasial. That's
> understandable. Besides, even in Gentoo community, there is voice
> doubting if OpenRC suits Gentoo.
> 
> Debian is about the freedom to choose.
[...]

Debian is supposed to be an integrated system.  We, the developers,
choose what can reasonably be integrated.

Users always have the freedom to run other software that we don't
package, or to use (or develop) derivatives that replace some core
components.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


signature.asc
Description: This is a digitally signed message part

Bug#684501: ITP: libsub-exporter-progressive-perl -- Only use Sub::Exporter if you need it

[Nuno Carvalho]

Package: wnpp
Severity: wishlist
Owner: Nuno Carvalho 

* Package name: libsub-exporter-progressive-perl
  Version : 0.001004
  Upstream Author : Arthur Axel Schmidt 
* URL : http://search.cpan.org/dist/Sub-Exporter-Progressive/
* License : Artistic 1, GPL 1
  Programming Lang: Perl
  Description : Only use Sub::Exporter if you need it

Sub::Exporter is an incredibly powerful module, but with that power comes
great responsibility, as well as some runtime penalties. This module is a
Sub::Exporter wrapper that will let users just use Exporter if all they are
doing is picking exports, but use Sub::Exporter if users try to use
Sub::Exporter's more advanced features, like renaming exports.


-- 
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/20120810003858.23027.12950.reportbug@localhost

Re: Bug#684396: ITP: openrc -- alternative boot mechanism

[Steve Langasek]

On Fri, Aug 10, 2012 at 02:21:08PM +0200, Andrew Shadura wrote:
> On Fri, 10 Aug 2012 13:11:12 +0200
> Josselin Mouette  wrote:

> > Le vendredi 10 août 2012 à 17:04 +0900, hero...@gentoo.org a écrit : 
> > > Debian is about the freedom to choose.

> > No, it is not.

> No, it is.

No, it really isn't.  It's about creating a technically excellent operating
system that meets our users needs.

Developers need the freedom to *make* autonomous technical choices as part
of the process of making Debian technically excellent; and in some cases the
answer for meeting our users needs is "both".  But this latter argument does
not apply to core infrastructure decisions, and arguing that Debian is
*about* the freedom to choose is missing the point.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Steve Langasek]

On Fri, Aug 10, 2012 at 09:03:19AM +0800, Chow Loong Jin wrote:
> On 10/08/2012 08:04, Steve Langasek wrote:
> > On Fri, Aug 10, 2012 at 01:16:17AM +0200, Adam Borowski wrote:
> >> Wasn't the idea of porting to non-Linux rejected by upstart's upstream? 

> > Porting upstart to non-Linux kernels has never been rejected by upstream. 
> > It just requires porters to do the porting; no one involved in upstart
> > upstream has any applicable BSD or Hurd porting experience.

> If I recall correctly, non-Linux ports were required by upstream to be
> maintained in a separate bzr branch, because upstart's upstream did not want
> compatibility code inside the main code-base. This sounds very much like "if 
> you
> want to port it, fork it."

That was several years ago, and there's a new upstream maintainer of upstart
now.  This would be open to rediscussion if there were any interested
porters to discuss it with.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Harald Jenny]

On Fri, Aug 10, 2012 at 10:55:51AM +0200, Marco d'Itri wrote:
> There are two main issues with trying to support multiple init systems.
> The first one is the time needed to do it. The second and more important 
> one is being limited by the features of the less capable implementation, 
> which would be a disgrace.

I tried to change from sysvinit to systemd for checking the improvements
it brings and had to move back because of
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862 so I guess "less
capable implementation" is in this case a very relative term and mostly
depends on the used features of the user... btw one of the most wanted
features of at least systemd is discussed here:
http://lists.fedoraproject.org/pipermail/devel/2012-June/169365.html

> 
> -- 
> ciao,
> Marco

Kind regards
Harald Jenny


-- 
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/20120810192020.ga3...@harald-has.a-little-linux-box.at

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Svante Signell]

On Fri, 2012-08-10 at 00:50 +0200, Josselin Mouette wrote:
> Le jeudi 09 août 2012 à 23:53 +0200, Carlos Alberto Lopez Perez a
> écrit : 
> > What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to 
> > work.
> 
> Please explain again why we should cripple the Linux port for the sake
> of toy ports?

Please calm down, Debian is bigger in scope than GNU/Linux only,
fortunately! And the openrc packaging initiative is a _very_ good
proposal!



-- 
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/1344635248.25305.6.camel@x60

choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)

[Eugene V. Lyubimkin]

On 2012-08-10 09:09, Steve Langasek wrote:
[...]
> > > Le vendredi 10 août 2012 à 17:04 +0900, hero...@gentoo.org a écrit : 
> > > > Debian is about the freedom to choose.
[...]
> No, it really isn't.  It's about creating a technically excellent operating
> system that meets our users needs.
> 
> Developers need the freedom to *make* autonomous technical choices as part
> of the process of making Debian technically excellent; and in some cases the
> answer for meeting our users needs is "both".  But this latter argument does
> not apply to core infrastructure decisions, and arguing that Debian is
> *about* the freedom to choose is missing the point.

Declaring "one area -- one chosen tool" is declaring the monopoly in the
area. As with other monopolies, this often leads to "vendor" lock-in,
stagnation, stopping developing the standards. Have seen examples of all
that occasionally.

I believe this hurts Debian (or any other project which chose to
not accept choices in certain areas) in the long run and don't fit to
'making [...] technically excellent' well.

YMMV.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer


-- 
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/20120810215345.GB12900@r500-debian

Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)

[Russ Allbery]

"Eugene V. Lyubimkin"  writes:
> On 2012-08-10 09:09, Steve Langasek wrote:

>> No, it really isn't.  It's about creating a technically excellent
>> operating system that meets our users needs.

>> Developers need the freedom to *make* autonomous technical choices as
>> part of the process of making Debian technically excellent; and in some
>> cases the answer for meeting our users needs is "both".  But this
>> latter argument does not apply to core infrastructure decisions, and
>> arguing that Debian is *about* the freedom to choose is missing the
>> point.

> Declaring "one area -- one chosen tool" is declaring the monopoly in the
> area. As with other monopolies, this often leads to "vendor" lock-in,
> stagnation, stopping developing the standards. Have seen examples of all
> that occasionally.

> I believe this hurts Debian (or any other project which chose to
> not accept choices in certain areas) in the long run and don't fit to
> 'making [...] technically excellent' well.

I think Steve's point is that the goal is to make Debian technically
excellent.  Sometimes that means providing choice, and sometimes it
doesn't.  All things being equal, I think a system that's flexible is more
technically excellent than one that isn't, but all things are almost never
equal (in one way or another).

There are choices that we don't support because the process of supporting
that choice would involve far more work than benefit, and the final goal
is excellence, not choice for its own sake.  For example, we don't allow
users to replace the system C library with a different one.  That's
something that we *could* do, but the general consensus of the project is
that investing our effort in that is not the best way to produce
excellence.

I happen to think that supporting multiple init systems *is* the correct
technical choice to achieve technical excellence, but I agree with Steve
that freedom to choose should not be stated as the end goal.

-- 
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/87628qz999@windlord.stanford.edu

Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)

[Josselin Mouette]

Le samedi 11 août 2012 à 00:53 +0300, Eugene V. Lyubimkin a écrit : 
> Declaring "one area -- one chosen tool" is declaring the monopoly in the
> area. As with other monopolies, this often leads to "vendor" lock-in,
> stagnation, stopping developing the standards. Have seen examples of all
> that occasionally.

That’s a very theoretical reasoning. Practically, when you have several
init implementations, what you can do is limited by the least capable of
them — even worse, instead of bringing more features, you can only use
the intersection of their functionality.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1344640360.4958.20.camel@tomoyo

Re: Change default PATH for Jessie / wheezy+1

[Philipp Kern]

On Fri, Aug 10, 2012 at 08:54:24AM +0200, Alberto Fuentes wrote:
> For the record and at least up to squeeze, you do have a sudo group
> but you are *not* added to that group.

If you are using an empty root password during installation, you do get sudo
rights.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)

[Faidon Liambotis]

On 08/11/12 01:12, Russ Allbery wrote:
> There are choices that we don't support because the process of supporting
> that choice would involve far more work than benefit, and the final goal
> is excellence, not choice for its own sake.  For example, we don't allow
> users to replace the system C library with a different one.  That's
> something that we *could* do, but the general consensus of the project is
> that investing our effort in that is not the best way to produce
> excellence.

I kind of disagree with that. I don't think that the fact that we don't
support multiple C libraries is the result of a "consensus decision".

I think it's just because noone attempted to properly do that and prove
it's viability and usefulness either to a portion of the userbase or the
project as a whole.

Similarly, I don't think the kFreeBSD ports or any of the other Linux
architecture ports were a consensus decision. People just did it, the
work was of reasonable standards and useful both to expanding the
userbase and to improving the quality of the other ports.

People are working on building Debian with LLVM (which is great IMHO).
Very few people complained about that and the talk was very much
welcomed at DebConf. We even have a GSoC project about it. There are
other similar examples.

As for OpenRC, as far as I understand it, it's similar -but with its LSB
header compatibility much less intrusive- with file-rc. None of the two
are an /sbin/init replacement.

The fact that the systemd-upstart debate is hot and controversial
doesn't mean that everything else that is even remotely related to the
boot process must be rejected from the archive. And certainly not
because a few people think so and are being loud in a mailing list.

Regards,
Faidon


-- 
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/5025abc8.8070...@debian.org

Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)

[Russ Allbery]

Faidon Liambotis  writes:
> On 08/11/12 01:12, Russ Allbery wrote:

>> There are choices that we don't support because the process of
>> supporting that choice would involve far more work than benefit, and
>> the final goal is excellence, not choice for its own sake.  For
>> example, we don't allow users to replace the system C library with a
>> different one.  That's something that we *could* do, but the general
>> consensus of the project is that investing our effort in that is not
>> the best way to produce excellence.

> I kind of disagree with that. I don't think that the fact that we don't
> support multiple C libraries is the result of a "consensus decision".

> I think it's just because noone attempted to properly do that and prove
> it's viability and usefulness either to a portion of the userbase or the
> project as a whole.

> Similarly, I don't think the kFreeBSD ports or any of the other Linux
> architecture ports were a consensus decision. People just did it, the
> work was of reasonable standards and useful both to expanding the
> userbase and to improving the quality of the other ports.

I think we're actually agreeing, so let me try to rephrase what I meant to
make that more obvious.  :)  I think Debian makes a lot of implicit
consensus decisions not to do something simply by no one going and doing
it.  And this is particularly true of things like allowing multiple C
libraries that require lots of work by everyone in the project.  People
realize how much work it would be up front and never attempt it, which is
a form of consensus decision-making.

It doesn't have to mean that we explicitly discussed it and decided not to
do it.  In fact, I find the discussions about things like this to be
mostly useless.  They're generally mostly conducted by a small number of
people who are usually bystanders to the actual work, the arguments become
quickly repetitive, and the discussions provide very little substantive
input into whether the work should continue or not.

The real way consensus decision-making tends to happen in the project is
that people try to do something and see how much push-back they get, often
with the help of a few highly-connected people in Debian who are able to
push on making a general change with the various teams.  (And we have a
hard time doing things that are project-wide, because that process isn't
very formal.)

For things that someone can go work on by themselves, such as exploring
openrc, the most effective approach seems to be to open a discussion on
debian-devel if they want some input, read the first couple day's worth of
discussion, and then ignore the rest of the thread and just go on and do
whatever one feels the right thing is.  Almost none of the subsequent
discussion after the first few days will be original or worth reading, let
alone responding to.  Even for things that can't be done by one team,
seeking consensus by talking directly to the other teams and groups most
affected is probably going to be more productive than participating in a
100-message thread in debian-devel.

-- 
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/87zk62uriw@windlord.stanford.edu

Bug#684549: ITP: pepper -- source code statistics reporting tool

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: "Antoine Beaupré" 

* Package name: pepper
  Version : 0.3.2
  Upstream Author : Jonas Gehring
* URL : http://scm-pepper.sourceforge.net
* License : GPL-3
  Programming Lang: C++, Lua
  Description : source code statistics reporting tool

 pepper is a flexible command-line tool for retrieving statistics and
 generating reports from source code repositories. It ships with
 several graphical and textual reports, and is easily extendable using
 the Lua scripting language. pepper includes support for multiple
 version control systems, including Git and Subversion. Using native
 language bindings, multi-threading and a local revision cache, it
 provides fast access to repository data.


--
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/20120811023829.14695.27931.report...@marcos.anarcat.ath.cx

Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)

[Steve Langasek]

On Sat, Aug 11, 2012 at 12:53:45AM +0300, Eugene V. Lyubimkin wrote:
> On 2012-08-10 09:09, Steve Langasek wrote:

> > > > Le vendredi 10 août 2012 à 17:04 +0900, hero...@gentoo.org a écrit : 
> > > > > Debian is about the freedom to choose.

> > No, it really isn't.  It's about creating a technically excellent operating
> > system that meets our users needs.

> > Developers need the freedom to *make* autonomous technical choices as part
> > of the process of making Debian technically excellent; and in some cases the
> > answer for meeting our users needs is "both".  But this latter argument does
> > not apply to core infrastructure decisions, and arguing that Debian is
> > *about* the freedom to choose is missing the point.

> Declaring "one area -- one chosen tool" is declaring the monopoly in the
> area. As with other monopolies, this often leads to "vendor" lock-in,
> stagnation, stopping developing the standards. Have seen examples of all
> that occasionally.

... says the man who thinks multiarch should be held up indefinitely because
a perl reimplementation of apt should take precedence.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)

[Thomas Goirand]

On 08/11/2012 05:53 AM, Eugene V. Lyubimkin wrote:
> Declaring "one area -- one chosen tool" is declaring the monopoly in the
> area. As with other monopolies, this often leads to "vendor" lock-in,
> stagnation, stopping developing the standards. Have seen examples of all
> that occasionally.
>   
Exactly! And in this particular case, the "vendor" is RedHat, and
the programs are systemd and udev. If we can have an alternative,
using OpenRC and mdev, then I really welcome it! Choosing systemd
just because it *seem* to look better *now*, knowing that we have
a quite hostile upstream, *and* dismissing any other alternative,
is a very dangerous bet which I don't think Debian should do. That
is, I believe, the most important point of all this thread.

Let's welcome OpenRC and see how it goes... This doesn't mean that
we are choosing *now* what will be the *default* init system. Just
that we are open to a new alternative.

Thomas Goirand (zigo)


-- 
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/5025e9aa.7000...@debian.org