Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

[Luk Claes]

+1

On Tue, Oct 31, 2017 at 5:46 PM, Sam Hartman  wrote:

> > "Russ" == Russ Allbery  writes:
>
> Russ> Martin Steigerwald  writes:
> >> Russ Allbery - 28.10.17, 16:13:
>
> >>> There wasn't *anything* "left out" of that discussion.
>
> >> In my opinion this is a pretty bold statement.
>
> >> If everyone has been heard, noticed, felt and valued, if
> >> everything has been covered, then why are we discussing it… yet
> >> again now?
>
> Russ> Those are not equivalent statements.  In that sort of
> Russ> discussion, it is literally impossible to make everyone feel
> Russ> valued, since at least some people on each side will only feel
> Russ> valued if their preferred option is chosen.  That's therefore
> Russ> not a reasonable thing to attempt to achieve; we can try to
> Russ> maximize the number of people who feel valued, but there are
> Russ> usually at least some people involved in this large and
> Russ> sprawling of a decision for whom "valued" is synonymous with
> Russ> "agreed with."
>
> For myself, I've found that if I work with people I can often get to a
> point where they feel valued even when there is disagreement.
> As you point out that's not true for some people and it is difficult
> even when it is possible.
>
> I was not planning on discussing systemd again.
>
> I am discussing how we handle conflict because I hope we can do a better
> job of helping  people feel valued even when we do not agree with their
> technical positions.
> In the limit, I hope to do your literally impossible:-)
>
> Fortunately, I'd be thrilled and filled with joy to simply get closer to
> that limit.  Helping create a culture where we have mechanisms to help
> ourselves separate value from agreement, and where we value using those
> mechanisms would delight me.
> I think even that is a hard ask, but I do not think it is literally
> impossible.
>
> --Sam
>
>

Re: Code of Conduct violations handling process

[Luk Claes]

On 09/03/2014 07:21 PM, Russ Allbery wrote:
 Scott Kitterman skl...@kitterman.com writes:
 Manoj Srivastava sriva...@debian.org wrote:
 
   How do you suppose we keep the atmosphere from devolving back to
 the poisonous flame-fest days, and enforce various codes of conduct
 policies?  I have seen far too many tech conferences without codes of
 conduct devolve into misogynistic and occasionally racist
 experiences. The argument that codes of conduct are forms of censorship
 is frequently made, but, I am afraid, not very convincingly.
 
 None of those things are at issue in this case. It's not relevant. 
 
 What case?  Ian raised a bunch of general questions about how we plan on
 enforcing our CoC, with no reference to any specific incident.  You seem
 to be convinced that this is about some specific incident and, further,
 about forcing some specific action about that specific incident, but so
 far as I can tell, this belief on your part is not based on anything
 that's been said in this mailing list.

Hmm, how can you argue this with the statement that we should not invite
Linus on future conferences?

 Even if you're right and this is all inspired by some specific incident,
 the general questions are still worth discussing seriously in their own
 right.  There's no need to dismiss the entire conversion (or, worse, be
 flippant about it in a way that implies that Debian doesn't care about the
 experience of people on its mailing lists or at its conferences) just
 because you *think* you disagree with the motives of the person who raised
 the issues.

True, but it's also unfair to dismiss the specific case because you want
to take it broader.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54078163.4000...@debian.org

Re: Planned changes to Debian Maintainer uploads

[Luk Claes]

On 06/10/2012 01:57 PM, Ansgar Burchardt wrote:

 We plan to instead implement an interface where developers upload
 a signed command file to ftp-master to grant upload permissions
 instead, similar to dcut.  This could end up looking similar to
 this:

Good idea!

 We will also drop the check that the DM is in Uploaders of the
 previous version and Changed-By of the current version. This has
 caused problems for DMs that have multiple uids attached to their
 key in the past. (This technically allows DMs to sponsor uploads to
 packages they have upload permissions for and to grant upload
 permissions to packages the DM does not maintain (yet). This should
 not be abused.)

Indeed, that check should be dropped.

 Please note that we currently do not know when we might get around
 to implement these changes.

I guess the plan is to integrate it with dak: so python code and have
it go to the projectb database?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd4b522.9050...@debian.org

Re: OSI affiliation

[Luk Claes]

On 02/22/2012 02:09 AM, Charles Plessy wrote:
 Le Tue, Feb 21, 2012 at 09:36:28AM -0800, Russ Allbery a écrit :

 I do think we should, if we join, state publicly (in whatever press
 release we generate announcing our membership) that Debian is not adopting
 the OSI license review process for Debian and that Debian will continue to
 conduct its own license review as we do now, and that we continue to
 disagree with OSI in some areas on what licenses should be considered
 free.
 
 I think that it is an important clarification to make.
 
 Thanks to this clarification, I would like to recommend that, in case the
 OSI has already discussed a license, this work is taken into account
 when making a review on debian-legal.  The OSI has recently opened
 public mailing lists and a bug tracker, that will help a lot to avoid
 duplicating work when it is descriptive or comparative.

Not sure why you think anything needs to be reviewed on debian-legal as
it is just a list of random people commenting on random legal issues and
has no direct say whatsoever about any legal or other issue in Debian...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f44895b.2080...@debian.org

Overview of Debian's financial flows

[Luk Claes]

Hi

Here is an overview of the most important financial flows of money hold
on Debian's behalf this year up to May 31st.

January:

SPI [0] (in USD):
  * donations:+ 9,849.73
  * freight:  - 3,372.66
  * hard drives:  - 1,138.35
  * processing fees:  -23.68
  * SPI 5%:   -   142.58
  * travel reimbursement: - 1,030.13

ffis [1] (in EUR):
  * donations:+   721.11
  * BSP Moenchengladbach  -   297.50
  * new backup server - 7,607.48

February:
-
SPI (in USD):
  * donations:+ 2,039.00
  * Debian Edu sponsoring:- 5,022.00
  * Processing Fees:  -70.96
  * BSP New York: -19.92
  * SPI 5%:   -   101.95
  * travel reimbursement: - 1,085.06

ffis (in EUR):
  * donations:+   100.00
  * travel reimbursement  -   500.00

March:
--
SPI (in USD):
  * donations:+ 4,759.35
  * DebConf Housing: - 28,620.00
  * DebConf Liability Ins: -  390.00
  * Incoming Wire Fee:-15.00
  * Panama Mini DebConf:  - 1,100.00
  * Processing Fees:  -26.93
  * Spanish Mini DebConf: - 2,061.15
  * SPI 5%:   -44.97
  * travel reimbursement: - 2,826.31

ffis (in EUR):
  * donations:+   216.11

April:
--
SPI (in USD):
  * donations:+ 1,888.15
  * Candy for LH: -67.00
  * Hardware for MIPS:-76.29
  * Processing Fees:  -66.76
  * SPI 5%:   -54.91
  * Trademark Reg:-   500.00
  * travel reimbursement: -   602.31

ffis (in EUR):
  * donations:+51.11
  * Groupware Meeting:-   240.00
  * travel reimbursement: -   719.43

May:

SPI (in USD):
  * donations:   + 41,199.65
  * DebConf DayTrip:  - 1,003.50
  * new archive server:  - 17,051.35
  * Processing Fees:  -   242.51
  * SPI 5%:   -46.20
  * travel reimbursement: - 5,472.59

ffis (in EUR):
  * donations:+   547.11

Note that DebConf financial flows are included in SPI's figures, though
mentioned separately where easily possible. Also note that some of the
sponsoring for meetings and Debian Edu is (or will be) used by its
organisers for travel reimbursement.

More information about the Debian Auditor's role and the list of
organisations holding assets in trust for Debian can be found on the
wiki [2].

Cheers

Luk

[0] http://www.spi-inc.org/
[1] http://www.ffis.de/
[2] http://wiki.debian.org/Teams/Auditor


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c24e91e.4000...@debian.org

Re: Invite to join the Release Team

[Luk Claes]

Clint Adams wrote:
 [Adding and M-F-T-ing -project]
 
 On Sun, Mar 14, 2010 at 10:04:58AM +0100, Marc 'HE' Brockschmidt wrote:
 I want to point out that Luk's mail was not in any way discussed in the
 release team. I think it is horrible.

 I welcome everyone to critize the release team. I would prefer help, of
 course, but on the other hand, I do understand that people can see a
 problem, but don't have the time to fix. It would be nice if such
 criticism would be sent directly to the release team, and bluntly
 point out what the problem is, as that makes it easier to work on the
 issue.
 
 Okay, so when there is a mysterious release team meeting in Cambridge,
 and there is no discussion or planning of it on debian-release, or
 #debian-release, or anywhere else public that I can see, and there is
 zero evidence that it was planned or happened on official channels,
 and at least two of the participants (or whom I assume were participants)
 tell me that transparency is either completely unimportant or
 low-priority, and the DPL-2IC team seems to favor the opposite of
 transparency, how is one supposed to know about this meeting in
 time to complain about it?  How and why should one complain to the
 release team directly?

Transparency can be nice, though there is zero to nothing discussed
about the release meeting at Cambridge because it was unclear what was
agreed on if anything and it lasted till quite some months and meetings
later before it started to make any sense.

When Dato left, I had to suddenly give the talk at DebConf and I was not
ready to communicate, though the press wanted to send something out.
There was a major misunderstanding which was probably my fault, though
nothing was the same again afterwards.

Now I took a VAC to be able to get some rest and think things over and
the only things I see when I come back are complaints directed to my
person (and the Release Team) regarding python2.6 and communication.

The complaints may very well be valid, though the way they are out are
very much not IMHO.

The whole thing about secrecy is exagerated AFAICS as there just is not
much to tell. The reason these things mostly remain private is that
there is not much to tell and making things public without the consent
of everyone involved is not done.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b9cfbf7.6080...@debian.org

I'm resigning as Release Manager

[Luk Claes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

It's time to stop thinking I would be able to keep working as Release
Manager in this climate, I hereby resign as Release Manager.

Cheers

Luk
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkudF7AACgkQ5UTeB5t8Mo0KKwCfWrxGSnPLvG/EpYEAJcI9w6Ga
gooAn3n5QIJgXn53STFBi9zwWo+VCHSA
=Z2WP
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b9d17b0.4050...@debian.org

Re: squeeze release cycle?

[Luk Claes]

Raphael Hertzog wrote:
 On Tue, 10 Nov 2009, Stefano Zacchiroli wrote:
 Sure, if most DDs have just took that mail as a proposal that they can
 safely ignore, the release team should probably be more precise, but I
 doubt the substance will be anything else than what we have now. (I also
 duly notice that the release team has been heavily flamed just after DC9
 for not having stated explicitly the word proposal, so they might have
 been tempted to write proposal now to avoid flaming ... We're all
 humans.)
 
 Sure, but they could say: “based on the input we got, we propose to
 freeze in march 2010. If no major complaints come up, we'll confirm
 this schedule in 2 weeks.”

If no major things (like a way too high RC bug count) would interfere we
still intend to freeze in March.

So please align your plans with that target and help reducing the
blockers, TIA.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debian money

[Luk Claes]

Sune Vuorela wrote:
 On 2009-09-09, Steve McIntyre lea...@debian.org wrote:
  1 New hardware / equipment

a The DSA team have a wishlist of new hardware they'd like, along
  with a set of donated machines that need configuring and/or
  shipping. As far as I'm concerned, so long as the individual
  requests here look reasonable then they get approved as and when
  they happen.

b Maintainers of big packages might benefit a lot if we can
  loan/donate big machines to them to make things faster. Should
  be an easy thing to work out - nominate such people please!
 
 Yep. Both of them is interesting.
 
 I would personally like to be able to rebuild kde in half the time I
 currently spend on it.

Maybe we should think about the combination too: a very fast development
box (or cluster) for Debian contributors?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debian Maintainers Keyring changes

[Luk Claes]

Nico Golde wrote:
 Hi,
 * Debian FTP Masters ftpmas...@ftp-master.debian.org [2009-09-06 23:13]:
 The following changes to the debian-maintainers keyring have just been 
 activated:

 dog...@pps.jussieu.fr
 Removed key: 521B0E56C8AD98A189B9C56886BCABFF1C00C790


 li...@ict.ac.cn
 Full name: LIU Qi
 Added key: A8C0860CD8A9D6FC551F6E2CA4AB763B00EC886F


 st...@glondu.net
 Removed key: 467FC0C018311E9479465FC7060F2876FCE03DAA

 Debian distribution maintenance software,
 on behalf of the Keyring maintainers
 
 How come two of the 3 removed keys have no Full name?

The removed keys have no Full name field, the added key has. For
reference the removed keys are for two new DDs: Mehdi Dogguy and
Stéphane Glondu.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Switching the default startup method

[Luk Claes]

Martin Wuertele wrote:
 Hi Steve!
 
 * Steve Langasek vor...@debian.org [2009-08-24 09:19]:
 
 So far, the only bugs that have been highlighted in this thread appear to be
 bugs that happen when trying to remove insserv.  If there aren't any
 problems with the new system, why do we need to support downgrading?
 
 Because several people prefere to use file-rc for various reasons, e.g.
 on embedded systems. Therefore it is essential that insserv can be
 purged without running into such bugs.

AFAIK embedded systems don't use plain Debian so don't have to keep the
same Essential package set anyway.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Switching the default startup method

[Luk Claes]

Martin Wuertele wrote:
 Hi Steve!
 
 * Steve Langasek vor...@debian.org [2009-08-24 10:03]:
 
 The main thing I know about file-rc is that it's a corner case that further
 breaks upgrade handling when packages need to renumber their symlinks in
 /etc/rc?.d.  I know embedded is often used as a catch-all to describe all
 kinds of crackful ideas, but I'm at a loss to see how this makes file-rc
 in particular appealing to anyone.
 
 It's easy to maintain, it doesn't require a bunch of symlinks like
 sysv-rc nor does it require the magic of insserv, it is easy to change
 the order in which services are started without time-consuming resolving 
 dependencies (eg linksys WRT54GS v1.1, asus wl500g boot pretty fast with
 it).

There is no reason to use insserv on embedded systems, though if you do,
you could create the image somewhere else on a fast machine and don't
have the draw backs of time-consuming resolving dependencies AFAICS?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Switching the default startup method

[Luk Claes]

Bernd Zeimetz wrote:
 Raphael Geissert wrote:
 #475478 insserv: uninstallation fails horribly if an init script has
 been removed.
 [...]
 #538959 needs actually to be worked on. The current state is not how
 it should be.
 (which you later said it should be #511753)

 These two only seem to occur when insserv is removed, and since it is now
 pseudo-essential that should never happen, IOW: IMO they are not grave (I
 do agree that they should be addressed, though).
 
 Wrong. People who want to switch away from sys-rc/insserv need to be able to
 remove it. It is grave.

For (semi-)essential packages there is no guarantee that removing will
be easy. I know of quite some essential packages that are not easy to
remove at all.

Switching away from sysv-rc is apparently possible as Phil is using
upstart with insserv.

It's quite true that removing should be made optional if possible,
though that does not seem grave to me.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Switching the default startup method

[Luk Claes]

Alexander Wirt wrote:
 Raphael Hertzog schrieb am Monday, den 24. August 2009:
 
 *snip*
 
 So please point us to bugs related to breakages on upgrades (there have
 been some I know, but I think Petter dealt with them correctly) if you
 want to use that argument to not switch to insserv by default. The
 current bugs that you pointed out only have to do with file-rc
 users that are not happy.

 I would like to mention the fact that the new file-rc maintainer is not
 really cooperative either (thus not improving the situation for its
 users). It would be nice if Alexander pointed out why he doesn't want to
 fix 539609, his angry reply in
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539591#15 doesn't bring
 the discussion forward while Petter tried to lay the path to allow file-rc
 to be a working alternative again.
 I don't see any point on supporting insserv within file-rc. I use file-rc to
 have an alternative to such a system. File-rc is different and will not work
 properly with dependency based booting. I think resorting the configuration
 file (hint, its a user file) is not a solution - so how should I implement it
 in file-rc?. Its all about choice and also I don't like if another maintainer
 which is not able to see its own bugs like to force me on its - in my eyes -
 broken solution. All I want to have is that sysv-rc is working properly, its
 usage of update-rc.d together with the debconf switch is just broken and a
 bug and reacting on this bug with filling a bug against file-rc that it
 should insserv in the future is not ok. 

Why would file-rc not work properly with dependency based booting?

You might want to look if insserv overrides can help.

What is broken with the usage of update-rc.d or the debconf switch?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Switching the default startup method

[Luk Claes]

Wouter Verhelst wrote:
 On Mon, Aug 24, 2009 at 03:34:51PM +0200, Raphael Hertzog wrote:
 On Mon, 24 Aug 2009, Bernd Zeimetz wrote:

 With dependency based ordering, you just state the dependencies and you
 let it figure out the order.

 There are advantages to dependency-based boot systems, sure; but there
 are advantages to *not* having that, too (e.g., it is more
 deterministic, and therefore easier to debug).
 Well, both are deterministic but they do not decide of the ordering in the
 same way and it's just easier for our brains to represent a number-based
 sequence.
 
 Sorry, but dependency-based boot systems are *not* deterministic.
 
 Let's assume the following:
 
 - initscript a depends on b
 - initscript c declares that it wants a to be started first if it is
   installed, but that it is not a problem if it isn't installed.
 
 Now we may have either of the following situations, depending on whether
 the user does or does not install recommendations:
 
 - b is started first, then a, then c
 - b is started, and c too. The order depends on coincidence, since there
   is no relationship between the two
 
 If initscript c should actually declare a dependency on initscript b,
 then you have a bug that the maintainer may find himself hard-pressed to
 reproduce, simply because he does have the package containing initscript
 a installed.

If there is a bug in the dependencies of c, then there is indeed a
problem that should get fixed. I don't see what you try to prove with
that though?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Luk Claes]

Bernd Zeimetz wrote:
 Sandro Tosi wrote:
 
 what can happen is that he prepare a rough solution, sent to debian in
 a sense hey, take it, I've done my work, it's an ugly hack but I have
 no time to prepare an elegant solution; Now I got to go, I have
 another 1000 things to do. I'm not sure it will happen, but I fear it
 would.
 
 That happens already. See the Python 2.6 migration for a lot of bad 
 examples...

Hmm, AFAICT python2.6 did not really happen in Debian yet because
Mathias is trying to not continue with the existing hacks that have
major issues when upgrading and wants to have a clean solution. AFAICS
that was already communicated in February [0] and was only really acted
on around DebConf [1]. You can blame everyone involved, but I think it
might be better to cooperate on fixing it instead.

Cheers

Luk

[0] http://lists.debian.org/debian-devel/2009/02/msg00431.html
[1] http://lists.debian.org/debian-python/2009/08/msg3.html


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: The Python mess in Debian

[Luk Claes]

Bernd Zeimetz wrote:
 To come back to Debian
 
 Luk Claes wrote:
 Hmm, AFAICT python2.6 did not really happen in Debian yet because
 Mathias is trying to not continue with the existing hacks that have
 major issues when upgrading and wants to have a clean solution.
 
 The only hack is the broken piece of python-central and Matthias not being 
 able
 to accept that somebody else is able to provide a well working solution 
 without
 a ton of hacks which makes it a pain in the ass to migrate away from it. We 
 now
 have a *lot* of packages with extra maintainer scripts which take care of
 cleaning up behind python-central. That's not the way ho things should work.

AFAIK python-central does have the necessary tools to clean up.

You might notice that in the proposal nor python-central nor
python-support would remain...

 AFAICS
 that was already communicated in February [0] and was only really acted
 on around DebConf [1].
 
 Wrong. Several people tried to contact Matthias on various ways and never got 
 a
 reply. He also completely failed to communicate with those people who maintain
 most Python related packages on Debian, except during Debconf. This is *NOT* 
 the
 way how Python should be maintained. Actually several people already thought
 abut hijacking Python due to the complete lack of communication with the 
 Python
 Maintainer, who prefers to force his changes on people instead of finding an
 acceptable resolution. While I think that large parts of this are the result 
 of
 him being overworked due to Ubuntu stuff, this is not the way how things 
 should
 go. During Debconf [1] came up, but I can't see it happen soon as there are
 *way* too many problems with the proposal, and it would bring us back to
 pre-Etch areas..

You seem to misunderstand what the problems to be solved are and what
the proposed solution would bring.

 There were rumours that Python 2.6 was not uploaded to unstable due to bugs or
 missing things in python-support, but as usual there was no bug filed, and
 nobody talked to the python-support maintainer.
 
 You can blame everyone involved, but I think it
 might be better to cooperate on fixing it instead.
 
 Don't even think about blaming me for not trying to cooperate on Python 
 related
 things if you have no damn clue.

I did not intend to blame you at all, sorry if it seemed I did.

AFAICT, the real problem is that after unpack many python modules do not
work as they use symlink hackery in the postinst.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Luk Claes]

Bernd Zeimetz wrote:
 Luk Claes wrote:
 
 If the freeze date is well known in advance the question becomes moot
 unless some maintainer wants to work against the freeze AFAICS. Having a
 known freeze date is meant to help everyone to be able to plan better
 and refrain from doing high impact changes right before the freeze.
 
 There is nothing bad with a fixed freeze date. Just with the way it was 
 planned
 for December.

s/planned/announced/

It was and still is not meant as a decision, but as a proposal though
the announcement said otherwise due to miscommunication from my side
which I cannot undo unfortunately.

I'm not convinced that we will be able to freeze in December anymore and
I still want to talk to teams and people to see how their schedules can
fit in with a proposal of a new freeze date. I do consider that we
should delay the date significantly as many of the feedback already
received indicates that there is more time needed before we freeze.

Cheers

Luk



-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Luk Claes]

Mark Shuttleworth wrote:
 Cyril Brulebois wrote:
 Raphael Geissert geiss...@debian.org (05/08/2009):
   
 Like some people said during Debconf: freezing in December doesn't
 necessarily mean freezing the first day or even the first week of
 December; the 31 is still December, which means there are 30 days to
 decide many things, if necessary.
 
 Without having to resort to nitpicking on days, was the “freeze” term
 define anywhere? My main question would be: will it be possible to e.g.
 switch the default compiler right before the freeze and trigger possible
 hundreds of serious FTBFS bugs? Or is some incremental freeze still
 supposed to happen? (Putting -release in Cc to catch their attention.)
   
 
 At least on the Ubuntu side, there would be room to agree in advance on
 items that are as yet unreleased, but which have for various reasons
 clear advantages and well understood risks.

Just providing a bit of Debian specific context:

A freeze in Debian is usually very strict and only allows small diffs
that fix release critical bugs, release goal bugs (and sometimes
documentation or translation bugs).

 So, for example, if someone on the toolchain team said GCC 4.5 is going
 to be released in February, and we've run a test rebuild of the archive
 and there were only 20 FTBFS's then it might well be possible to get
 consensus around that new version being planned as a consensus base
 version for releases in 2010.

This is normally out of the question within a Debian freeze, just before
the freeze could be an option if there is a clear commitment to fix the
remaining bugs though.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Luk Claes]

Cyril Brulebois wrote:
 Raphael Geissert geiss...@debian.org (05/08/2009):
 Like some people said during Debconf: freezing in December doesn't
 necessarily mean freezing the first day or even the first week of
 December; the 31 is still December, which means there are 30 days to
 decide many things, if necessary.
 
 Without having to resort to nitpicking on days, was the “freeze” term
 define anywhere? My main question would be: will it be possible to e.g.
 switch the default compiler right before the freeze and trigger possible
 hundreds of serious FTBFS bugs? Or is some incremental freeze still
 supposed to happen? (Putting -release in Cc to catch their attention.)

If the freeze date is well known in advance the question becomes moot
unless some maintainer wants to work against the freeze AFAICS. Having a
known freeze date is meant to help everyone to be able to plan better
and refrain from doing high impact changes right before the freeze.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Re-thinking Debian membership - take #1: inactivity - status update

[Luk Claes]

Sandro Tosi wrote:
 On Sun, Aug 2, 2009 at 11:56, Stefano Zacchiroliz...@debian.org wrote:
 On Wed, Jul 22, 2009 at 06:03:41PM +0200, Stefano Zacchiroli wrote:
 This proposal received a lot of interest back then, but in the end
 went nowhere. I think we should resurrect it and put into use at
 least some of its parts. In particular, the part about expiration
 of DD rights received only minor criticisms; criticisms which I've
 tried to address.
 Here is a status update.

 My reading of the discussion which followed the initial proposal is
 that we have consensus on the general idea; yet, there are small
 divergences on some details (e.g., 1 year vs 2 year, when/if
 notifying, ...).
 
 some questions I still see without a clear answer:
 
 - who will decide the above (and below) details? are they left to the
 implementors? I believe the proposal should contains some sort of
 lower limits (what if they decide 1 month of inactivity is enough?
 ok it's purely hypotetical, but it still applies).

DAM. Well, when DAM would decide too restrictive, one could try to
convince them to do otherwise or even overrule them.

 - what's your ETA for this proposal to be operative?

That's up to DAM.

 - what about non-DDs that are currently tracked in MIA database, along with 
 DDs?

Nothing changes regarding MIA.

 - what will happen to the packages of DDs deactivated by this proposal?

Like with the WAT runs, there will very probably be a feedback to the
MIA Team.

 - will the MIA team be dismantled? who's in charge of this? will you
 take care of removing all the traces of MIA team from Debian
 documentations (like wiki, devref, etc) or from wherever is
 referenced? (of course, if we decide to remove it and not archive)
 or edit them, where needed?

You are mixing WAT and MIA apparently. The current proposal may replace
the DAM's WAT runs AFAICS, it does *not* affect MIA except from the
feedback generated after deactivation of DDs.

 - what to do about the current (yet unanswered) queries we've
 received? should we reply please wait for this to be approved?
 should we fulfill? when should we stop operations? (I'm personally not
 that motivated to work on something that's dying.)

There is no reason at all to change processing.

 Since, AFAIR, DAM has not commented in the thread, in the last days I
 contacted a DAM representative (Joerg Jaspert) in private to seek
 comments on the idea. The bottom line is that DAM is fine with the
 proposed changes and is willing to replace (manual) WAT runs [2] with
 an automatic mechanism like the one we discussed.  I also pinged DSA,
 which reasonably considers this discussion none of its business and
 will happily implement whatever the project and DAM decide on the
 matter.
 
 I do believe it would have been nice if you contacted (not saying
 discuss with) the MIA team about this proposal (since the team main
 activities are under discussion here), either before or after your
 made it public.

You seem to misunderstand the proposal AFAICS. The MIA Team would still
be operative for non DDs in general and for DDs in a proactive way (aka
during the inactivity period).

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Luk Claes]

Frans Pop wrote:

On Wednesday 29 July 2009, Meike Reichle wrote:

The Debian project has decided to adopt a new policy of time-based
development freezes for future releases, on a two-year cycle.


Disappointing to see such an announcement without any prior discussion on 
d-project, d-devel or d-vote. Some explanation of how and by who this 
decision was reached would be appreciated.


The Release Team proposed a plan in the keynote at DebConf. There were 
some important considerations, but in general the audience welcomed the 
plan.


The announcement was made to avoid confusion and unclear press coverage.


So from now on we release when it's time instead of when it's ready?
RC bugs are no longer relevant?


No, we freeze in time, we release when ready. RC bugs are still one of 
the measures to see when we are ready.


Thanks for your feedback.

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Luk Claes]

Sune Vuorela wrote:

On 2009-07-29, Frans Pop elen...@planet.nl wrote:



On Wednesday 29 July 2009, Meike Reichle wrote:

The Debian project has decided to adopt a new policy of time-based
development freezes for future releases, on a two-year cycle.

Disappointing to see such an announcement without any prior discussion on=20


I'm disappointed by the decision, the timing and the process.
I'm especially dissapointed about the we freeze after less than a year
of open unstable.

The process:

This is not something that should be done only by the release team
without a broad discussion amongst the developers, unless the relaese
team wants to do it them selves without cooperation from the package
maintainers.


Who would you like to propose a release cycle to the project if not the 
Release Team?


To be clear the Release Team cannot just decide what the release cycle 
will be, though we proposed a plan in the team's keynote at DebConf and 
the plan was welcomed by the audience. There were some important 
considerations though.



The timing:

If we are going to do a yearly release, we need to announce it to the
developers more than 5 months before freeze. Too many people have too
many plans.


We do not plan to do a yearly release, we plan to have a release about 
every 2 years while having a one time exception for next release by 
freezing this December.



We also need to coordinate such things with the larger packaging teams
to see wether it fits their schedules and their upstream schedules. For
example from a KDE point of view, it is around teh worst time.


I guess you are talking about freezing this December and not in general?

Lets discuss the issues regarding KDE and see if we can come to a solution.


...and we still have the same kernel and X in testing as in stable.


Both of which are being worked on currently.


The decision:

Why doing a 12 months release to get into the new schedule instead of
just adopting a 24 months schedule based on the lenny release? [1]


The main reason is that the Release Team hopes to now have the momentum 
to make a time based freeze work. If we would delay, it will very 
probably mean that many developers 'forget' about what the time based 
freeze is about.



By freezing after around 9 months after thawing, we will again annoy the
many sid users we have, and by doing releases after 12 months after a
release, we will start annoy the corporate users.


s/releases/release/


By freezing after around 9 months of unstable we annoy the developers
who wants to get stuff done before a release.


The developers have had the opportunity and still have the opportunity 
to get stuff done before the release. It's true that developers should 
probably consider to already be careful about what to upload, but there 
is still opportunity to do changes till the freeze.



And what happened to when it is ready ?


That has not changed at all. That's the reason we do not want to do a 
time based release, we will only release when we are ready.



If a freeze is expected to be short, the release team needs help from
the package maintainers. This is not the way to get the package
maintainers to help them.


It's indeed the package maintainers that can make sure that the freeze 
will take a long time. Though if they consider the points you made 
earlier in this mail I'm confident that they will try to keep the freeze 
short.



I'm considering how we can get this decision undone.  Anyone up for
helping with that?


Very constructive... what plan do you have in mind that will be shared 
by the Release Team and the project as a whole?



[1] Some people says it is to get to work better with ubuntu in security
things and other such stable support - and having the same package
versions will make it easier to share patches.  Unfortunately, in some
cases this will not fit. For example, Qt4.6 and KDE4.4 is expected to be
released in january, which would be right after the debian freeze. I
would be very surprised to see a ubuntu releaese in april with kde4.3
and qt4.5. And here, we now already have two browser engines that we
can't work properly together and share patches with ubuntu, because too
much has (probably) happened.
And for much other software, there is probably similar examples.


Are you confident that KDE will be better at releasing in time and with 
a higher quality than they are used to? Otherwise it looks to me like we 
would need many more months before we can freeze KDE.


Cheers

Luk


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Luk Claes]

Sandro Tosi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Debian decides to adopt time-based release freezes


No, the project DID NOT decide it, the release team did, and the
project has to accept it; there's a lot of difference.


No, the Release Team proposed a plan. The project is free to accept or 
refuse the plan. Of course refusing the plan will have its consequences 
within the Release Team as well as within the project.



The Debian project has decided to adopt a new policy of time-based
development freezes for future releases, on a two-year cycle. Freezes


and what are the real advantages of this? I saw none in this announce.


The main advantage of a time based freeze would be that developers have 
a clear idea about when the cutoff is for new features and when the 
period of stabilising to a release starts. This should give developers a 
 better chance to plan and more responsibility in how they want to 
support their packages.



will from now on happen in the December of every odd year, which means
that releases will from now on happen sometime in the first half of every
even year.  To that effect the next freeze will happen in December 2009,
with a release expected in spring 2010. The project chose December as a
suitable freeze date since spring releases proved successful for the
releases of Debian GNU/Linux 4.0 (codenamed Etch) and Debian GNU/Linux
5.0 (Lenny).


if time-based is REALLY needed, why then not freeze on even Dec and
release on Spring on odd years? this will allow the current release
cycle to have enough time to achieve something, while letting
time-based proposers happy.


The main reason is that we now have the momentum to try a time based 
freeze and that delaying the freeze would cause developers to 'forget' 
about what a time based freeze is about.



Time-based freezes will allow the Debian Project to blend the
predictability of time based releases with its well established policy of
feature based releases. The new freeze policy will provide better
predictability of releases for users of the Debian distribution, and also


bullshit! we are trading quality for what? We release when it's ready,
not when the clock ticks. it's completely a non-sense, and it's
generating only bad feelings in developers and users.


Hmm, you put it very negative while the intention is not at all how you 
put it:


We will only release when we are ready to make sure we do not have to 
trade quality.
We will freeze on a upfront specified date to give developers a chance 
to better plan what should be included in the release.



and predictability is the only advantage of this proposal? if so, then
simply let's drop it: pro and cons are damn wrong.


No, see above.


allow Debian developers to do better long-term planning.  A two-year
release cycle will give more time for disruptive changes, reducing


Not this time.


True, this time we want to make sure we have the momentum to do a time 
based freeze and maybe get some developers to think about shorter time 
plans.



inconveniences caused for users. Having predictable freezes should also
reduce overall freeze time.


should we remember here that lenny freeze took +6 months?


Note that how long the freeze takes is the responsibility of all 
developers as the most important measure (RC bugs) can be influenced by 
everyone.



The new freeze policy was proposed and agreed during the Debian Project's
yearly conference, DebConf, which is currently taking place in Caceres,
Spain. The idea was well received among the attending project members.


1. what about the developers that couldn't come to DC? don't we
deserve to be asked for our opinion? are we of a lower class? is this
a decision only made by a team and then you want to us to pretend the
whole project decided it?


Not at all. The Release Team proposed a plan and it was welcomed during 
the team's keynote at DebConf. But your and others input is very much 
appreciated.


The announcement was made to be sure that press coverage would not 
differ from the actual message and confuse people. It seems it has not 
reached that goal completely, though the intentions were good.



2. it doesn't seem all the attendants agreed with it, given what
happened yesterday evening on #debian-release.


I don't know what happened yesterday evening on #debian-release.


To conclude:

- - we are giving up our quality-based release for a time-based one
for no particular reason


Not at all.


- - there is a constant drift away from debian by our users, this
would be the killing shot


Why? We do try to take into account considerations to improve the usability.


- - this is a change in our most important aspect of our work: the
release. How can I go now to my boss and propose to switch to debian
once this is happening?


You could propose the skip one release if needed.

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact 

Re: [OT] aggressiveness on our mailing lists.

[Luk Claes]

Charles Plessy wrote:

Le Thu, Jul 23, 2009 at 10:30:17PM -0500, Manoj Srivastava a écrit :

While I do not approve of ad hominem attacks on the mailing
 list, I think that we can go over much to the other side: We should not
 be overly genteel about silly ideas.


You twist people words and extrapolate to the silliest interpretation, that you
use as a pretext for adding insults to your messages. I am sick of this, and
unsubscribed from this list.


Twisting people's words is unfortunately very normal behaviour for Manoj.

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [OT] aggressiveness on our mailing lists.

[Luk Claes]

Manoj Srivastava wrote:

On Fri, Jul 24 2009, Luk Claes wrote:


Twisting people's words is unfortunately very normal behaviour for Manoj.


On Fri, Jul 24 2009, Raphael Hertzog wrote:
Or he should post less and take the time to review what he 
writes... (including the pass where he's supposed to remove

the unneeded agressivity)


This is hilarious. Two posts attacking the man -- ad hominem --
 and these are the folks talking about being less aggressive.


Twisting again are you?

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [OT] aggressiveness on our mailing lists.

[Luk Claes]

Manoj Srivastava wrote:

On Fri, Jul 24 2009, Luk Claes wrote:


Manoj Srivastava wrote:

On Fri, Jul 24 2009, Luk Claes wrote:


Twisting people's words is unfortunately very normal behaviour for Manoj.

On Fri, Jul 24 2009, Raphael Hertzog wrote:

Or he should post less and take the time to review what he
writes... (including the pass where he's supposed to remove
the unneeded agressivity)

This is hilarious. Two posts attacking the man -- ad hominem --
 and these are the folks talking about being less aggressive.

Twisting again are you?


Only if you call quoting what you say twisting your words.


You put it in a different context to match better what you wanted to 
bring across, I name that twisting, though you're still free to call 
that whatever you like.



This is a concept funny in itself.


You ridiculously trying to defend yourself from twisting words while 
continuing to do it in more subtle ways, sure.


Cheers

Luk


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: DAM and NEW queues processing

[Luk Claes]

Lucas Nussbaum wrote:

On 23/06/09 at 16:18 +0200, Ana Guerrero wrote:

NM process:


 - the NM process could be reduced to 5 to 10 questions choosen by the
   AM amongst the 50+ questions currently in the NM templates, 

...

This *might* work if we solve what in my opinion is the main problem here: 
DDs advocating too early. Actually, if the applicants are ready, they will 
have few problems with their processes in the current format (it is normal 
do not know a few questions, nobody knows everything) and it will be result 
in a reduced exchange of emails: less time for AM, FD and DAM.


And we already have DM to avoid the frustration to not being able to upload
trivial packaging changes. 
Now DM has been here for some time, we might consider improve it, but that is

another issues.


I've been advocating people too early (i.e, I've advocated people so
that they could start NM, while in the meantime, I wouldn't have
advocated them for DM). The reason is that the unassigned applicants
list is huge, so, when considering whether you should advocate someone
or not, you basically have to wonder whether the person will behave well
when he gets an AM in 6 months.

It all depends on the meaning of the advocacy. Does it mean I believe
that X is ready to be a DD now (which would be stupid, since X will
wait at least a year before becoming a DD) or I believe that X is ready
to start the NM process.


Is this not the main reason it keeps happening: everyone thinks they 
should advocate early while that makes the process long for everyone?


I always understood advocating as I'm confident that X will be a good DD 
(both socially as well as technically).


Cheers

Luk


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Draft vote on constitutional issues

[Luk Claes]

Matthew Johnson wrote:
 On Sun May 10 18:34, Luk Claes wrote:
 3. Option X overrides a foundation document, possibly temporarily (?)
 Not possible. You can only override a decision and amending a foundation
 document is the previous option.
 
 What would you call the vote to ship non-free software in etch? Because
 that is what I mean. We are agreeing to do something which the
 foundation document said we would not, but only for a certain period of
 time (etch).

Well, that's rather incomplete as that means that we are shipping
non-free software in main before etch (in experimental, unstable,
testing), in stable (etch) and probably still after etch till it gets
fixed in experimental, unstable, testing. As it is very strange
formulated for what is really happening and it's ultimately the
maintainer and ftp-master's decision to ship it like that, I don't see
why you want to vote on it? It's not like you override the decision of
the maintainer/ftp-master, but rather acknowledge it.

 I don't _care_ what you call that, I call it a temporary override of a
 foundation document.

Please do read the constitution and don't use these terms if you mean
something else.

A temporary conflict with the foundation document for some packages is
only as temporary as the issues getting fixed. I don't see why there
needs to be a vote for a release as the release is only showing to the
broad audience what was already there all the time and not getting
fixed. When the Release Team decides to tag an issue release-ignore,
it does that when there are clear signs that the issues are being worked
on, but it being unrealistic to get fixed in time for the release. If it
would get fixed in time, the Release Team would of course still try to
include the fix in the release.

You could of course argue that the maintainer and ftp-master were not
respecting a foundation document, though in that case you should
override their decision IMHO.

 4. Option X is declared not to be in conflict with a foundation document (?)
 5. Option X conflicts with a foundation document, but explicitly doesn't
want to override the FD (?)
 6. Option X would appear that it might contradict an FD, but doesn't say
which of 2-5 it is.
 4-6 are normal position statements AFAICS.
 
 That's certainly a point of view, but not the one every holds.

Yes, though please give some clear indications in the constitution on
how you can interpret it differently as I don't see them, TIA.

 1. and 2. are what we wish every vote were like.

 3. is things like we agree that the kernel modules aren't free, but
 we'll ship them anyway or we'll ship them for this release.
 This one would be in 4-6 AFAICS.
 
 Why do you say that. This is definitely contrary to a foundation
 document (if you don't think it is, please pick a different example
 which is) and we want it to be binding. Ergo, not a position statement.

Well, there is no such category in the constitution. If you do want to
include it, you'd better prepare a vote to include it IMHO.

 5. is something like Allow Lenny to release with  firmware blobs.  This
 does not override the DFSG, which I don't think makes any sense.
 One cannot override a document.
 
 See above. I'm not interested in arguing about terminology, I think it's
 clear what I mean by 'override a document', please suggest alternative
 phrasing if you prefer.

It's you who are using the terminology in a different context and
meaning than what is used in the constitution AFAICS.

 As the DFSG is a document that state our guidelines of what is free, I
 don't see how it would get changed even temporary when we would have a
 vote on 'Allow Lenny to release with firmware blobs'.
 
 OK, if you prefer it changes the SC to allow exceptions which don't
 conform to the DFSG. I'm sorry if I'm not being clear here,  I was
 hoping people would get the gist of what I meant, but I'll try and be
 more pedantic in future.

Nope, it's telling that firmware blobs are not covered by the DFSG for
Lenny. It can't both conflict and not be covered by the same document
AFAICS?

 Now, I understand you don't like the use of 'override' when describing
 option 3, I'm happy to describe it as something else, but _I_ think that
 the constitution at the moment requires 3:1 majority for this sort of
 vote. I know other people are equally certain it does not, but this is
 why I want to clarify it one way or another, to avoid future upset.
 Well, what I propose to do is to read the constitution and use its terms
 instead, which would ease these discussions a lot AFAICS.
 
 That would be great, unfortunately there seems to be a bit of a grey
 area here, hence the problems.

Only because people don't seem to read the constitution and follow some
ideas from what's included in the constitution that I don't find written
in it. Please do point me to the relevant sections of the constitution
if you find them, TIA.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org

Re: Draft vote on constitutional issues

[Luk Claes]

Thomas Bushnell BSG wrote:
 On Tue, 2009-05-12 at 20:09 +0200, Luk Claes wrote:
 Either Social Contract section one and the DFSG prohibit the
 distribution of a non-free blob in the release, or they do not.
 This 'in the release' is bogus, I guess you mean in 'main'?
 
 Debian is only free software.  Non-free is distributed by Debian, but it
 is not part of Debian.  By in the release I mean the released versions
 of Debian (which includes only main and optional).  

We don't have a component called optional, nor do we only distribute our
releases.

 If they prohibit it, then it is an override to distribute
 notwithstanding the prohibition.

 If they do not prohibit it, then no resolution is necessary.

 You seem to say an inconsistent thing: that they do prohibit it, and we
 can avoid that prohibition by calling it a practical consensus instead
 of an override.  Surely, however, it is the effect that matters, and
 not the label you give it.
 Well that's the thing with goals, they are not strict rules, but we do
 try to reach them (though not at all cost) ...
 
 Perhaps you should propose an amendment to our Social Contract, which
 speaks not of goals and aims, but of promises.  Indeed, the point behind
 the language of *contract* is that these are not merely goals, but firm
 promises.  You presumably would support an amendment to section one of
 the social contract, changing it from a promise into a statement of a
 goal.  But such an amendment has not yet been passed, and your clear
 declaration that you are not willing abide by the social contract as
 written is troubling.

It's already included in there: Debian will remain 100% free. As we're
only improving, I don't see how it's not a goal as we were never 100%
free, we are not 100% free and probably will never be 100% free.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Draft vote on constitutional issues

[Luk Claes]

Thomas Bushnell BSG wrote:
 On Tue, 2009-05-12 at 17:06 +0200, Wouter Verhelst wrote:
 I think this is the core of the disagreement. I do not call it a
 temporary override of a foundation document; I call it a temporary
 practical consensus between the needs of our users and the needs of
 the free software community.
 
 I don't understand.
 
 Either Social Contract section one and the DFSG prohibit the
 distribution of a non-free blob in the release, or they do not.

This 'in the release' is bogus, I guess you mean in 'main'?

 If they prohibit it, then it is an override to distribute
 notwithstanding the prohibition.

 If they do not prohibit it, then no resolution is necessary.
 
 You seem to say an inconsistent thing: that they do prohibit it, and we
 can avoid that prohibition by calling it a practical consensus instead
 of an override.  Surely, however, it is the effect that matters, and
 not the label you give it.

Well that's the thing with goals, they are not strict rules, but we do
try to reach them (though not at all cost) ...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Draft vote on constitutional issues

[Luk Claes]

Matthew Johnson wrote:
 On Sat May 02 00:32, Luk Claes wrote:

 PS: There is a reason why I send the mail about the definitions of the 
 terms even if Kurt as well as you seem to ignore it.
 
 I posted a while back citing several types of vote option [0], with some
 examlpes. I'm maybe not using the terminology you'd like, but I hope
 you can see what I mean. Here they are again:
 
 1. Option X conforms to a foundation document (clearly not 3:1)
 2. Option X changes a foundation document (clearly 3:1)
 3. Option X overrides a foundation document, possibly temporarily (?)

Not possible. You can only override a decision and amending a foundation
document is the previous option.

 4. Option X is declared not to be in conflict with a foundation document (?)
 5. Option X conflicts with a foundation document, but explicitly doesn't
want to override the FD (?)
 6. Option X would appear that it might contradict an FD, but doesn't say
which of 2-5 it is.

4-6 are normal position statements AFAICS.

 1. and 2. are what we wish every vote were like.
 
 3. is things like we agree that the kernel modules aren't free, but
 we'll ship them anyway or we'll ship them for this release.

This one would be in 4-6 AFAICS.

 4. is things like we think that firmware can be its own source, so
 shipping blobs is fine
 
 5. is something like Allow Lenny to release with  firmware blobs.  This
 does not override the DFSG, which I don't think makes any sense.

One cannot override a document.

As the DFSG is a document that state our guidelines of what is free, I
don't see how it would get changed even temporary when we would have a
vote on 'Allow Lenny to release with firmware blobs'.

 Now, I understand you don't like the use of 'override' when describing
 option 3, I'm happy to describe it as something else, but _I_ think that
 the constitution at the moment requires 3:1 majority for this sort of
 vote. I know other people are equally certain it does not, but this is
 why I want to clarify it one way or another, to avoid future upset.

Well, what I propose to do is to read the constitution and use its terms
instead, which would ease these discussions a lot AFAICS.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Draft vote on constitutional issues

[Luk Claes]

Matthew Johnson wrote:

As suggested [0] I think we should clarify these issues before any other
votes. As such I'd like to suggest a draft for the vote.

I'm proposing several options for a couple of reasons. Several of them I
would rank above further discussion, but I also want to make sure that
there is an option for everyone on here. I'm trying to clarify our
current situation. Resolving the vote without such a clarification does
not help this. You should all see an option below which you think is the
Status quo, but I'm certain that not everyone agrees with which one, so,
if you want the status quo, please vote for the option which describes
it, not for further discussion. If you _can't_ see what you think is the
status quo below, now is the time to point this out. (note, I'm not
formally proposing this as a vote yet, but would like to fairly soon)


I think trying to propose many options together is very wrong as you are 
very probably not objective for all the options nor will you be able to 
word it properly for the ones that do care about an option you don't 
really care about.


The other risk you take by proposing many options at once is to mix 
unrelated things in the same vote IMHO.



Option 1 - No Supermajority

We do not believe that we should require anything more than a simple
majority for any changes to the constitution or foundation documents.

   - replace Constitution 4.1 point 2 with Amend this constitution
   - in Constitution 4.1 point 5, point 3, remove A Foundation Document
  requires a 3:1 majority for its supersession. 

This option amends the constitution and hence requires a 3:1 majority.


I would be very surprised if this option would get enough seconds if you 
would propose it.



Option 2 - All conflicting GR options require a Supermajority

We believe that any GR which has an option which overrides some or all
of a foundation document, even temporarily, implicitly modifies it to
contain this exception and thus requires a 3:1 majority


This all boils down to the definition of override which I tried to state 
in the other thread. If you go by my definition, this is really a 
non-option IMHO.



Option 4 - Balancing issues between users and freedom

We believe that there will be cases where the project must balance
between our priorities of our users and of Debian remaining 100% free.
Project decisions which make such a balance do not require a
Supermajority, but all others do

   - Add Social Contract 6:

   6. Works that our not 100% free but are required by our users.

   We acknowledge that there may be occasions where it is not possible
   to place the interests of our users first with purely free software.
   As such, we may on occasion provide software which does not meet our
   normal standards of freedom if it is necessary in the interests of
   our users. In all cases we will work towards a free system where such
   compromises are not necessary

   - replace Constitution 4.1 point 5 with Issue, supersede,
  withdraw, amend and add exceptions to nontechnical policy 
  documents and statements.
   - in Constitution 4.1 point 5 add point 4: All GR options which 
  provide exceptions to a foundation document (temporary or

  permanent) implicitly modify the document to contain that
  exception and require a 3:1 majority


Same remark as above.


This option amends the constitution and social contract and hence
requires a 3:1 majority.


This option does not look related to supermajority requirements to me.


Option 5 - Temporary overrides without Supermajority

We believe that GRs may temporarily override foundation documents
without requiring a 3:1 majority. Resolutions which are in conflict with
a foundation document and make a permanent change must modify the
foundation document and require a 3:1 majority

   - replace Constitution 4.1 point 5 with Issue, supersede,
  withdraw, amend and add exceptions to nontechnical policy 
  documents and statements.
   - in Constitution 4.1 point 5 add point 4: All GR options which 
  provide permanent exceptions to a foundation document implicitly

  modify the document to contain that exception and require
  a 3:1 majority
   - in Constitution 4.1 point 5 add point 5: All GR options which 
  provide temporary exceptions to a foundation document only require

  a simple majority to pass.

This option amends the constitution and hence requires a 3:1 majority.


This boils down to the definition of override again...


Option 6 - Votes may modify or be a position statement, but must be explicit

We believe that any vote which overrides a Foundation Document modifies
it to contain that exception and must explicitly say so in the proposal
before the vote proceeds.  Such overrides require a 3:1 majority.


This is already the case AFAICS


A GR which explicitly states that it does not override a Foundation
Document but instead offers a project interpretation of that Foundation

Re: Twittering on planet.d.o?

[Luk Claes]

Frans Pop wrote:
 (Luk BCCed to make sure he sees the thread.)

No need, I read -project.

 It appears that today either Luk himself or someone else added a Status 
 feed to planet.d.o with one-liner info messages about what Luk's up to.

I did that.

 These messages have already started to annoy me as
 a) there are relatively a lot of them

There are only a few per day maximum from me. If there were more that
reached you today it's probably because it contained the whole feed up
to now.

 b) they don't really provide any information, or at least no context
 c) they are very simply not blog posts

They are indeed no genuine blog posts, it are microblogging posts.

 Although sending out such messages may be interesting to some, I also do 
 not think they can be a replacement for proper announcements of changes 
 in services or whatever. We have proper, official communication channels 
 for that. (But that may not be the intention anyway.)

They are not meant as proper announcements as there should not be any
proper announcement on a blog (unless it's a copy of something on the
lists) IMHO.

 Although I don't use Twitter myself, I understand that's a service that 
 has been set up for such messages.

I don't use Twitter btw as that is closed and the company behind it
decides whatever it wants, I use an open variant called identi.ca

 Personally I'd like to see planet.d.o remain a pure blog aggregator. If 
 people want to start a Debian twit service/channel/whatever, that's of 
 course fine, but let's not mix dissimilar things in one service.

Well I don't intend to tweet extensively, but only as a replacement for
real blogging as I'm not up to writing long blog posts.

 Luk: what do you think yourself?

I think having a very limited amount of tweets from people that do not
write long blog posts is ok, though if it's not appreciated I'll remove
my feed.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Draft for lenny release announcement

[Luk Claes]

Alexander Reichle-Schmehl wrote:

===

h2Dedication/h2

pDebian GNU/Linux 5.0 qLenny/q to Thiemo Seufer, a Debian
Developer who
died on December 26th, 2008 in a tragic car accident.



There seems to be a part of the sentence missing...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Developer Status

[Luk Claes]

Raphael Geissert wrote:
 Joerg Jaspert wrote:
 On 11547 March 1977, Raphael Geissert wrote:
 Debian Maintainer
 -
 They are allowed to upload their own (source) package. The allowed list
 of (source) packages to upload can be edited by any member of the NM
 committee[NMC], who will do a package check before they add new packages
 to the DM's list.
 I believe everything is ok up to this point: why does the NMC need to
 review the packages? I mean: has there been any problem with the current way
 DMs are allowed to upload? can't the project trust in DDs as to what
 packages can DMs upload?
 We do trust DDs - everyone can become a member of the NM Committee,
 you just have to do a little AM work.
 
 ...you just have to do a /little/ extra work I would say. I don't think 
 that's
 the right way to do it.
 
 If a reviewing team is really needed it should be built from the QA side, 
 not
 from the management/NM side. Which would thereby have to drop the AM work
 requirement and instead put some other sort of requirement, if needed/wanted.

The NM committee is composed of AMs which already completed doing a
review process succesfully in the last couple of months. So I think it's
only logical to ask them to review. I think a (prospective) DM is better
served by such a (hopefully) proper review than a possibly less good
review of a random DD.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Developer Status

[Luk Claes]

Raphael Geissert wrote:
 2008/10/23 Luk Claes [EMAIL PROTECTED]:
 Raphael Geissert wrote:
 Joerg Jaspert wrote:
 On 11547 March 1977, Raphael Geissert wrote:
 Debian Maintainer
 -
 They are allowed to upload their own (source) package. The allowed list
 of (source) packages to upload can be edited by any member of the NM
 committee[NMC], who will do a package check before they add new packages
 to the DM's list.
 I believe everything is ok up to this point: why does the NMC need to
 review the packages? I mean: has there been any problem with the current 
 way
 DMs are allowed to upload? can't the project trust in DDs as to what
 packages can DMs upload?
 We do trust DDs - everyone can become a member of the NM Committee,
 you just have to do a little AM work.
 ...you just have to do a /little/ extra work I would say. I don't think 
 that's
 the right way to do it.

 If a reviewing team is really needed it should be built from the QA side, 
 not
 from the management/NM side. Which would thereby have to drop the AM work
 requirement and instead put some other sort of requirement, if 
 needed/wanted.
 The NM committee is composed of AMs which already completed doing a
 review process succesfully in the last couple of months. So I think it's
 only logical to ask them to review. I think a (prospective) DM is better
 served by such a (hopefully) proper review than a possibly less good
 review of a random DD.
 
 Right, but do the members of the NMC cover the wide variety of
 programming languages?
 or what kind of review are they going to do? just packaging stuff? if
 it is just the latter it would be much easier and faster to send a RFC
 to -mentors and let people scream out loud.
 
 And please note that I said QA side, with which I didn't mean to
 refer to the QA group, but to a variety of people who know what to
 look at and how to do it; not a random AM who happens to have already
 completed doing a review process successfully (which actually doesn't
 guarantee that the AM is competent enough, as the usual NM process
 consists on sending the templates and later reviewing the responses).

You're very wrong here. The AM's job is to review if someone would be
capable of being a good Debian Developer. Reviewing responses to the
templates is *not* the main job. Have the prospective DD learn things;
get the prospective DD think and search before answering; and reviewing
actual tasks and skills by reviewing the prospective DD's packages next
to possible other 'tasks' takes most of the time.

It's not at all about a questionaire where you only have to tick the
right answers because that would defeat the spirit of the process. For
many applicants it takes a long time because they think it's just a
questionaire...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: package maintainer contact lists and their posting policy

[Luk Claes]

Jonas Meurer wrote:
 Hello,
 
 I discovered that [EMAIL PROTECTED] rejects any
 mails from non-subscribers even though the address is listed as
 maintainers contact address for grub packages in Debian. This topic has
 already been discussed in the past, and to my knowledge it has been
 agreed that the described situation is not an option.

Right.

 I discussed the issue with Robert Millan and others in #debian-devel on
 IRC. Unfortunately Robert seems rather ignorant about this issue. 
 
 As I think that the current situation is not acceptable, I suggest that
 alioth admins overwrite the current posting policy for pkg-grub-devel.

Wrong, alioth admins should make sure the default is sane, but they
shouldn't overwrite current policies unless requested/acked by the
listmaster or project admin IMHO.

If we are not able to contact the maintainer via the address mentioned
in the Maintainer field in unstable, we normally open a bug to change
the address in the next address as changing it is not possible without
an upload. If the maintainer does not (intend to) change the Maintainer
field in a reasonable timeframe while it lists an address that is not
usable (enough), I would argue that the package should be orphaned.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Becoming a new contributor

[Luk Claes]

MJ Ray wrote:
 [EMAIL PROTECTED] wrote:
 As a non-developer you can:
 - maintain packages through a sponsor
 
 Prepare the package as if you were a debian developer (see the various
 packaging guides on http://www.debian.org/devel/ for details - start
 with an Intent To Package bug report), then either approach a sponsor
 (my offer is http://people.debian.org/~mjr/sponsor-apogi.html if it's
 relevant) or post an RFS (Request for Sponsor) message to
 debian-newmaint until your package is picked up.

Please do have a look at http://www.debian.org/devel/wnpp before
packaging a new piece of software.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Release Update: freeze, architecture requalification

[Luk Claes]

Clint Adams wrote:
 On Sat, Jul 19, 2008 at 05:53:20PM +0200, Luk Claes wrote:
 suites. Well we don't really want to special case i386, but currently it
 
 Then why do you?

Because it's not up to us to decide how buildd maintainers take care of
their job.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: my treatment in #debian

[Luk Claes]

Rahul Jain wrote:
 As a regular in #debian (on OPN/freenode) for over 5 years and a
 contributor to the debian project, one would expect that I would be
 treated slightly better by the ops than random newbies.

I guess if you're such a frequent user of the channel you do know that
there is #debian on irc.debian.org (OFTC)?

I guess if you have regular problems with stew on that channel you
informed at least all the channel ops and maybe also the staff of the
Freenode network?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: how to do an NMU

[Luk Claes]

Julien Cristau wrote:
 On Sun, Jun  1, 2008 at 00:42:57 +0200, Stefano Zacchiroli wrote:
 
 On Sat, May 31, 2008 at 07:18:14PM +0200, Frans Pop wrote:
 Because bugs may also have been (or seem to have been overlooked). The 
 risk here is that the person doing the NMU thinks oh, that's an old 
 issue and the fix seems so simple and goes ahead and NMUs it, while 
 there may be very valid reasons for not fixing it (or at least not with 
 _that_ fix).
 Then they should have been mentioned in the bug log, shouldn't they?

 ... and IME they usually *are* for active teams, so I'm not sure I can
 buy your argument. I rather conclude that active teams won't risk
 anything with the procedure which is being proposed, while not active
 teams will see NMUs, as they should.

 That's probably true for RC bugs, but I can't swear all bugs with a
 patch in my packages have a maintainer comment.  This DEP wants to
 extend NMUs to all bug severities.

NMUs are already possible for all bug severities. I don't know why some
people think they are not?

Though these bugs don't fall in the 0-day NMU rules, so the usual NMU
rules should be followed which includes some steps to contact the
maintainer after the bug was filed and before the NMU is uploaded (to
the DELAYED queue).

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: The giving some time to the maintainer rule

[Luk Claes]

Lucas Nussbaum wrote:
 On 30/05/08 at 18:24 -0700, Steve Langasek wrote:
 On Fri, May 30, 2008 at 11:49:14AM +0200, Lucas Nussbaum wrote:
 Now, what we don't agree on:
  - I think that giving some time should only be very strongly
recommended, but not mandatory.
  - You think that giving some time should be mandatory.
 I think that our opinions are basically the same. The difference is that
 you want to write something in stone, while I prefer not to impose rules
 where it's not necessary, because:
 This is begging the question.  Experience tells me that the sort of rules
 under discussion *are* necessary.
 
 You are still talking about the rule The maintainer *MUST* give some
 time to react before uploading the NMU, right?
 
 - If you make it mandatory, then you have to provide a workaround for
   cases where it's just not possible to wait. And you also have to list
   those cases.
 And, so?  That's what we have today.  What's the problem with this that
 you're trying to fix?
 
 No, that's not what we have today. What we have today is the release
 team deciding that it has authority to change the NMU rules, to allow
 0-day NMUs for bugs older than 7 days old.
 - Does the RT really have authority ?

According to the Developer's Reference at least the release manager has...

 - 0-day means no need to give some time to the maintainer.

Wrong: 0-day means no need to give the maintainer *extra* time

 You uploaded a lot of such NMUs yourself, sometimes on packages with an
 active maintainer, without even providing a patch on the BTS previously.

Only where the maintainer didn't react yet in the time (mostly about 7
days) given...

 You realize that this discussion about the NMUers must give some time
 to the maintainer-rule also affects the current 0-day NMU policy?

It does already...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: how to do an NMU

[Luk Claes]

Frans Pop wrote:
 On Saturday 31 May 2008, Lucas Nussbaum wrote:
 I propose to add NMUs are usually not appropriate for
 team-maintained packages. Consider sending a patch to the BTS
 instead. to the bullet list.
 It really depends on the team. There are small teams where all members
 might become unresponsive at the same time. I don't think that we
 should special-case this.
 
 Yes, it probably does depend on the team. But several people have raised 
 this point now, which probably means that it _is_ a real concern. When 
 are you (the proposers of this DEP) going to start listening to your 
 peers instead of dismissing their concerns?
 
 A lot of packages are team-maintained not only because it is more fun to 
 work together, but also because those packages (or groups of packages) 
 are more complex, or have interactions that may not be obvious at first 
 glance. Which means that there may well be a bigger likelyhood that an 
 NMU will break things.
 
 All members of a team becoming unresponsive is possible, agreed.
 But it is a hell of a lot less likely than at least one member of the 
 team being able to respond to urgently needed changes if appropriately 
 notified.

So, why should there be any special treatment as they are more likely to
respond early anyway? Or are you questioning normal NMU intents, RC/RG
bugs and d-d-a announcements as appropriate notifications?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: how to do an NMU

[Luk Claes]

Frans Pop wrote:
 On Saturday 31 May 2008, Luk Claes wrote:
 All members of a team becoming unresponsive is possible, agreed.
 But it is a hell of a lot less likely than at least one member of
 the team being able to respond to urgently needed changes if
 appropriately notified.
 So, why should there be any special treatment as they are more likely
 to respond early anyway? Or are you questioning normal NMU intents,
 RC/RG bugs and d-d-a announcements as appropriate notifications?
 
 Because bugs may also have been (or seem to have been overlooked). The 
 risk here is that the person doing the NMU thinks oh, that's an old 
 issue and the fix seems so simple and goes ahead and NMUs it, while 
 there may be very valid reasons for not fixing it (or at least not with 
 _that_ fix).
 
 A follow-up to the bug report with just hey, this issue seems to be 
 forgotten, could someone please take another look as it seems important 
 would then be a lot more appropriate and take a lot less time all around 
 then preparing the patch, uploading it to delayed and then getting to 
 hear sorry, this is not good, please remove your NMU from the queue.
 
 Large teams also often have large numbers of issues to deal with. Which 
 does mean that (unfortunately) issues may be missed or forgotten about.
 Or maybe it is something that is normally taken care of by one particular 
 team member and other team members ignored the issue for that reason but 
 are capable of picking it up if prompted to do so.
 
 There is just no reason to bypass the maintainers if they are otherwise 
 active. In such cases just talking to the maintainers (through the BTS or 
 otherwise) is just a lot more appropriate and effective, at least as a 
 first step, than going straight to an NMU - even with the safeguards 
 incorporated in the DEP.

Ok, though I'd rather have a (strong) recommendation to prod maintainers
(in a team or not), then to special case teams...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Luk Claes]

Bas Wijnen wrote:
 Hi,

Hi

 === nmudiff improvements

Can you please just file a bug against devscripts and leave this out of
the DEP?

 = the nmudiff patch is not controversial. Why include it in the DEP?
 
 * If the DEP isn't agreed upon, the patch has no reason to be
   included in devscripts.

It also has no reason to not be included AFAICS.

 * It gives the opportunity to discuss the formulation at the same
   time as the rest of the DEP.
 * DEPs are supposed to allow changes in several parts of Debian at
   the same time. That's a good test case :-) 

Ok, though I didn't see much discussion about it...

 = Is that really the best place to discuss stable, security and QA
 uploads, and binNMUs?

Yes, though the versioning of security uploads will probably be used and
decided by the Security Teams and the versioning of stable uploads will
probably be used and decided by the Stable Release Team anyway... Though
I won't oppose guidelines for the versioning.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: who should be allowed to do QA uploads ?

[Luk Claes]

Ralf Treinen wrote:
 On Sun, May 25, 2008 at 08:50:45AM +0200, Bas Wijnen wrote:
 
  * QA upload.

 If you want to do an NMU, and it seems that the maintainer is not
 active, it is wise to check if the package is orphaned. When doing the
 first QA upload to an orphaned package, the maintainer should be set to
 Debian QA Group  [EMAIL PROTECTED] . Orphaned packages which did
 not have a QA upload yet still have their old maintainer set. There is a
 list of them at http://qa.debian.org/orphaned.html.
 
 Just a thought:
 
 IMHO it would make sense to allow teams other than QA to do QA uploads
 for orphaned packages. Teams focused on a particular toolset (OCaml, perl,
 TeX, kde, gnome, ...) may be better motivated to keep up a minimal
 quality standard for packages using that toolset, and they may be better
 skilled to do this.

Either it's adopted or it's not IMHO. Long time orphaned packages are
not worth shipping and should be removed altogether IMHO. If no one
wants to take care of maintaining it, the package is either not
important or should get a replacement that someone thinks is worth
maintaining...

 Sure, every dd can do a QA upload, the advantage of having another team
 being listed as maintainer would be that this team would receive all the
 bug reports. The team might choose not to adopt the package in order to
 make clear that the package is still orphaned.

A team could adopt the package and request for an adopter (RFA). The
difference is that the package would be maintained in the mean time...

 I do not see how to accomplish this without adding a new field to the
 control file, however, since currently we use maintainer=QA in order to
 indicate that a package is orphaned. 

No, the indication that a package is orphaned is the bug against wnpp.
Changing the maintainer is just to make it more obvious for everyone
involved as the previous maintainer should not be contacted anymore.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: violence - take 2

[Luk Claes]

Patrick Frank wrote:
 Before anybody even considers using public defacements like
 paddy is a troll, lets hunt him
 you should be aware of context.

A part of the context is that the OFTC IRC-network doesn't want you on
their network... Even if Debian has strong links with the IRC network,
you are complaining in the wrong forum...

 The context is certain Debian Developers playing the cabal game,
 not only recently, but starting 3-4 years ago.
 
 The situation that started the hunt for the paddy was my public
 complaints on #debian.de on irc.freenode.net about the social
 violence that was present. This social violence was targeted at
 the most vulnerable and most helpless people: the newbies

You are talking about a different IRC network over here...

 My complaints to the Freenode Staff Team were not heard, because
 Rob Levin himself was under fire by those people who founded
 irc.oftc.net as so called anti-lilo network. Details to prove
 my claims can be delivered if that is required.

The OFTC network is not anti Freenode, get your facts straight...

 The excuse of the Freenode Staff Team for not taking action
 against the violent behaviour of several Debian Developers was
 the dull statement This is IRC. Deal with it. Staff never 
 interfers with channel matters.

You're again talking about a different IRC network...

 As this problem was never resolved properly a lot of people had
 no other choice than going violent themselves.

Doing wrong because others do wrong, doesn't make right...

 Since my claims are still standing after 3-4 years that some
 people have to fix their anti social personality problems in
 a different way than abusing other people on IRC, the addressed
 Debian Developers see the need to play the cabal game.

You having problems with some individuals doesn't make it a Debian
problem. You wanting to escalate it to 2 IRC networks and the Debian
project tells more about yourself than about the individuals you claim
to be anti social...

 Defacements and playing the cabal game due to the inability to
 fix ego problems.

Accusations like this are not going to help anything AFAIK...

 Its the choice of every single Debian Developer to join this
 game or to help fix social problems.
 
 Your call.

Is it, it looks more like it's your call on how you want to interact
with your so called cabal...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: No buildd redundancy for alpha/mips/mipsel

[Luk Claes]

On Thu, Nov 29, 2007 at 12:01:54PM +0100, Frans Pop wrote:
 On Thursday 29 November 2007, Aurelien Jarno wrote:
  James Andrewartha a écrit :
   Not a buildd, but [1] notes that there's an alpha porting machine
   waiting for more than a year to be set up by DSA. I don't know if
   there's an RT ticket, but there is a bug [2] about this, which was
   closed this week, although it looks like by accident.
 
  This machine has been setup, it is called albeniz.debian.org, that's why
  the bug has been closed.
 
 Then it's not yet been activated by ftp-masters as it's not listed on [1].
 Guess that will happen soon.

Why would a porter machine be listed on buildd?

Cheers

Luk

 Good news!
 
 [1]http://buildd.debian.org/~jeroen/status/architecture.php?suite=unstablea=alpha

Re: No buildd redundancy for alpha/mips/mipsel

[Luk Claes]

On Wed, Nov 28, 2007 at 08:32:40AM +0100, Frans Pop wrote:
 http://release.debian.org/etch_arch_qualify.html lists that alpha, mips and 
 mipsel a having buildd redundancy, but that does not seem to match reality 
 as both only have a single buildd (alpha: goetz; mips: ball; mipsel: rem).

Hmm, etch is already released. You might be right that it's not done for
lenny yet. Though that's mainly because most of the architecture pages
are incomplete after many requests to complete them...

I think you'd better look at db.debian.org/machines.cgi to have an idea
of the current status...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bits from the DPL: DSA and a few other things

[Luk Claes]

Frans Pop wrote:
 On Saturday 03 November 2007, Sam Hocevar wrote:
 \o/ DSA++ \o/

 Your announcement is nice, and I'm sure it took a lot of hard work to get 
 this far, but I have serious doubts that it is enough. Some elaboration on 
 the way forward, including a word on that other team that is always the 
 subject of controversy and complaints, would be very much appreciated.

Rome was not built on one day... everyone knows this is not the end, but
it's at least a start to get things rolling again...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: What do Open Source Projects need?

[Luk Claes]

Patrick Frank wrote:
On 6/4/07, *Steve Langasek* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:



 Are you a paid troll, or do you do this on a volunteer basis?


If you aim to be humorous I find the situation of Sven Luther
not suitable for that.

In case this is your way of dealing with with my opinion,
then I have to add you to the list of debian developers who
are lacking empathy for other people and intuition for conflict
situations.


It's an honest question to someone who is only trying to put more oil on the 
fire...


Cheers

Luk


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Release Team meets in Germany

[Luk Claes]

Hi

The Debian Release Team will organise a meeting in Germany right before
Debcamp. Andreas Barth, Adeodato Simo, Marc Brockschmidt, Luk Claes and
Martin Zobel Helas will brainstorm about how the Lenny release cycle
can work even better than the Etch release cycle worked. This of course
includes identifying release goals and blockers; and getting a first
idea of the release schedule. You will be able to read more about the
actual content of the meeting in the release update that will be posted
after the meeting :-)

Cheers

Luk Claes
Debian Release Team



signature.asc
Description: OpenPGP digital signature

Re: Programmieren mit Delphi

[Luk Claes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cristaino Ronaldo wrote:
 Meine Damen und Herren,

Hi

The language used on this mailing list is supposed to be English!

 ich habe linux möchte aber wie mit Delphi
 Programmieren welche Programmier sprache ist genau so
 wie Delphi und kann sie bei Linux benutzen währe nett
 wenn ich eine antwort bekommen würde und wo bekomme
 ich das programm her und es sollte kostelos sein danke

Your question is more appropriate on debian-user@lists.debian.org or the
German counterpart if you prefer...

I would try freepascal...

Cheers

Luk
- --
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDUMJ35UTeB5t8Mo0RAoPfAJ9+nbIklllvilo1R1q4pqO6NYc//wCgr/fW
LN5onXDL7vUzzzrr6JQ3HOw=
=uI2S
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: consultant entries that will be removed unless they pong

[Luk Claes]

Michelle Konzack wrote:
 Hello Thomas,

Hi (though Thomas is not the only reader of [EMAIL PROTECTED])

 I have already send two Messages to [EMAIL PROTECTED] in a delay
 of two month and like to know, how long does it take to be included ?

I don't know what happened with your first message, but only your
message of 9 days ago has arrived and will be acted on if we come to it
in FIFO order.

 Over two month to wait is definitiv to much.

Please, come back when it is so much and keep in mind that it was far
more worse due to a huge backlog that is now at about 100 messages.

Cheers

Luk

 Am 2005-07-06 11:00:06, schrieb Thomas Huriaux:
 
Hi,

According to the policy for the consultants page [1], the consultant
must answer e-mails within four weeks. All the not recently
updated/added consultants have been pinged, and we are still waiting for
an answer from the 245 consultants in the attached list.

They will receive a last chance e-mail in the next few days, and will be
removed one week after this mail if they don't answer.

[1] http://www.nl.debian.org/consultants/#policy

Cheers,

-- 
Thomas Huriaux
 
 
 
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: locateing near DDs

[Luk Claes]

Noèl Köthe wrote:
 Hello,

Hi

 I remember a (python?) script on a d.o machine which returns DDs near an
 entered location.
 Anybody can help me with the machine name and maybe the script name?

Yes.

It is on gluck:///home/edward/findnearestdevel.py

Note that it's not up to date though.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Consultant entries that will be removed unless there is an email address provided

[Luk Claes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

According to the new policy for the consultants page which you can find
at the bottom of the consultants page [1] an email address is required
to be listed.

So, attached is the list of the entries that have no email address
included. These entries will be removed from the consultants page in
about 4 weeks from now unless there is an email address provided by then.

Cheers

Luk

[1] http://www.nl.debian.org/consultants/#policy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCl0i65UTeB5t8Mo0RAowGAJ90cz1YMZEa2AFyvn+w76ZGxr1iUgCdG6Nu
HaX7b483ZOMTambnfWPwmqE=
=F4WA
-END PGP SIGNATURE-
# Consultant: Brazil
p
nameKRISTOFFER DA SILVA LAGERSTROuml;M
URL http://www.teknologico.com/;
rates   Only in consult
additional_info teknologico
/p

# Consultant: France
p
nameIvan Kanis
company Links Consulting
address 210 Ave. Roumanille 06410 Biot
phone   +33 678 824 456
URL http://www.kanis.cc/;
rates   250 euro per day
/p

# Consultant: Germany
p
nameMartin Schulze
company InfoCon
address Oldenburg, DEc
phone   +49-441-9738830
fax +49-441-777884
rates   Negotiable.
/p

# Consultant: Germany
p
company Yospot GmbH
address Bayerstr. 33, 80335 Muuml;nchen, Bayern. Germany
phone   +49 89 55292861
URL http://yospot.de/;
rates   Please contact for rates
/p

# Consultant: India
p
nameVIkram Munjal
company Microhat.com Pvt Ltd
address D 104 First floor, lajpat nagar 1, new delhi, INc
phone   +91-11-6918291
phone   +91-11-9811024391
URL http://www.microhat.com;
rates   very economical
/p

# Consultant: Sweden
p
nameRoger Abrahamsson
address Umearing;, SEc
phone   +46-10-6933-939 (preferably evenings)
rates   Depends on work to be done, but generally between $60-$120 US per 
hour.
/p

# Consultant: Switzerland
p
nameMax Moser
company Moser Informatik
address Oberfeldstrasse 120B, 8408 Winterthur, CHc
phone   +41 76 577 23 55
URL http://www.moser-informatik.ch/;
rates   Based on the amount of time
other   Security and wireless
/p

# Consultant: US
p
nameJason Mesker
company Internet Tool amp; Die
address Louisville, KY, USc
phone   +1-502-584-8665
fax +1-502-585-5005
rates   Please contact for rates.
/p

# Consultant: US
p
nameStuart Trusty
company Linux Labs
address 230 Peachtree St NW, Atlanta, GA 30303, USc
phone   +1-800-788-9319
phone   +1-404-577-7747
URL http://www.linuxlabs.com/;
rates   $75 to $250
additional_info stuart_t
/p

# Consultant: US
p
nameJohn Brahy
company NNL Software
address 16942 PCH Suite# 202, Sunset Beach/Los Angeles, California, USc
phone   +1-562-591-1432
URL http://www.brahy.com;
rates   depends on type of work and location
additional_info john_b
/p

# Consultant: US
p
nameJames Nurmi
company Blackbox Consulting Corporation
address Blacksburg, Va. 24060, USc
phone   540-357-1034
URL http://www.blackboxcorporation.com/;
rates   50-250/hr (negotiable)
additional_info james_n
/p

# Consultant: US
p
namealvin Oga
company 1U Ring Inc aka Linux-Consulting.com
address 3777 Stevens Creek Blvd, Santa Clara CA  94501, USc
phone   408-98-Linux
URL http://www.Linux-Consulting.com;
/p

# Consultant: US
p
nameMichaeljohn Clement
address 2351 Jet Wing Dr., Colorado Springs, CO, 80916, USc
phone   (719) 964-7991
URL http://www.mjclement.com/;
rates   $60-$100 USD/hr. depending on the project, the kind of work, and my 
current
 workload. Discounts for: non-profit, educational, or open-source 
projects.
 Free help always available for project planning and simple questions.
additional_info michaeljohn_c
/p

# Consultant: US
p
nameTom King
company Totally Secure Transactions, Inc.
address POB 6531, Villa Park, IL 60181, USc
fax 630-563-9199
phone   630-816-8278
URL http://www.totallysecuresolutions.com/;
rates   varies by job.   Call or fax for a free quotation.
/p

Re: New policy for http://www.debian.org/consultants

[Luk Claes]

Tobias Toedter wrote:
Hi,
Hi Tobias
[...]
So this is my proposal, including all modifications mentioned above:
Policy for Debian's consultants page

1. Mandatory contact information
You must provide a working e-mail address and answer e-mails sent to you
within four weeks at most. You are not allowed to use your official
@debian.org address, as required by the DMUP.
2. Further contact information
If you'd like to provide an URL, please note that you cannot use an
official *.debian.org domain, according to the DMUP.
3. Multiple cities/regions/countries
Every consultant has to choose in what country (only one) they want
to be listed. They can choose only one address to be mentioned, but
they can of course mention additional cities, regions or countries on
their additional info or on their website.
Additions, modifications, and removals of entries
=
If you wish to have your company added to this page, please mail the 
following information to [EMAIL PROTECTED]:
The only (minor) remark I have: I would change the above sentence to 
..., please mail any of the following information to 
[EMAIL PROTECTED]: as not all the fields are required. A different 
wording of the same idea would also be fine by me.

* Name
* Company
* Address
* Phone
* Fax
* Email
* URL
* Rates
* Additional information, if any
A request for an update of the consultant's information should be sent
to [EMAIL PROTECTED], preferably from the e-mail address mentioned
on the consultants page (http://www.debian.org/consultants).
If the above criteria are no longer met, the consultant should receive a
warning message that they are about to be removed from the listing, unless
they fulfill all criteria again. There should be a grace period of four
weeks.
Some parts (or all) of the consultant's information can be removed if
it doesn't comply with this policy anymore or on the maintainers'
discretion.
Cheers
Luk
PS: I included the whole proposal as you didn't Cc [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

QA Hacking @ HEL

[Luk Claes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

This is a cunning plot to increase interest in Quality Assurance among
Debian contributors.

There will be a QA Hacking event preceding Debconf5 [1] in Helsinki.

Those who want to participate, please sign up here:
http://wiki.debian.net/?DebianQAHacking

Don't forget to mention the date when you expect to arrive and what you
will be working on (everything QA [2] related is fine).

See you in HEL!

Luk

PS: For all those who might not be able to attend the QA Hacking in HEL,
please keep in mind that there will also be a mini-QADebconf in
Darmstadt, Germany[3].
PS2: More information about the event will be available at the wiki page
[4].

[1] http://www.debconf.org/debconf5
[2] http://qa.debian.org
[3] http://lists.debian.org/debian-qa/2005/03/msg00102.html
[4] http://wiki.debian.net/?DebianQAHacking
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCU/Sc5UTeB5t8Mo0RAoTPAJ9a+edVx65506VxrulztrLeqR/uZQCeKHBM
SmLQHmYCOp2tC1leXAdYNFk=
=fZ9o
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: New policy for http://www.debian.org/consultants/

[Luk Claes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Vandenabeele wrote:
| On Sun, Jan 16, 2005 at 06:35:49PM +, MJ Ray wrote:
|
|I dislike the nearest big city idea, though. I live and
|work in an area with a small city nearby and then four bigger
|cities surrounding me. Most of my work comes from the nearest
|and furthest of those cities. Grouping by English region or
|county also splits me from them, but customers seem to check
|neighbouring areas. I'm not sure why they only check one city
|listing, but that's what seems to happen, as far as I can tell.
|
|
| I would also have problems with appointing the best city for
| a commercial match. For us (in Belgium), Belgium (the country)
| would be a far better match than any city (and why not use
| stateor US based business ?).
In practice it won't be used if not necessary (there are not much
consultants listed in Belgium).
| So my suggestion is to replace close big city with
| description of your region (and than everyone can choose
| if that is Ottawa or Northern California or Leuven
| or Europe).
Normally it should be possible to find the region when you know the
'close big city', nothing prevents someone to mention more than one
'close big city'.
Cheers
Luk
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFB7BMk5UTeB5t8Mo0RAgj6AJoCYQo/bo07H9dCedtc316mAh5qJACgw1eS
kRClepYd76h/WzYE7jb/ylY=
=fW8Q
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: New policy for http://www.debian.org/consultants/

[Luk Claes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marc Haber wrote:
| On Sun, Jan 16, 2005 at 05:35:32PM +0100, Martin Schulze wrote:
|
|If you want to be listed on www.debian.org it's only fair to require
|that a link to www.debian.org is somewhere on your website as well.
|
|
| You can't force things. If we politely ask people to link back, that's
| ok. But I don't think that it is Debian style to require that.
|
| We do regard licenses with advertising clauses as non-free, don't we?
|
| A lot of companies do promotion for Debian by selling Debian systems
| instead of the major distributions (which are _much_ easier to sell
| since they fit much better into the thoughts of an average suit), or
| they even have people working on payroll for Debian.
Aren't these companies mentioned as partners?
Cheers
Luk
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFB6pqD5UTeB5t8Mo0RAqahAJ9ihNj+5H4yjHUc8LBp9SQNAZ9K3gCffFHh
51cNoU4zOGBBrGbI+6KDO2g=
=R7xn
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]