Re: GR Proposal 2: Declassification of -private

[Martin Schulze]

Margarita Manterola wrote:
> Also, people in the NM queue that have to agree to the Social Contract
> and the DFSG, might be interested in knowing why these documents have
> the shape they have before actually agreeing to them.

Once they leave NM-mode and enter DD-mode they can read the archive
directly on master.

Regards,

Joey

-- 
In the beginning was the word, and the word was content-type: text/plain


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

Re: Reflections about the questions for the candidates

[Martin Schulze]

Frank Küster wrote:
> > * Frank Küster <[EMAIL PROTECTED]> [2006-03-05 18:48]:
> >> I also asked the DPL a question about backups of the development
> >> machines (after the CVS corruption last year) and never got any answer.
> >
> > FWIW, there is a dedicated backup server now.  I don't know any
> > details though (nor why it was never announced).
> 
> So you also don't know what is backed up, and how often?

I've just looked in my archive and have to admit that I indeed
totally forgot to announce this service.  I guess one reason for
the missing announcement is that the machine broke down two weeks
after its installation and the "real" machine proposed for this task
hasn't arrived yet, so we had to go with a backup solution.

The missing announcement is totally my fault, so please don't blame
any DPL for this.  I'll craft a text later to be sent to d-d-a.

Regards,

Joey

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.


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

Re: Question to all candidates about stable point releases

[Martin Schulze]

Jeroen van Wolffelaar wrote:
> On Sat, Mar 04, 2006 at 01:02:20PM +0100, Marc 'HE' Brockschmidt wrote:
> > Though Martin 'Joey' Schulze as stable release manager presents lists of
> > packages that are accepted into the next stable point release on a
> > regular basis, they normally are not released "roughly two months after
> > the last update" (which is the official plan).
> > 
> > Do you know why this doesn't work as planned? What would you do to 
> > make regular point releases possible?
> 
> The biggest part of the reason here that actually doing the releases
> take a fair bit of work to implement with the current infrastructure.

?!?

> Changes are currently being implemented to improve the handling of
> proposed-updates, in order to have those point releases happing more

Could you explain how the changes could help providing a stable update
mor often, when...

> easily. It'll still require an ftp-master to find the time to do it, and
> there can be any number of reasons why nobody finds the time to do it --

...there's still an ftp-master needed and ftp-master is not devoting time
to this task?

> Debian being volunteer-driven as it is. I personally don't think it's a
> huge issue if those point releases are not 100% regular, because for the
> majority it's security updates, but it's still good to have them not too
> far apart, esp. for those updates that are not also already distributed
> via security.debian.org. With significantly less effort required each
> time from the side of ftp-master, I think stable point releases can
> happen more regularly. There can be other ways to improve too, but not

> by direct intervention from the DPL role -- a DPL should not want to
> micro-manage.

That's a great answer.

For the record:

Feb 6th: SRM sends mail to ftp-master trying to negotiate a timeline
Mar 5th: SRM sends another mail since nobody replied to the old one
Mar 5th: aj complains that nobody answered his mail from Feb 22 about
 modificating proposed-updates

Still no word from ftp-master if or when the next stable update can
be implemented.  As usual, the SRM is left in vain and pain.

Regards,

Joey

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.


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

Re: NM process (was: Question to all candidates about the NM process)

[Martin Schulze]

Pierre Habouzit wrote:
> almost 3 monthes to have an AM
> 2 days to pass T&S and P&P
> 5 days more because of a mail of mine, stuck on an SMTP
> exactly 8 monthes (WTF !?!?!) to have then my account created.

Did you notice that things have changed a bit since Joerg is acting
as pre-DAM?

Regards,

Joey

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.

Please always Cc to me when replying to me on the lists.


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

[EMAIL PROTECTED]: Request to be approved as FTP-Master]

[Martin Schulze]

- Forwarded message from Martin Schulze <[EMAIL PROTECTED]> -

Date: Tue, 7 Mar 2006 14:23:33 +0100
From: Martin Schulze <[EMAIL PROTECTED]>
To: XX
Cc: [EMAIL PROTECTED]
Subject: Request to be approved as FTP-Master

I hereby request to be approved as FTP-master with proper permissions
in order to be able to fully prepare and release stable updates.  My
plan is to only touch stable update stuff and not work on any other
corner of ftpmastership.

Regards,

Joey

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.



- End forwarded message -

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.


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

Re: Question to all candidates about stable point releases

[Martin Schulze]

Anthony Towns wrote:
> > > which is to change the queue structure so that uploads don't enter
> > > proposed-updates until approved by the SRM. 
> > I'm wondering why you don't take the more obvious step: add the SRM as
> > an ftp-master for specifically updating stable. 
> 
> I was made an ftp-master for the purpose of maintaining and updating
> testing; so that's certainly an option. ftpmaster work requires a
> different set of skills to release management though, and frankly Joey's
> already got enough stuff to do, without worrying about the nuts and
> bolts of the dak implementation. TTBOMK, he hasn't shown any interest
> in doing that stuff himself, either [0].

I fact I even once wrote that I don't want to become an ftpmaster as
well.  However, releasing stable updates just doesn't work as it
should.  Hence, I've reconsidered and requested to become an
ftpmaster.

It's true that I already work a lot for Debian, often it consumes most
of my day.  That's why I don't want to take over another duty.
However, things just don't work as they should, and being able to
actually implement the stable update on my own will save me from a lot
of frustration, grief and wasted time.  Hence, it will save me time in
the long term.  Therefore I've reconsidered.
  
> > I believe that
> > empowering people to fix things themselves works many times better than
> > reducing the amount of work someone else has to do for them.
> 
> Certainly, and that's exactly what the queue changes should achieve
> -- they give the SRM the power to accept and reject proposed updates
> directly, rather than have to supply a list of them to ftpmaster.

These changes are all great and will help problems in the process, but
they don't help finding an ftpmaster to a) respond to mails from the
SRM, b) assign time to implement the update and c) finally do the
update.  It's window-dressing what you're doing here.

> [0] Indeed, you'll see that every single mail Joey sends out about the
> stable updates includes a disclaimer like "An ftpmaster still has
> to give the final approval for each package since ftpmasters are
> responsible for the archive.  However, I'm trying to make their
> work as easy as possible in the hope to get the next revision out
> properly and without too much hassle."

This disclaimer is in the status because I don't have permissions to
do the update on my own.

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.


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

Re: Question to all candidates about stable point releases

[Martin Schulze]

Anthony Towns wrote:
> *sigh*

Full ack.

> > For the record:
> > Feb 6th: SRM sends mail to ftp-master trying to negotiate a timeline
> > Mar 5th: SRM sends another mail since nobody replied to the old one
> > Mar 5th: aj complains that nobody answered his mail from Feb 22 about
> >  modificating proposed-updates
> 
> So, really the timeline is:
> 
>   Dec 14th, 2.6.8 and 2.4.27 advisories get released, the first
> kernel updates for sarge
>   Dec 17th, 3.1r1 gets released
>   Dec 20th, 3.1r1 gets announced 
> 
>   Jan 20th, DSA-946-1 is released for sudo, breaking the buildds,
> and introducing critical bugs 349196, 349549, 349587, 349729
>   Feb  6th, Joey mails indicating he'd like to release the update
> at the end of Feb (27th/28th) or a little bit later at
> the end of February. "let me know if this is ok for
> you - or if this is not ok for you"
>   Feb 22nd, I mail both Joey (as SRM) and the security team noting the
> queue changes that should happen "with a stable update
> coming up"
>   Mar  3rd, Jeroen mails the security team and Bdale regarding whether
> the patch proposed in 349196 is satisfactory [0]
>   Mar  4th, I mail both Joey and the security team again, having not
> received a response
>   Mar  5th, Joey complains at not hearing anything,
> I ask what about the previous couple of mails,
> Joey tells me I'm not interesting in a stable update
> Joey replies to the other mail
>   Mar  6th, I try to explain why this needs to happen at the same as a
>   stable update
>   Mar  7th, Joey posts to -vote, at which point you can see what's going on

You forgot to mention that I've answered your mail, you've copied
to the security team again.

Could you explain what Jeroen mail have to do with a stable update?

Maybe you want to add mails from other random people to your timeline
as well?

Regards,

Joey

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.


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

Re: Question to all candidates about stable point releases

[Martin Schulze]

Raphael Hertzog wrote:
> On Tue, 07 Mar 2006, Marc Haber wrote:
> > I note that it took you 16 days to reply, and that you seem to want to
> > build a dependency between a change which is not strictly needed to
> > make a point release (if it were needed, why was it possible to
> > release 3.1r1?) and 3.1r2. May I ask why?
> 
> It seemed obvious to me. If uploads to s-p-u are blocked for approval by
> the SRM, this needs to happen just after a point release so that s-p-u is 
> empty

Why does it need to happen directly after r2?
Why can't it happen after r3?
Why is the SRM not informed in February that that queue changes are a 
predependency?
Is this a pre-dependency for the next stable update?

Regards,

Joey

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.


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

Re: Question to all candidates about stable point releases

[Martin Schulze]

Raphael Hertzog wrote:
> On Tue, 07 Mar 2006, Andreas Barth wrote:
> > > It seemed obvious to me. If uploads to s-p-u are blocked for approval by
> > > the SRM, this needs to happen just after a point release so that s-p-u is 
> > > empty
> > > to start with the new system (probably because once a package is in s-p-u,
> > > there's no easy way to remove it and removing manually doesn't make much 
> > > sense).
> > 
> > And what is the problem to introduce that with 3.1r3 or even 3.1r4?
> 
> There's none apart of requiring again work from ftpmasters the next time.
> And since good programmers are lazy ... :-))
> 
> Anwyay it looks like aj is ready to implement it now, so I don't see why
> Joey would refuse that. But the relation between aj and Joey are quite
> complicated [1], and maybe aj is trying to get the required input now by
> postponing the stable release so that Joey has a good reason to reply.

I don't object to these changes.  I'd be stupid if I did.

However, still there's no perspective *when* the next stable update
may happen, and ftpmasters able to implmeent have still not answered.
I also don't remember any ftp master saying that this change is a
pre-dependency (I don't remember aj wrote that, but I'd have to
check to be sure).

Regards,

Joey

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.


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

Re: Question to all candidates about stable point releases

[Martin Schulze]

Marc Haber wrote:
> > > and that you seem to want to
> > > build a dependency between a change which is not strictly needed to
> > > make a point release (if it were needed, why was it possible to
> > > release 3.1r1?) and 3.1r2. May I ask why?
> > 
> > The dependency is the other way -- that change needs to happen immediately
> > after a stable update, and this is the first one that's suitable. The
> > reason I think it's a good idea is that it means most of the work can be
> > done by the stable release manager directly during the months in between
> > updates, rather than as part of the update itself.
> 
> Did you talk to the stable release manager before trying to reduce his
> work load?

I remember talking to $ftpmaster 1-2 years ago about being able to
approve package to go into proposed-updates btw.  I think that I
spoke with James though, not with aj - again: not sure about who.

Regards,

Joey

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.


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

Re: Questions for Jeroen van Wolffelaar and Andreas Schuldei

[Martin Schulze]

Jeroen van Wolffelaar wrote:
> On Tue, Mar 07, 2006 at 07:33:36PM +, Matthew Garrett wrote:
> > Thanks for the answers. However, to a large extent they seem to be "We 
> > didn't fulfil many of our aims last year, but we will this year" and 
> > justification for that seems to be "I'll be in charge instead of 
> > Branden". If that's the case, why did you not step up to provide 
> > leadership within the team when it became clear that Branden wasn't 
> > providing what you considered to be insufficient leadership?
> 
> Ignoring the question whether Branden was actually providing
> insufficient leadership:
> 
> I don't think it'd be particularly well-recieved if someone who, after
> all, was not elected, would assume leadership. Regardless of the

Hmm, but that's how a team usually works in Debian, most teams are not
elected and organise themselves.  Many have a "leader" personality who
is trying to get things done.

Regards,

Joey

-- 
It's time to close the windows.


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

Questions to the candidates

[Martin Schulze]

Hi,

I'd like to ask some questions to the prospecitve project leaders:

1. Which are Debians top five strengths in your opinion?

2. Where do you identify Debians top five problems?

3. Do you plan to do anything to change the public recognition that
   Debian suffers from severe release problems and that its stable
   distribution is generally outdated?  If so, what?

4. In light of the well organised presence of Skolelinux and the
   professional presence of Ubuntu at several conferences and exhibitions
   do you believe Debian is represented adequately?

5. Do you see any services for our users or developers missing or
   poorly maintained?  If so, which and what do you plan to do to
   fix this?

6. What is your opinion about the current situation with the backports
   and volatile archives?  Currently they don't run on projects assets.

7. What is your opinion about the current situation with the snapshot
   archive?  Currently it doesn't run on projects assets.

Regards,

Joey

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.


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

Re: [EMAIL PROTECTED]: Request to be approved as FTP-Master]

[Martin Schulze]

Martin Schulze wrote:
> - Forwarded message from Martin Schulze <[EMAIL PROTECTED]> -
> 
> Date: Tue, 7 Mar 2006 14:23:33 +0100
> From: Martin Schulze <[EMAIL PROTECTED]>
> To: XX
> Cc: [EMAIL PROTECTED]
> Subject: Request to be approved as FTP-Master
> 
> I hereby request to be approved as FTP-master with proper permissions
> in order to be able to fully prepare and release stable updates.  My
> plan is to only touch stable update stuff and not work on any other
> corner of ftpmastership.
> 
> Regards,
> 
>   Joey
> 
> -- 
> Given enough thrust pigs will fly, but it's not necessarily a good idea.
> 
> 
> 
> - End forwarded message -
> 
> -- 
> Given enough thrust pigs will fly, but it's not necessarily a good idea.

This has been rejected by James Troup.

Regards,

Joey

-- 
It's time to close the windows.


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

Re: Question for all candidates: handle debian-admin more openly

[Martin Schulze]

Bill Allombert wrote:
> On Tue, Mar 07, 2006 at 10:56:57PM +0100, Martin Zobel-Helas wrote:
> > Now my question:
> > 
> > 1.) Do you think it would be a good idea to handle debian-admin more
> > openly? 
> > 
> > 2.) Would you encourage debian-admin to do so? If yes, how?
> > 
> > 3.) Do you think more DSA are needed?
> 
> I would like to experiment with "DSA assistants". The idea is that some
> Debian machines could not need special priviledge to operate and are not
> critical to operation, so they could be operated by "DSA assistants"
> which would have much less priviledges. This could reduce the work on
> the DSA and allow Debian to operate more machines, and "DSA assistants"
> could eventually became full DSA once they gather the trust of the DSA
> team. This could also increase transparency as a side effect.

You mean, like the site-admin who maintains the host already?
(i.e. Matt for paer, merulo, gluck; wiggy for klecker; etc.?)

> Alioth is a debian.org machine with a separate set of admin, so there is
> a precedent.

No.  Alioth is not DSA maintained, that's totally different setup.

> Example of non-priviledged services include secondary web services and
> developers accessible port machines with separate accounts.  As an
> aside, I think there should be more developers-accessible port machines.

Why?

For which ports?

Regards,

Joey

-- 
MIME - broken solution for a broken design.  -- Ralf Baechle


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

Re: question for all candidates

[Martin Schulze]

Andreas Schuldei wrote:
> * Matthew Garrett <[EMAIL PROTECTED]> [2006-03-07 20:09:11]:
> > > When important teams seem to be disfunctional or have a hard time to
> > > find a structure that scales into the future I would however use my
> > > powers of delegation to restructure the team from the outside. I would
> > > only do that after I worked with the team to help it overcome it's
> > > issues itself, however.
> > 
> > If you were DPL right now, which teams would you consider making formal 
> > delegates regardless of their wishes?
> 
> It would depend on weather I had good additional people that
> could make (in my oppinion) a difference in team dynamics and
> performance.
> 
> Important teams I would watch in order of priority:
> - Stable security
>   There was a security blackout during the summer of 2005, with
>   repercussions in the press and public oppinion, hurting the
>   project.  

Err... you know that this was caused by disfunctional infrastructure
not maintained by the security team, right?

> - Press   
>   Debian could do with an active, outgoing press department. I
>   look for people with an outgoing personality, time, excellent
>   english and experience with press. Packaging skills are less
>   important. I would like local sub-departments with tight
>   coordination with the "headquarter".
>   Just very recently Alexander Schmehl was added to [EMAIL PROTECTED]
>   That is a good step forward and we will follow closely, as with
>   the security team.

Good input for the press team is always good - yet only very seldom
provided.

Regards,

Joey

-- 
MIME - broken solution for a broken design.  -- Ralf Baechle

Re: Question for all candidates: handle debian-admin more openly

[Martin Schulze]

Sven Luther wrote:
> On Thu, Mar 09, 2006 at 07:31:49AM +0100, Martin Schulze wrote:
> > Bill Allombert wrote:
> > > Example of non-priviledged services include secondary web services and
> > > developers accessible port machines with separate accounts.  As an
> > > aside, I think there should be more developers-accessible port machines.
> > 
> > Why?
> > 
> > For which ports?
> 
> The three quad-power5 machines that IBM donated to debian for powerpc64 work,
> and nobody knew about, and are now sitting in augsbourg  (1 used by the
> augsbourg university, and two maintained by Bastian Blank, who distribute
> accounts on it).

Are bruckner and voltaire overloaded or do they lack services the developers
need?

Another question would be if the Debian project should accept every
arbitrary donation and increase their machine pool even when there
is no use the machine?

> It was my believe that at least one of them should be maintained under the
> umbrella of the DSA team, in order to have it thrusted to be used to upload
> packages, but the DSA team refused to have anything to do with them, which i
> suppose is understandable since they have no time for it. I proposed to handle
> it for them though, or have Bastian do so, and was equally refused.

I've once told you that currently (one year ago or so) there is no
use for them, since a) voltaire works fine as buildd and bruckner
works fine as developer machine.

> This is no blame, or something, i can clearly understand your
> frustration and that i may not have asked at the right time or something, just
> the machines are mostly underused, which is a shame, they are fast, have good
> memory, disks and bandwidth, and even the licences for the virtual partitions
> allowing to create sub machines for different usages.

Well, they haven't been negotiated with leader, hardware-donations, ports
or debian-admin prior to the donation.  What do you expect?  When I donate
you a pencil while you're perfectly fine with your old pencil and the new
one doesn't provide anything better, you won't use it either.

Regards,

Joey

-- 
MIME - broken solution for a broken design.  -- Ralf Baechle


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

Re: [EMAIL PROTECTED]: Request to be approved as FTP-Master]

[Martin Schulze]

martin f krafft wrote:
> also sprach Martin Schulze <[EMAIL PROTECTED]> [2006.03.08.0853 +0100]:
> > This has been rejected by James Troup.
> 
> What was the reason?

No reason given.

Regards,

Joey

-- 
MIME - broken solution for a broken design.  -- Ralf Baechle


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

Re: Questions for all candidates: plurality of mandates

[Martin Schulze]

Anthony Towns wrote:
> More generally, Joey's a member of DSA and as such has root on
> security-master.d.o; if he really wanted to he could maintain the dak
> install there (or an entirely different system) himself for security

I must not do that.  Being a system administrator is not a green light
for hacking in arbitrary services maintained by another team or
person.  This has been a rule for Debian admin for a long time and it
actually grants that those who maintain a service really maintain it
and ar not confronted with arbitrary changes made by others.

Hence, DSA must not interfere with infrastructure maintained by other
people.  This rule is only broken when either the person maintaining a
service has given their ok or when the service is harming something
and somebody immediately needs to get something done hencely.

Thus, I must not fiddle with the DAK installation on either spohr
or klecker unless ftpmaster give their ok for that.

> updates. The reason he hasn't already done that is precisely the above --
> keeping that stuff in order, and supporting new things like secure-apt,
> and finding and fixing bugs in it is a distraction from the stuff he's
> there to do.

Being able to do stable updates entirely would have saved a lot of
time, effort and nerves in the long term.  Well.  That's past anyway.

> And obviously there are problems with the code that need fixing -- it's
> not perfect, and even if it were we'd keep thinking up things it could
> do better anyway. For example, at the moment Moritz and I are trying to
> track down a bug where the s.d.o Release file fails to generate properly,
> and where the update being processed fails to get copied from s.d.o
> into ftp-master/proposed-updates.

That's great to hear.  A solution will help aba and zobel a lot.  This
issue has been mentioned to ftpmaster months if not years ago and
several times.

> And it has been fairly frustrating trying to do that for Joey, since when

You should not do it for me but for Debian.

> things don't get fixed perfectly the first time, they get treated as a
> major catastrophe; and that's why things don't go smoothly all the time,

Things don't have to be fixed in the first time.  However, people should
get a response when they ask, and in case of infrastructure issues a
perspective.  Even a response "umh...  I don't know what's going on,
I'll look into it when I find time" would be a good response.

> It hasn't always been this way -- the last time the security team took
> care of all that stuff themselves was prior to woody's release in 2002
> (which included the addition of ia64, hppa, mips, mipsel and s390). And
> as much as Joey does complain when it breaks [1], going to anything else
> would still be a major step backwards [2].

It's out of question that the current infrastructure, as long as it is
working, is essential and that the security team would have a hard
time supporting sarge and woody without it.  However, hell freezes
when the infrastructure is not working and those responsible for it
don't respond and react.  Maybe you remember the disaster that
happened when sarge was released.

> [2] "The security team is very thankful for the buildd network as it
>  simplifies the roll-out of security updates a lot.  We couldn't
>  support our distributions without this buildd network.  It is an
>  essential projects asset and an essential resource of the security
>  team."
> -- http://lists.debian.org/debian-devel/2005/03/msg01830.html

This can only be printed and framed lots of times.

Regards,

Joey

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth


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

Re: question for all candidates

[Martin Schulze]

Andreas Schuldei wrote:
> Pigs can fly and the Security Team is changing. I like to believe
> that the DPL team had a role in that. If it worked so well for

It didn't have.

The changes were underway and in discussion independently.

> the security team, why do you think it should be impossible for
> the other core teams? To be a leader reqires to have hope for the
> future. I still have that and I will pursue those possible
> scenarios that I belive hold most promise, trying to staying
> clear of the destructive ones.

Regards,

Joey

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth


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

Re: Question for all candidates: handle debian-admin more openly

[Martin Schulze]

Sven Luther wrote:
> > > > > Example of non-priviledged services include secondary web services and
> > > > > developers accessible port machines with separate accounts.  As an
> > > > > aside, I think there should be more developers-accessible port 
> > > > > machines.
> > > > 
> > > > Why?
> > > > 
> > > > For which ports?

Still not answered by Bill.

> > > The three quad-power5 machines that IBM donated to debian for powerpc64 
> > > work,
> > > and nobody knew about, and are now sitting in augsbourg  (1 used by the
> > > augsbourg university, and two maintained by Bastian Blank, who distribute
> > > accounts on it).
> > 
> > Are bruckner and voltaire overloaded or do they lack services the developers
> > need?
> 
> The release team has called for a multi-arch implementation to support
> powerpc64 userland over the biarch situation. This calls for a machine capable
> of building *and running* powerpc 64 code, which is not the case of existing
> powerpc 32bit machines.

Such requests and requirements change the situation.  However, I have
to admit that I first read about this particular requirement here.  I
noticed some babbling about ppc64, sparc64, mips64 and s390x
architectures but nothing that ended up in "will be included in the
archive, hence, requres buildd and development machines".

If this has changed, most probably debian-admin won't deny two
machines for these purposes.

--
Question to the release and archive people: Is there such a
requirement?  Will such architectures indeed be included the archive?
Do we really need machines of the particular 64 bit architectures?  If
so for which architectures exactly?
--

> > Another question would be if the Debian project should accept every
> > arbitrary donation and increase their machine pool even when there
> > is no use the machine?
> 
> We plan to support powerpc64 userland for etch, as thus this is necessary.

Who is "we" in this case?  Is it the Debian project?

> Furthermore these machines could be used for other use than just development,
> but then, i guess it is preferable to get a donation from intel than get a
> donation from ibm ?

I don't want to judge between donators and I don't see a reason why
Debian should do so.  Instead we should judge between donations and
use the best that we can get.

> > > It was my believe that at least one of them should be maintained under the
> > > umbrella of the DSA team, in order to have it thrusted to be used to 
> > > upload
> > > packages, but the DSA team refused to have anything to do with them, 
> > > which i
> > > suppose is understandable since they have no time for it. I proposed to 
> > > handle
> > > it for them though, or have Bastian do so, and was equally refused.
> > 
> > I've once told you that currently (one year ago or so) there is no
> > use for them, since a) voltaire works fine as buildd and bruckner
> > works fine as developer machine.
> 
> sure, but we need a powerpc64 autobuilder for etch.

I'm sorry but I don't see powerpc64 mentioned in the list of release
architectures for etch in the status mail from the release team:
http://lists.debian.org/debian-devel-announce/2005/12/msg00013.html
Maybe you could point me to where it is listed?

Regards,

Joey

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth


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

Re: Questions to the candidates

[Martin Schulze]

Steve McIntyre wrote:
> I'll turn the question around - what do _you_ think we're missing or
> not maintaining correctly? The services that I need are working OK,
> but I'm only one person.

I don't know of an important missing service, but I may have only
a limited view.

I'd still like to see a Debian source repository that uses an SCM
system to maintain different versions and branches of the software
we package so people can easily retrieve the changes.

With the snapshot archive this can be done, despite online browsing.

I do see problems, though:
  - packages.debian.org lacks many copyright and changelog files
(but we're working on this already)
  - snapshot.debian.net lost a large chunk of its archive with
a disk crash and neither we as the Debian project nor the
maintainer Free Software Foundation Japan (or was it Debian JP?)
has a backup.  (this is being worked on as well, though)
  - I don't know how widely torrents of our CD and DVD images
are used and if we run our own tracker software (or whatever
is needed).

Regards,

Joey

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth


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

Re: question for all candidates

[Martin Schulze]

martin f krafft wrote:
> also sprach Martin Schulze <[EMAIL PROTECTED]> [2006.03.10.2250 +0100]:
> > > Pigs can fly and the Security Team is changing. I like to believe
> > > that the DPL team had a role in that. If it worked so well for
> > 
> > It didn't have.
> > 
> > The changes were underway and in discussion independently.
> 
> Not trying to pick on anyone here, but the DPL team came into play
> and I sparked the Oldenburg security meeting idea, and *then* things
> started moving. If they'd been underway long before, I wouldn't be
> able to tell because noone was informed.

Wrong.

The security team has discussed issues internally long before some
people met in Oldenburg.

Regards,

Joey

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth


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

Re: question for all candidates

[Martin Schulze]

martin f krafft wrote:
> also sprach Martin Schulze <[EMAIL PROTECTED]> [2006.03.11.0010 +0100]:
> > > > It didn't have.
> > > > 
> > > > The changes were underway and in discussion independently.
> > > 
> > > Not trying to pick on anyone here, but the DPL team came into play
> > > and I sparked the Oldenburg security meeting idea, and *then* things
> > > started moving. If they'd been underway long before, I wouldn't be
> > > able to tell because noone was informed.
> > 
> > Wrong.
> 
> How can any of the above be wrong? Maybe I failed to make it
> explicit that *it seemed to me* (and not only me) that things
> started moving only after...

You wrote "and then things started moving", which is wrong because
restructuring the security team was already in discussion and part
of it already implemented.

Regards,

Joey

-- 
Experience is something you don't get until just after you need it.


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

Re: Question for all candidates: handle debian-admin more openly

[Martin Schulze]

Bill Allombert wrote:
> > > Example of non-priviledged services include secondary web services and
> > > developers accessible port machines with separate accounts.  As an
> > > aside, I think there should be more developers-accessible port machines.
> > 
> > Why?
> 
> Having two developers-accessible port machines for a platform means
> more total CPU time (important for the slower ports) and
> that we still have one usable when the other is down. 

Why would we need "more total CPU time"?  Not even leisner is
overloaded at the moment, and it's probably the slowliest machine.
(leisner has a different problem, though).

Assuming that the port machines run stable, and if they don't they or
the port loses some of their usability, there is no need to maintain
more than one development machine for a particular port.

Downtimes from 1-3 days are no problem for developers-accessible port
machines usually.  That's different to buildds, but we're not talking
about them at the moment.

Hence, please explain why we need "more total CPU time" and when a
downtime from a couple of days maximum is a problem.

> (db.debian.org do not list gluck as having chroot, and list vore as
> a sparc port machine. However vore seems to be down currently.
> pergolesi has both amd64 chroot and i386 chroot.)

Hmm, vore should be up.  Should be up soon again.

> Only i386 and powerpc have two port machines. 

Seeing it this way, it may be worth considering to remove the chroots
on gluck as the machine already deals with enough load.

> Also Joey, this was not intended as a critic of the work of the DSA

My questions were also not intended as counter-critic, but only as a
request for clarification.

> But my reasoning is that we could add more machine without increasing 
> the load on the DSA team.

My question stays: Why?

Of course, we could add all machines that get donated to the Debian
project, but why should we?

Regards,

Joey

-- 
Experience is something you don't get until just after you need it.


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

Re: Questions for Andreas Schuldei

[Martin Schulze]

Andreas Schuldei wrote:
> You were very busy and I knew you and joey had issues and a hard
> time working together. In the same IRC conversation I first asked
> Anthony about his working relationship with Joey. He would have
> been an excellent contact point inside FTP-master to work with
> him on e.g. his stable point releases. It would have been an easy
> and smooth way to avoid conflicts between you and Joey in that
> respect in the future. Unfortunatly I learned that could not work
> for personal reasons, either. I think I did not ask Ryan to help
> you and Joey out since I knew already from Joey that the two did
> not get along so well. I am not sure, though. Have you asked
> Ryan? 

For what it's worth, I don't have a personal problem with either James
or Ryan.  My problems are that James and Ryan as ftpmasters are often
quite unresponsive to mail, that both as wanna-build admins have been
quite unresponsive via mail and that both as security.debian.org
infrastructure admin have been quite unresponsive via mail.

As you guessed it, mail is my preferred means of communication.  Mail
should work since this is a world-wide and international project with
different up- and downtimes of their members.

Ryan told me that I should send mail and pester him via IRC afterwards
for infrastructure/w-b issues.  That's giving me a hard time, but I'll
try to do so (there was no need for a long time, though).

Regards,

Joey

-- 
Experience is something you don't get until just after you need it.


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

Re: Question for all candidates: handle debian-admin more openly

[Martin Schulze]

Bill Allombert wrote:
> On Sat, Mar 11, 2006 at 11:47:25AM +0100, Martin Schulze wrote:
> > Why would we need "more total CPU time"?  Not even leisner is
> > overloaded at the moment, and it's probably the slowliest machine.
> > (leisner has a different problem, though).
> 
> > Hence, please explain why we need "more total CPU time" and when a
> > downtime from a couple of days maximum is a problem.
> 
> "Developers accessible machines" are used by human beings which are 
> by nature much less patient and much more subject to real life issues
> than build daemons.
> 
> The faster a port machine is, the less painful it is to debug a 
> problem and so developers are more willing to work on it. Fixing
> the bug sooner given them also more time to work on others bugs
> and reduce the delay caused by the bug.

So you want faster machines and not more machines.
That's a different issue.

While we're at it, we're in need of a fast ARM machine with a
local disk and enough RAM (>=128MB).

> > My question stays: Why?
> > 
> > Of course, we could add all machines that get donated to the Debian
> > project, but why should we?
> 
> If we are donated machines that are significantly faster than the
> developers machines for the same architecture, I think we should provide
> access to them (unless the machines were affected to another usage, of
> course).

Why not replace the older machines then?

Should Debian develop a hardware zoo of old, superseded and hence unused
machines?

Regards,

Joey

-- 
The only stupid question is the unasked one.


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

Re: Questions to the candidates

[Martin Schulze]

Frank Küster wrote:
> >>5. Do you see any services for our users or developers missing or
> >>   poorly maintained?  If so, which and what do you plan to do to
> >>   fix this?
> >
> > I'm not directly aware of anything important missing at the moment. I
> > know that we struggled to get packages.d.o running again, but that is
> > now in hand. When we do have problems, more visibility on the causes
> > and solutions would be useful - that's where we have had problems in
> > the past.
> >
> > I'll turn the question around - what do _you_ think we're missing or
> > not maintaining correctly? The services that I need are working OK,
> > but I'm only one person.
> 
> - Backups.  This DPL debate has revealed that actually there are some
>   meanwhile, but it's not yet properly documented, and some important

Where do you want it to be documented?
There has been an announcement on debian-devel-announce.
There is technical project-internal documentation as well.

There were backups of critical resources before, on my own harddisk, though...

>   services (alioth/svn) don't seem to have regular backups.

I'm not sure I've mentioned this in public already, but a backup
facility together with a new machine for the alioth services are
available, they need to be set up and connected properly, though.
This is work in progress by the Alioth admins.

Regards,

Joey

-- 
The only stupid question is the unasked one.


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

Re: Question for all candidates: handle debian-admin more openly

[Martin Schulze]

Steve Langasek wrote:
> On Fri, Mar 10, 2006 at 11:20:47PM +0100, Martin Schulze wrote:
> > Such requests and requirements change the situation.  However, I have
> > to admit that I first read about this particular requirement here.  I
> > noticed some babbling about ppc64, sparc64, mips64 and s390x
> > architectures but nothing that ended up in "will be included in the
> > archive, hence, requres buildd and development machines".
> 
> > If this has changed, most probably debian-admin won't deny two
> > machines for these purposes.
> 
> > --
> > Question to the release and archive people: Is there such a
> > requirement?  Will such architectures indeed be included the archive?
> > Do we really need machines of the particular 64 bit architectures?  If
> > so for which architectures exactly?
> > --
> 
> No decision has been made about including such partial architectures in the
> archive yet.  I think it's the logical way to go once multiarch matures, but
> it hasn't really been discussed in-depth.  The need for autobuilders capable
> of running binaries of these types exists whether or not we implement
> multiarch, though, because we already have sparc, powerpc, i386, and s390
> library packages in the archive providing 64-bit variants for these
> architectures; having 32-bit autobuilders stumble over security builds of
> glibc would be a bad thing.

Glibc in woody can by autobuilt.
Glibc in sarge can by autobuilt.
Glibc in etch can most probably by autobuilt.

Which security updates are you talking about?

> But this may have been largely mitigated in the meantime by some changes to
> dpkg-dev (dpkg-shlibdeps) that eliminate the dependency on ldd.  If the
> existing lib packages can be autobuilt, I don't see any need to rush
> additional 64-bit autobuilders, since I think the current biarch approach to
> libraries is pretty lousy and shouldn't be expanded given that multiarch is
> on the horizon.

So the conclusion is that we currently don't need these machines.
Please correct me if I'm wrong.

Regards,

Joey

-- 
The only stupid question is the unasked one.


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

Re: Questions to the candidates

[Martin Schulze]

Frank Küster wrote:
> Martin Schulze <[EMAIL PROTECTED]> wrote:
> 
> > Frank Küster wrote:
> >> >>5. Do you see any services for our users or developers missing or
> >> >>   poorly maintained?  If so, which and what do you plan to do to
> >> >>   fix this?
> >> >
> >> > I'm not directly aware of anything important missing at the moment. I
> >> > know that we struggled to get packages.d.o running again, but that is
> >> > now in hand. When we do have problems, more visibility on the causes
> >> > and solutions would be useful - that's where we have had problems in
> >> > the past.
> >> >
> >> > I'll turn the question around - what do _you_ think we're missing or
> >> > not maintaining correctly? The services that I need are working OK,
> >> > but I'm only one person.
> >> 
> >> - Backups.  This DPL debate has revealed that actually there are some
> >>   meanwhile, but it's not yet properly documented, and some important
> >
> > Where do you want it to be documented?
> > There has been an announcement on debian-devel-announce.
> 
> At some place where it can be found even if you don't want to look up a
> month-old announcement.  What about http://db.debian.org/machines.cgi,
> and the developers reference, in the section about "Debian machines"? 

Umh... <http://db.debian.org/machines.cgi?host=bartok> already says
"Description: Backup Center of Debian"

Hmm, the developers reference is not my domain.  Please send its maintainer
a patch, file a bug report or drop its maintainer a line.

> > There is technical project-internal documentation as well.
> 
> Aha, where?  

It's not relevant for the end-user.
/org/admin.debian.org/doc/backup.debian.org
And in the da-backup package.

Regards,

Joey

-- 
The only stupid question is the unasked one.


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

Re: Debian Backup Server (was: Questions to the candidates)

[Martin Schulze]

Frank Küster wrote:
> Moving this to -devel, it's off-topic for -vote; Cc to -admin.
> 
> Martin Schulze <[EMAIL PROTECTED]> wrote:
> 
> >> At some place where it can be found even if you don't want to look up a
> >> month-old announcement.  What about http://db.debian.org/machines.cgi,
> >> and the developers reference, in the section about "Debian machines"? 
> >
> > Umh... <http://db.debian.org/machines.cgi?host=bartok> already says
> > "Description: Backup Center of Debian"
> 
> I'd rather like to see information which services on a given machine is
> backed up there.

Please start a page in the Wiki based on the Mail to -devel-announce,
and ask me periodically about updates.  There's already one admin
page in the Wiki, so please use a suitable name and add a link.

> >> > There is technical project-internal documentation as well.
> >> 
> >> Aha, where?  
> >
> > It's not relevant for the end-user.
> > /org/admin.debian.org/doc/backup.debian.org
> > And in the da-backup package.
> 
> Which doesn't seem to be available in sid currently?

It's only available in cvs.debian.org (source) and db.debian.org (binary).

> - at which time of day is the backup made

cat /etc/cron.d/da-backup

> - for how long are the backups kept for a given service

That differs.

> - what would valid reasons be for the DSA to extend the keep time for a
>   given service?  Or how do you decide about this time, anyway?

Needs to be decided on a per-source basis.

> - Would it, in principle, be possible to add home directories, or parts
>   of them, if they provide services to the public?

All home directories on all hosts would make the disk requirement explode.

When a developer runs an important service out of their home directory
that'd be a good reason to add a particular directory.

> - What are the criteria for getting a backup rolled out - would "I
>   deleted that file that was not yet under version control" be a request
>   you'd happily process, or would that cause too much workload?

Yes, no.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.


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

Re: Proposal: The DFSG do not require source code for data, including firmware

[Martin Schulze]

Steve Langasek wrote:
>  The application of DFSG#2 to firmware and other data
>  
> 
> The Debian Project recognizes that access to source code for a work of
> software is very important for software freedom, but at the same time
> "source" is often not a well-defined concept for works other than those
> traditionally considered "programs".  The most commonly cited definition is
> that found in version 2 of the GNU GPL, "the preferred form of the work for
> making modifications to it," but for non-program works, it is not always
> clear that requiring this "source" as a precondition of inclusion in main
> is in the best interest of our users or advances the cause of Free Software:
> 
>   - The author's preferred form for modification may require non-free tools
> in order to be converted into its final "binary" form; e.g., some
> device firmware, videos, and graphics.
>   - The preferred form for modification may be orders of magnitude larger
> than the final "binary" form, resulting in prohibitive mirror space
> requirements out of proportion to the benefits of making this source
> universally available; e.g., some videos.
>   - The "binary" and "source" forms of a work may be interconvertible with no
> data loss, and each may be the preferred form for modification by
> different users with different tools at their disposal; e.g., some
> fonts.
> 
> While the Debian Free Software Guidelines assert that source code is a
> paramount requirement for programs, they do not state that this is the case
> for non-program works, which permits us to consider whether one of the above
> points justifies a pragmatic concession to the larger context within which
> Free Software operates.
> 
> THE DEBIAN PROJECT therefore,
> 
> 1. reaffirms its dedication to providing a 100% free system to our
> users according to our Social Contract and the DFSG; and
> 
> 2. encourages authors of all works to make those works available not
> only under licenses that permit modification, but also in forms that make
> such modifications practical; and
> 
> 3. supports the decision of the Release Team to require works such as
> images, video, and fonts to be licensed in compliance with the DFSG without
> requiring source code for these works under DFSG #2; and
> 
> 4. determines that for the purposes of DFSG #2, device firmware
> shall also not be considered a program.

I have some problems, publically saying that binary firmware blobs
that most probably contain a lot of small programs "shall also not be
considered a program" (regardless of "a" or "several").  We're not
saying Pi is 3.14 either.

We do know that there are programs included in binary firmware blobs
most of the time after all.

How about the following instead?

  4. supports the decision of the Release Team to require device 
firmware
to be licensed in compliance with the DFSG without requiring source code for
possibly enclosed software.

I could imagine to say acknowledge that Debian consideres it ok to include
binary firmware blobs without their source to code to be licenced DFSG-free.

Regards,

Joey

-- 
Never trust an operating system you don't have source for!


signature.asc
Description: Digital signature

Re: Proposal: The DFSG do not require source code for data, including firmware

[Martin Schulze]

Sven Luther wrote:
> What Steve and others who seconded him propose is to ship non-free firmware in
> main, and declaring it as data, and thus disguising it as free software.

I guess that's a good statement, it's disquising firmware, not necessarily
as Free Software, but disguising it.  We should be honest enough to accept
that it {does,may} contain software that is run on processors and maybe
(to be decided by vote) decide to accept this for the time being and ship
it regardlessly (or not...).

Regards,

Joey

-- 
Never trust an operating system you don't have source for!


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

Re: Firmware & Social Contract: GR proposal

[Martin Schulze]

Anthony Towns wrote:
> The Debian Project resolves that:
> 
> (a) The Social Contract shall be reverted to its original form,
> as at http://www.debian.org/social_contract.1.0

ARGS.  This is certainly one of the worst GR proposals I've seen.

Not seconded, of course.

I believe it would be more helpful if we:

 - continue to work on the GFDL problems until no work only licensed
   under this license that we consider non-free is left over in main;

 - continue to work together with the kernel team and the upstream
   kernel developers to fix the firmware issue;

 - build the required infrastructure for the debian-installer so that
   non-free firmware can be loaded;

 - maybe even provide a howto for external vendors to modify the
   official CD/DVD images and/or installer to include non-free
   firmware in a special directory so that it can be added easier than
   by supplying a second CD or whatever;

 - would accept the fact that we are not able to remove all non-free
   firmware blobs from the kernel shipped with etch but will continue
   our effort to do so for future releases.

Several kernel developers have recognised the problem.  Bdale spoke at
a kernel developers meeting several years ago and addressed this
problem.  Now that it has been recognised as problem, and now that
there have been work and effort put into this issue, paddling back
would be the worst we could do.

> (c) In addition to the commitments made in the Social Contract,
> the Debian System shall only include documentation, images,
> sounds, video, fonts and similar works that meet the Debian
> Free Software Guidelines, and are available in some reasonably
> modifiable form.
> 
> (d) Notwithstanding the above, the Debian Free Software Guidelines
> shall not be applied to logos, firmware or the text of copyright
> licenses that may be included in the Debian System.

Excluding firmware blobs these two may be discussable and could be
added into an Explanation/Appendix of the Social Contract.

> (e) Following the release of etch, the Debian Project Leader shall:
>   i.   ensure that the Debian community has a good understanding
>of the technical and legal issues that prevent the Debian
>Free Software Guidelines from being applied to logos and
>firmware in a manner that meets the needs of our users;

How would the DPL do that?  Walk around, shake hands with members of
the Debian community and explain the issue face-to-face?

>   ii.  ensure that project resources are made available to
>people working on addressing those issues;


>   iii. provide a report to the Debian community on progress achieved
>in these areas at DebConf 7 in Edinburgh.

That's nothing that should be part of a GR.  Feel free to make it
happen nevertheless, which would be a good thing, of course.

> Personally, I think it's a mistake to have a social contract that we
> can't meet -- I would much rather say "we're not only meeting our social
> contract, but we're going above and beyond it" than keep worrying about
> how we've overpromised and keep having to underdeliver.

It is totally ok to define high goals and accept that we don't meet
them for a given release.

Regards,

Joey

-- 
Open source is important from a technical angle. -- Linus Torvalds


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

Re: Firmware & Social Contract: GR proposal

[Martin Schulze]

Josselin Mouette wrote:
> Le mardi 05 septembre 2006 à 19:07 -0700, Thomas Bushnell BSG a écrit :
> > For me the key question is whether the d-i team is actually doing the
> > work or not.  Are they?  If the answer is "yes", then I might vote for
> > a delay.  If the answer is "no", then I see no reason that a delay
> > will change things.
> 
> As Joey's analysis shows, this would lead to a delay of at least 6
> months. Given that we're already frozen, I don't think this is something
> we can afford if we want etch to be consistent.

It would be more honest to recognise, accept and document the fact
that we are not able to fix this situation entirely for etch but are
continuing to do so and will probably more more into this direction
for the next release.  We should not delay etch due to this, imho.

I believe that it would be great if we could release etch without
non-free firmware blobs in main and a proper infrastructure to add
them on demand if people want this during the installing and booting.

However, if this can't be met in time, it seems honest to me to admit
this and more healthy to leasen this particular goal for this
particular release (etch) due to the late stage of the release.

Regards,

Joey

-- 
Open source is important from a technical angle. -- Linus Torvalds


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

Re: Firmware & Social Contract: GR proposal

[Martin Schulze]

Anthony Towns wrote:
> >  1. I'm utterly frustrated with your ways. The mail on d-d-a could not
> > have any other answer that "please release etch in time", that's
> > something a perfect moron could have predicted without a doubt. 
> 
> 26% of the people on the forums said supporting hardware requiring
> non-free firmware was the highest priority; another 15% said not shipping
> sourceless firmware in main was; that's 41% all up or 86 people.

Probably > 50% of the people working with computers want to run
Windows, does that mean we should kick Linux out and use the kernel
from Redmond instead?

Regards,

Joey

-- 
Open source is important from a technical angle. -- Linus Torvalds


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

Re: Proposal: Apologize for releasing etch with sourceless/non-free firmware

[Martin Schulze]

Lionel Elie Mamane wrote:
> On Fri, Aug 25, 2006 at 11:03:47AM +0100, Daniel Ruoso wrote:
> > I propose the following option to the GR:
> 
> > 
> > The Debian Project reaffirms its commitment of providing a 100% free
> > operating system, and reaffirms the decisions taken by GR 2004-03, but
> > some technical issues regarding firmware couldn't be solved in the
> > timeframe to release etch, and, therefore, the next Debian release,
> > codename etch, will still contain sourceless/non-free firmwares. The
> > Debian Project apologize for this, and will continue to work on finding
> > a way to solve this issue.
> > 
> 
> Seconded.

Very good (too bad we couldn't fulfil this, though).

Seconded.

Regards,

Joey

-- 
The good thing about standards is that there are so many to choose from.
-- Andrew S. Tanenbaum


signature.asc
Description: Digital signature

Re: The Sourceless software in the kernel source GR

[Martin Schulze]

> On Mon, 18 Sep 2006 18:46:50 -0700, Don Armstrong <[EMAIL PROTECTED]> said: 
> > But just like the groundwork and foundation of a structure, the
> > non-actionable content of a resolutions can contain information on
> > how the actionable content is to be interpreted. As such, it is part
> > of the resolution, and needs to be included with the content made
> > available to voters.

Umh, then I need to ask why the resolution is not clear enough
so that it does not need the preamble to know in which way the
author has intended its interpretation?  As Manoj pointed out
already, courts look at the resolution when *interpreting* it,
not at the preamble, so it seems pretty useles in that regard.

Regards,

Joey

-- 
It's time to close the windows.


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

Re: Proposal: Recall the Project Leader

[Martin Schulze]

Seconded.

Regards,

Joey

Denis Barbier wrote:
> Hi,
> 
> Anthony Towns ends up his announce[1] about dunc-tank.org with these
> two paragraphs:
> 
> The first article[2] on the topic's already been
> published; with one somewhat inaccuracy - this is not a
> Debian project, and is being specifically handled outside
> of Debian to both ensure that any conflict of interest
> that might occur can be decided by Debian in Debian's
> favour, and to allow other groups that have different
> ideas about what priorities are important to encourage
> contributions to those areas.
> 
> A question that has been raised is whether the
> organisation can be sufficiently "outside" of Debian when
> the DPL is intimately involved.  I don't have the answer
> to that - in my opinion it can be, but whether this one is
> will be up to Debian to decide.
> 
> The article's title mentioned in the first paragraph is: "Debian
> experiments with funding group to release 'etch' on time".  Even
> if Anthony Towns and other Dunc-tankers claim that their project
> is not affiliated to Debian, external people will still see this
> project as being handled by the Debian Project Leader, and thus
> implicitly by the Debian project.
> 
> But we, Debian developers, can make this confusion vanish, and I
> would like to propose that we answer to the valid question quoted
> in the second paragraph above by recalling our Project Leader, as
> allowed by our Constitution (section 4.1.1) and am seeking seconds
> for this proposal.
> 
> Denis Barbier
> 
> [1] http://azure.humbug.org.au/~aj/blog/2006/09/19#2006-09-19-omg
> [2] http://www.computerworld.com.au/index.php/id;1964607233;fp;4194304;fpid;1



-- 
GNU GPL: "The source will be with you... always."


signature.asc
Description: Digital signature

Re: Proposal: Recall the Project Leader

[Martin Schulze]

Michael Banck wrote:
> On Thu, Sep 21, 2006 at 12:05:39AM +0200, Denis Barbier wrote:
> > Again, the question is: is this organisation sufficiently "outside"
> > of Debian when the DPL is intimately involved.  In my opinion, the
> > answer is obviously no, meaning that this quarantine will not work
> > and as a result may badly harm the project.  By recalling the
> > Project Leader, we ensure that there is no confusion between both
> > projects, give the Dunc project a better chance of success, and
> > preserve Debian in case of failure.
> 
> Uhm, did you ask any of the dunc-tank people whether they would like to
> carry on after your GR passed?  I don't see that as a given.

Which would imply that it is strongly associated to the project leader
which was the reason why Denis proposed this general resolution.

Err... Did I just misunderstand you?

Regards,

Joey

-- 
This is GNU/Linux Country.  On a quiet night, you can hear Windows reboot.


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

Re: Proposal: Recall the Project Leader

[Martin Schulze]

John Goerzen wrote:
> * Debian itself donated $1000 to the Gnome project to fund its
>   development due to a dispute with KDE over Qt licensing.
>   I don't recall this coming with strings such as "can't be spent on
>   programmer time".  So there is even precedent for the project
>   doing this sort of thing.

Maybe it wasn't known to you but this money wasn't used to pay a particular
developer but to let some developers travel to a conference.  So it's a
totally different issue.

Regards,

Joey

-- 
This is GNU/Linux Country.  On a quiet night, you can hear Windows reboot.


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

Re: Proposal: Recall the Project Leader

[Martin Schulze]

Matthew R. Dempsky wrote:
> On Wed, Sep 20, 2006 at 07:43:22PM +0200, Denis Barbier wrote:
> > Anthony Towns ends up his announce[1] about dunc-tank.org with these
> > two paragraphs:
> 
> > A question that has been raised is whether the
> > organisation can be sufficiently "outside" of Debian when
> > the DPL is intimately involved.  I don't have the answer
> > to that - in my opinion it can be, but whether this one is
> > will be up to Debian to decide.
> 
> What's so scandalous about the DPL encouraging a timely release?

It's not about a timely release, it's about Debian directly or indirectly
paying *some* developers for the work they signed up to.

Regards,

Joey

-- 
This is GNU/Linux Country.  On a quiet night, you can hear Windows reboot.


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

Re: Proposal: Recall the Project Leader

[Martin Schulze]

Pierre Habouzit wrote:
> Le jeu 21 septembre 2006 20:44, Graham Wilson a écrit :
> > On Thu, Sep 21, 2006 at 07:10:25PM +0200, Pierre Habouzit wrote:
> > > I'd say that I'm not more comfortable with Steve McIntyre beeing
> > > involved and a DPL-assistant (or whatever name his position has)
> > > either, so if Aj stops beeing involved with dunc-tank, (1) is in
> > > fact half solved.
> >
> > Then shouldn't those who are attempting to recall aj also try to
> > remove Steve from his delegate position? Because, as of now, it seems
> > (based on the GRs on the table) that the only problem people have is
> > with aj's involvement.
> 
>   Technically, if Aj is deposed, steve will be as well. And as I said, 
> if Aj is retiring from dunc-tank, then Steve's position has to be 
> clarified in a second stage IMHO yes. Nothing has been done "against" 
> Steve's position as DPL-Assistant, especially because it's 
> not "allowed" in the constitution.

Umh?  Why would Steve be disposed as well?  I'm missing a crucial bit
here, I guess.

Regards,

Joey

-- 
This is GNU/Linux Country.  On a quiet night, you can hear Windows reboot.

Please always Cc to me when replying to me on the lists.


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

Re: Proposal: Recall the Project Leader

[Martin Schulze]

martin f krafft wrote:
> also sprach Martin Schulze <[EMAIL PROTECTED]> [2006.09.23.2110 +0200]:
> > It's not about a timely release, it's about Debian directly or
> > indirectly paying *some* developers for the work they signed up
> > to.
> 
> No, it's about a timely release and enabling two people of core
> importance to dedicate even more of their time, using limited funds
> in a well-defined manner. It's about an experiment to see whether
> it has the potential break our track record of continuously missing
> our deadlines.
> 
> And quite obviously, there's a lot of personal, emotional stuff
> involved on the side of the opponents. Are you jealous that you're
> not getting any money this time? Are you fearing that you may never
> get any money?

I'm not jealous.  I'm totally disappointed.  I'll have to reorder the
priorities in my life.  I'm sure I get money if I want to.  I just
have to drop some Debian work to be able to work on other issues -
which I have often declined in the past.

This thing shows me that releasing is important and that what I've
done is not.  Fine.  Then I shall not do it anymore, I guess.

> In your "essay" you ask: "Why should those, who have to make money
> in other areas in order to live at all, continue to work
> voluntarily?" -- I've tried to answer that in my recent blog post:
> because they believe in the project they're working on, and they're
> ready to look forward with everyone else, not peek sideways to see
> what the others are doing or whether they're better off.

I have some problems believing in the project...

I now also see it drowning.

In the past I have always tried to demonstrate stability and
confidence in Debian and I know that my steady work has been a reason
for some developers not to take a leave.  I can't do that anymore.

Regards,

Joey

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.


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

Re: Proposal: Recall the Project Leader

[Martin Schulze]

Martin Schulze wrote:
> > > On Thu, Sep 21, 2006 at 07:10:25PM +0200, Pierre Habouzit wrote:
> > > > I'd say that I'm not more comfortable with Steve McIntyre beeing
> > > > involved and a DPL-assistant (or whatever name his position has)
> > > > either, so if Aj stops beeing involved with dunc-tank, (1) is in
> > > > fact half solved.
> > >
> > > Then shouldn't those who are attempting to recall aj also try to
> > > remove Steve from his delegate position? Because, as of now, it seems
> > > (based on the GRs on the table) that the only problem people have is
> > > with aj's involvement.
> > 
> >   Technically, if Aj is deposed, steve will be as well. And as I said, 
> > if Aj is retiring from dunc-tank, then Steve's position has to be 
> > clarified in a second stage IMHO yes. Nothing has been done "against" 
> > Steve's position as DPL-Assistant, especially because it's 
> > not "allowed" in the constitution.
> 
> Umh?  Why would Steve be disposed as well?  I'm missing a crucial bit
> here, I guess.

Oh, you were talking about Sledge and not about vorlon I guess, now it
makes sense.

Regards,

Joey

-- 
Life is a lot easier when you have someone to share it with.  -- Sean Perry


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

Re: Summary? (Or: my vote is for sale!)

[Martin Schulze]

Sven Luther wrote:
> Jurij, i still think your draft is lightyears more clear and to the point than
> most GRs out there.

One comment.  As BLOB stands for Binary Large OBject, binary blob
is somewhat "strange".

Regards,

Joey

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.

Please always Cc to me when replying to me on the lists.


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

Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation

[Martin Schulze]

Seconded.

Regards,

Joey

Martin Wuertele wrote:
> I disagree with the Policy delegation decision of our DPL [1] and
> therefore propose a resolution as defined in section 4.2.2 of the Debian
> constitution to delay the decision of the Debian Project Leader keeping
> the Package Policy Committee as defined[2] in place until the Debian
> Project Leader has found at least three people "who'll be active in
> maintaining policy according to the policy process"[3] and delegates
> them. Consequently the REJECT for uploads of debian-policy must be
> removed.
> 
> My reason for this proposal is the impression the revocation of the
> delegation is based on the disagreement of the interpretation of the
> policy between the chair of the Package Policy Committee and the Debian
> Project Leader.
> 
> [1] http://lists.debian.org/debian-project/2006/10/msg00233.html
> [2] http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
> [3] http://lists.debian.org/debian-project/2006/10/msg00238.html
> 
> yours Martin



-- 
There are lies, statistics and benchmarks.


signature.asc
Description: Digital signature

Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation

[Martin Schulze]

Steve Langasek wrote:
> On Wed, Oct 25, 2006 at 09:40:43PM +0200, Martin Wuertele wrote:
> > I disagree with the Policy delegation decision of our DPL [1] and
> > therefore propose a resolution as defined in section 4.2.2 of the Debian
> > constitution to delay the decision of the Debian Project Leader keeping
> > the Package Policy Committee as defined[2] in place until the Debian
> > Project Leader has found at least three people "who'll be active in
> > maintaining policy according to the policy process"[3] and delegates
> > them. Consequently the REJECT for uploads of debian-policy must be
> > removed.
> 
> > My reason for this proposal is the impression the revocation of the
> > delegation is based on the disagreement of the interpretation of the
> > policy between the chair of the Package Policy Committee and the Debian
> > Project Leader.
> 
> So you think it's wrong for the DPL to overrule the policy delegate because
> of a disagreement, and therefore in your disagreement you wish to overrule
> the DPL?

I'd rather interpret the proposal as:

s/overrule/postpone the decision of/
until new CTTE people have been assigned.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.


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

Re: [GR] DD should be allowed to perform binary-only uploads

[Martin Schulze]

> >> Note that if you can get SPI to transfer the debian.org zone to other
> >> DNS servers than the current ones, you can NMU the infrastructure.
>
> Andreas Barth <[EMAIL PROTECTED]> wrote:
> > I heavily disagree to that. The current servers are owned by Debian or
> > sponsored to Debian by some people. So Debian does have a say what
> > happens on them or not. (Please note that this doesn't contain any
> > approval or disapproval of any action on our servers, but just a
> > disapproval to this concept.)
> 
Julien BLACHE wrote:
> You've totally missed the point. All it takes to "NMU" the
> infrastructure is to have a new one ready, then get SPI to change the
> DNS servers associated to debian.org.

I've heard that there's a second unofficial buildd network, so that
part would probably be easy.

... just pondering and calculating...

Joey

-- 
Life is a lot easier when you have someone to share it with.  -- Sean Perry


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

Re: BREAKING NEWS: Debian developers aren't trusted

[Martin Schulze]

Francesco P. Lovergine wrote:
> On Sun, Feb 11, 2007 at 04:24:45AM +0200, Kalle Kivimaa wrote:
> > Josselin Mouette <[EMAIL PROTECTED]> writes:
> > >> Personally, I don't like either of the checks, but I've seen zero
> > >> effort from Aurelian and friends to demonstrate they can be trusted,
> > 
> > Quoting partial sentences without disclosing the original source is
> > what usually only the yellow press does. I don't trust the "news" they
> > report.
> > 
> 
> I would add that quoting without proper context rendering is also a known 
> habits of too many people in MLs and generally used to enforce their own 
> opionions and mantaining very high the level of unuseful flaming. 

How does this help the underlying problem that the Debian project leader
considers developer colleague Aurelien and his friends (probably many
other Debian developers) not to be trusted?

Regards,

Joey

-- 
Life is a lot easier when you have someone to share it with.  -- Sean Perry


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

Re: [GR] DD should be allowed to perform binary-only uploads

[Martin Schulze]

Julien BLACHE wrote:
> >> Note that if you can get SPI to transfer the debian.org zone to other
> >> DNS servers than the current ones, you can NMU the infrastructure.
> >
> > But (probably) only if it was at the request of the DPL.
> 
> Could be at the request of the Project, via a GR I think, if the DPL
> was, say, unwilling to act and fix a broken situation wrt
> infrastructure administration and developer access to the said
> infrastructure.

Unlikely.  SPI usually has a defined authorisationship with an associated
project, this refers to people, not the project as a whole or their
developers or their internal voting results.  However, a GR should be
able to kick the DPL out of leadership and the next vote would install
a new DPL who would then have a say.

Regards,

Joey

-- 
Life is a lot easier when you have someone to share it with.  -- Sean Perry


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

Re: [GR] DD should be allowed to perform binary-only uploads

[Martin Schulze]

Julien BLACHE wrote:
> Martin Schulze <[EMAIL PROTECTED]> wrote:
> 
> > Unlikely.  SPI usually has a defined authorisationship with an associated
> > project, this refers to people, not the project as a whole or their
> > developers or their internal voting results.  However, a GR should be
> > able to kick the DPL out of leadership and the next vote would install
> > a new DPL who would then have a say.
> 
> Which is interesting, considering that in such a situation we might
> not even be able to run a vote.

Uh?  There's still the secretary last I checked.

Regards,

Joey

-- 
Life is a lot easier when you have someone to share it with.  -- Sean Perry


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

Re: [GR] DD should be allowed to perform binary-only uploads

[Martin Schulze]

Wesley J. Landaker wrote:
> On Monday 12 February 2007 09:08, Stephen Gran wrote:
> > [...] reproducibility will suffer.  The fact that it failed to run the
> > binary correctly in this failure instance is good.  But another day, it
> > may fail to correctly run gcc, and that would be bad if it exited 0 with
> > a wrongly built binary.
> 
> And couldn't this just as easily happen with *real* machines with 
> motherboard problems, bad memory, overheating CPUs, or, say Pentium 

2.6 kernel instead of 2.4 - happened on mips(el)? and hppa at least.
fwiw.

Regards,

Joey

-- 
Long noun chains don't automatically imply security.  -- Bruce Schneier


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

Re: BREAKING NEWS: Debian developers aren't trusted

[Martin Schulze]

Hamish Moffatt wrote:
> > ] I am really upset by the way the ARM build daemons are managed. The
> > ] packages are not uploaded regularly, with sometimes three days between
> > ] two uploads. [...]
> > ]
> > ] All of that resulted in ARM being the slowest architecture to build
> > ] packages. [...]
> > 
> > -- http://blog.aurel32.net/?p=33
> > 
> > I don't imagine Aurelien's any less upset, but as far as I can see, there
> > aren't actual problems with the way arm's keeping up at present:
> 
> Another problem is that the buildd email mailbox is apparently piped to
> /dev/null.

FWIW, buildd mail is processed by a daemon, you are probably referring
to something else.

Regards,

Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erdös


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

Re: BREAKING NEWS: Debian developers aren't trusted

[Martin Schulze]

Frank Küster wrote:
> >> > I don't imagine Aurelien's any less upset, but as far as I can see, there
> >> > aren't actual problems with the way arm's keeping up at present:
> >> 
> >> Another problem is that the buildd email mailbox is apparently piped to
> >> /dev/null.
> >
> > FWIW, buildd mail is processed by a daemon, you are probably referring
> > to something else.
> 
> I guess he's referring to the [EMAIL PROTECTED] addresses.  If

They're (usually) not sent to the build daemon itself, so no.

Regards,

Joey


-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erdös


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

Re: Debian Project Leader Elections 2007: Draft ballot

[Martin Schulze]

Marc Haber wrote:
> Or are we going to require an IQ test before people allowing to vote,
> understanding the ballot being one of the test?

Seconded.

Regards,

Joey

-- 
The MS-DOS filesystem is nice for removable media.  -- H. Peter Anvin


signature.asc
Description: Digital signature

Re: ajt's anti-rebuttal

[Martin Schulze]

Anthony Towns wrote:
> On Thu, Mar 15, 2007 at 06:35:59PM +0100, Andreas Barth wrote:
> > * Anthony Towns (aj@azure.humbug.org.au) [070314 19:25]:
> > > Since then we've also had Debian Times established
> > I don't see at all how this is realated to you being DPL - in fact, I
> > would have prefered a more active role of the DPL to revive the usage of
> > the debian-news list.
> 
> Joey's been maintaining -news for quite some time now, he's the person
> who should be deciding what's posted on the list, and what's not. While I
> can certainly agree that it'd be useful to have more stuff appear there,
> I don't think there's been a good enough demonstration that someone else
> will do at least as good a job to warrant overruling Joey's decision on
> that (at the very least there hadn't been when this was being discussed
> in May or July last year).

To add a remark here, the press team welcomes contributions and
ideas for news releases.  Unfortunately, very few people have spoken
with the press team before and discussed issues that could (and would)
be send out as press releases.  There have been some, admittedly, and
there have been press releases based on their work.

Debian Press Work 
Event Announcements 
Summer of Code 

Regards,

Joey

-- 
If nothing changes, everything will remain the same.  -- Barne's Law


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

Re: Debian Maintainers GR Proposal, alternative update

[Martin Schulze]

Steffen Joeris wrote:
> I took ajs proposal and modified it to fit my understanding of DM. See the 
> patch below the proposal, together with my comments for more information.
> I avoid repeating most of the arguments, which were send several times in 
> dozens of mails. This is just my proposal and let's see, if some people want 
> to support it, or if we just forget about it :)
> 
>  Debian Maintainers Proposal 
> 
> The Debian Project endorses the concept of "Debian Maintainers" with
> limited access, and resolves that:
> 
> 1) A new keyring will be created, called the "Debian maintainers keyring".
>It will be initially maintained by:
> 
> 
> * the Debian Account Managers (Joerg Jaspert, James Troup)
> * the New-maintainer Front Desk (Christoph Berg, Marc Brockschmidt,
>   Brian Nelson)
> * the Debian Keyring maintenaners (James Troup, Michael Beattie)
   

>It will be known as the normal people behind the NM process.
>Changes to the team may be made by the DPL under the normal rules for
>delegations or if the teams accept new members.
> 
>The keyring will be packaged for Debian, and regularly uploaded
>to unstable.
> 
> 
> 2) The initial policy for an individual to be included in the keyring
>will be:
> 
> * that the applicant acknowledges Debian's social contract,
>   free software guidelines, and machine usage policies.
> 
> * that the applicant provides a valid gpg key, signed by a
>   Debian developer (and preferably connected to the web of
>   trust by multiple paths).
> 
> * that at least one Debian developer (preferably more) is willing
>   to advocate the applicant's inclusion, in particular that the
>   applicant is technically competent and good to work with.
> 
> * that the applicant has to go through an NM process
>   (this means the ID check and the most important parts of P&P and T&S
>   have to be done, the AM needs to recommend the NM and FD needs to 
> check
>   whether the report is complete or not)
> 
> (Note: If the NM applies for DD status, he can become a DM after FD approval)

Is "an NM process" different from "the NM process"?

If the last item would require the applicant to apply for NM-ship and
not be rejected from this process, it would help those in the NM process
waiting for one thing or another.  It should be required that the applicant
is maintaining a package already as well, though.

Regards,

Joey

-- 
GNU GPL: "The source will be with you... always."


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

Re: On the "Debian Maintainers" GR

[Martin Schulze]

Nacho Barrientos Arias wrote:
> > It appears to me that the DM concept as sketched in the GR is mainly
> > meant to let NMs upload earlier, i.e. it tries to fix the fact that
> > front-desk or DAM approval take too long. I think the fix for that is
> > just to find someone besides Joerg to also read the AM reports. DMs as
> > in the GR are a workaround, not a solution.
> 
> IMHO DMs is something Debian needs, a bunch of people stuck at NM is
> perfectly able to upload high quality packages themselves but
> otherwise I completely agree with the paragraph above. DMs is a small
> patch, not a solution.

With your rationale, NMs who maintain packages well and are sufficiently
clueful should be granted upload rights even before finishing NM, instead
of the invention of a second class of maintainers.

Regards,

Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erdös


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

Re: On the "Debian Maintainers" GR

[Martin Schulze]

Raphael Hertzog wrote:
> - Not everybody deserves to be DD. [2]

> [2] The NM process rejects some people who have the technical abilities to
> maintain packages but who are not in sync with the rest of the community.
> I fail to see why we should refuse their technical contribution. The NM
> process also scares away people who don't have the technical abilities to
> become DD. That doesn't mean they wouldn't be able to maintain some
> simple packages.

Uh oh?  You want to grant people upload permission who we DOCUMENTATEDLY
DO NOT WANT as Debian developer?  How crap is that?

Regards,

Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erdös


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

Re: On the "Debian Maintainers" GR

[Martin Schulze]

Raphael Hertzog wrote:
> > maintained by someone who isn't keeping up with Debian-wide changes, and
> 
> Why that ? I expect all DM to be subscribed to d-d-a and would suggest a
> check (or even some enforcement with auto-subscription if we really want).

Why is this not written in the GR but the use of which software to use
and on which list to announce new members?

Regards,

Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erdös


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

Re: On the "Debian Maintainers" GR

[Martin Schulze]

Josselin Mouette wrote:
> Le jeudi 26 juillet 2007 à 16:20 +0200, Loïc Minier a écrit :
> >  But what if this results in higher quality packages than the one of
> >  overly busy DDs (because the maintainers are very focused on their pet
> >  packages)?  Did you think of this consequence?
> 
> If someone can make such packages, he should become a DD, full stop.

.

Regards,

Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erdös


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

Re: On the "Debian Maintainers" GR

[Martin Schulze]

Nacho Barrientos Arias wrote:
> > Nacho Barrientos Arias wrote:
> > > > It appears to me that the DM concept as sketched in the GR is mainly
> > > > meant to let NMs upload earlier, i.e. it tries to fix the fact that
> > > > front-desk or DAM approval take too long. I think the fix for that is
> > > > just to find someone besides Joerg to also read the AM reports. DMs as
> > > > in the GR are a workaround, not a solution.
> > > 
> > > IMHO DMs is something Debian needs, a bunch of people stuck at NM is
> > > perfectly able to upload high quality packages themselves but
> > > otherwise I completely agree with the paragraph above. DMs is a small
> > > patch, not a solution.
> > 
> > With your rationale, NMs who maintain packages well and are sufficiently
> > clueful should be granted upload rights even before finishing NM, instead
> > of the invention of a second class of maintainers.
> 
> (Perhaps my bits were a bit fuzzy)
> 
> No. NMs should be granted upload rights as soon as they finish the NM
> process (but a faster and a more productive one). We don't need to
> reinvent the wheel, we have a fantastic NM infrastructure that only
> needs more care.
> 
> The above is the ideal situation, but if it is not possible then the
> DM starts making sense and I will support it.

Then we should first take step one and adjust the NM process before
we should go to step n which would be the introduction of DM.


Regards,

Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erdös


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

Re: On the "Debian Maintainers" GR

[Martin Schulze]

Andreas Barth wrote:
> * Holger Levsen ([EMAIL PROTECTED]) [070727 13:02]:
> > Sure. But why shouldnt trusted non-DDs not be able to upload their teams 
> > packages? And a subscriber and active Debian Edu developer I think it would 
> > make complete sense and would be helpful, if certain non-DDs from our team 
> > (not all of them, but I have 2-3 in mind) could upload to Debian.
> 
> First of all, why don't these people become DDs? :))

Didn't Skolelinux wish to prepare new contributors for NM and thus DD?

Regards,

Joey

-- 
The MS-DOS filesystem is nice for removable media.  -- H. Peter Anvin


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

Re: On the "Debian Maintainers" GR

[Martin Schulze]

Andreas Barth wrote:
> * Martin Schulze ([EMAIL PROTECTED]) [070728 11:37]:
> > Andreas Barth wrote:
> > > * Holger Levsen ([EMAIL PROTECTED]) [070727 13:02]:
> > > > Sure. But why shouldnt trusted non-DDs not be able to upload their 
> > > > teams 
> > > > packages? And a subscriber and active Debian Edu developer I think it 
> > > > would 
> > > > make complete sense and would be helpful, if certain non-DDs from our 
> > > > team 
> > > > (not all of them, but I have 2-3 in mind) could upload to Debian.
> > > 
> > > First of all, why don't these people become DDs? :))
> > 
> > Didn't Skolelinux wish to prepare new contributors for NM and thus DD?
> 
> That's ok. Then, the right step would be that these people become DDs.

They will.  After they have passed NM to which they are motivated.

Regards,

Joey

-- 
The MS-DOS filesystem is nice for removable media.  -- H. Peter Anvin


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

Re: The Debian Maintainers GR

[Martin Schulze]

Pierre Habouzit wrote:
> > Why are you setting up a buildd network not handled by the buildd admins 
> > and by DSA ? (No need to reply, it's just to show you the parallel)
> 
>   Nice ad-hominem. It's always a pleasure to see how easily you fall in
> those traps when you don't have proper arguments to use.

I'm crying!

>   ftbfs.de is dealing with volatile, experimental buildd's, non official
> architectures. Thing that I'd have personally liked to see dealt with
> by debian.org and DSA. Sadly, DSA is AWOL/unresponsive/whatever. Unlike

FWIW, DSA has about nothing to do with buildds.

Regards,

Joey

-- 
The MS-DOS filesystem is nice for removable media.  -- H. Peter Anvin


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

Re: On the "Debian Maintainers" GR

[Martin Schulze]

Kalle Kivimaa wrote:
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> > arguments in favor of DM the more it's about introverted geeks, and
> > uncoordinated work. Maybe we should care more about people that are nice
> > to users rather about introverted guys that do not care about the rest
   ^^^
> > of the world, shouldn't we ?
> 
> I find this comment highly offensive. I'm assuming you are (in part)
> referring to me, and although I am both introverted and a geek, I do
> believe I care about the rest of the world.
  ^

So apparently you're not addressed by Pierre, so why take it
personally offensive?

Regards,

Joey

-- 
The good thing about standards is that there are so many to choose from.
-- Andrew S. Tanenbaum


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

Re: The Debian Maintainers GR

[Martin Schulze]

Joerg Jaspert wrote:
> On 11096 March 1977, Anthony Towns wrote:
> 
> > And there's the usual spin. Not everything's about who has power over
> > whom, Joerg. At least try to have the courage to stand up in public for
> > what you do in private.
> 
> I dont have a problem with it being public.
> I have one with someone just making something public that was private
> *without even asking if its ok*.

Calm down, listmasters have probably already sent him a warning for
this rude behaviour and violation of the code of conduct as they did
with/to Patrick Frank.

Regards,

Joey

-- 
Whenever you meet yourself you're in a time loop or in front of a mirror.


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

Re: Constitutional amendment: reduce the length of DPL election process

[Martin Schulze]

Moritz Muehlenhoff wrote:
> Wouter Verhelst wrote:
> > While we're at it, I've long felt that a one-year DPL term is just too
> > short (because a DPL needs to spend a few months to get worked in, and
> > can't do all that much when the next election is about to turn up for
> > fear of being accused to be campaigning, often leaving only slightly
> > over half a year or so of time for real work to be done). If more people
> > feel like it, I'll draft up an amendment that turns it into a two-year
> > term, or so.
> 
> Please formulate a GR and I'll second it immediately. 18-24 months seems
> sensible, annual elections are a waste of everyone's time.

FWIW, I believe that 2 years is too long, both for the DPL who may have
to assign much more time to it than now, and for the project that may
suffer under one DPL and would suffer even longer.

Regards,

Joey

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.


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

Re: Constitutional amendment: reduce the length of DPL election process

[Martin Schulze]

Marc Haber wrote:
> I think that a longer term could be a good idea. There must be a
> reason why DPLs are usually invisible and unable to address the real
> problems in the project.

Which, of course and quite naturally, simply vanish when they take the
burdon of being DPL another year.

Regards,

Joey

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.


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

Re: Results for General Resolution: Endorse concept of Debian maintainers

[Martin Schulze]

Martin Zobel-Helas wrote:
> Hi, 
> 
> On Sat Aug 04, 2007 at 19:54:00 -0500, Debian Project Secretary wrote:
> > Hi,
> > 
> > The resolution passes, with 386 votes from 345 developers.
> > 
> 
> > The winners are:
> >  Option 1 "Endorse the concept of Debian Maintainers"
> > 
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> 
> So what is the next step now?
> 
> I propose that i reassign all my applicants to aj/buxy and stop being
> AM... Who else will do that?

Sweet.

However, are you sure that burrying NM is a proper response to this
bypass?  What I found very interesting is that several new DDs who
went through NM considered it proper and educating.  Only the last
step meant too much waiting (DAM stage, we all know that).  Thus,
in general, I am not sure that ditching NM would be the proper
action.

Regards,

Joey

-- 
It's time to close the windows.


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

Re: Technical committee resolution

[Martin Schulze]

Holger Levsen wrote:
> Hi Moritz,
> 
> On Thursday 03 April 2008 23:51, Moritz Muehlenhoff wrote:
> > > And if so, what is the plan for wordpress in etch and lenny?
> > I recommend to drop it from Lenny, but if people choose to
> > repeat mistakes I won't waste my time on argueing.
> 
> Thanks for clarifying. Sounds sensible to me, but then I think we should also 
> drop wordpress from etch.

What would that help?  Etch is already released and whoever wanted to
install wordpress most probably has already done so.  Without replacing
the package with an empty dummy package and big warning signs, our
users are left in the dark and won't even notice that.

Regards,

Joey


-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.


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

Re: supermajority options

[Martin Schulze]

John H. Robinson, IV wrote:
> Chris Lawrence wrote:
> > 
> > Except, we're stuck with the non-compromise in the meantime.  If Vote
> > #1 is "rm -rf ftp.debian.org:/debian/pool/non-free", it's going to be
> > a bit of a pain to fix that :-)
> 
> restore from backup.
> 
> restore from snapshot.debian.org
> 
> not that hard.

I guess our ftpmasters will love you.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Re: Debian Project Leader Elections

[Martin Schulze]

Bill Allombert wrote:
> On Wed, Feb 12, 2003 at 11:28:06PM -0600, Debian Project Secretary wrote:
> > Hi,
> > 
> > This is the final day of the nomination period, which started
> >  on 2003/01/24, and shall end on 2003/02/14 00:00:00 UTC. The
> >  campaigning period shall start then. Voting shall start on March 7th
> >  (2003/03/07 0:0:0 UTC), and shall end on 2003/03/28 0:0:0 UTC.
> 
> Is it possible to have a list of people would have nominated themselves
> available during the nomination period and not only after ? Maybe on
>  ?  This list maybe important for someone who
> hesitate to nominate h{is|er}self.

So far, Moshe Zadka, Bdale Garbee
and Martin Michlmayr have nominated.

Regards,

Joey

-- 
A mathematician is a machine for converting coffee into theorems.

Re: [Moshe Zadka ] Independent Count

[Martin Schulze]

Manoj Srivastava wrote:
> Hi,

[No need to cc dwn@ if you post to -vote and/or -devel-announce, monitoring
both always.  Providing a stripped down paragraph, however, would be 
appreciated.]

Rest for Moshe.

> Date: 24 Mar 2003 15:46:05 -
> Cc: [EMAIL PROTECTED]
> From: Moshe Zadka <[EMAIL PROTECTED]>
> Subject: Independent Count
> To: [EMAIL PROTECTED]
> X-Folder: Bulk
> 
> Dear Debian Project Leader,
> 
> As one of the candidates in the DPL elections, I feel that some remarks
> made by the secretary in #debian-devel have caused me to be unable to
> trust his integrity. I do not feel I can trust his words about the voting
> tallies for the upcoming elections. I wish that an independent Debian
> Developer be appointed for calculating the tallies himself. The other
> developer should be a widely trusted developer in the Debian community.
> 
> Thanks in advance for addressing my concerns,
> Moshe Zadka
> DPL Candidate, 2003 Elections

If you can't trust Manoj, who else can you trust in this project?

And do you really believe that people want you as DPL when you are
apparently unable to compress an IRC log to the relevant "offensive"
messages, but send a 300 lines IRC logfile instead?

Regards,

Joey

-- 
Linux - the choice of a GNU generation.

Re: [Moshe Zadka ] Independent Count

[Martin Schulze]

Buddha Buck wrote:
> Martin Schulze wrote (publically to Moshe Zadka):
> >And do you really believe that people want you as DPL when you are
> >apparently unable to compress an IRC log to the relevant "offensive"
> >messages, but send a 300 lines IRC logfile instead?
> 
> Er, in fairness to Moshe, the impression I got from reading the 300 
> lines of IRC logfile was that the log was added, unedited, by Manoj.

Ouch!  In that case I apologize to Moshe for accusing him.

Regards,

Joey

-- 
Linux - the choice of a GNU generation.

Please always Cc to me when replying to me on the lists.

Re: Robonson wins [...]

[Martin Schulze]

Michael Banck wrote:
> On Mon, Apr 21, 2003 at 01:44:38PM +0200, Matthias Urlichs wrote:
> > This election has demonstrated quite nicely that those Debian developers 
> > who voted prefer Martin to any other single candidate. In other words, if 
> > you held a vote which would ask whether to annul the vote and replace 
> > Martin with Brandon, the majority would be against that proposal. 
> 
> Nobody wants to replace Martin with Brandon. Who is this Brandon guy,
> anyway? This Robonson people seem to talk about?

He's one of /THEM/ and, no, I'm not permitted to go into details.

Regards,

Joey

-- 
If nothing changes, everything will remain the same.  -- Barne's Law

Re: GR: Removal of non-free

[Martin Schulze]

Anthony DeRobertis wrote:
> 
> On Jan 2, 2004, at 14:37, MJ Ray wrote:
> 
> >On 2004-01-01 10:50:53 + Kalle Kivimaa <[EMAIL PROTECTED]> wrote:
> >
> >>At the moment that is not a good answer in my opinion, as it would
> >>mean losing much of the current Java support.
> >
> >I thought there were some Java systems which could go in Debian now. 
> >Is that correct?
> 
> Not really. They don't have all the features of the Sun implementation, 
> and much (most?) java software doesn't work with them.

That, however, is no reason to avoid Free Software being added to
Debian.  Having them in main could encourage people to work on
them.  I admit, that the outcome may also be the contrary: People
believe that Debian did a very poor job packaging Java stuff since
"nothing" works.

> Because they don't, as far as their maintainers know, work with any 
> Java in main.

That's something the community (we as well) should work on.

Regards,

Joey

-- 
MIME - broken solution for a broken design.  -- Ralf Baechle

Re: GR: Removal of non-free

[Martin Schulze]

Clint Adams wrote:
> > Almost all the support for non-free in Debian is a free result of
> > our support for free software. The n-m process, the BTS, the PTS, the
> > mailing lists, policy, our security infrastructure, our buildds, our
> > mirror network, release management, buildds all have to exist whether we
> > support non-free or not, and none of them would be significantly simpler
> > or even different if we didn't support non-free. The archive might be
> 
> Which buildds currently build non-free?

None.

Regards,

Joey

-- 
All language designers are arrogant.  Goes with the territory...
-- Larry Wall

Re: one of the many reasons why removing non-free is a dumb idea

[Martin Schulze]

Sven Luther wrote:
> > (One cannot start projects for non-free stuff on Sourceforge, of course,
> > but somebody could setup a similar service for www.nonfree.org. Asking
> > the Alioth admins how difficult that would be might be a good first step)
> 
> Sourceforge is evil and non-free anyway, so we should use savannah ...
> wait, not possible, savannah will not accept non-free stuff, hum ...

apt-get install gforge, Roland Mas worked hard improving the packages
that run on the alioth system.  You can create your own installation
without too much hassle, I guess.

Regards,

Joey

-- 
Life is a lot easier when you have someone to share it with.  -- Sean Perry

Re: summary of software licenses in non-free

[Martin Schulze]

Craig Sanders wrote:
> ALMOST FREE
> ---

While I appreciate your effort, non-free means that the package
doesn't meet the DFSG but can be distributed by Debian and our
mirrors.  According to our own guidelines the packages are not free,
since they fail one or more clauses of our guidelines.  Calling then
"almost free" or "semi-free" is only sham.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Re: summary of software licenses in non-free

[Martin Schulze]

Craig Sanders wrote:
> > > ALMOST FREE
> > > ---
> > 
> > While I appreciate your effort, non-free means that the package doesn't meet
> > the DFSG but can be distributed by Debian and our mirrors.  According to our
> > own guidelines the packages are not free, since they fail one or more 
> > clauses
> > of our guidelines.  Calling then "almost free" or "semi-free" is only sham.
> 
> sorry, but you are wrong.
> 
> most of the packages in that group *ARE* almost-free.  many of them even
> (almost half, at a guess) qualify as 'semi-free' by the FSF's overly strict
> definition.

If they fail our own guidelines for Free Software they are not free, hence
non-free.  Calling them semi-free suggest that they are not, which is wrong.
Calling them so is only sham and will contribute to confusion.

I also consider it critical that the FSF is calling non-free Software
semi-free but that's a different problem we cannot fix.  They also
release documentation that is non-free in our sense, sigh.

Regards,

Joey

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

Please always Cc to me when replying to me on the lists.

Re: A transition plan to fsf-linux.org

[Martin Schulze]

John Lines wrote:
> An easier route to make an ideologically pure Linux distribution, suitable for
> endorsement by RMS and the FSF would be for the FSF, who already have machines
> and infrastructure, to set up a Debian mirror which only contains main and
> re-badge it as fsf-linux. There are quite a number of Debian based 
> distributions

GNU/Linux.

There were still too many references in the packages to non-free stuff,
was the argument I remember from the last such suggestion/discussion.

Regards,

Joey

-- 
We all know Linux is great... it does infinite loops in 5 seconds.
-- Linus Torvalds

Re: General Resolution: Handling of the non-free section

[Martin Schulze]

Henrique de Moraes Holschuh wrote:
> On Tue, 24 Feb 2004, Debian Project Secretary wrote:
> > The next release of Debian will not be accompanied by a 
> > non-free
> > section; there will be no more stable releases of the 
> > non-free
> > section. The Debian project will cease active support of the
> > non-free section. Clause 5 of the social contract is 
> > repealed.
> 
> That's what I call bad timing.  Getting the non-free GR out in the middle of
> the GFDL fiasco crisis?   So far, it looks like we will have to need to
> shunt all GFDL docs to non-free (not to mention other standards, RFCs,
> etc)...  so how can one vote for non-free to be gone entirely?

GFDL fiasco crisis hasn't started yet since the issue is to be ignored for
the release of sarge.

One can (and should!) vote on non-free regardless of the GFDL problems.
In Debian, a package is either free or non-free (and if it is free but
depends on non-free it has to be moved to contrib).  It doesn't matter
if it is non-free due to a patent, dmca or gfdl.

Regards,

Joey

-- 
Long noun chains don't automatically imply security.  -- Bruce Schneier

Re: Proposal: Keep non-free

[Martin Schulze]

Matt Pavlovich wrote:
> I have personally negotiated with several hardware vendors including
> Matrox, Nvidia, and Compaq about making drivers and other support
> software 100% DFSG compliant.  The success has been mixed, but in every
> case, they are beginning to "see the light".  

I'm very glad to read this.

> Nvidia is the #1 or #2 video chip manufacturer in the world.  Removing
> support for their product is not good for Debian.  It will only increase
> support difficulties and alienate new users from trying to use Debian
> software.  Debian must understand that Linux is still *very* new to many
> vendors (software and hardware).  It will take some time for these
> vendors to successfully integrate within the community.

Please keep in mind that the Debian project does not exist to be "good"
for Debian.  Instead it exists to provide the (best and) free operating
system.  The inVidious stuff is definitively not free, and hence should
not contaminate our thoughts and ideology.

> If we abandon non-free, we are essentially telling Nvidia and other
> vendors:
> 
> "Thank you for taking the time to integrate your software onto our
> platform, but your efforts are not good enough and we refuse to
> distribute it."

As long as it is not Free Software I don't see a problem with this.

We cannot include it in Debian anyway, since it is non-free.  If Debian
stops distributing it but people will build ftp.non-free.org, what's
the different from the users' perspective?  A new apt-line.  Oh horror...

> Thanks, but no thanks?!?!?  That is just closed minded and is a slap in
> the face to the vendors that are *writing* software for Linux.  Take a

I rather see it the other way around.  It's a big slap in the face of
Free Software Linux authors that some companies don't provide specs or
free drivers for their products but instead contaminate the kernel with
proprietary and non-free modules.  I'm not only talking about ideological
contamination but also real contamination since some of these drivers
are buggy and render the kernel unusable or crash or do whatever.  People
notice this as *Linux is buggy*, which is not the case, but people don't
recognize this.

Regards,

Joey

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth

Re: Proposal: Keep non-free

[Martin Schulze]

Andreas Barth wrote:
> * Martin Schulze ([EMAIL PROTECTED]) [040226 08:55]:
> > We cannot include it in Debian anyway, since it is non-free.  If Debian
> > stops distributing it but people will build ftp.non-free.org, what's
> > the different from the users' perspective?  A new apt-line.  Oh horror...
> 
> What do we gain from replacing non-free on Debian with
> ftp.non-free.org?

ftp.non-free.org would not have to be maintained by Debian, contrary
to ftp.debian.org.

Regards,

Joey

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth

Re: Proposal: Keep non-free

[Martin Schulze]

Sven Luther wrote:
> > We cannot include it in Debian anyway, since it is non-free.  If Debian
> > stops distributing it but people will build ftp.non-free.org, what's
> > the different from the users' perspective?  A new apt-line.  Oh horror...
> 
> Because most probably, nobody will build ftp.non-free.org. I would be
> happy to be proven the contrary though, and once such an alternative
> structure is up, and works in an acceptable way, then i would see no
> opposition to move non-free to it. But upto now, i have seen only empty
> words about it. Is the free software/open source way of doing not : show
> the code, and if it is good, let's use it. The same should go in this
> case.

Sounds like a henn-and-egg problem to me:

 1. as long as non-fre is distributed through debian.org nobody
will build nonfree.org.

 2. as long as nonfree.org isn't functional, debian.org cannot
(should not?) stop distributing non-free.

For this, I'd just say, stop distributing non-free through debian.org
and wait for the demand to build nonfree.org by the people interested
in such a repository.  There are some Debian people insterested in,
so that the know how from debian.org can/will be used as well.

Regards,

Joey

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth

Re: Proposal: Keep non-free

[Martin Schulze]

Andreas Barth wrote:
> * Martin Schulze ([EMAIL PROTECTED]) [040226 10:25]:
> > Andreas Barth wrote:
> > > * Martin Schulze ([EMAIL PROTECTED]) [040226 08:55]:
> > > > We cannot include it in Debian anyway, since it is non-free.  If Debian
> > > > stops distributing it but people will build ftp.non-free.org, what's
> > > > the different from the users' perspective?  A new apt-line.  Oh 
> > > > horror...
> 
> > > What do we gain from replacing non-free on Debian with
> > > ftp.non-free.org?
>  
> > ftp.non-free.org would not have to be maintained by Debian, contrary
> > to ftp.debian.org.
> 
> Is there someone to maintain ftp.non-free.org than, or is this just a
> theoretical case?

Since both nonfree.org and non-free.org are registred to Debian people
I'd assume they to be willing to maintain it as well.

Regards,

Joey

PS: Wasn't this discussed one month ago already?

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth

Re: OT: Progeny Linux

[Martin Schulze]

David N. Welton wrote:
> > Easy one. As seen on debian-devel@ recently, Progeny (I think,
> > correct me if I'm wrong) has this Componentized Linux idea. Which is
> > all nice and good, and should help custom distros all right. So, the
> > plans are set straight already.
> 
> I saw Ian's online journal as linked by LWN, but can anyone point me
> to something more specific?  It sounds very vaporwareish to me, but
> maybe there is some substance to it that I'm missing.  Links to -devel
> discussions are ok.

Matt Black added  to
DWN which seems to contain more information.  Here's Ians weblog:


Regards,

Joey

-- 
Testing? What's that? If it compiles, it is good, if it boots up, it is perfect.

Re: Questions to candidates

[Martin Schulze]

Zenaan Harkness wrote:
> > No.  Debian is about creating a operating system with free software,
> > and I don't think we should be in the business of distributing
> > non-free software.  I think we should focus on what we do best (create
> > and integrate free software), and this would also get us closer to
> > other players in the community, such as the FSF.
> 
> What about Debian distributing documentation - do you see it as
> software, do you see all documentation (eg. philosophical) as software?
> 
> Eg. GFDL documentation?
> RFCs?

*cough* POSIX manpages?

Regards,

Joey

-- 
Testing? What's that? If it compiles, it is good, if it boots up, it is perfect.

Re: Questions for candidates -- Debian's Organizational Structure

[Martin Schulze]

Branden Robinson wrote:
> I think the following roles should be formally delegated:
> FTP Archives
> Release Manager
> Release Manager for "stable"
> Bug Tracking System
> Mailing Lists Administration
> Mailing Lists Archives
> New Maintainers Front Desk
> Developer Accounts Managers
> Keyring Maintainers
> Security Team [3]
> Web Pages [3]
> System Administration
> LDAP Developer Directory Administrator
> DNS Maintainer (hostmaster)
> Hardware Donations Coordinator
> Accountant
> 
> It's possible some of the above roles should be condensed into one.

Out of curiosity, do you plan to only formally make the people working
in these departments delegates?  If not, do you plan to fill the roles
with different people than today?

> > Do you believe the Tech Committee is effective in its role for the
> > project?
> 
> I suspect not; as I stated in my platform[2]:
> 
>   I will reactivate the Technical Committee -- which has fallen dormant
>   again -- or amend the Constitution to replace it with a body that
>   works better. That almost a year has gone by with no mail to the list
>   (apart from a test message by Wichert Akkerman), let alone a dispute
>   to resolve, makes me suspect that this body has lost the confidence of
>   the developers. I'd like to work with the members of the Committee
>   that are still interested in serving to see how this body can be
>   improved and revitalized.

I wonder why reviving the CTTE has to wait until you become the project
leader.

Regards,

Joey

-- 
Linux - the choice of a GNU generation.

Re: tb's questions for the candidates

[Martin Schulze]

Gergely Nagy wrote:
> How would I manage the conflict? There's no problem. I'll just split
> into two, or duplicate myself.

I ... WANT ... THIS ... TECHNOLOGY !!!

Regards,

Joey

-- 
Linux - the choice of a GNU generation.

Re: drop or keep non-free - from users viewpoint

[Martin Schulze]

Sven Luther wrote:
> On Mon, Mar 08, 2004 at 11:46:42AM -0800, Thomas Bushnell, BSG wrote:
> > Sven Luther <[EMAIL PROTECTED]> writes:
> > 
> > > If i am stopped from maintaining the driver for the ADSL modem that
> > > provides me access to the internet, and thus enables me to do my debian
> > > work, will you step in and pay me (and others who use the same modem) a
> > > new adsl modem that is supported by non-free software.
> > 
> > How could the removal of non-free stop you from maintaining the
> > driver?  
> 
> No more BTS ? no more download area.

Why shouldn't there be a bugs.nonfree.org?  Cloning the Debian BTS requires
work and copying the non-free bugs over as well, and you'd lose the ability
to reassign bugs from and to free packages to and from non-free packages
but since the archives would be separated anyway, I don't consider this as
a big problem.

The download area would probably be ftp.nonfree.org, I guess.  I don't
think that you as developer would lose access to it and I also don't
believe that users would lose the ability to download non-free packages.
There may be a problem during the transition, of course.

Regards,

Joey

-- 
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

Re: drop or keep non-free - from users viewpoint

[Martin Schulze]

Eduard Bloch wrote:
> > > do you mean the default source.list after installation? Does the sarge
> > > installer also not ask the user if he want to include non-free? 
> > 
> > Yes.
> 
> Then we should change it again.

Yes, we should.  The possibility to add 'non-free' shouldn't be mentioned
at all.  People who want to use that software, should add the line to the
apt config file on their own.  It's not that difficult and it would also
emphasise the fact that non-free is not part of Debian, but only uses some
amount of the Debian infrastructure.

Regards,

Joey

-- 
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

Re: drop or keep non-free - from users viewpoint

[Martin Schulze]

Sven Luther wrote:
> On Tue, Mar 09, 2004 at 08:22:15AM +0100, Martin Schulze wrote:
> > Sven Luther wrote:
> > > On Mon, Mar 08, 2004 at 11:46:42AM -0800, Thomas Bushnell, BSG wrote:
> > > > Sven Luther <[EMAIL PROTECTED]> writes:
> > > > 
> > > > > If i am stopped from maintaining the driver for the ADSL modem that
> > > > > provides me access to the internet, and thus enables me to do my 
> > > > > debian
> > > > > work, will you step in and pay me (and others who use the same modem) 
> > > > > a
> > > > > new adsl modem that is supported by non-free software.
> > > > 
> > > > How could the removal of non-free stop you from maintaining the
> > > > driver?  
> > > 
> > > No more BTS ? no more download area.
> > 
> > Why shouldn't there be a bugs.nonfree.org?  Cloning the Debian BTS requires
> > work and copying the non-free bugs over as well, and you'd lose the ability
> > to reassign bugs from and to free packages to and from non-free packages
> > but since the archives would be separated anyway, I don't consider this as
> > a big problem.
> 
> And how do i reassign a bug to ppp for example then ? 

You close the bug in the nonfree.org BTS and open it again in the
debian.org BTS, copying as much information as are useful.

It's not as nice as before, of course, but non-free won't use the
Debian infrastructure anymore as well.  I believe that this is
an acceptable hassle.

You can't move bugs between the Debian and the GNOME, KDE, Mozilla
etc. bug tracking systems either and this  is acceptable already.

Regards,

Joey

-- 
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

Re: Proposal: Keep non-free

[Martin Schulze]

Andrew Suffield wrote:
> > > >hardware manufacturers (in the last instance) only. Do you think that
> > > >they produce everything built in their devices?
> > > 
> > > Do you really think that hardware manufacturers don't decide what to 
> > > build into their devices?
> > 
> > Of course they do, but they have different primary goals, eg. produce
> > the hardware product in this century, make it good enough to sell enough
> > of it. Or do you prefer hardware that is 10 times slower or incompatible
> > to what 95% of the market uses, beeing 200% more expensive?
> 
> Ah, the old argument that says free software can never possibly work
> or compete with commercial software.

fwiw: free software and commercial software don't exclude each other.
Guess you are referring to proprietary software instead.

Regards,

Joey

-- 
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

Re: drop or keep non-free - from users viewpoint

[Martin Schulze]

Manoj Srivastava wrote:
> > requires work and copying the non-free bugs over as well, and you'd
> > lose the ability to reassign bugs from and to free packages to and
> > from non-free packages but since the archives would be separated
> > anyway, I don't consider this as a big problem.
> 
>   But, I suspect, you  are not planning on doing this work, so
>  whether you feel it is a big problem or not does not help in bringing
>  the hypothetical to fruition. 

Wrong.  I'd be willing to help setting nonfree.org up.  This issue
is a pain in the ass already, hence I'll be happy to get it off of
the table.

>   And where would the box and bandwidth dome from? Oh, I see,
>  since it is all hypothetical vapourware, details like that don't
>  matter.

For what it's worth, Daniel Stone already donated a machine for this.

It's probably not the optimal solution, but it's a solution we can
start with and move services to another machine once a donor feels
the need to support Debian users wrt. non-free software.

This proposal is not vapourware nor is it theoretical.  We've discussed
it in small groups already, and I believe it's doable, and probably
will result in *.nonfree.org being operational.  Sorry to disappoint you.

Regards,

Joey

-- 
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

Re: The Ineffectual DPL?

[Martin Schulze]

Adam Heath wrote:
> In the past several years, I have seen a few different DPLs in (in)action.  I
> have not seen the betterment of the Debian Project as a whole(as a result of
> actions the DPLs have done), yet each DPL has said how well they have improved
> the situation.  Additionally, each candidate has vowed to improving Debian,
> yet, in all reality, they will not be able to implement what they desire.

Most of what the DPL does, you don't see.  Most of what they do, I
don't see.  However, I've noticed a lot of what tbm did, since I was
involved in many parts.

The DPL cannot force people to do something.  He only can encourage
people to go a certain path, he cannot force people to actually do so.

However, in order to reach a certain goal, he can try to help people
be able to reach it.  For example, help people get funding to attend
developers meetings.  Help people to fund CD or poster prints to be
given out at conferences.  Help people talk with external entities
about Free Software and the like (saying one is Leader of Debian is
something much different than saying to be a Debian developer).  Most
of this, however, you don't notice because it happens outside of
public mailing-lists.

Regards,

Joey

-- 
Whenever you meet yourself you're in a time loop or in front of a mirror.

Re: Social Contract GR's Affect on sarge

[Martin Schulze]

Andreas Barth wrote:
> * Anthony Towns (aj@azure.humbug.org.au) [040426 07:10]:
> > As this is no longer limited to "software", and as this decision was
> > made by developers after and during discussion of how we should consider
> > non-software content such as documentation and firmware, I don't believe
> > I can justify the policy decisions to exempt documentation, firmware,
> > or content any longer, as the Social Contract has been amended to cover
> > all these areas.
> 
> I can remember that the title was "editorial changes", and I can't
> understand it how this can change the importance of the sections.
> Furthermore, the exceptions till now was not due to the fact that we
> don't require documentation to be free (quite contrary, there was a
> consensus on d-legal about GFDL not free), but due to the fact that we
> want to have enough time to come up with a proper solution.

Well, the changes were editorial to our understanding of the social
contract with regards to freeness of data, especially since this
was discussed over and over on debian-legal before.

Speaking of the GFDL, only those documents released under the GNU FDL
are non-free that make use of invariant sections for anything else
than its license, right?

Hence, every document released under the GNU FDL needs to be checked
for every version, but the FDL doesn't render documentation non-free
inherently, right?  It doesn't render it free inherently, either, which
is very bad since a new version could become non-free unexpectedly.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.

Re: Social Contract GR's Affect on sarge

[Martin Schulze]

Anthony Towns wrote:
> As such, I can see no way to release sarge without having all these
> things removed from the Debian system -- ie main.
> 
> This will result in the following problems:
> 
>   * important packages such as glibc will have no documentation

This should not be too bad given that glibc is not only documented
in its own info files but also in the man-pages package that is
distributed from different sources.

Oh wait, man-pages became non-free upstream recently...

The Debian package was freed, though.

>   * many pieces of hardware will not be supported by the Debian system
> itself

Since we already face this "problem" woody already due to new hardware
being incompatible with older one, only the number will grow.

>   * firmware will need to be split out of the kernel into userspace
> in all cases

It's good when this happens.

>   * firmware will need to be packaged separately from the
> kernel/X in all cases

Apparently.

>   * debian-installer will need to be rewritten to support obtaining
> non-free firmware but not other non-free packages

It would be a clean solution at the end of the day, so this is good.

>   * firmware for drivers needed for booting (network cards
> particularly) will need to be made available as udebs in
> non-free, and separate non-free d-i images will need to be
> made for people relying on that firmware

This is awkward, I admit.  On the other hand, developers also voted
to keep non-free distributed on debian.org machines, so this is a
good chance to support it accordingly, sigh.

> At the rate we're currently going, I don't really expect to be able to
> achieve this this year. In light of the new Social Contract, however,
> I don't believe there are any other decisions I can make in this area.

Thanks for the clarification.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Re: Social Contract GR's Affect on sarge

[Martin Schulze]

Francesco P. Lovergine wrote:
> Did you have a look to FSF-related software in the last few time?

I normally use them, of course.

> Issue a 'man emacs' for instance

What am I supposed to read there?  Mine doesn't say that it's using
the FDL but since its date says it's from 1995 December 7, I doubt
it does.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.