Re: Bits (Nybbles?) from the Vancouver release team meeting

[Sven Luther]

On Mon, Mar 14, 2005 at 05:09:02PM -0800, Steve Langasek wrote:
> On Mon, Mar 14, 2005 at 04:38:35PM -0800, Thomas Bushnell BSG wrote:
> > Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > > The inclusion of ia64 in the release count is a projection, based on
> > > where I believe things are today.  Nothing the release team is doing
> > > ensures that ia64 is going to be a viable port, a year from now when
> > > we're trying to release etch; and nothing says that one or more of the
> > > other ports won't be in a position to meet those criteria and get added
> > > to the release list.
> 
> > How can they be, since they will be off in another archive?  You can't
> > decide now to put an arch in scc and at the same time say you won't
> > know whether it's in tier1 or tier2 until etch is close to release.
> 
> Please re-read the proposal.  Not all the architectures proposed for
> release with etch are architectures that have enough download share to
> justify keeping them on the primary mirror network; these are
> *separate*, if heirarchically related, requirements.

I think one of the things that disturbs me with this is the lep from the
previous plane of selective arch mirroring, to dropping anything but x86 from
the main archive as seems outlined by the announcement.

I really don't understand why we can't have everything on our main archive (on
ftp-master or whatever), and then from there do some clever trick to mirror
the arches depending on workload or whatever, with a small set of all-tier
mirrors, and most mirrors for going for a reduced set of architectures, with
ftp..debian.org DNS resolving to a revolving list of mirrors handling
the arch or whatever.

So, could you clarify what this plan has as consequence for the developer, the
upload queue, the place where packages are stored ? And explain how you got
from the "let's diminish bandwidth requirements of our mirrors by not
mirroring some arches" to the "let's kick most arches out of our archive to a
second-class archive left to fend for itself" that was announced.

> Releasing archs via scc.debian.org (and mirror network) is not an
> obstacle, because scc.debian.org vs. ftp.debian.org is a *mirroring*
> convenience only.  The uploads still all go through
> ftp-master.debian.org, which is where the release action happens.

Ok, that clarifies the above, and is more in touch with what was previously
planned. But why didn't you clearly state that in the announcement ? 

And will mirrors be able to decide which arch they want to mirror ? or will
the set of arches be imposed by debian ? 

Friendly,

Sven Luther


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Steve Langasek]

On Mon, Mar 14, 2005 at 10:39:24AM +0100, Robert Millan wrote:
> On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:

> > To be eligible for inclusion in the archive at all, even in the
> > (unstable-only) SCC archive, ftpmasters have specified the following
> > architecture requirements:

> > [...]

> > - binary packages must be built from the unmodified Debian source
> >   (required, among other reasons, for license compliance)

> Is this a simple sanity requirement (i.e. no hacked crap being 
> uploaded to the archive), or does it imply that all packages in base 
> (or base + build-essential) need to be buildable from unmodified 
> source?

I assume what you're asking here is whether non-GNU/Linux ports have to
have the same base system as the GNU/Linux ports do.  This was not
implied.  The implication here is that you can't have a separate version
of the same source package for your architecture just because the
maintainer isn't willing to accept patches.

> > - the port must demonstrate that they have at least 50 users

> How do you demonstrate that?  Via popularity-contest?

 collect a list of names? :)  Doesn't seem that hard to me, is
there any reason you think it would be?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Release sarge now, or discuss etch issues? (was: Bits (Nybbles?) from the Vancouver release team meeting)

[Christian Perrier]

> I do not understand why the Nybbles team mixed their good news about
> sarge with their foreseeably controversial plans or proposal for etch.

This may have been a strategical error, yes.

For me, the Vancouver meeting goal was obviously the sarge release and
IMHO, they achieved their goal very well.

My interpretation is that doing so, interesting ideas cam to float
around and  were formalized enough for the "post-sarge" plans to be
announced.

We should be realistic : this meeting was a good opportunity of
getting together what we can call "key people" (no offense intended at
all...far from this) and thus a good opportunity for these key people
to make proposals.

OK, experience shows that they should probably have separated the
things about sarge release and the things about post-sarge
ideas/plans/whatever, as everyone knows that *any* proposal made in
Debian triggers a counterproductive flamew^W endless discussion.

I suppose there were reasons for this and I grant the Vancouver
meeting people enough respect for having good reasons...even if this
ends up in being a strategical error.

My personal concern now is avoiding to "throw out the baby with the
bath's water" as we say in French.

OK, the architecture handling is controversial. Fine...this will
probably delay etch more than we would like. But could we please focus
on releasing sarge first? By focus, I also mean avoidn wasting
valuable DD time to endless discussions (no real human can read this
thread already), flamewars and personal attacks (I'm quite saddened by
Julien's hard attacks and proposal to do the Revolution).

This thread obviously shows that some more real life discussions are
needed about post-sarge plans and I don't doubt that involved people
will welcome more contributions and start thinking again.

This is very likely to be my last contribution to this thread
except in sub-threads dealing with sarge release.


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

Re: status of buildds?

[Martin Zobel-Helas]

Hi Ingo,

On Tuesday, 15 Mar 2005, you wrote:
> On Mon, Mar 14, 2005 at 11:37:31PM -0800, Thomas Bushnell BSG wrote:
> 
> > > >The s390 porting team can perfectly well do what the hurd-i386 porting
> > > >team does: build them themselves.  I mean, umm, you don't have to be
> > > >hooked into w-b to upload packages.
> > > Why are some architectures refused the same service that others get?
> > You have to ask w-b for that one.  But regardless, which is better?
> > Do nothing, because w-b isn't doing what s390 wants, or deal with it
> > oneself?  Instead of fighting about who should solve the problems, why
> > not solve it?
> 
> It's the job of w-b admins to add new buildds in a timely manner. If they
> don't do that, they simply fail (one significant part of) their job.
or they just have their reasons not to do.


-- 
Please do NOT CC me, i am reading the lists i am posting to.


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

Re: Vancouver meeting - clarifications

[Sven Luther]

On Tue, Mar 15, 2005 at 08:58:44AM +0100, Andreas Barth wrote:
> Hello, world,
> | - the release architecture must have N+1 buildds where N is the number
> |   required to keep up with the volume of uploaded packages
> The reason for this proposal should be instantly clear to everyone who
> ever suffered from buildd backlogs. :)
> 
> We want that all unstable packages are directly built under normal
> circumstances and that in the even of a buildd going down the arch does
> not suffer noticably.  The long periods of trying to get some RC-bugfix
> in while some arch has a backlog should disappear with etch.

You mysteriously dropped the N should be <= 1 proposal here, which is the one
which generated outcry from the slower arches. Why ? 

> | - the Debian System Administrators (DSA) must be willing to support
> |   debian.org machine(s) of that architecture
> | - there must be a developer-accessible debian.org machine for the
> |   architecture.
> Well, the second point is - I hope - obvious why we want this. This first
> one is just a conclusion of the second.

And what happens if the DSA are not willing to support the architecture but
someone else is ? Do this someone else get invited in the DSA team ? Or as a
DSA assistent for that architecture, with limited or no power on the other
machines of the project ?

> | - the Release Team can veto the architecture's inclusion if they have
> |   overwhelming concerns regarding the architecture's impact on the
> |   release quality or the release cycle length
> This is just more or less an emergency-exit: If we consider an architecture
> really unfit for release, we can use our veto. This is one of the things I
> hope will never happen.

Yes, but it is an all-powerful veto-right, which should be assorted with
adequate counter-limitations to ensure someone will not abuse it in the
future.

> Having said this, this all doesn't exclude the possibility for a
> non-release arch to have some "testing" which can be (mostly) in sync with
> the release architectures testing - just that if it breaks, the release
> team is not forced anymore to hold the strings together.  For example,
> the amd64-people are doing something like that right now.

Yes, but the proposal doesn't invite for this to happen, nor shows clearly
that this is a wanted thing. 

> I hope that this mail is able to shed some light onto these issues. Please
> accept my apologies for the missing information in the first mail.

Thanks for the clarifications,

Friendly,

Sven Luther


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

Re: Debian makes titles

[Christian Perrier]

> Are you happy with that?

People talking about Debian ? Sure.

"Press" misunderstanding issues, no, but this is not the first time.

Sure, we will have (we already have) a nice Internet rumour saying
"Debian drops most architectures". But, well, we have rumours about
nearly anything alors une de plus ou une de moins...:)



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

Re: Another load of typos

[Christian Perrier]

Quoting Florian Zumbiehl ([EMAIL PROTECTED]):
> Hi,
> 
> now that the problems with my last bunch of bug reports on mostly "its"
> vs. "it's" mistakes some months ago seem to be solved, I've found another
> load of typos of the "a" vs. "an" flavor, about 110 in total.

please please please...for anything which can be localized (especially
debconf templates) add something about translations in the bug
reports.

At least pointing the developers to podebconf-report-po for warning
translators that their translation needs an update because the
original English was changed for instance. All they have to do is
installing po-debconf and run this utility from the top of their
package's source tree after making the change and run
debconf-updatepo.

Indeed, typo and spell corrections should not need translation updates
and affected translations can certainly be unfuzzied.WHEN ONE
KNOWS HOW TO DO THIS CLEANLY...:-)

For package descriptions, this is less harmful as indeed there is no
real way to handle translations properly (the DDTP does not really
implement stuff for that and I'm even not sure it is still working
properly).

So, I really suggest that you separate things between package
descriptions and debconf templates. For the latter, plese get in touch
with debian-i18n.



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

Re: status of buildds?

[Aurelien Jarno]

On Tue, Mar 15, 2005 at 08:59:55AM +0100, Martin Zobel-Helas wrote:
> Hi Ingo,
> 
> On Tuesday, 15 Mar 2005, you wrote:
> > On Mon, Mar 14, 2005 at 11:37:31PM -0800, Thomas Bushnell BSG wrote:
> > 
> > > > >The s390 porting team can perfectly well do what the hurd-i386 porting
> > > > >team does: build them themselves.  I mean, umm, you don't have to be
> > > > >hooked into w-b to upload packages.
> > > > Why are some architectures refused the same service that others get?
> > > You have to ask w-b for that one.  But regardless, which is better?
> > > Do nothing, because w-b isn't doing what s390 wants, or deal with it
> > > oneself?  Instead of fighting about who should solve the problems, why
> > > not solve it?
> > 
> > It's the job of w-b admins to add new buildds in a timely manner. If they
> > don't do that, they simply fail (one significant part of) their job.
> or they just have their reasons not to do.
if so, why they don't share them with us instead of saying no?

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: Release sarge now, or discuss etch issues?

[Marc Haber]

On Tue, 15 Mar 2005 09:07:47 +0100, Christian Perrier
<[EMAIL PROTECTED]> wrote:
>My personal concern now is avoiding to "throw out the baby with the
>bath's water" as we say in French.

Dropping the majority of our archictecture is exactly throwing out the
baby with the bath's water (we have the same saying in German).

>OK, the architecture handling is controversial. Fine...this will
>probably delay etch more than we would like. But could we please focus
>on releasing sarge first?

No. The longer the Vancouver Paper stands undisputed, the more it will
be regarded as "widely accepted". If the paper needs being thrown in
its author's faces, it needs to be _now_.

>(I'm quite saddened by
>Julien's hard attacks and proposal to do the Revolution).

I must admit, that he kind of speaks my mind. Of course, that means
that Debian will vanish in its entirety over the time. It is already
hard enough to convince suits to allow using Debian instead of SuSE or
Redhat, but if Debian disintegrates into two or even more sub-Debians,
this will be the end of Debian in commercial settings. _This_ is what
saddens me.

Now, Christian, how would you feel if somebody else would decide to
drop all language efforts besides English, French, German and
simplified Chinese? These feelings are the same feelings that the
porters have _right_ _now_.

Greetings
Marc, i386-only user, but stil concerned about alternative
architectures

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Vancouver meeting - clarifications

[Aurelien Jarno]

On Tue, Mar 15, 2005 at 08:58:44AM +0100, Andreas Barth wrote:
> As Steve wrote
> | The reality is that keeping eleven
> | architectures in a releasable state has been a major source of work for
> | the release team, the d-i team, and the kernel team over the past year;
> | not to mention the time spent by the DSA/buildd admins and the security
> | team.
> Considering the experience of the release team, the number of different
> architectures were _one_ part responsible for release delays - not the only
> one, and the others need also to be solved.
Could you share a little bit more your experience? You say it is part
responsible for release delays, could you tell us why?

> | - the release architecture must have N+1 buildds where N is the number
> |   required to keep up with the volume of uploaded packages
> The reason for this proposal should be instantly clear to everyone who
> ever suffered from buildd backlogs. :)
Which means a lot more buildd. Does the ftpmasters will accept them?

> | - the Security Team must be willing to provide long-term support for
> |   the architecture
> If not, we can't release with that arch. I think this is also quite
> obvious. Of course, one way to get the security team to provide support
> might be to help them.
> 
> | - the Debian System Administrators (DSA) must be willing to support
> |   debian.org machine(s) of that architecture
> | - there must be a developer-accessible debian.org machine for the
> |   architecture.
> Well, the second point is - I hope - obvious why we want this. This first
> one is just a conclusion of the second.
If they don't want, in why a developer-accessible debian.org machine
supported by the arch porter team is a problem?

> | - the Release Team can veto the architecture's inclusion if they have
> |   overwhelming concerns regarding the architecture's impact on the
> |   release quality or the release cycle length
> This is just more or less an emergency-exit: If we consider an architecture
> really unfit for release, we can use our veto. This is one of the things I
> hope will never happen.
Yes, as again, so that empowers don't loose too much power...

> For example, the more architectures are included the longer the migration
> testing script takes.  We are already at the limit currently (and also
> have out-of-memory issues from time to time). For example, currently we
> restrict the number of some hints to only 5 per day to keep up the
> scripts. 
If there isn't enough memory, what about adding some, or changing the
machine doing that job? Not let's drop archs, that's easier...


-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: status of buildds?

[Marc Haber]

On Tue, 15 Mar 2005 08:59:55 +0100, Martin Zobel-Helas
<[EMAIL PROTECTED]> wrote:
>On Tuesday, 15 Mar 2005, you wrote:
>> It's the job of w-b admins to add new buildds in a timely manner. If they
>> don't do that, they simply fail (one significant part of) their job.
>or they just have their reasons not to do.

If so, I would suggest communicating these reasons. Currently, they
don't.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Discussion about tier-2 testing and how to achieve a release of tier-2 arches after all. (Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Sven Luther]

On Mon, Mar 14, 2005 at 11:23:48PM -0800, Steve Langasek wrote:
> On Mon, Mar 14, 2005 at 10:32:57AM +0100, Sven Luther wrote:
> > On Mon, Mar 14, 2005 at 12:23:12AM -0800, Steve Langasek wrote:
> > > On Sun, Mar 13, 2005 at 11:21:29PM -0800, Thomas Bushnell BSG wrote:
> > > > Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > > > > On Sun, Mar 13, 2005 at 10:47:15PM -0800, Thomas Bushnell BSG wrote:
> > > > > > Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > > > > > > The sh and hurd-i386 ports don't currently meet the SCC 
> > > > > > > requirements, as
> > > > > > > neither has a running autobuilder or is keeping up with new 
> > > > > > > packages.
> 
> > > > > > It is impossible for any port under development to meet the SCC
> > > > > > requirements.  We need a place for such ports.  Where will it be?
> 
> > > > > On the contrary, the amd64 port does, and is currently maintained
> > > > > completely outside official debian.org infrastructure.
> 
> > > > The amd64 port did not always.  Ports under development take time; the
> > > > amb64 port is at a late state in its development.  I don't understand
> > > > why autobuilding is important to SCC; maybe if you could explain that
> > > > I would understand.
> 
> > > The point is that the ftpmasters don't want to play host to various
> > > ports that *aren't* yet matured to the point of usability, where "being
> > > able to run a buildd" is regarded as a key element of usability in the
> > > port bootstrapping process.  The amd64 team have certainly shown that
> > > it's possible to get to that point without being distributed from the
> > > main debian.org mirror network.
> 
> > I don't really understand that point though, since the plan is to drop 
> > mirror
> > support for all minor arches, what does it cost to have a 3 level archive
> > support : 
> 
> >   1) tier 1 arches, fully mirrored and released.
> 
> >   2) tier 2 arches, mostly those that we are dropping, maybe mirrored from
> >   scc.debian.org in a secondary mirror network. (why not ftp.debian.org/scc
> >   though ?).
> 
> >   3) tier 3 arches, or in development arches, available on
> >   ftp.debian.org/in-devel or something.
> 
> > I don't see how having the in-devel arches be hosted on alioth instead on 
> > the
> > official debian ftp server would cause a problem.
> 
> > Also, i don't understand why scc.debian.org is better than 
> > ftp.debian.org/scc,
> > really, ideally we could have /debian, /debian-scc, and /debian-devel or
> > something such. Is it really a physical problem fro ftp-master to held all
> > these roles ? What is it exactly that ftp-masters want to drop all these
> > arches for ? 
> 
> Nothing in the SCC plan implies a separate dak instance for
> scc.debian.org vs. ftp.debian.org.  On the contrary, since there are
> release architectures that would not be distributed via ftp.debian.org
> under this plan, it is a requirement that all of the architectures in
> question continue to use ftp-master.debian.org for uploads and the dak
> instance.

Ok. This clarification was missing from your original announcement though, and
there are still questions on how tier-2 arches will be able to setup their own
testing support. Taking snapshots from unstable is not a viable solution.

I understand that the testing scripts doesn't scale well, they run once for
each arch, don't they, but moving testing to per-arch archives as i proposed
in my 'build tier-2 arches from testing' proposal, asks the question of how
the communication between the per-arch testing setup and the tier-1 setup
communicate, and also where an arch porter uploads his arch-specific fixes to.

He can either upload to the tier-1 unstable, with the risk of seing the upload
hold by tier-1 testing-hold-up issues and not trickling down to the per-arch
testing setup, or upload to the per-arch unstable archive, with the risk of
the change getting lost when a new tier-1 upgrade comes.

Ideally the fix should be uploaded to both tier-1 unstable and
per-arch-unstable, and a mechanism setup for holding imports from tier-1
testing until the arch-fix is included in it.

Obviously this needs :

  1) cooperation from the tier-1 maintainers to apply the tier-2 arch fix, and
  suitable workarounds for if the maintainer doesn't do its job (NMU allowed
  after a given set of time or if a new upload was done without fixing the
  arch-specfic problem without a good reason).

  2) a way to workaround packages that are kept out of testing for non-tier-2
  related reasons.

  3) discipline on the porters part to do and follow two uploads, and maybe a
  third if 2) happens, thus imposing a higher workload on them than
  necessarily needed.

I don't know, maybe building from testing is not so good an idea after all,
and some building from tier-1 unstable, with a testing script whose additional
criteria would be for the package to be in tier-1 testing.

Altough building from tier-1 testing is the most natural idea if there is hope
of tier-2 stab

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow ([EMAIL PROTECTED]) [050314 15:35]:
>> Andreas Barth <[EMAIL PROTECTED]> writes:
>> > * Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:45]:
>> >> On Sun, Mar 13, 2005 at 11:16:56PM +0100, Andreas Barth wrote:
>> >> > Our goal is that the queue gets empty from time to time, and so,
>> >> > priority shouldn't prevent a package from being built.
>> >> 
>> >> How often should the queue be emptied, or when will an architecture be
>> >> declarared not-keeping-up?
>> >
>> > In light of
>> > http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html
>> >   the release architecture must have N+1 buildds where N is the number
>> >   required to keep up with the volume of uploaded packages
>> > at least once per day for etch.
>
>> That means no more m68k. Given that some packages compile up to 12
>> days there will be plenty of times the queue doesn't empty once per
>> day.
>
> needs-build can be empty even if packages _are_ currently building.

Not with "N may not be > 2". Say 3 mozilla clones get uploaded. Each
of the N+1 buildds grabs one and ist busy for 5 days. If any other
package gets uploaded in that time the queue will not be empty.

Unless you take packages even while building. But I'm sure a long
"building" queue on the buildds would be cheating and not count.

>> I would like to see some stats showing on how many days in the last
>> year an arch reached 0 needs-build. I highly doubt that any arch
>> managed to do it every day troughout the last year.
>
> You know why goals are important? 0 needs-build is definitly a goal we
> should work to.

I disagree. 0 needs-build once a day is a bad line to draw. Saying
packages must be build a day before they become testing candidates
would be a better line. But that would require a non starving queue to
mean anything but 0 needs-build.

I don't see any great harm with packages getting build 5 days late if
they have to wait 10 days for testing. As long as they do get build on
time.


But what do I know, I'm not an RM. So lets thing about the criterion:

Strictly requiring 0 needs-builds every day means the buildd must have
enough power to cope even with huge upload peeks and if one of the
buildds fail at a peak time no arch will cope with that. Obviously
some leaway will have to be given for arch to temporarily not meat the
criterion, say 0 needs-build on 75% of all days and no more than 3
consecuitve failures wihtout special circumstances or something of
that sort. Right?

Or do you realy want to remove i386 from the release if it fails 0
needs-build 10 times before etch release?

> Cheers,
> Andi
> -- 
>http://home.arcor.de/andreas-barth/
>PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

MfG
Goswin


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Steve Langasek]

Hi Aurélien,

On Mon, Mar 14, 2005 at 10:56:51AM +0100, Aurélien Jarno wrote:
> Steve Langasek a écrit :
> >The much larger consequence of this meeting, however, has been the
> >crafting of a prospective release plan for etch.  The release team and
> >the ftpmasters are mutually agreed that it is not sustainable to
> >continue making coordinated releases for as many architectures as sarge
> >currently contains, let alone for as many new proposed architectures as
> >are waiting in the wings.  
> Would it be possible to have a list of such proposed architectures?

I think this has already been answered, by someone who knows better than
I.

> >This change has superseded the previous SCC (second-class citizen
> >architecture) plan that had already been proposed to reduce the amount of
> >data Debian mirrors are required to carry; prior to the release of sarge,
> >the ftpmasters plan to bring scc.debian.org on-line and begin making
> >non-release-candidate architectures available from scc.debian.org for
> >unstable.
> If scc.debian.org is not mirrored, it would be possible to have much 
> more place than now. Does it means that more architecture could be 
> supported? I am thinking of the SH port that would need to separate
> tree, if I remember correctly.

Well, first, I don't think anyone is keen on the idea of an
scc.debian.org that *doesn't* get mirrored; we know it won't be mirrored
as extensively as ftp.debian.org will be, but we can aspire to it being
useful enough to people that it could be mirrored as extensively as
ftp.debian.org *currently* is.  (Though probably a little less, in
practice.)  Adding a bunch more ports (the SH port is basically 4
different ABIs and counting, at this point) with *no* cost/benefit
analysis on the mirroring front doesn't seem like a good idea to me.

But I'm not sure that the sh ports are far enough along that mirror
space is the limiting factor either; since they have 4 different ABIs to
support, my understanding is that the porters (and the buildds) are
spread rather thin.

> > Note that this plan makes no changes to the set of supported release
> > architectures for sarge, but will take effect for testing and unstable
> > immediately after sarge's release with the result that testing will
> > contain a greatly reduced set of architectures, according to the
> > following objective criteria:
> I would add:
> - there should be at least 2N buildd admins for this architecture. A lot 
> of problems with buildds are caused by buildd admins unavailable at the 
> same time for a given arch.

I don't know that 2N buildd admins is necessary, but I think having >1
buildd admin for a port is a good idea.  I'm not sure it should be
mandatory -- a lot of recent per-arch delays have actually been tied to
the availability of *local* admins, for instance, not to buildd admins
per se.  It bears thinking about what the exact problem being solved
here is that isn't already solved by requiring hot-spare buildds.

> >Architectures that are no longer being considered for stable releases
> >are not going to be left out in the cold.  The SCC infrastructure is
> >intended as a long-term option for these other architectures, and the
> >ftpmasters also intend to provide porter teams with the option of
> >releasing periodic (or not-so-periodic) per-architecture snapshots of
> >unstable.
> My primary desktop machine is an i386, but it was sometimes ago and for 
> a limited period of time and hppa machine, because my i386 had problems. 
> It allowed me to continue my work on Debian packages. In the case this 
> new infrastructure is set up, does upload from a SCC architecture to 
> unstable would still be allowed? If no, source only upload must be 
> allowed again.

Since non-RC (release candidate) architectures are going to be in the
same unstable tree as the RC architectures (uploads to ftp-master,
etc.), I don't see any reason that this would be disallowed.

> >- there must be a sufficient user base to justify inclusion on all
> >  mirrors, defined as 10% of downloads over a sampled set of mirrors
> AFAIK, only i386 currently meet this criterion.

Of the architectures currently in sarge, that's correct.  It's assumed
that amd64 will easily meet this 10% mark for etch.  (If it doesn't,
then the cut-off probably has to be re-thought, since it doesn't make
much sense to have a 1/11 split between ftp.d.o and scc.d.o,
*particularly* when the 11 archs together *would* most likely account
for > 10%.)

> BTW, I am not sure this is really a good way to measure the use of an 
> architecture, mainly because users could use a local mirror if they have 
> a lot of machines of the same architecture. How about using popcon *in 
> addition* to that?

This isn't being used to measure the use of the architecture; it's being
used to measure the *download frequency* for the architecture, which is
precisely the criterion that should be used in deciding how to structure
the mirror network.

> >To be eligible for inclus

Re: Questions for the DPL candidates

[cobaco (aka Bart Cornelis)]

On Tuesday 15 March 2005 02:50, Anthony Towns wrote:
> cobaco (aka Bart Cornelis) wrote:
> >>That's why it's posted on the lists now -- it never too late to get
> >>input into something in Debian; even after we've committed to
> >> something, we can almost always change our minds.
> >
> > er, saying "we've committed to this" really comes across as a 'fait a
> > compli' to a lot of people.
>
> Any "proposal" made by all the people who'll have to implement it is
> going to come across as a fait accompli, no matter how you phrase it.
> And, to some extent, that's exactly the right reaction.

 from the discussion going on in this thread I gathered that neither the 
porters, nor the security team, nor the kernel team was present in 
Vancouver, I would definately class them as part of "people who'll have to 
implement this"

> But, I mean, take the above -- I didn't say we'd committed to this; I
> said that if we had, it could *still* be changed -- yet your instinct
> was to take the opposite implication out of it.

right, as other people have mentioned, this proposal was phrased in pretty 
much the worst way possible, that does not help getting the right reaction

> > again I'm missing why's here, it may be obvious to members of the
> > release team, but it's not obvious to me (nor it would seem a lot of
> > other people on the list), and an "I think" does not tell me anything.
>
> There're a range of reasons, most of which probably won't be obvious to
> everyone 'til after the fact. 
which is why I would expect whoever makes the proposal to explain the 
reasons.

> Having more flexibility to bend the release requirements, and 
> being able to choose to focus porting efforts on a stable target instead
> of a moving one are useful features for some ports, though, I think. 
doesn't the Vancouver proposal say that tier-2 architectures would be based 
on unstable? I'd hardly call that a stable target. As proposed elsewhere in 
the thread testing would be better if that's the goal.

> >  if you want a technical discussion intead of a political one it helps
> > to
>
> ...not have it on a Debian mailing list. :-/
ok, while you do have a point (to some extend), explaining things would at 
least cut down on the peripheral stuff considerably.

-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)


pgpYHJGSOE9ov.pgp
Description: PGP signature

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Philip Charles]

On Tue, 15 Mar 2005 20:04, Sven Luther wrote:
> On Tue, Mar 15, 2005 at 07:32:12AM +0100, Marc Haber wrote:
> > On Mon, 14 Mar 2005 22:51:40 +0100, Sven Luther
> >
> > >> Do not expect mirror admins to run Debian, and to be willing to
> > >> pull smart mirroring tricks.
> > >
> > >What do they use now ?
> >
> > I know the mirror admin of one of the tier-2-Mirrors. His box runs
> > RedHat, and mirrors Redhat, SuSe, FreeBSD, OpenBSD, kernel.org and a
> > bunch of other sites, and he uses plain rsync.
>
> Even plain rsync can do smart things.
>
> > I am not even sure whether ftp2.de.debian.org even pulls tricks to
> > mirror the pool first and dists last.
> >
> > >And does it not allow already to mirror only woody or
> > >only some arches ?
> >
> > How can tht be accomplished without reading the Packages files?
>
> Well, it could be done by doing a first mirroring from the main archive
> to some special url the mirrors get, this is the most naive solution, i
> am sure there are many more.
>
> > > Or at least there is plan to allow for this ?
> >
> > I hope so, but our ftpmasters seem to be committed to reduce archive
> > sites by completely dropping arches.
>
> That is the new development, previously per-arch mirroring, or dropping
> some arches from the mirror network was considered, so there must be a
> solution for that.
>
Many of the mirrors I have investigated are only partial - no source; no 
architecture A, B or C.  However, most do carry stable, testing and 
unstable.  Its no great deal running a partitial mirror, debmirror is 
designed for this.  Mind you I had worked an alternative solution before 
discovering debmirror and no doubt others have done the same.

Phil
--
  Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand
   +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420
 [EMAIL PROTECTED] - preferred.  [EMAIL PROTECTED]
  I sell GNU/Linux & GNU/Hurd CDs & DVDs.   See http://www.copyleft.co.nz


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

debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Sven Luther]

On Mon, Mar 14, 2005 at 04:51:55PM -0800, Matt Zimmerman wrote:
> On Tue, Mar 15, 2005 at 01:14:30AM +0100, Sven Luther wrote:
> 
> > On Mon, Mar 14, 2005 at 06:10:30PM -0500, Andres Salomon wrote:
> > > Yes, I would like to reiterate that coordination between Martin Pitt, the
> > > Ubuntu kernel team, and the Debian kernel team has been an invaluable
> > > resource for Debian; there are a lot of security fixes in Debian
> > > kernels that were brought to my attention by either Fabio or Martin.
> > 
> > Because they are in the security-announce-loop and we are not though, right 
> > ? 
> 
> Can you restate the question more clearly?  In particular, expand the
> pronouns "they" and "we", and explain what the security-announce-loop is.

There is this vendor-specific-security-announce-with-embargo thingy.

The debian kernel team mostly handles the unstable and testing kernel, is not
in the loop for getting advance advice on those problems, so we cannot build
fixed versions until the vulnerability gets announced, and thus we can't
upload kernels in a timely fashion like ubuntu or other vendors do, who often
have a couple week of advance warnings. On slower arches this could be a
problem.

The debian-security team is handling stable only, and there are no security
updates for unstable until way after the embargo is over, and for testing a
bit after that, depending if the kernels get hinted in or not.

To have proper security-in-testing-or-unstable for the kernel, the
debian-kernel security team, or at least a few members of it, need to be made
aware of the embargoed security holes, and get a chance to fix them in
advance, maybe with a private or security non-public copy of our svn tree
(using svk maybe).

This is not a ubuntu related problem though, and the help the ubuntu
kernel/security team has provided us was invaluable, but it should maybe not
be necessary if the information was not unrightfully hold from us in the first
time.

Friendly,

Sven Luther


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

Requireing 98% built sources (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[David Schmitt]

On Monday 14 March 2005 22:30, Bdale Garbee wrote:
> [EMAIL PROTECTED] (David Schmitt) writes:
> > On Monday 14 March 2005 11:10, Rene Engelhard wrote:
> >> pcc is barely at 98%. I don't think that barrier should be that high. We
> >> *should* at last release with the tree most important archs: i386,
> >> amd64, powerpc.
> >
> > Please, 98% is not high. It is just a call to porters to get their act
> > together.

[much agreeable stuff]

> The real question on the day of release is what the build percentage of
> 'testing' is for each architecture, and that's a pretty easy place to drive
> the numbers near or to 100% if we think it's important enough!

The 98% are a requirement to reach tier-1 with testing-major and FTBFS==RC 
status. As with policy changes DDs have to "show the code" first before they 
get the "official" stamp. As you correctly say, once an arch enters tier-1, 
testing should stay at >98% built. Which still forces the archto stay ahead 
of the 98% in unstable, I would guess that to prevent a drooping arch from 
delaying the whole project too much.


On a tangent, some sentences I wrote before understanding your paragraph:

If an arch that would be tier-1 otherwise is dropped two days before etch 
releases because there are only 97.999% built sources after demonstrating the 
ability to reach 99+% for months, I would call the decisionmaker nuts.

If on the other hand the arch in question was never able to prove consistent 
buildd performance they probably also are not able to consistently and 
instantly react on security issues and have a much higher probability to 
cause shlib-skew and testing-propagation hold-ups.


Regards, David

-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> Op ma, 14-03-2005 te 17:59 +0100, schreef Goswin von Brederlow:
>> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>> 
>> > Op vr, 11-03-2005 te 19:14 -0800, schreef Steve Langasek:
>> >> The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
>> >> sorted by:
>> >> 
>> >> - target suite
>> >- previous compilation state (already built packages are prioritized
>> > above packages never built for the target architecture)
>> >>   - package priority
>> >> - package section
>> >>   - package name
>> >> 
>> >> I personally believe it would be beneficial to prioritize by upload 
>> >> urgency
>> >> as well (probably as a sort criterion between package priority and package
>> >> section), but the w-b maintainers disagree.
>> >
>> > I agree with the w-b maintainers. The queue order is only interesting in
>> > the case where there is a backlog; in other cases, packages are usually
>> > built rather fast. In the case where there is a backlog, those trying to
>> > fix the architecture (usually those that are working on it) should be in
>> > charge of deciding what package gets built first, not the maintainer of
>> > a random package -- /all/ package builds are urgent if there's a
>> > backlog.
>> 
>> Since you think an empty queue is normal why then fight changes to the
>> queue order?
>
> You misunderstood. I don't fight generic changes to the order; I just
> don't think it would be a good thing that any random developer could
> prioritize his pet package.

My suggestion is to use an aging algorithm with "time * alpha +
beta". Aspects of a source would then affect alpha and beta.

Example:

- Essential: yes adds 100 to beta and 5 to alpha.
- Urgency: critical adds 10 to beta and 1 to alpha

The package with the highest score gets build first. Alpha makes a
package advance the queue faster overtaking other packages while beta
makes packages start further up in the queue.

By adjusting the changes to alpha and beta each aspect of a source can
be finely tuned to have some affect on the queue. So random developer
can influence the priority by setting the urgency but not so much as
to abuse the power and deadlock other packages.


Instead of the urgency of uploads the number of bugs (weighted by
priority) could be used instead or on top of that. Or the number of
depends, revers depends, dep-waits,  A lot of aspects could be
added up to set alpha and beta for each package.

Even alpha=1, beta=- and time in
minutes would be an improvement. That would mean that after 6 days any
package would be build before a fresh upload of the most essential
package.

MfG
Goswin


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

Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Joey Hess]

Sven Luther wrote:
> There is this vendor-specific-security-announce-with-embargo thingy.
> 
> The debian kernel team mostly handles the unstable and testing kernel, is not
> in the loop for getting advance advice on those problems, so we cannot build
> fixed versions until the vulnerability gets announced, and thus we can't
> upload kernels in a timely fashion like ubuntu or other vendors do, who often
> have a couple week of advance warnings. On slower arches this could be a
> problem.
> 
> The debian-security team is handling stable only, and there are no security
> updates for unstable until way after the embargo is over, and for testing a
> bit after that, depending if the kernels get hinted in or not.
> 
> To have proper security-in-testing-or-unstable for the kernel, the
> debian-kernel security team, or at least a few members of it, need to be made
> aware of the embargoed security holes, and get a chance to fix them in
> advance, maybe with a private or security non-public copy of our svn tree
> (using svk maybe).
> 
> This is not a ubuntu related problem though, and the help the ubuntu
> kernel/security team has provided us was invaluable, but it should maybe not
> be necessary if the information was not unrightfully hold from us in the first
> time.

You seem to be implying that ubuntu is providing you with confidential
prior warning about kernel security holes, but I really doubt this,
since many of the ubuntu secutity advisories that I've backchecked
against the debian kernels have turned out to still be unfixed in the
kernel teams's svn weeks later.

My experience is that the kernel security team is not very quick to fix
publically known security holes, or to make uploads specifically for
those holes once they have a fix. Even if we limit it to fixing the
kernel-source packages and ignore the whole issue of rebuilding
kernel-image packages for all arches.

-- 
see shy jo


signature.asc
Description: Digital signature

Dropping from mirror network vs dropping from tier-1 (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[David Schmitt]

On Monday 14 March 2005 19:36, Sven Luther wrote:
> Well, as long as the discussion is on dropping from the mirror network,
> yes, you may be right, but the proposal is to drop from stable/testing
> altogether, isn't it ?

Quoting from the Nybbles proposal:

"[...] the list of release candidate
architectures will be further split, with only the most popular ones
distributed via ftp.debian.org itself.  The criterion for being distributed
from ftp.debian.org (and its mirrors) is roughly:

- there must be a sufficient user base to justify inclusion on all
  mirrors, defined as 10% of downloads over a sampled set of mirrors
"

Elsewhere I believe Steve mentioned, that earlier versions had tier-1 == 
ftp.d.o, but that this was dropped (exactly because of arches like s390 who 
should be able to reach tier-1 easily, but really have no reason to be on the 
mirror network).


Regards, David

-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
  -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Steve Langasek]

On Mon, Mar 14, 2005 at 11:00:12AM +0100, Sven Luther wrote:

> > There are a few problems with trying to run testing for architectures
> > that aren't being kept in sync.  First, if they're not being kept in
> > sync, it increases the number of matching source packages that we need
> > to keep around (which, as has been discussed, is already a problem);
> > second, if you want to update using the testing scripts, you either have
> > to run a separate copy of britney for each arch (time consuming,
> > resource-intensive) or continue processing it as part of the main
> > britney run (we already tread the line in terms of how many archs
> > britney can handle, and using a single britney check for archs that
> > aren't keeping up doesn't give very good results); and third, if
> > failures on non-release archs are not release-critical bugs (which
> > they're not), you don't have any sane measure of bugginess for britney
> > to use in deciding which packages to keep out.

> What about building the scc (or tier 2 as i would say) arches from testing and
> not unstable ? this way you would have the main benefit of testing (no RC
> bugs, no breakage of the day kind of problems). Obviously this means you would
> need some kind of override for per-arch fixes, but preferably these fixes will
> be applied twice, once to the per-arch repo, and then to a new unstable upload
> which fixes the problem. Uploading only to unstable may cause undue delays.

Building against testing instead of against unstable also means you
don't have any of the controls testing is supposed to provide to protect
against uninstallable packages: as soon as you build a new library
package, everything that depends on it is uninstallable.

This really makes unstable snapshotting, or building stable once it's
released as Anthony has also suggested in this thread, look like much
better options than trying to build out of testing.

> > For these reasons, I think the snapshotting approach is a better option,
> > because it puts the package selection choices directly in the hands of
> > the porters rather than trying to munge the existing testing scripts
> > into something that will make reasonable package selections for you.

> So, why don't you do snapshoting for testing ? Do you not think handling all
> those thousands of packages manually without the automated testing thinhy
> would be not an over-burden for those guys ? 

> You are really just saying that the testing scipts don't scale well, and
> instead of finding a solution to this, you say let's drop a bunch of 
> architecture,
> and make it another-one's problem.

I think we should discuss various solutions to address the needs of
porters involved in non-release archs.  I think trying to run a full
testing infrastructure, or build against testing instead of unstable, is
unlikely to be a good solution for those porters in practice because of
some of the issues that I've pointed out.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Security support on tier-2 (was: Re: COUNT(buildd) IN (2,3))

[David Schmitt]

On Monday 14 March 2005 20:07, Julien BLACHE wrote:
> Stephen Gran <[EMAIL PROTECTED]> wrote:
> >> > Thus the problem is less in the development and more in the support
> >> > of testing requirements (all arches in sync) and stable support
> >> > (security response time). Therefore the N<=2 requirement is only
> >> > needed for tier-1 arches but not for the tier-2 which will not
> >> > officially release a stable.
> >>
> >> What is the detailed reasoning for this requirement anyway ?
> >
> > I thought that was fairly clear - a 12 day build of a security fix is
> > unacceptable, especially since it hampers getting that fix out the door
> > for everyone else.
>
> Then we have to adjust our security support policy. Define Tier-1
> archs for security support, release updates for them first. Then for
> the others. I fail to see how this could be a problem.

The problem for me is on machines (like my old sparc nameserver, providing 
service for 1500 users, being attacked multiple times a day) where receiving 
a security update days later[1] is no option. Having sparc in tier-1 without 
zero-day security updates would be no use to me, because I couldn't honestly 
say that "all tier-1 architectures are fit for production use and properly 
supported by Debian."


I don't know what to do with tier-1.5 arch fulfilling everything except prompt 
security updates.


Regards, David

[1] Time to Exploitation after announcement is going down to hours. Attack 
rates are in the some-per-hour range. Prototype flashworm simulations reach 
99% infection in seconds. And I don't see how it is getting any better.
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Vancouver meeting - clarifications

[Bas Zoetekouw]

Hi Andreas!

You wrote:

> As Steve wrote
> | The reality is that keeping eleven
> | architectures in a releasable state has been a major source of work for
> | the release team, the d-i team, and the kernel team over the past year;
> | not to mention the time spent by the DSA/buildd admins and the security
> | team.
> Considering the experience of the release team, the number of different
> architectures were _one_ part responsible for release delays - not the only
> one, and the others need also to be solved.

OK, but I doubt that dropping architectures is the only way of solving
this.  Wouldn't it be possible for example to expand the release team?
Or by better collaboration between porters and the release team?  Or by
changing or enhancing the infrastructure?

I find it a bit hard to believe that Debian isn't able to support 11
architectures while for example FreeBSD and NetBSD seem to manage fine.

> For example, the more architectures are included the longer the migration
> testing script takes.  We are already at the limit currently (and also
> have out-of-memory issues from time to time). For example, currently we
> restrict the number of some hints to only 5 per day to keep up the
> scripts. Also, the udebs are not taken into account, which requires more
> manual intervention. With a lower number of release architecture, we can
> and will improve our scripts.

So to me the obvious thing to do seems to improve the scalability of the
testing scripts rather than dropping lots of architectures.


To summarize, I have the feeling that the conclusion that the number of
supported architectures is the real underlying problem, was made too
fast.  As far as I've been able to gather from the other thread, two
problems were mentioned that need to be solved to speed op the releases:
 1. not enough manpower/too much work for the ftp-masters, release team,
security team;
 2. mirror bandwidth/space problems;
and you've just told about this one:
 3. testing scripts scalability problems.

It seems to me that these are the real problems that need to be solved,
and it's not obvious to me that dropping 8 architectures is the way to
do it.  For example, as the number of packages keep growing, the same
problems will resurface --- even if we have lots less architextures to
take care off ---  and those will have to be solved in some other, more
fundamental way.

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 


signature.asc
Description: Digital signature

Re: Vision for the future (was: Re: COUNT(buildd) IN (2,3))

[David Schmitt]

On Monday 14 March 2005 19:38, Sven Luther wrote:
> On Mon, Mar 14, 2005 at 07:17:08PM +0100, David Schmitt wrote:
> > Both are currently "happening." The current release and security teams
> > say that they cannot support the tier-2 arches for etch. The porters jump
> > up and prove them wrong by creating
> > stable-with-security-updates-after-two-weeks and eventually we will have
> > timely Debian stable releases people can trust their jobs on and Debian
> > stable-with-security-updates-after-two-weeks releases for
>
> Which end done doing less because they have to duplicate all the
> architecture already in place for tier1, no ?

I believed that to be the point of this whole thread: the people who do this 
work for sarge believe that they won't be able to release etch within any 
reasonable timeframe with the current modus operandi.

A specific example: Security updates.

If they are no more than a regular buildd upload, then doing 
stable-with-security-updates-after-two-weeks should be possible without much 
effort from the porters.

If security updates are more than a buildd compiling and uploading a new 
source package after a DSA was released, that is a good hint why the current 
security team is burdened by this and why this should be put on porters 
shoulders.

I know that a stable release is more than security updates, but I think the 
argument holds also for other parts: D-I, package selection, RC-bug handling, 
etc ...

In any way I think the effect should not be a fork of efforts but more people 
adding work where it will help the arch reach tier-1 status or realizing that 
the arch cannot fulfil the (vary) high quality standards Debian/stable 
adheres to.


Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: status of buildds?

[Goswin von Brederlow]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Ingo Juergensmann <[EMAIL PROTECTED]> writes:
>
>> On Mon, Mar 14, 2005 at 08:43:40PM -0800, Thomas Bushnell BSG wrote:
>> 
>> > For s390 and sparc, it appears that only one machine is in place
>> > building these archs.
>> 
>> As Bastian Blank said yesterday on IRC, w-b admins are idly refusing to add
>> a new buildd for s390 to the ACLs. So, blame neuro and/or elmo, not s390... 
>
> The s390 porting team can perfectly well do what the hurd-i386 porting
> team does: build them themselves.  I mean, umm, you don't have to be
> hooked into w-b to upload packages.
>
> If the s390 team is unhappy with w-b, they can simply set up their own
> autobuilding and do it themselves; all the software is free software.
>
> There are probably other solutions too; I find incoherent the concept
> of an "idle refusal".
>
> Thomas

We did that last year for m68k, mips, mipsel and alpha and it produced
a great flame since some machines where hosted by non DDs and none of
them were approved by the debian admin team. The opinions (including
an RM too) expressed in that flame resulted in the effort to help
archs with backlogs with extra buildds to shut down to comply with
their wishes.

MfG
Goswin


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

Security support for tier-2 (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[David Schmitt]

On Tuesday 15 March 2005 07:49, Matthias Urlichs wrote:
> Don't get me wrong, I'd love to have eternal security support for m68k
> (or whatever compiles the kernel most slowly), but if I don't get that
> choice, given "late" or "never" I'll happily take the former.

Then read the Nybbles proposal as a invitation to forming a $tier_2_arch 
security team, recompiling packages from DSAs as needed. Yes, you will be 
later than everyone else, but you will definitely be finished before "never".

Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Vancouver meeting - clarifications

[Tollef Fog Heen]

* Andreas Barth 

| For example, the more architectures are included the longer the migration
| testing script takes.  We are already at the limit currently (and also
| have out-of-memory issues from time to time). For example, currently we
| restrict the number of some hints to only 5 per day to keep up the
| scripts. Also, the udebs are not taken into account, which requires more
| manual intervention. With a lower number of release architecture, we can
| and will improve our scripts.

Debian has a fairly big chunk of cash lying about.  If we have
problems doing testing migration because of not enough hardware, this
is something I think we should spend money on.  Or we could ask a
sponsor (hi HP!:) if they would be willing to donate some more memory.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Sven Luther]

On Tue, Mar 15, 2005 at 04:21:21AM -0500, Joey Hess wrote:
> Sven Luther wrote:
> > There is this vendor-specific-security-announce-with-embargo thingy.
> > 
> > The debian kernel team mostly handles the unstable and testing kernel, is 
> > not
> > in the loop for getting advance advice on those problems, so we cannot build
> > fixed versions until the vulnerability gets announced, and thus we can't
> > upload kernels in a timely fashion like ubuntu or other vendors do, who 
> > often
> > have a couple week of advance warnings. On slower arches this could be a
> > problem.
> > 
> > The debian-security team is handling stable only, and there are no security
> > updates for unstable until way after the embargo is over, and for testing a
> > bit after that, depending if the kernels get hinted in or not.
> > 
> > To have proper security-in-testing-or-unstable for the kernel, the
> > debian-kernel security team, or at least a few members of it, need to be 
> > made
> > aware of the embargoed security holes, and get a chance to fix them in
> > advance, maybe with a private or security non-public copy of our svn tree
> > (using svk maybe).
> > 
> > This is not a ubuntu related problem though, and the help the ubuntu
> > kernel/security team has provided us was invaluable, but it should maybe not
> > be necessary if the information was not unrightfully hold from us in the 
> > first
> > time.
> 
> You seem to be implying that ubuntu is providing you with confidential
> prior warning about kernel security holes, but I really doubt this,

Nope, but i was at one time hinted that i should wait a couple of days before
starting a 12 hours build.

> since many of the ubuntu secutity advisories that I've backchecked
> against the debian kernels have turned out to still be unfixed in the
> kernel teams's svn weeks later.

There is nobody actively doing debian security for unstable kernels right now,
well, not consistently, and not with the kind of advance warning that is
needed. This is rather a disapointement, i believe. But i understand that our
security team doesn't want or can care about unstable/testing security
updates.

> My experience is that the kernel security team is not very quick to fix
> publically known security holes, or to make uploads specifically for
> those holes once they have a fix. Even if we limit it to fixing the
> kernel-source packages and ignore the whole issue of rebuilding
> kernel-image packages for all arches.

No, but it is coming, and should be improved post-sarge hopefully. The
kernel-team has come a long way since Herbert abandoned it for
chinese-internal-political-differences, but there is still no real interaction
between the kernel-team and the security team.

Still, people on the vendor list or whatever have weeks advance knowledge of
those security problems.

Also, as said, post-sarge the rebuild issues will be fixed by a single kernel
package infrastructure, altough i am not sure how our auto-builders will
support that, but we will see. The sarge kernel is mostly frozen anyway so it
is out of our hands.

Friendly,

Sven Luther


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

m68k (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[David Schmitt]

On Monday 14 March 2005 19:25, Goswin von Brederlow wrote:
> I think the only criteria m68k fails are the "2 buildds have to
> suffice to keep up with etch" and the "10% download shares".

The second criterion is only for the mirror network, not for tier-1. Please 
read the Nybbles proposal again:

" the list of release candidate
architectures will be further split, with only the most popular ones
distributed via ftp.debian.org itself.  The criterion for being distributed
from ftp.debian.org (and its mirrors) is roughly:

- there must be a sufficient user base to justify inclusion on all
  mirrors, defined as 10% of downloads over a sampled set of mirrors
"

Does m68k have developers to support d-i and support from the security team?

Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Sven Luther]

On Tue, Mar 15, 2005 at 01:21:59AM -0800, Steve Langasek wrote:
> On Mon, Mar 14, 2005 at 11:00:12AM +0100, Sven Luther wrote:
> 
> > > There are a few problems with trying to run testing for architectures
> > > that aren't being kept in sync.  First, if they're not being kept in
> > > sync, it increases the number of matching source packages that we need
> > > to keep around (which, as has been discussed, is already a problem);
> > > second, if you want to update using the testing scripts, you either have
> > > to run a separate copy of britney for each arch (time consuming,
> > > resource-intensive) or continue processing it as part of the main
> > > britney run (we already tread the line in terms of how many archs
> > > britney can handle, and using a single britney check for archs that
> > > aren't keeping up doesn't give very good results); and third, if
> > > failures on non-release archs are not release-critical bugs (which
> > > they're not), you don't have any sane measure of bugginess for britney
> > > to use in deciding which packages to keep out.
> 
> > What about building the scc (or tier 2 as i would say) arches from testing 
> > and
> > not unstable ? this way you would have the main benefit of testing (no RC
> > bugs, no breakage of the day kind of problems). Obviously this means you 
> > would
> > need some kind of override for per-arch fixes, but preferably these fixes 
> > will
> > be applied twice, once to the per-arch repo, and then to a new unstable 
> > upload
> > which fixes the problem. Uploading only to unstable may cause undue delays.
> 
> Building against testing instead of against unstable also means you
> don't have any of the controls testing is supposed to provide to protect
> against uninstallable packages: as soon as you build a new library
> package, everything that depends on it is uninstallable.

No, because each arch will have per-arch testing support. It is just a way for
the arches to catch up with testing, and thus being in line for a release, as
when testing gets frozen, those arches will naturally catch up to the frozen
and then released stable version, and be ready for a point release later on.

> This really makes unstable snapshotting, or building stable once it's
> released as Anthony has also suggested in this thread, look like much
> better options than trying to build out of testing.

We all agree that random unstable snapshotting i no good idea, but i disagree
with the stable snapshoting, since this means that the tier-2 arches will only
be able to really start working once stable is released, while at the same
time working for the next stable release, thus introducing a skew of effort.

The proposal i have, altough maybe not perfect, will allow for the arches to
continue working at mostly the same pace as the rest of the project, and thus
not be excluded.

> > > For these reasons, I think the snapshotting approach is a better option,
> > > because it puts the package selection choices directly in the hands of
> > > the porters rather than trying to munge the existing testing scripts
> > > into something that will make reasonable package selections for you.
> 
> > So, why don't you do snapshoting for testing ? Do you not think handling all
> > those thousands of packages manually without the automated testing thinhy
> > would be not an over-burden for those guys ? 
> 
> > You are really just saying that the testing scipts don't scale well, and
> > instead of finding a solution to this, you say let's drop a bunch of 
> > architecture,
> > and make it another-one's problem.
> 
> I think we should discuss various solutions to address the needs of
> porters involved in non-release archs.  I think trying to run a full
> testing infrastructure, or build against testing instead of unstable, is
> unlikely to be a good solution for those porters in practice because of
> some of the issues that I've pointed out.

Could you be more clear about this ? which issues are those ? And how do you
make sure those arches have a stable base to do their daily work on ? And if
testing is not appropriate for them, why don't we drop testing altogether ?
Again this smells at kicking them out and letting them in the cold, altough i
doubt that was your intention.

Friendly,

Sven Luther


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

Requirement for "unmodified source" (was: Bits (Nybbles?) from the Vancouver release team meeting)

[Frank Küster]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> On Mon, Mar 14, 2005 at 10:39:24AM +0100, Robert Millan wrote:
>> On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
>
>> > - binary packages must be built from the unmodified Debian source
>> >   (required, among other reasons, for license compliance)
>
>> Is this a simple sanity requirement (i.e. no hacked crap being 
>> uploaded to the archive), or does it imply that all packages in base 
>> (or base + build-essential) need to be buildable from unmodified 
>> source?
>
> I assume what you're asking here is whether non-GNU/Linux ports have to
> have the same base system as the GNU/Linux ports do.  This was not
> implied.  The implication here is that you can't have a separate version
> of the same source package for your architecture just because the
> maintainer isn't willing to accept patches.

There might be an other case where a changed source package might be
needed: People are talking about releases of tier-2 arches which are
made by the porter teams, and made on the basis of a major release.  If
there was still a FTBFS-on-tier-2 bugs (not RC!) in a package, a source
change  is needed for such a tier-2-arch release; it's not possible to
simply take unstable sources where the fix has been applied.

To me, this would still be "unmodified Debian source", it just happens
to be a different version; I guess license-wise there is no problem with
that.  It might be a problem with disk space and archive maintenance,
however. 

Would it be possible, from the ftp-masters point of view, to have not
only the stable sources of the released architectures in the archive,
but additionally also the patched sources for tier-2 arches?  Of course
the different porter teams of tier-2 arches would have to coordinate, so
that one changed stable-plus-tier2-patches source version is
sufficient. 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Proposal] Upgrade newraff hardware

[Bill Allombert]

Hello Debian developers,

It had come several times that one major problem is the load of
wanna-build connection on newraff, and the time and memory it take 
to run the testing scripts.

Debian certainly has enough goodwill to get a donation of a couple of
really fast box with lots of RAM, and has enough money to buy them
anyway.  Especially a box with SSL exchange hardware support could be
useful. 

Given the importance of the ftp-master team, it is our best interest to
make sure they have more than sufficient computers resource available
for theirs duty.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>
[Remember: the first merkel box had 42Gb of RAM]

Imagine a large red swirl here. 


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

Re: Call for help / release criteria

[David Schmitt]

On Monday 14 March 2005 22:58, Christian Kurz wrote:
> On [14/03/05 19:05], David Schmitt wrote:
> > They do so now. Are you (all) prepared to take up the call?
>
> Pardon, but where do you see any public e-Mail from any of the "the
> people doing release, ftpmaster, etc." asking for help? I've yet so see
> an e-Mail public stating that they are overloaded and need help. If you
> interpret this proposal as a call for help, then I would say Debian has
> a bigger communication problem then I though before.

Regardless of what is written in the Nybbles proposal, if it is read as "we 
are the cabal of Debian, your arch is dismissed, work is useless" then Debian 
has already failed.

There are requirements for a really-stable release, there are requirements for 
requesting time from "central management", there are requirements which are 
already being talked about, there is a minimal proposal of support for tier-2 
releases. Anthony Towns said in another mail in this thread:

"Feedback from porters on how these things could actually work usefully 
in real circumstances would be valuable here. Having a way of making 
snapshots is probably the minimal level of support we'd envisage, 
working out what that would actually achieve, and what benefits more 
support would actually bring would be interesting."



Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Julien BLACHE]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andres Salomon <[EMAIL PROTECTED]> wrote:

>> I hereby ask the people involved in this proposal to step down
>> immediately from their positions in the Project. You've violated a
>> couple of rules already, and you've violated the spirit of this Project.
>
> *blink*.  Are you high?  One of the RMs makes an announcement stating that
> we're *almost* ready to freeze sarge, and you're asking RMs and FTPMasters
> to resign?  What will that solve, at this point?

That will save us from self-destruction. There's no point in making a
new release if we're going to disappear after that.

Moreover, the more I read this thread, the more I question the values
of some of the people involved. It looks like some of us should really
reconsider their involvment in the Project.

But then again, that's only my opinion, and people on IRC suggest I'm
an idiot. I know from the mails I'm getting that I'm not.

JB.

- -- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCNq7WzWFP1/XWUWkRAgKWAJ4n0xwjp5eJQU01pDo6q6d2UHfE9wCfdmTs
+4Rw1YEB91CubzSKhKPDB6k=
=Zol+
-END PGP SIGNATURE-


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Julien BLACHE]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Langasek <[EMAIL PROTECTED]> wrote:

>> And keeping IA64 in the loop is just another joke from the release
>> team. It'd be interesting to find out, but I bet more m68ks were sold
>> than IA64 last year.
>
> Which of these two architectures are you more likely to be able to run a
> current 2.6 kernel on, BTW?

I fail to see why this matters at all. It's not in your list of
requirements, remember ?

> You do know that m68k is the only architecture still carrying around
> 2.*2* kernels in sarge?

Yes. But there are 2.4 kernels available too, don't forget to mention
that fact. No 2.6, though, but that's not a problem right now. Might
become a problem for etch, I agree.

m68k folks, is there anything in the works for 2.6 ?

> The inclusion of ia64 in the release count is a projection, based on
> where I believe things are today.  Nothing the release team is doing
> ensures that ia64 is going to be a viable port, a year from now when
> we're trying to release etch; and nothing says that one or more of the
> other ports won't be in a position to meet those criteria and get added
> to the release list.

What Thomas Bushnell said.

JB.

- -- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCNrAbzWFP1/XWUWkRArlpAJ9Os1Fl9XP7EjkaZieoCiLzHbqxdQCeJSW7
gSC/WuUfQdEkAfZsrM6Vl9k=
=uZIr
-END PGP SIGNATURE-


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Frank Küster]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> On Mon, Mar 14, 2005 at 10:06:35AM -0600, John Goerzen wrote:
>
>> I also have no objection to releasing stable later on some archs, or not
>> at all, of nobody from those archs works to do it.
>
>> I do object to preventing those archs from releasing stable, and from
>> being supported at all by the security infrastructure.
>
> Please clarify what you think a late-releasing stable arch is going to
> look like, in contrast to what has been proposed, given that keeping
> release architectures in sync is the only thing we have that guarantees
> the sources in testing (and therefore in stable) are in a releasable
> state for each of those architectures.

I guess the late-releasing stable arch would very much look like the
core architectures, just that its buildd's took more time to do the
compilation, and that there are different promises to our users on this
arch (security support by the porters team "as good as possible").

In case there are bugs in the release that are RC bugs for the
late-releasing, tier-2 arch, but do not apply to the main arches (or are
not RC for them), there are two possibilities:

a) drop that package (and (build-)dependencies) from that arch.  That
   might well be a working alternative; arches that are used for
   embedded devices, or mainly for servers/firewalling/... might well do
   without KDE or some number-crunching application.

b) Provide the possibility to have a "stable-plus-tier-2-patches" branch
   in the archive, with a very limited number of source packages that
   are derived from stable with the necessary patches for tier-2 arches.

In the long run, it might be even possible to get along with the stable
sources alone, plus a second, tier-2-specific diff.gz - if I'm not
mistaken it is planned to enable dpkg to work with a more flexible
format for source packages.

If there are such source changes, the porters must rebuild the parts of
the archive that build-depend on the changed packages, guaranteeing the
consistency of the release.  But this won't be a very harsh requirement,
since most of the arch-specific RC bugs are FTBFS, anyway.


Regards, Frank


-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Building tier-2 against testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[David Schmitt]

On Tuesday 15 March 2005 10:41, Sven Luther wrote:
> On Tue, Mar 15, 2005 at 01:21:59AM -0800, Steve Langasek wrote:
> > On Mon, Mar 14, 2005 at 11:00:12AM +0100, Sven Luther wrote:
> > > > There are a few problems with trying to run testing for architectures
> > > > that aren't being kept in sync.  First, if they're not being kept in
> > > > sync, it increases the number of matching source packages that we
> > > > need to keep around (which, as has been discussed, is already a
> > > > problem); second, if you want to update using the testing scripts,
> > > > you either have to run a separate copy of britney for each arch (time
> > > > consuming, resource-intensive) or continue processing it as part of
> > > > the main britney run (we already tread the line in terms of how many
> > > > archs britney can handle, and using a single britney check for archs
> > > > that aren't keeping up doesn't give very good results); and third, if
> > > > failures on non-release archs are not release-critical bugs (which
> > > > they're not), you don't have any sane measure of bugginess for
> > > > britney to use in deciding which packages to keep out.
> > >
> > > What about building the scc (or tier 2 as i would say) arches from
> > > testing and not unstable ? this way you would have the main benefit of
> > > testing (no RC bugs, no breakage of the day kind of problems).
> > > Obviously this means you would need some kind of override for per-arch
> > > fixes, but preferably these fixes will be applied twice, once to the
> > > per-arch repo, and then to a new unstable upload which fixes the
> > > problem. Uploading only to unstable may cause undue delays.
> >
> > Building against testing instead of against unstable also means you
> > don't have any of the controls testing is supposed to provide to protect
> > against uninstallable packages: as soon as you build a new library
> > package, everything that depends on it is uninstallable.
>
> No, because each arch will have per-arch testing support. It is just a way
> for the arches to catch up with testing, and thus being in line for a
> release, as when testing gets frozen, those arches will naturally catch up
> to the frozen and then released stable version, and be ready for a point
> release later on.
>
> > This really makes unstable snapshotting, or building stable once it's
> > released as Anthony has also suggested in this thread, look like much
> > better options than trying to build out of testing.
>
> We all agree that random unstable snapshotting i no good idea, but i
> disagree with the stable snapshoting, since this means that the tier-2
> arches will only be able to really start working once stable is released,
> while at the same time working for the next stable release, thus
> introducing a skew of effort.
>
> The proposal i have, altough maybe not perfect, will allow for the arches
> to continue working at mostly the same pace as the rest of the project, and
> thus not be excluded.
>
> > > > For these reasons, I think the snapshotting approach is a better
> > > > option, because it puts the package selection choices directly in the
> > > > hands of the porters rather than trying to munge the existing testing
> > > > scripts into something that will make reasonable package selections
> > > > for you.
> > >
> > > So, why don't you do snapshoting for testing ? Do you not think
> > > handling all those thousands of packages manually without the automated
> > > testing thinhy would be not an over-burden for those guys ?
> > >
> > > You are really just saying that the testing scipts don't scale well,
> > > and instead of finding a solution to this, you say let's drop a bunch
> > > of architecture, and make it another-one's problem.
> >
> > I think we should discuss various solutions to address the needs of
> > porters involved in non-release archs.  I think trying to run a full
> > testing infrastructure, or build against testing instead of unstable, is
> > unlikely to be a good solution for those porters in practice because of
> > some of the issues that I've pointed out.
>
> Could you be more clear about this ? which issues are those ? 

Sven, Steve is referring to the first part of his mail, where he says that 
building from testing will lose "any of the controls testing is supposed to 
provide to protect against uninstallable packages".

> And how do 
> you make sure those arches have a stable base to do their daily work on ?

More stable than unstable? As stable as testing? Please explain this to me, I 
am little slow in the morning.

> And if testing is not appropriate for them, why don't we drop testing
> altogether ? 

Off the top of my head I would say because testing was appropriate for a small 
number of arches but didn't appropriately scale for a bigger number of arches 
where the probability of breakage on any single one of them approaches one.

Also testing is absolutely needed to be able to properly support stable after 
the release: this needs synced

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Julien BLACHE]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matt Zimmerman <[EMAIL PROTECTED]> wrote:

>> How could we know ? We know nothing about Ubuntu, nothing about
>> Canonical, nothing about the goals, nothing about how everything was
>> done to begin with, nothing about who works or doesn't work there.
>
> Details about Ubuntu and its goals can be found on the website.  In many
> respects there is more information available about Ubuntu activity, and the
> goals of the project, than about organizations which provide you with the
> essentials of life.  Yet, you seem to trust them by default, while you
> assume that Ubuntu seeks to cause you harm.  Why?

Because Ubuntu appeared behind a screen of smoke. And smoke hasn't
dissipated yet. Debian Developers were not informed in an appropriate
manner of what was going on there.

>> Everything was done with the exact same secret used for this plan. And
>> nobody cared enough to write up a proper announcement for Debian
>> developers.
>
> An announcement of what?  The release meeting, or Ubuntu?  You'd be wrong in
> either case, as can be easily shown by mailing list archives.

Ubuntu. Sure, there was a mail posted to -devel. It basically said
"Hey folks, look there, we're doing something, there are patches. We
have no name yet.". It said nothing else. It did not even list the
people involved. We had to find out by hanging out on IRC. Nice way of
treating your fellows, indeed.

And now you're pointing us to the Ubuntu website, but it's a bit
late.

>> How are we supposed to trust you ? I certainly can't until this is
>> fixed.
>
> Fixed?  You haven't identified a problem, and you seem to be attacking those
> who are working to solve well-known problems in Debian.

By destroying the Project ? Interesting approach.

JB.

- -- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCNrMXzWFP1/XWUWkRAqMIAJ9OPOnkk7HJLDQr1/k0I54I8FGufgCeNosD
f203tHU/vncbSHe/wGDlm+A=
=fEhg
-END PGP SIGNATURE-


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

Re: [Proposal] Upgrade newraff hardware

[Aurélien Jarno]

Bill Allombert a écrit :
Hello Debian developers,
It had come several times that one major problem is the load of
wanna-build connection on newraff, and the time and memory it take 
to run the testing scripts.

Debian certainly has enough goodwill to get a donation of a couple of
really fast box with lots of RAM, and has enough money to buy them
anyway.  Especially a box with SSL exchange hardware support could be
useful. 

Given the importance of the ftp-master team, it is our best interest to
make sure they have more than sufficient computers resource available
for theirs duty.
Seconded.
And if it is not possible to get a donation, Debian has enough money to 
buy them.

--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Julien BLACHE]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Palmer <[EMAIL PROTECTED]> wrote:

>> I hereby ask the people involved in this proposal to step down
>> immediately from their positions in the Project. You've violated a
>> couple of rules already, and you've violated the spirit of this
>> Project.
>
> You're going to purge a number of people with experience and knowledge
> because of a poorly worded announcement?

It's not only a poorly worded announcement, it's a problem of not
working with the others, and deciding upon them without any
input. It's still the same communication problem, still the same "this
is *MY* corner of the Project, GO AWAY!".

>> It will. It just doesn't have to happen. Our call; we're the ones
>> making Debian, they're not.
>
> Who are "they"?  The RMs?  I'm pretty sure they're doing a hell of a lot

Everybody involved in this infamous proposal (I'd rather say "plan",
but rumour has it that it's only a proposal).

> towards "making Debian", and the ftpmasters are doing a decent chop of
> things too.

Sure, and I won't say the contrary. But having a great infrastructure
(which is the case) and great people doing good work is of no help in
making Debian if you haven't got any packages. We have some 10k+
packages, only a fraction of them are actually maintained by those
people.

That's what I meant to say.

JB.

- -- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCNrSGzWFP1/XWUWkRAvqPAJ4vSlmRo8o+5xa3h10WskSPzPaQ2QCfYoi9
6U/TVV+69ZZT/bqz/5Riwk0=
=gcq+
-END PGP SIGNATURE-


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

Re: Release sarge now, or discuss etch issues?

[Frank Küster]

Joey Hess <[EMAIL PROTECTED]> schrieb:

> Frank Küster wrote:
>> I do not understand why the Nybbles team mixed their good news about
>> sarge with their foreseeably controversial plans or proposal for etch.
>> I fear that we will have a huge, long flamewar.  And many competent,
>> active people will start coding implementations of alternatives to the
>> Nybbles plan, alternatives that will allow us to make releases also of
>> the SCC/tier-2 arches.
>> 
>> I think all this discussion about etch should be delayed until sarge is
>> out.  Of course we would need a statement from the Nybbles team that
>> they do not intend to make decicions, and not to settle facts before a
>> thorough discussion has taken place - after the release.

Meanwhile, there have been statements on -vote, e.g. by aj in

http://lists.debian.org/debian-vote/2005/03/msg00626.html

,
| That said, I don't think any of the implementation has been started
| yet, and it certainly won't be completed 'til sarge is released; so
| there's plenty of time for further comments or tweaks or even
| reinventions.
`

that make me confident that there will be time for discussion, an open
discussion. 

> The fact that the release team now sees the light at the end of the
> tunnel for the release of sarge means that now is the time we need to
> begin planning for etch. Allowing unstable development to pick back up
> after a release with no clear plan for the next release has been shown
> time and time again to delay the next release by one to two *years*.

I agree.

> The rest follows from that.

It follows from that that we should start the discussion, yes.  But it
doesn't follow that we had to start the discussion by sending a mail to
-devel-announce that proposed a drastic change without consulting all
parties involved, *and* that did not sound like a proposal, but a
decision.  

The waste of resources follows from that, I fear.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

amd64/multiarch transition (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[David Schmitt]

On Monday 14 March 2005 20:24, Goswin von Brederlow wrote:
> If it weren't for sarge blocking us we would have submitted multiarch
> patches as early as one year ago. Should we start submitting / NMUing
> them for _experimental_ now to get this change running and tested? Or
> should we keep waiting for sarge getting released and then massfile
> them the next week?

From my observations on other major transitions, I believe it is typically 
handled by announcing and maintaining a public, central non-bts place to keep 
track of all major problems (including lists of affected packages [ORDER BY 
maint]) until 75-90% of the transition is finished and only afterwards file 
bugs on those packages that still pose problems. This often also included 
maintaining a external repository with all changed packages (see SELinux for 
example).


Regards, David

-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Vancouver meeting - clarifications

[Andreas Barth]

* Tollef Fog Heen ([EMAIL PROTECTED]) [050315 10:50]:
> * Andreas Barth 

> | For example, the more architectures are included the longer the migration
> | testing script takes.  We are already at the limit currently (and also
> | have out-of-memory issues from time to time). For example, currently we
> | restrict the number of some hints to only 5 per day to keep up the
> | scripts. Also, the udebs are not taken into account, which requires more
> | manual intervention. With a lower number of release architecture, we can
> | and will improve our scripts.
 
> Debian has a fairly big chunk of cash lying about.  If we have
> problems doing testing migration because of not enough hardware, this
> is something I think we should spend money on.  Or we could ask a
> sponsor (hi HP!:) if they would be willing to donate some more memory.

Well, that was one of the examples where we pay a price for more
architectures. Of course, the testing migration script is not all, and
this problem can be solved, but I think we should not forget that we pay
a price - even if at the end, we think the price is acceptable.

(And, BTW, newraff is a quite mature box. Of course, there is always
more and better hardware available, but newraff is already a very good
machine. And, we want to give the testing migration script more tasks,
like handling of the udebs, which puts load off from human being and on
into a script. But that increases the ressources the script uses.)


One of the problems is that for every decision (and even for the
decision to don't make a decision), we pay a price.  There are prices
I'm not willing to pay (like another release cycle of the length of
sarge) - but well, if Debian goes into that direction, I'll go out of
the way.  Other people are not willing to pay other prices.  My goal is
to find a route to take that as many people as possible are considering
as acceptable.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Frank Küster]

Anthony Towns  schrieb:

> Alastair McKinstry wrote:
>> The question is: how do you release a SCC arch, if at all?
>
> AFAIK, the terminology is FCC/SCC for mirror split, and "release-arch"
> and "non-release-arch" for which arches get released as stable. So the
> question is "how do you release a non-release arch?"
>
> Once you get over giggling at the phrasing (or maybe that's just me),
> there're a few answers. The ones that come to my mind are:
>
>   (a) Just build against testing/stable instead of unstable; when etch
> happens, fix up any remaining problems, and release a snapshot that
> more or less matches etch. Rinse, repeat.

Would the task of setting up an archive for the fixed up sources, and
the resulting binary packages, be on the shoulder of the porters alone,
or would there be support by the ftpmasters, and especially by the
system administrators?  Will it at least be possible to host such an
archive on a debian.org machine?

[This I think should be the case]

Will it be possible to get the fixed-up sources reintegrated in point
releases of stable?

[don't know whether this is desirable]

>   (b) Just build against unstable, until you get bored. Then stop,
> clean up some stuff and do some basic testing, then release a snapshot.

This would make security support much harder.  The first question above
still is interesting here.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Julien BLACHE]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tollef Fog Heen <[EMAIL PROTECTED]> wrote:

> | How could we know ? We know nothing about Ubuntu, nothing about
> | Canonical, nothing about the goals, nothing about how everything was
> | done to begin with, nothing about who works or doesn't work there.
>
> That, sir, would be entirely the fault of yourself.  It's three clicks
> from the front page of canonical.com what the goals of Ubuntu is.
> It's well documented on the www.ubuntu.com pages.  About who works or
> doesn't work there, well, though it's not secret, it's not like the
> company roster is publically available.  A lot of the names should be
> easy to pick out, though.

For $DEITY's sake. Will you please understand that the Ubuntu folks
totally failed to inform their fellows about what was going on ? And
at the time, there was no Canonical website, no Ubuntu website. Only a
handful of patches up on no-name-yet.

I think we deserved a better explanation.

> I don't think accusing the Ubuntu developers of hiding information is

At the time of no-name-yet, they *were* hiding information.

> fair.  I don't think most Debian developers would be happy if the
> Ubuntu developers forced more information down their throats -- just
> look at how unhappy people got by jdub posting his «ubuntu blog
> updates» to a feed which ended up on planet debian.

I have no problem with posts about what's going on at Ubuntu, be it on
Planet or on -devel or on -custom (I don't read -custom, but I could
start) or wherever.

> | How are we supposed to trust you ? I certainly can't until this is
> | fixed.
>
> You can look at the processes as documented on the Ubuntu web site.

I found out, thanks.

> There's not much we can do to make you trust us, saying «please trust
> us, we're nice» is a no-op.  You can look at what the Ubuntu
> developers are doing and make your own judgements.  Ask on the lists,
> ask on IRC.  I don't think posting Ubuntu material to Debian lists is
> in any way appropriate.

I have no problem whatsoever about working with the Ubuntu folks, and
you know it, btw :)

I never refused to work with someone. I never refused a good patch. I
never killfiled anyone. Debian is a teamwork, and I'm playing in the
team as much as I can. That's not true of everybody.

JB.

- -- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCNrmvzWFP1/XWUWkRAg2RAKDGiflyjFM1v6psZh2QilFHbNrwSgCgpwxf
nKUJ/f0DScAhXllo46epu5I=
=r1x4
-END PGP SIGNATURE-


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andreas Barth]

* Steve Langasek ([EMAIL PROTECTED]) [050315 00:00]:
> Colin mentioned the possibility of adding an "Architecture:" field
> instead.  That seems better than an etch-ignore tag anyway, for what you
> want to achieve here.

Yes, that sounds well.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Building tier-2 against testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Sven Luther]

On Tue, Mar 15, 2005 at 11:18:54AM +0100, David Schmitt wrote:
> On Tuesday 15 March 2005 10:41, Sven Luther wrote:
> > Could you be more clear about this ? which issues are those ? 
> 
> Sven, Steve is referring to the first part of his mail, where he says that 
> building from testing will lose "any of the controls testing is supposed to 
> provide to protect against uninstallable packages".

Ah, ok, then i think i have replied to this already.

> > And how do 
> > you make sure those arches have a stable base to do their daily work on ?
> 
> More stable than unstable? As stable as testing? Please explain this to me, I 
> am little slow in the morning.

You know that following unstable, especially for not mainstream arches, mean
random breakage-of-the-day, and such, right ? Also it means that you don't get
the protection against RC bugs and such, which would affect the stability of
your main work plateforms, and make clean installations from scratch often
impossible for large amount of time.

> > And if testing is not appropriate for them, why don't we drop testing
> > altogether ? 
> 
> Off the top of my head I would say because testing was appropriate for a 
> small 
> number of arches but didn't appropriately scale for a bigger number of arches 
> where the probability of breakage on any single one of them approaches one.

Yes, but the thing is that the two-distribution approach, one for uploading
packages, the other for having a base for proven-good packages is useful and
even needed. This is currently denied the arch porters.

Furthermore the fact to have a testing which follows and mirrors the tier-1
testing is vital to allow for stable point releases. rejecting tier-2 testing
support based on tier-1 testing kills in the egg any chance of a stable point
release later on.

> Also testing is absolutely needed to be able to properly support stable after 
> the release: this needs synced arches, else security updates would need to 
> recompile several different minor diverging versions each time.

No i don't think this holds. Once stable is released, it is totally divorced
from testing, and only gets interaction through stable-proposed-updates.

Friendly,

Sven Luther


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[David Schmitt]

On Monday 14 March 2005 17:02, Marc Haber wrote:
> On Mon, 14 Mar 2005 10:21:39 -0500, Stephen Gran <[EMAIL PROTECTED]>
>
> wrote:
> >So far as I can tell, the governing rule in Debian thus far has always
> >been that the people doing the work get to make the decisions about
> >their corner of the project.  I don't see that that's going to change
> >any time soon, and I don't particularly think it should.
>
> The problem is that it is extremely hard to be allowed to do any work
> for Debian, and I think that should change. I know of two core teams
> in Debian which have more than half of their members in an in-active
> state. This is bad. People who are not doing any actual work should
> resign and allow themselves to be replaces with people who are eager
> to do work and to take responsibility.

As long as you don't provide pointer to relevant material this sounds like hte 
earlier claim, that Martin Schulze is the only active security team member 
because his DSA announcements are the only ones posted[1].


Regards, David
[1] I'm exaggerating a little bit here.
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Vancouver meeting - clarifications

[Marc Haber]

On Tue, 15 Mar 2005 08:58:44 +0100, Andreas Barth
<[EMAIL PROTECTED]> wrote:
>Hello, world,

Hello, Andi.

Nice to hear from you.

>Please allow me another remark: That meeting didn't finalize the release
>goals for etch. We talked about some of course - like we do on IRC quite
>often, but we didn't finalize anything.

Good. Please take note that the finanlizing needs to be done in a
different process.

>I was asked quite often via IRC what the reasonings for this kind of
>proposal were. I'll answer the reasons from the release point of view - but
>please remember that there are also ftp-masters/mirror concerns that the
>release team doesn't directly take care of, but which are of course still
>important.

However, I currently do not expect ftpmaster to communicate with mere
mortals, so their motivation will probably remain in the dark as many
other parts of their mysterious day-to-day-work we all happen to
heavily depend on.

>As Steve wrote
>| The reality is that keeping eleven
>| architectures in a releasable state has been a major source of work for
>| the release team, the d-i team, and the kernel team over the past year;
>| not to mention the time spent by the DSA/buildd admins and the security
>| team.
>Considering the experience of the release team, the number of different
>architectures were _one_ part responsible for release delays - not the only
>one, and the others need also to be solved.

Can you outline the delays that were caused by the number of different
architectures?

>| - the release architecture must be publicly available to buy new
>that has the reason that the system needs to be "alive". It can't be
>Debians task to try to keep a dying arch up as long as possible.

Why? We have been filling that gap nicely, providing for a solid user
base. This has also been a promotion for mainstream architectures, and
a motivation to keep a Debian system reasonably small. I can imagine
that a lot of people decided to use Debian on their currently
productive systems because the same system also runs on the nice gem
in the basement. You guys are suggesting throwing that away.

> Of course,
>there will be a timespan during which an arch is hard to buy, but still
>useful and somehow available.  We should of course support the release
>during this time which would probably mean one or two releases but does
>not mean we will be able to infintly support this arch.

Infinity is of course not an option.

>| - the release architecture must have N+1 buildds where N is the number
>|   required to keep up with the volume of uploaded packages
>The reason for this proposal should be instantly clear to everyone who
>ever suffered from buildd backlogs. :)
>
>We want that all unstable packages are directly built under normal
>circumstances and that in the even of a buildd going down the arch does
>not suffer noticably.  The long periods of trying to get some RC-bugfix
>in while some arch has a backlog should disappear with etch.

I am missing the rationale for the upper bound on number of buildds.

>| - the release architecture must have successfully compiled 98% of the
>|   archive's source (excluding architecture-specific packages)
>well, that's just an "the architecture is basically working", so that we
>don't get too many RC-bugs because of architecture-specific issues, and
>also don't get too many packages kept out of testing for not all archs
>being built. Of course, the 98% is not engraved into stone, and might just
>be another arbitrary high number like 97.5%. From looking at the usual
>level where we start noticing problems with testing migrations, a number
>in this range is sane.

It needs, however, to be more tightly specified how that number is
determined. Will an architecture be dropped if it drops below for one
day? Or is it needed to constantly stay below that threshold for the
entire release period?

>| - the release architecture must have a working, tested installer
>I hope that's obvious why. :)

The architectures you plan to release have a working installer,
anaconda, for years. d-i was developed to allow release of all
architectures. You are dropping that requirement, flushing all d-i
efforts down the drain.

>| - the Security Team must be willing to provide long-term support for
>|   the architecture
>If not, we can't release with that arch. I think this is also quite
>obvious. Of course, one way to get the security team to provide support
>might be to help them.

I do not recall the security team requesting help for supporting other
architectures than i386. otoh, other teams of debian have a history of
rejecting help offers. That makes the mere mortal developer reluctant
with offering help to teams any more since nobody likes rejection.

>| - the Debian System Administrators (DSA) must be willing to support
>|   debian.org machine(s) of that architecture
>| - there must be a developer-accessible debian.org machine for the
>|   architecture.
>Well, the second point is - I hope - obvious why we w

Re: [Proposal] Upgrade newraff hardware

[Brian Nelson]

On Tue, Mar 15, 2005 at 11:05:13AM +0100, Bill Allombert wrote:
> Hello Debian developers,
> 
> It had come several times that one major problem is the load of
> wanna-build connection on newraff, and the time and memory it take 
> to run the testing scripts.
> 
> Debian certainly has enough goodwill to get a donation of a couple of
> really fast box with lots of RAM, and has enough money to buy them
> anyway.  Especially a box with SSL exchange hardware support could be
> useful. 

Sounds like it's already quite powerful:

Processor: Dual Intel P4 Xeon 2.8Ghz 
Memory: 6Gb 
Disk space: 735Gb [6x147Gb RAID 5] 
Bandwidth: 100Mbit colocated LAN 

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Re: Dropping from mirror network vs dropping from tier-1

[Frank Küster]

David Schmitt <[EMAIL PROTECTED]> wrote:

> Elsewhere I believe Steve mentioned, that earlier versions had tier-1 == 
> ftp.d.o, but that this was dropped

Yes, although it requires thorough reading, this is what the Vancouver
proposal seems to say.

>(exactly because of arches like s390 who 
> should be able to reach tier-1 easily, but really have no reason to be on the 
> mirror network).

But it does *not* say that s390 is likely to be among the released
architectures.  And I do not understand why.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Questions for the DPL candidates

[Julien BLACHE]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sven Luther <[EMAIL PROTECTED]> wrote:

> I wonder also, do we still not have some sun donated sparc box running part of
> our infrastructure ? How will that stay if we drop sparc support ? 

According to db.d.o:
 - auric: RAID is dead (and auric is basically demilitarized since the
   compromise -- not even running a buildd, although I'm not sure
   about that)
 - kubrick: disk is dead
 - vore: I think it's acting as a buildd

BTW, couldn't we get our acts together and buy new disks for all those
poor machines which disks are dead ? That would resurrect quite a few
machines, including an alpha buildd (escher).

JB.

- -- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCNryCzWFP1/XWUWkRAkOeAKDFEBogaHqhSzxvfQmwAmrmHdRERgCgrUvM
Eyw+2fDzcTWlWpQrQ96U820=
=PpSM
-END PGP SIGNATURE-


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[David Schmitt]

On Tuesday 15 March 2005 11:10, Julien BLACHE wrote:
> Matthew Palmer <[EMAIL PROTECTED]> wrote:
> > towards "making Debian", and the ftpmasters are doing a decent chop of
> > things too.
>
> Sure, and I won't say the contrary. But having a great infrastructure
> (which is the case) and great people doing good work is of no help in
> making Debian if you haven't got any packages. We have some 10k+
> packages, only a fraction of them are actually maintained by those
> people.

Looking at efforts for coordination and doing the needed work for a stable 
release (tracking RC bugs, D-I, security support, buildd administration) the 
ratio is exactly the other way. Debian is Debian/stable. Removing those 
working primarily on releasing would leave only a shell of Debian behind.



Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andreas Tille]

On Tue, 15 Mar 2005, Julien BLACHE wrote:
For $DEITY's sake. Will you please understand that the Ubuntu folks
totally failed to inform their fellows about what was going on ? And
at the time, there was no Canonical website, no Ubuntu website. Only a
handful of patches up on no-name-yet.
I think we deserved a better explanation.
Hmmm, I do not remember that Corel did some better information policy
when they made a Debian derived distribution.  There are other examples
as well.  I do not want to compare Ubuntu with those commercial
distributors, but if we build a FREE operating system nobody has to
inform us about anything as long it is conform to our license.
And no, I do not exactly know what Ububtu people are doing but I see
no harm in it if they employ a certain amount of DDs as other companies
do as well.  Please could we concentrate back on our own problems instead
of discussing the problems of other distributions.
Our own problem is whether certain groups inside Debian have problems
in communication with other interested people which do not (yet)
belong directly to this group.  I would answer this question with:
Yes, by a certain amount.
We have to enhance communication as a certain kind of documentation:
  1. Reasonable protocols of discussion inside these groups are
 be useful for their own work.  These protocols can be opened
 (we don't hide problems).
  2. Lower barriere for potential helpers to step in (because they
 are informed about what's going on.)
  3. This would (hopefully) reduce FUD.
So why not setting up at a certain web space containing information about
meeting of groups like the Vancouver meeting:
1. Date + Time
2. Location
3. Agenda
4. Invited people
  ---> This should be published before the meeting
5. Log about the points which were discussed after the meeting in
   form of a technical documentation
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Colin Watson]

On Mon, Mar 14, 2005 at 02:59:29PM -0800, Steve Langasek wrote:
> On Mon, Mar 14, 2005 at 05:59:21PM -0500, Joey Hess wrote:
> > Somewhere else in this vast thread, someone suggested that they be
> > serious and etch-ignore instead. Or perhaps serious bugs that are only
> > tagged with a SCC arch should be automatically treated as etch-ignore.
> 
> > This actually seems to make more sense, since they could become RC for
> > etch if we change out minds and add an arch to the set of release
> > arches. Or they might need to become RC after etch if the set of release
> > arches changes then.
> 
> > Any thoughts on this from the BTS admins / RMs?
> 
> Colin mentioned the possibility of adding an "Architecture:" field
> instead.  That seems better than an etch-ignore tag anyway, for what you
> want to achieve here.

Right. We might need to do either etch-ignore or a lower severity in the
meantime, though; Architecture: would take a little while to implement
properly.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: Release sarge now, or discuss etch issues? (was: Bits (Nybbles?) from the Vancouver release team meeting)

[Julien BLACHE]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christian Perrier <[EMAIL PROTECTED]> wrote:

> OK, the architecture handling is controversial. Fine...this will
> probably delay etch more than we would like. But could we please focus
> on releasing sarge first? By focus, I also mean avoidn wasting
> valuable DD time to endless discussions (no real human can read this
> thread already), flamewars and personal attacks (I'm quite saddened by
> Julien's hard attacks and proposal to do the Revolution).

Christian, I am quite disappointed to read this.

Please realize that the so-called proposal is nothing else than a
plan, that would be enforced if this thread wasn't taking place.

It has absolutely nothing to do with what has been discussed
previously. The authors are the same who said repeteadly that the
number of architectures wasn't reponsible for the sarge delay.

Now, apply the same kind of plan to i18n/l10n. You'd probably feel
insulted too.

JB.

- -- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCNr9LzWFP1/XWUWkRAjPRAKC5fEmhfL31Q+zY2iULvtXLpye5wQCfTA1f
v0wMI26pqO/qwvUrgrXrw90=
=soNX
-END PGP SIGNATURE-


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[David Schmitt]

On Monday 14 March 2005 16:23, John Goerzen wrote:
> On Mon, Mar 14, 2005 at 12:47:58PM +0100, Julien BLACHE wrote:
> > Basically, you're just leaving a number of Debian users out in the
> > cold. Users who choose Debian because we were the only distribution
> > out of there to provide serious support for the architectures they
> > care for, for various reasons.
>
> Indeed.  I am one such user.  I have always felt fortunate that I don't
> have to really care what architecture a machine is, because "of course
> it runs Debian".  I have run Debian on Alpha, x86, amd64, powerpc, and
> sarc systems, both as a desktop and a server environment on most of
> these.

And if the security team is not able to support those arches as-is, someone 
will have to step up and do the work. Overly long delays for security updates 
also diminish the usefulness of $arch.

It will break my heart if I have to retire my sparc nameserver and his 
backup-sister. But I'd rather do it because the current security team says 
that they won't support it for etch (which gives me ample time for 
contingency planning) than somewhen in the night after some flashworm hit me 
because the security update was delayed (for whatever $arch-specific reason).


Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Security support for tier-2 (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[David Schmitt]

On Monday 14 March 2005 17:18, Sven Luther wrote:
> On Mon, Mar 14, 2005 at 11:12:29AM -0500, David Nusinow wrote:
> > On Mon, Mar 14, 2005 at 09:54:49AM -0600, John Goerzen wrote:
> > > It is not unstable that I am (most) worried about.
> > >
> > > It is the lack of any possibility of a stable release that concerns me.
> > > Even if the people for a given arch were to build a stable etch, it
> > > would have no home in Debian, would suffer from being out of the loop
> > > on security updates, etc.
> >
> > Well, we do know the security team needs help. What I'd love to see is
> > each port have someone on the security team to handle their specific
> > bugs, binary builds and testing. That might scale better and decrease the
> > overall load on the team. This is all in line with what seems to be the
> > central thesis of the proposal: shift more of the core burden to the
> > porters. Of course, this does demand a lot, but the burden has to go
> > somewhere, and the people currently carrying large portions of it are
> > saying they can't do this any more.
>
> Notice too that the exact same people whose help is needed are those that
> are pissed by this proposal, and whose help has been repeteadly rejected in
> the past.


Sven, is there a specific reason you believe that the proposers will 
prevent[1] security-support on scc.d.o for tier-2 arches or are you only 
ranting?




Regards, David

[1] plus/minus access to embargoed vendor-sec lists, this is a very sensitive 
area
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Vancouver meeting - clarifications

[Frank Küster]

Marc Haber <[EMAIL PROTECTED]> wrote:

> On Tue, 15 Mar 2005 08:58:44 +0100, Andreas Barth
>
>>I was asked quite often via IRC what the reasonings for this kind of
>>proposal were. I'll answer the reasons from the release point of view - but
>>please remember that there are also ftp-masters/mirror concerns that the
>>release team doesn't directly take care of, but which are of course still
>>important.
>
> However, I currently do not expect ftpmaster to communicate with mere
> mortals,

Anthony Towns was very active on the lists these days.  The threads on
-vote last week, IMO, were a nice example of non-communication -
everybody talked, but Anthony did not understand our concerns, and we
didn't understand him.  But what he wrote on -devel about the Vancouver
proposal was quite clear, and can be called communication.

We are still lacking a rationale for the Vancouver proposal from the
ftmasters, though.


Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Ingo Juergensmann]

On Tue, Mar 15, 2005 at 10:45:59AM +0100, Julien BLACHE wrote:

> >> I hereby ask the people involved in this proposal to step down
> >> immediately from their positions in the Project. You've violated a
> >> couple of rules already, and you've violated the spirit of this Project.
> > *blink*.  Are you high?  One of the RMs makes an announcement stating that
> > we're *almost* ready to freeze sarge, and you're asking RMs and FTPMasters
> > to resign?  What will that solve, at this point?
> That will save us from self-destruction. There's no point in making a
> new release if we're going to disappear after that.

Well, they could resign immediatedly after or with the release. 

> Moreover, the more I read this thread, the more I question the values
> of some of the people involved. It looks like some of us should really
> reconsider their involvment in the Project.

Unfortunately there are always the wrong people reconsider their involvment
in the project. Remember the last wave of retirement announces?
Whereas the people that actually should retire are just saying nothing, even
when they've been asked. 
 
> But then again, that's only my opinion, and people on IRC suggest I'm
> an idiot. I know from the mails I'm getting that I'm not.

Been there, done that, too... 
I always got several private mails during my last years rants, although I
was entitled in public as an idiot and moron as well, which led me to the
point that's not me being an idiot, but those who call others that way. 
Anyway, even Galileo Galilei was entitled to be an idiot when he stated that
not the earth is the middle of the universe... 

-- 
Ciao...  // 
  Ingo \X/


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[David Schmitt]

On Tuesday 15 March 2005 03:09, Anthony Towns wrote:
> Soon everyone loves you, and you get a huge userbase, and hit 10% of
> i386+amd64 downloads or five times powerpc's current userbase or so, and
> say "I wanna be on ftp.d.o!!" Then you get moved across over a month or
> so, and become a "tier-1" arch. Yay you.

If I read the proposal (and Steves explanations) right, ftp.d.o mirroring and 
tier-1 are not coupled. You seem to imply that. Please clarify.



Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Ingo Juergensmann]

On Tue, Mar 15, 2005 at 10:51:24AM +0100, Julien BLACHE wrote:

> > You do know that m68k is the only architecture still carrying around
> > 2.*2* kernels in sarge?
> Yes. But there are 2.4 kernels available too, don't forget to mention
> that fact. No 2.6, though, but that's not a problem right now. Might
> become a problem for etch, I agree.
> m68k folks, is there anything in the works for 2.6 ?

To my knowledge there are even buildds running 2.6 on m68k. 
Even more: 
I took just another piece of m68k hardware, which Debian bought for the m68k
port, to Roman Zippel on March, 3rd in order to let him write the needed
drivers for that accelerator card. So, there will even be new drivers for
m68k soon that will be made for 2.6 kernel series, I think. 

With the new proposal of de facto dropping m68k support, I'm this -><- close
to recommend to Roman, that he better should invest his time into other
projects, because Debian wouldn't appreciate his work to bring up another
public m68k machine. 

-- 
Ciao...  // 
  Ingo \X/


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

Re: Vancouver meeting - clarifications

[Tollef Fog Heen]

* Andreas Barth 

| Well, that was one of the examples where we pay a price for more
| architectures. Of course, the testing migration script is not all, and
| this problem can be solved, but I think we should not forget that we pay
| a price - even if at the end, we think the price is acceptable.

Sure.

| (And, BTW, newraff is a quite mature box. Of course, there is always
| more and better hardware available, but newraff is already a very good
| machine. And, we want to give the testing migration script more tasks,
| like handling of the udebs, which puts load off from human being and on
| into a script. But that increases the ressources the script uses.)

If throwing hardware at a problem solves the problem and we're talking
about reasonable amounts of hardware and this helps the release, I
think it's an entirely appropriate thing to do.  It helps the
volunteers use their time well.  We haven't gotten donations to let
them sit around in a bank account, unused.  We've gotten them to
improve the distribution.  If that means buying hardware, fine, we'll
do that.

(As I'm not a RM/RA and don't have access to newraff, I didn't know
newraff ran out of memory due to the testing scripts -- in fact, I
thought it was doing very well, given that auric used to have problems
completing the testing scripts at all (IIRC), while aj said the
scripts take about 20 minutes on newraff now (he posted this in
January).)

I think identifying those kinds of bottlenecks is important and will
help us make releases happen faster.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: Accepted vile 9.4-r1 (powerpc sparc i386 source all)

[Thomas Dickey]

In article <[EMAIL PROTECTED]> you wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1

> Format: 1.7
> Date: Tue, 15 Mar 2005 00:28:38 +1100
> Source: vile
> Binary: xvile vile-filters vile vile-common
> Architecture:  all i386 powerpc source sparc 
> Version: 9.4-r1

thanks.   For 9.5, the short list I have remaining is to finish the Inno
Setup script and fix the bugs reported in the ruby filter.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Henning Makholm]

Scripsit Steve Langasek <[EMAIL PROTECTED]>

> In this instance, the current blocker is only an issue at all because
> ftp-master is not scaling well to handle all of the wanna-build ssh
> connections that are implied by the activation of another build queue...

Is there an underlying reason why the wanna-build management for all
architectures needs to happen on ftp-master? Speaking as an outsider,
I would expect that this task was relatively independent for each
architecture. Would it be a feasible long-range plan to let each
architecture have its own wanna-build running on some machine that can
sustain the load? If not, why not?

-- 
Henning Makholm  "Panic. Alarm. Incredulity.
   *Thing* has not enough legs. Topple walk.
  Fall over not. Why why why? What *is* it?"


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Henning Makholm]

Scripsit Anthony Towns 
> Mark Brown wrote:

>> Would it also be possible for porters to update the snapshots in some
>> manner beyond having an apt source equivalent to the security archive
>> added by d-i?

> It'd be possible, certainly -- cf proposed-updates and stable.

The proposal says that secondary architectures are not allowed to have
proposed-updates and stable.

> and the expectation is that non-release arches don't stress as much
> about RC bugs and similar as release arches will,

On what is this expectation founded? Mind you "non-release" is not a
status that the portes involved in the arch voluntarily choose; it is
something forced on them by the release team (or some of the other
veto powers of the Vancouver plan).

> which means you should be able to do an Ubuntu and say (as they do
> for universe) "we'll release when we want, and if random packages
> are broken, well, wait a few months and cross your fingers :)".

And what if a secondary architecture does not want to lower themselves
to that standard.

-- 
Henning Makholm"Vi skal nok ikke begynde at undervise hinanden i
den store regnekunst her, men jeg vil foreslå, at vi fra
 Kulturministeriets side sørger for at fremsende tallene og også
  give en beskrivelse af, hvordan man læser tallene. Tak for i dag!"

Re: ports.debian.org (Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Colin Watson]

On Mon, Mar 14, 2005 at 05:38:30PM +0100, Sven Luther wrote:
> On Mon, Mar 14, 2005 at 04:10:30PM +0100, Eduard Bloch wrote:
> > #include 
> > * Colin Watson [Mon, Mar 14 2005, 02:40:56PM]:
> > > On Mon, Mar 14, 2005 at 03:31:30PM +0100, Christoph Berg wrote:
> > > > I'd propose to use a less "discriminating" name for the scc archive.
> > > > What about ports.debian.org (which coincidentally already exists and
> > > > http-wise points to http://www.debian.org/ports/)?
> > > 
> > > I like this idea. SCC was a working codename that I think was originally
> > > intended to be changed as soon as somebody thought of something better,
> > > but nobody ever quite got round to it ...
> > 
> > Does it sound discriminating because you associcate that with real life?
> > Is "second class port" be a better name? (scp.d.o)? Or "non-releaseable
> > ports", nrp.d.o?

What Christoph said about second-class anything; and "non-releaseable"
is inaccurate, because whether or not an architecture is distributed
from ftp.d.o is orthogonal to releaseability, and the Vancouver proposal
envisages releasing at least one architecture from the secondary mirror
network (see the paragraph starting "Also, since the original purpose of
the SCC proposal was ...").

> I have proposed tier-1 ports for the main arches, tier-2 ports for the other
> ready ports but dropped from official support, and tier-3 ports for
> in-development ports.

My problem with that is that I think we (and more importantly, our
users) would always have to look up what these numbers meant. Using
words instead of numbers would be preferable. Furthermore your tiers
don't match the Vancouver proposal, in which there would be
architectures that would be released and officially supported but not
distributed from ftp.d.o.

The fundamental idea I'm trying to capture is "less popular" or
"minority interest" or something, but I can't think of a way to do that
that (a) doesn't sound offensive and (b) isn't incredibly wordy. "ports"
is the best I've heard so far.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andreas Tille]

On Tue, 15 Mar 2005, David Schmitt wrote:
And if the security team is not able to support those arches as-is, someone
will have to step up and do the work. Overly long delays for security updates
also diminish the usefulness of $arch.
I guess I missed the "Call for help on security issues on architecture xy"
mail on debian-devel-announce.  Can you point me to it please.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Colin Watson]

On Mon, Mar 14, 2005 at 08:58:46AM -0600, John Goerzen wrote:
> On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> > Therefore, we're planning on not releasing most of the minor architectures
> > starting with etch.  They will be released with sarge, with all that
> 
> That doesn't.  I see no problems with making an initial etch release
> consisting of whatever archs are ready, SCC or not.  If a given arch
> later has a working etch distribution and installer, why not publish an
> etch release for it, even if it is on SCC?

This paragraph from the proposal may bear repeating, since it was kind
of buried deep in the middle:

  Also, since the original purpose of the SCC proposal was to reduce the size
  of the archive that mirrors had to carry, the list of release candidate
  architectures will be further split, with only the most popular ones
  distributed via ftp.debian.org itself.  The criterion for being distributed
  from ftp.debian.org (and its mirrors) is roughly:

  - there must be a sufficient user base to justify inclusion on all
mirrors, defined as 10% of downloads over a sampled set of mirrors

Under this proposal, being on the SCC mirror network would not in itself
cause an architecture to be ineligible to release as part of etch.

> > - the release architecture must have N+1 buildds where N is the number
> >   required to keep up with the volume of uploaded packages
> > 
> > - the value of N above must not be > 2
> 
> It seems to me that if an arch can keep up with builds, why impose this
> artificial restriction?

I'm not sure where this restriction came from, and I didn't think to
question it at the time ...

> > ftpmasters also intend to provide porter teams with the option of
> > releasing periodic (or not-so-periodic) per-architecture snapshots of
> > unstable.
> 
> I'd rather see the option to produce the same per-architecture snapshot
> of testing as everyone else uses; that is, an etch release.

I wonder if we could simply use the current support in britney for
declaring that an architecture isn't keeping up to date and that any
problems with it shouldn't block the rest of testing. I'm not sure what
the consequences of that would be for the usability of testing on
non-releasing architectures, though; it might make them worse.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Debian offering stunnel/OpenVPN capabilities? [Was: Re: Restrictive SMTP server]

[Jesus Climent]

> > 
> > I'm willing to provide an OpenVPN tunnel to an SMTP server for any DD who is
> > unable to find alternate lodgings, and I'm pretty sure I'm not the only one.
> 
> I can offer something as well - I would probably lean towards just
> auth+ssl instead of over VPN, but it's up to you.  I just don't happen
> to have a VPN set up yet, so it's less ovrhead for me :)

Could we think on some stunnel or OpenVPN feature under
people.debian.org/other machine to get mail from debian.org routed to the
outside world?

With stunnel, a level3 of authentication would be needed, so that the server
gets a client certificate and the client gets a server one. With the
combination of both, one can connect to, say, port 25025 and get a proper
postfix/exim SMTP server on the remote machine.

I have been dealing with a similar configuration and seems to be working fine
so far.

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

And then he ran into my knife... he ran into my knife ten times.
--June (Chicago)


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

Re: [Proposal] Upgrade newraff hardware

[Ron Johnson]

On Tue, 2005-03-15 at 02:55 -0800, Brian Nelson wrote:
> On Tue, Mar 15, 2005 at 11:05:13AM +0100, Bill Allombert wrote:
> > Hello Debian developers,
> > 
> > It had come several times that one major problem is the load of
> > wanna-build connection on newraff, and the time and memory it take 
> > to run the testing scripts.
> > 
> > Debian certainly has enough goodwill to get a donation of a couple of
> > really fast box with lots of RAM, and has enough money to buy them
> > anyway.  Especially a box with SSL exchange hardware support could be
> > useful. 
> 
> Sounds like it's already quite powerful:
> 
> Processor: Dual Intel P4 Xeon 2.8Ghz 
> Memory: 6Gb 

Given sufficient load, even that can be insufficient.  A quad-
Opteron (in 32-bit mode, of course) would be sweet.

> Disk space: 735Gb [6x147Gb RAID 5] 
> Bandwidth: 100Mbit colocated LAN 

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"There is no maxim in my opinion which is more liable to be
misapplied, and which therefore needs elucidation than the
current one that the interest of the majority is the political
standard of right and wrong In fact it is only reestablishing
under another name a more specious form, force as the measure of
right"
James Madison, 1786



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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Michael Ablassmeier]

On 2005-03-15, Julien BLACHE <[EMAIL PROTECTED]> wrote:
>
> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>
>>> How could we know ? We know nothing about Ubuntu, nothing about
>>> Canonical, nothing about the goals, nothing about how everything was
>>> done to begin with, nothing about who works or doesn't work there.
>>
>> Details about Ubuntu and its goals can be found on the website.  In many
>> respects there is more information available about Ubuntu activity, and the
>> goals of the project, than about organizations which provide you with the
>> essentials of life.  Yet, you seem to trust them by default, while you
>> assume that Ubuntu seeks to cause you harm.  Why?
>
> Because Ubuntu appeared behind a screen of smoke. And smoke hasn't
> dissipated yet. Debian Developers were not informed in an appropriate
> manner of what was going on there.

Sorry, but i can't see the problem here. Everyone can go ahead and do a
value-added Distribution based on Debian. There is no need be verbose
about it, though. Also, i dont think the Debian Developers working for
Ubuntu have to justify why they are doing so. 

> By destroying the Project ? Interesting approach.

As this is just a _proposal_, you are free to suggest alternative
approaches on how to solve the Problems the Project is currently facing.

bye, 
   - michael


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

Re: Security support for tier-2 (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Sven Luther]

On Tue, Mar 15, 2005 at 12:22:34PM +0100, David Schmitt wrote:
> On Monday 14 March 2005 17:18, Sven Luther wrote:
> > On Mon, Mar 14, 2005 at 11:12:29AM -0500, David Nusinow wrote:
> > > On Mon, Mar 14, 2005 at 09:54:49AM -0600, John Goerzen wrote:
> > > > It is not unstable that I am (most) worried about.
> > > >
> > > > It is the lack of any possibility of a stable release that concerns me.
> > > > Even if the people for a given arch were to build a stable etch, it
> > > > would have no home in Debian, would suffer from being out of the loop
> > > > on security updates, etc.
> > >
> > > Well, we do know the security team needs help. What I'd love to see is
> > > each port have someone on the security team to handle their specific
> > > bugs, binary builds and testing. That might scale better and decrease the
> > > overall load on the team. This is all in line with what seems to be the
> > > central thesis of the proposal: shift more of the core burden to the
> > > porters. Of course, this does demand a lot, but the burden has to go
> > > somewhere, and the people currently carrying large portions of it are
> > > saying they can't do this any more.
> >
> > Notice too that the exact same people whose help is needed are those that
> > are pissed by this proposal, and whose help has been repeteadly rejected in
> > the past.
> 
> 
> Sven, is there a specific reason you believe that the proposers will 
> prevent[1] security-support on scc.d.o for tier-2 arches or are you only 
> ranting?

Because of [1], because they said they will drop security on tier-2 arches and
that porters should be left to fend by themselves, did they not ? 

Friendly,

Sven Luther


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Sven Luther]

On Tue, Mar 15, 2005 at 10:51:24AM +0100, Julien BLACHE wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> 
> >> And keeping IA64 in the loop is just another joke from the release
> >> team. It'd be interesting to find out, but I bet more m68ks were sold
> >> than IA64 last year.
> >
> > Which of these two architectures are you more likely to be able to run a
> > current 2.6 kernel on, BTW?
> 
> I fail to see why this matters at all. It's not in your list of
> requirements, remember ?
> 
> > You do know that m68k is the only architecture still carrying around
> > 2.*2* kernels in sarge?
> 
> Yes. But there are 2.4 kernels available too, don't forget to mention
> that fact. No 2.6, though, but that's not a problem right now. Might
> become a problem for etch, I agree.

There is 2.6 work on m68k, just not all subarches are ready for it though.

> m68k folks, is there anything in the works for 2.6 ?

Yep, runs since a couple of month last time i was informed for that, at least
on the amiga arch.

Friendly,

Sven Luther


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Henning Makholm]

Scripsit Steve Langasek <[EMAIL PROTECTED]>

>> I would add as for the core set architecture:
>> - there must be a developer-accessible debian.org machine for the 
>> architecture.

> This gets a little tricky for non-RC architectures, because if it's not
> already (or currently) a released architecture, we have no stable distro
> that can be installed on it, which means we have no security support for
> it; without security support, DSA isn't willing to maintain it, which
> means they probably aren't going to want to put a "debian.org" name on
> it, either -- and they certainly won't want to give it privileged access
> to LDAP.

So how can an architecture ever become releaseworthy? It will not get
release-certified before it has a a debian.org machine, and it cannot
get a machine in debian.org before it has a stable version with
security support, and it's not allowed to create a stable version and
provide security support for it before it has been release-certified.

> Well, if we wanted to make the decision without the input of developers,
> announcing it on d-d-a in advance of implementation isn't a very
> effective way to make that happen, is it?

If you wanted to make the decision _with_ the input of developers, why
did all the powers that be vehemently deny that the number of
architectures was a problem for the release schedule, right until
everyone turned on a platter and presented this fait accompli?

> I agree that our architecture coverage is important.  I don't know if
> stable support for all of these architectures is important,

It is.

> but I *do* know that stable support for all of these architectures
> costs us in terms of the release cycle.

The solution to that is to decouple the secondary architectures from
the release cycle of the main architecture. There is no visible reason
why the solution has to include a ban on making any stable release for
a minor architecture at all.

-- 
Henning Makholm   "Hele toget raslede imens Sjælland fór forbi."

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Henning Makholm]

Scripsit Steve Langasek <[EMAIL PROTECTED]>

> This really makes unstable snapshotting, or building stable once it's
> released as Anthony has also suggested in this thread, look like much
> better options than trying to build out of testing.

Building stable once it is released does look indeed like a good
option.  Only it's a pity that the Vancouver plan does not allow it.

-- 
Henning Makholm "However, the fact that the utterance by
   Epimenides of that false sentence could imply the
   existence of some Cretan who is not a liar is rather unsettling."


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Sven Luther]

On Tue, Mar 15, 2005 at 12:30:59PM +0100, Ingo Juergensmann wrote:
> On Tue, Mar 15, 2005 at 10:51:24AM +0100, Julien BLACHE wrote:
> 
> > > You do know that m68k is the only architecture still carrying around
> > > 2.*2* kernels in sarge?
> > Yes. But there are 2.4 kernels available too, don't forget to mention
> > that fact. No 2.6, though, but that's not a problem right now. Might
> > become a problem for etch, I agree.
> > m68k folks, is there anything in the works for 2.6 ?
> 
> To my knowledge there are even buildds running 2.6 on m68k. 
> Even more: 
> I took just another piece of m68k hardware, which Debian bought for the m68k
> port, to Roman Zippel on March, 3rd in order to let him write the needed
> drivers for that accelerator card. So, there will even be new drivers for
> m68k soon that will be made for 2.6 kernel series, I think. 
> 
> With the new proposal of de facto dropping m68k support, I'm this -><- close
> to recommend to Roman, that he better should invest his time into other
> projects, because Debian wouldn't appreciate his work to bring up another
> public m68k machine. 

Notice that m68k doesn't actively participate in the kernel-team, and package
their stuff in their own corner though, which may be the reason for this
perceived problem.

Friendly,

Sven Luther


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

Re: Debian offering stunnel/OpenVPN capabilities? [Was: Re: Restrictive SMTP server]

[Jesus Climent]

On Tue, Mar 15, 2005 at 01:04:53PM +0100, Jesus Climent wrote:
> > > 
> > > I'm willing to provide an OpenVPN tunnel to an SMTP server for any DD who 
> > > is
> > > unable to find alternate lodgings, and I'm pretty sure I'm not the only 
> > > one.
> > 
> > I can offer something as well - I would probably lean towards just
> > auth+ssl instead of over VPN, but it's up to you.  I just don't happen
> > to have a VPN set up yet, so it's less ovrhead for me :)
> 
> Could we think on some stunnel or OpenVPN feature under
> people.debian.org/other machine to get mail from debian.org routed to the
> outside world?
> 
> With stunnel, a level3 of authentication would be needed, so that the server
> gets a client certificate and the client gets a server one. With the
> combination of both, one can connect to, say, port 25025 and get a proper
> postfix/exim SMTP server on the remote machine.
> 
> I have been dealing with a similar configuration and seems to be working fine
> so far.

Forgot to mention that the way to get those certs in the server machine would
be using your gpg-signed certificate in combination with whichever way of
sending an email you have.

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

When you dance with the devil, you wait for the song to stop.
--Barry the Baptist (Lock, Stock and Two Smoking Barrels)


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

Re: Another load of typos

[Adeodato Simó]

* Christian Perrier [Tue, 15 Mar 2005 09:24:57 +0100]:

> Indeed, typo and spell corrections should not need translation updates
> and affected translations can certainly be unfuzzied.WHEN ONE
> KNOWS HOW TO DO THIS CLEANLY...:-)

  I've never had to to such thing, but I've wondered from time to time.
  So, if I do a spell correction in a debconf template, what should I
  take care of doing/not doing? (RTFM welcome if accompanied by a point
  to the relevant M :).

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
The Wright Brothers weren't the first to fly. They were just the first
not to crash


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

Re: Call for help / release criteria (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Julien BLACHE]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Palmer <[EMAIL PROTECTED]> wrote:

>> >> Why they don't ask for help?
>> >
>> > They do so now. Are you (all) prepared to take up the call?
>> 
>> Yes, we are. There are enough interested people here to replace the
>> current people in charge.
>
> A coup.  Yep, that'll solve the problem.

That "we" wasn't referring to any team in particular, but to the DDs
in general. And it's a fact, there are people in the Project ready to
step up for the jobs, who are willing to work in an open manner.

> Yeesh.

Blah.

JB.

- -- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCNtCPzWFP1/XWUWkRAgXSAKCuM7h5w/faxh8GCoIsve6u6iXLaACglTxU
1orK/2cbYaPDVcVI4WL3fuY=
=wrmc
-END PGP SIGNATURE-


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

Re: Vancouver meeting - clarifications

[Bill Allombert]

On Tue, Mar 15, 2005 at 11:38:51AM +0100, Andreas Barth wrote:
> * Tollef Fog Heen ([EMAIL PROTECTED]) [050315 10:50]:
> > Debian has a fairly big chunk of cash lying about.  If we have
> > problems doing testing migration because of not enough hardware, this
> > is something I think we should spend money on.  Or we could ask a
> > sponsor (hi HP!:) if they would be willing to donate some more memory.
> 
> Well, that was one of the examples where we pay a price for more
> architectures. Of course, the testing migration script is not all, and
> this problem can be solved, but I think we should not forget that we pay
> a price - even if at the end, we think the price is acceptable.

Sure, but Debian has received lots of donation in hardware and cash
*because* we were supporting more architectures. It seems fit to use
that money and donations to continue that path.

> (And, BTW, newraff is a quite mature box. Of course, there is always
> more and better hardware available, but newraff is already a very good
> machine. And, we want to give the testing migration script more tasks,
> like handling of the udebs, which puts load off from human being and on
> into a script. But that increases the ressources the script uses.)

Sure, but if buying 32Gb more RAM for sarge make the life of the
release team easier, it is a very good use of the money.

> One of the problems is that for every decision (and even for the
> decision to don't make a decision), we pay a price.  There are prices
> I'm not willing to pay (like another release cycle of the length of
> sarge) - but well, if Debian goes into that direction, I'll go out of
> the way.  Other people are not willing to pay other prices.  My goal is
> to find a route to take that as many people as possible are considering
> as acceptable.

Thanks to put the matter so clearly.

For the record, I am willing to pay the price of another release cycle
of the length of sarge much more than I am willing to pay the price of a
crippled release with only half a dozen architectures supported.  

However, I am not so pessimistic: we have released woody with less delay
than sarge will with the same set of architectures and several of them
were more problematic than any archs have been during sarge. (ia64 was
using gcc-2.96 and hppa gcc-3.0 which refused to compile legacy g++ code
and hppa g++ did not support exception).

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andreas Barth]

* Colin Watson ([EMAIL PROTECTED]) [050315 12:55]:
> I wonder if we could simply use the current support in britney for
> declaring that an architecture isn't keeping up to date and that any
> problems with it shouldn't block the rest of testing.

In that case, it might be better in the long term to make some
"synchronize" runs outside of current britney, as that might be better
in terms of speed and memory usage.

Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: status of buildds?

[Hamish Moffatt]

On Tue, Mar 15, 2005 at 10:41:12AM +0100, Goswin von Brederlow wrote:
> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> > If the s390 team is unhappy with w-b, they can simply set up their own
> > autobuilding and do it themselves; all the software is free software.
[..]
> We did that last year for m68k, mips, mipsel and alpha and it produced
> a great flame since some machines where hosted by non DDs and none of
> them were approved by the debian admin team. The opinions (including
> an RM too) expressed in that flame resulted in the effort to help
> archs with backlogs with extra buildds to shut down to comply with
> their wishes.

As you well know, the problem was that the buildds were run by
non-developers for whom we have no trust relationship, not that they 
were being run by a developer unofficially.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: ports.debian.org (Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Sven Luther]

On Tue, Mar 15, 2005 at 11:47:37AM +, Colin Watson wrote:
> On Mon, Mar 14, 2005 at 05:38:30PM +0100, Sven Luther wrote:
> > I have proposed tier-1 ports for the main arches, tier-2 ports for the other
> > ready ports but dropped from official support, and tier-3 ports for
> > in-development ports.
> 
> My problem with that is that I think we (and more importantly, our
> users) would always have to look up what these numbers meant. Using
> words instead of numbers would be preferable. Furthermore your tiers

Well, the user don't care, they point their apt sources at :

  ftp..debian.org

and everything works well for them, given the warning about possibly delays in
security updates (altough the nonexistence of security..debian.org
should hint them to that anyway).

> don't match the Vancouver proposal, in which there would be

I don't care about the Vancounver proposal all that much, since its basic
premise are the dropping of the minority arches, that is no stable release, no
testing infrastructure, no security updates. If that is not what was meant,
then a new announcement clarifying the points is in order.

> architectures that would be released and officially supported but not
> distributed from ftp.d.o.

I think the vancouver proposal, or at least its announcement was profundly
lacking in clarity, and didn't clearly separate the three different problems
and their solutions :

  1) mirror bandwidth and space issues.

  2) release management and autobuilders.

  3) security update for stable releases.

Am i not right in thinking that those where the key issues, and you that was
there, do you not think it would be welcome of the vancouver-cabal :) to
clarify their remedies for each of those points separatedly ? 

> The fundamental idea I'm trying to capture is "less popular" or
> "minority interest" or something, but I can't think of a way to do that
> that (a) doesn't sound offensive and (b) isn't incredibly wordy. "ports"
> is the best I've heard so far.

well, it probably sounds offensive because the proposed solution is offensive
in the first place, isn't it ? 

And ports, well, its all nice, but how do you measre inegality in port
treatment then ? will we have scp or something such ?

Friendly,

Sven Luther


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

Re: Vancouver meeting - clarifications

[Henning Makholm]

Scripsit Andreas Barth <[EMAIL PROTECTED]>

> Having said this, this all doesn't exclude the possibility for a
> non-release arch to have some "testing" which can be (mostly) in sync with
> the release architectures testing - just that if it breaks, the release
> team is not forced anymore to hold the strings together.  For example,
> the amd64-people are doing something like that right now.

OK, so you are explicitly backing down from the Vancouver paper's ban
against arch-specific "testing" distributions for minor
architectures. Do you speak for the entire Vancouver authorship here?

Alas, I infer that this means that the ban against arch-specific
"stable" distributions for minor architectures (even if security
updates can be provided in some way or another) still stands.
Thus the minor architectures will still effectively be forced out
in the dark. Can you provide any rationale for this decision?

-- 
Henning Makholm "Slip den panserraket og læg
  dig på jorden med ansigtet nedad!"

Re: Vancouver meeting - clarifications

[Peter 'p2' De Schrijver]

> | - the release architecture must have N+1 buildds where N is the number
> |   required to keep up with the volume of uploaded packages
> The reason for this proposal should be instantly clear to everyone who
> ever suffered from buildd backlogs. :)
> 
> We want that all unstable packages are directly built under normal
> circumstances and that in the even of a buildd going down the arch does
> not suffer noticably.  The long periods of trying to get some RC-bugfix
> in while some arch has a backlog should disappear with etch.
> 

That should be easy to achieve on any of the currently supported debian
architectures. Perhaps we need things like scratchbox or distcc to do
this, but it can be done and there is sufficient interest in the
community to make this happen.

> | - the release architecture must have successfully compiled 98% of the
> |   archive's source (excluding architecture-specific packages)
> well, that's just an "the architecture is basically working", so that we
> don't get too many RC-bugs because of architecture-specific issues, and
> also don't get too many packages kept out of testing for not all archs
> being built. Of course, the 98% is not engraved into stone, and might just
> be another arbitrary high number like 97.5%. From looking at the usual
> level where we start noticing problems with testing migrations, a number
> in this range is sane.

I strongly disagree with this. There is a need for a set of base
packages to work, but it's entirely reasonable to have a release for eg
m68k without KDE or other large package sets. It's not as if debian/m68k
would be unusable without KDE packages for example. 

> 
> | - the release architecture must have a working, tested installer
> I hope that's obvious why. :)
> 

As long as FAI or even raw debootstrap counts, I can agree here.

> | - the Security Team must be willing to provide long-term support for
> |   the architecture
> If not, we can't release with that arch. I think this is also quite
> obvious. Of course, one way to get the security team to provide support
> might be to help them.
> 

The porting community is happy to help out here. Feel free to send
requests for help, even to me.

> | - the Debian System Administrators (DSA) must be willing to support
> |   debian.org machine(s) of that architecture
> | - there must be a developer-accessible debian.org machine for the
> |   architecture.
> Well, the second point is - I hope - obvious why we want this. This first
> one is just a conclusion of the second.
> 

The first one basically gives the DSA unlimited powers over which archs
can be in debian. That's bad.

> | - the Release Team can veto the architecture's inclusion if they have
> |   overwhelming concerns regarding the architecture's impact on the
> |   release quality or the release cycle length
> This is just more or less an emergency-exit: If we consider an architecture
> really unfit for release, we can use our veto. This is one of the things I
> hope will never happen.
> 
> 

If you don't expect it to happen, there is no reason for this being
here. Ergo, please remove.

> 
> Something else which is related to the number of architectures in testing
> is that we pay a price for every architecture:
> 
> For example, the more architectures are included the longer the migration
> testing script takes.  We are already at the limit currently (and also
> have out-of-memory issues from time to time). For example, currently we
> restrict the number of some hints to only 5 per day to keep up the
> scripts. Also, the udebs are not taken into account, which requires more
> manual intervention. With a lower number of release architecture, we can
> and will improve our scripts.
> 
> 

I fail to see why less archs allows you to improve the scripts. You can
always improve them, regardless of how many usage they get. I believe
there is sufficient algorithm knowhow in the debian developer community
to solve the scalability problems.

> 
> Having said this, this all doesn't exclude the possibility for a
> non-release arch to have some "testing" which can be (mostly) in sync with
> the release architectures testing - just that if it breaks, the release
> team is not forced anymore to hold the strings together.  For example,
> the amd64-people are doing something like that right now.
> 
> 

The current proposal will lead to random arch specific forks. Each arch
decides when they want a release and will include it's own fixes for
arch specific problems. These fixes might go into debian or upstream or
not (depends if debian or upstream wants them. Given the current hostile
feelings of some debian people against anything no mainstream, I hope upstream
will want them). If they are not integrated in debian or upstream, this
will lead to multiple archs solving the same problems (consider
endianess, alignment bugs, wrong use of bitfields,...). This will also
lead to multiple inconsistent debian releases as the specific arch teams
decide on when to r

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Ingo Juergensmann]

On Tue, Mar 15, 2005 at 12:59:43PM +0100, Sven Luther wrote:

> > With the new proposal of de facto dropping m68k support, I'm this -><- close
> > to recommend to Roman, that he better should invest his time into other
> > projects, because Debian wouldn't appreciate his work to bring up another
> > public m68k machine. 
> Notice that m68k doesn't actively participate in the kernel-team, and package
> their stuff in their own corner though, which may be the reason for this
> perceived problem.

Has the kernel team made any advances to the m68k kernel team for a closer
cooperation? Or did they just yelled "Hey! We are now taking over the kernel
development, no matter if more capable people are outside of the project!"?

-- 
Ciao...  // 
  Ingo \X/


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Mark Brown]

On Tue, Mar 15, 2005 at 11:54:24AM +, Henning Makholm wrote:

> If you wanted to make the decision _with_ the input of developers, why
> did all the powers that be vehemently deny that the number of
> architectures was a problem for the release schedule, right until
> everyone turned on a platter and presented this fait accompli?

To be fair, there were some comments to that effect from some of the
relevant people beforehand.  For example, Joey Hess raised concerns
regarding the load placed on the d-i developers in some of the recent
"too many arches" threads.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: status of buildds?

[Ingo Juergensmann]

On Tue, Mar 15, 2005 at 11:34:58PM +1100, Hamish Moffatt wrote:
> On Tue, Mar 15, 2005 at 10:41:12AM +0100, Goswin von Brederlow wrote:
> > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> > > If the s390 team is unhappy with w-b, they can simply set up their own
> > > autobuilding and do it themselves; all the software is free software.
> [..]
> > We did that last year for m68k, mips, mipsel and alpha and it produced
> > a great flame since some machines where hosted by non DDs and none of
> > them were approved by the debian admin team. The opinions (including
> > an RM too) expressed in that flame resulted in the effort to help
> > archs with backlogs with extra buildds to shut down to comply with
> > their wishes.
> As you well know, the problem was that the buildds were run by
> non-developers for whom we have no trust relationship, not that they 
> were being run by a developer unofficially.

So, you call me not trustworthy, although it was *me* to first help out m68k
when kullervo was unable to keep up with package building? 
You call me not trustworthy, although all of the security team members had
an account on arrakis and used that for years of security building?
You call me not trustworthy, although I have setup crest, which still runs
with my licensed Amitcp Keys on its AmigaOS partition and I had root access
to it for a very long time?
You call me not trustworthy, although I still have root access to another
m68k buildd?
You call me not trustworthy, although I managed to get hardware not only for
m68k port, but for mips f.e. as well, and drove hundreds of kilometers two
weeks ago just to deliver another piece of hardware to another fellow m68k
developer?

*bummer*

-- 
Ciao...  // 
  Ingo \X/


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Ingo Juergensmann]

On Tue, Mar 15, 2005 at 12:45:13PM +, Mark Brown wrote:

> > If you wanted to make the decision _with_ the input of developers, why
> > did all the powers that be vehemently deny that the number of
> > architectures was a problem for the release schedule, right until
> > everyone turned on a platter and presented this fait accompli?
> To be fair, there were some comments to that effect from some of the
> relevant people beforehand.  For example, Joey Hess raised concerns
> regarding the load placed on the d-i developers in some of the recent
> "too many arches" threads.

Well, someone[TM] decided somewhen[TM] that d-i is mandatory for sarge. 
Of course a completely new implementation of an installer consumes a *lot*
of work, and I think everyone appreciate the work so far done, but I think
that work needs to be done just once, mainly. 
For example it's very unlikely that m68k will dramatically change their
numbers of supported hardware. So the future work load should be fairly
limited to keep m68k installable by d-i (except for newer kernels and such,
but that needs to be done anyway). 
Therefore I think d-i should be kept out of discussion for this. 

-- 
Ciao...  // 
  Ingo \X/


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

Re: Vancouver meeting - clarifications

[Andreas Barth]

Hi,

* Tollef Fog Heen ([EMAIL PROTECTED]) [050315 12:40]:
> * Andreas Barth 
> | (And, BTW, newraff is a quite mature box. Of course, there is always
> | more and better hardware available, but newraff is already a very good
> | machine. And, we want to give the testing migration script more tasks,
> | like handling of the udebs, which puts load off from human being and on
> | into a script. But that increases the ressources the script uses.)

> (As I'm not a RM/RA and don't have access to newraff, I didn't know
> newraff ran out of memory due to the testing scripts -- in fact, I
> thought it was doing very well, given that auric used to have problems
> completing the testing scripts at all (IIRC), while aj said the
> scripts take about 20 minutes on newraff now (he posted this in
> January).)

Well, but the saved time is already used: We rerun britney sometimes
multiple times a day. That makes resolving of some critical issues much
faster. So, we can only trade one issue with another.

(And please remember that even if the proposed policy would become
effective without any change, that doesn't necessarily mean the end to a
certain architecture, but just that the the amount of extra work the
architectures had been for the release team and other core teams needs
to go down. Of course, having better support is my prefered way, but if
that doesn't work, getting the number of archs down is another
possiblity.)


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Marc Haber]

On Tue, 15 Mar 2005 11:11:11 +0100, Frank Küster <[EMAIL PROTECTED]>
wrote:
>In the long run, it might be even possible to get along with the stable
>sources alone, plus a second, tier-2-specific diff.gz - if I'm not
>mistaken it is planned to enable dpkg to work with a more flexible
>format for source packages.

Having multiple diff.gz files will also greatly ease backporting
efforts.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Marc Haber]

On Tue, 15 Mar 2005 11:54:51 +0100, David Schmitt
<[EMAIL PROTECTED]> wrote:
>On Monday 14 March 2005 17:02, Marc Haber wrote:
>> The problem is that it is extremely hard to be allowed to do any work
>> for Debian, and I think that should change. I know of two core teams
>> in Debian which have more than half of their members in an in-active
>> state. This is bad. People who are not doing any actual work should
>> resign and allow themselves to be replaces with people who are eager
>> to do work and to take responsibility.
>
>As long as you don't provide pointer to relevant material this sounds like hte 
>earlier claim, that Martin Schulze is the only active security team member 
>because his DSA announcements are the only ones posted[1].

Our core teams don't communicate enough with mere mortals so there is
no hard evidence available, unfortunately. And as long as people do
not communicate, other people will speculate.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Vancouver meeting - clarifications

[Andreas Barth]

* Peter 'p2' De Schrijver ([EMAIL PROTECTED]) [050315 13:45]:
> > | - the release architecture must have successfully compiled 98% of the
> > |   archive's source (excluding architecture-specific packages)
> > well, that's just an "the architecture is basically working", so that we
> > don't get too many RC-bugs because of architecture-specific issues, and
> > also don't get too many packages kept out of testing for not all archs
> > being built. Of course, the 98% is not engraved into stone, and might just
> > be another arbitrary high number like 97.5%. From looking at the usual
> > level where we start noticing problems with testing migrations, a number
> > in this range is sane.

> I strongly disagree with this. There is a need for a set of base
> packages to work, but it's entirely reasonable to have a release for eg
> m68k without KDE or other large package sets. It's not as if debian/m68k
> would be unusable without KDE packages for example. 

You might try to convince me that KDE is architecture-specific :)

I hope you can agree that we need to say that "almost all" packages that
should be build are build. And I consider 97.5% to be a reasonable
level. Also, if we exclude too much, we might start to ask the question
why we should do a stable release for an arch that builds only a very
minor part of the archive. But the "excluding architecture-specific
packages" gives of course some possibilities which packages count and
which not.


> > | - the release architecture must have a working, tested installer
> > I hope that's obvious why. :)

> As long as FAI or even raw debootstrap counts, I can agree here.

Any installer inside Debian. Of course, we can't tell people "To install
Debian, you first need to install Gentoo" :)


> I fail to see why less archs allows you to improve the scripts. You can
> always improve them, regardless of how many usage they get. I believe
> there is sufficient algorithm knowhow in the debian developer community
> to solve the scalability problems.

Anyone who provides better scalability for britney is welcome.




Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Mark Brown]

On Tue, Mar 15, 2005 at 10:26:33AM +1000, Anthony Towns wrote:
> Mark Brown wrote:

> >Would it also be possible for porters to update the snapshots in some
> >manner beyond having an apt source equivalent to the security archive
> >added by d-i?

> It'd be possible, certainly -- cf proposed-updates and stable.

It would be useful if this could be clarified in any revision of the
proposal - I don't think I was the only one to read it as saying that
non-release ports wouldn't have any options other than simple snapshots.

> Whether it would happen would depend on how useful it is; you have to 
> add security.d.o to your sources.list and download from it for stable 
> releases anyway; and the expectation is that non-release arches don't 
> stress as much about RC bugs and similar as release arches will, which 

My thought was that some of the non-release architectures that were in
generally good shape might want to provide a version stable which would
ideally involve the ability to do things like tracking the released 
stable.

> Feedback from porters on how these things could actually work usefully 
> in real circumstances would be valuable here. Having a way of making 
> snapshots is probably the minimal level of support we'd envisage, 
> working out what that would actually achieve, and what benefits more 
> support would actually bring would be interesting.

Yup.  Presumably there would be varying requirements from the ports - at
least some of the ports would be perfectly happy with simple snapshots.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andreas Barth]

* Henning Makholm ([EMAIL PROTECTED]) [050315 12:45]:
> Scripsit Steve Langasek <[EMAIL PROTECTED]>

> > In this instance, the current blocker is only an issue at all because
> > ftp-master is not scaling well to handle all of the wanna-build ssh
> > connections that are implied by the activation of another build queue...
 
> Is there an underlying reason why the wanna-build management for all
> architectures needs to happen on ftp-master?

For any architecture that builds directly from accepted, having
wanna-build on ftp-master has some improvements.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)

[Frank Küster]

Peter 'p2' De Schrijver <[EMAIL PROTECTED]> schrieb:

[quoting Andreas Barth]

>> | - the release architecture must have successfully compiled 98% of the
>> |   archive's source (excluding architecture-specific packages)
>> well, that's just an "the architecture is basically working", so that we
>> don't get too many RC-bugs because of architecture-specific issues, and
>> also don't get too many packages kept out of testing for not all archs
>> being built. Of course, the 98% is not engraved into stone, and might just
>> be another arbitrary high number like 97.5%. From looking at the usual
>> level where we start noticing problems with testing migrations, a number
>> in this range is sane.
>
> I strongly disagree with this. There is a need for a set of base
> packages to work, but it's entirely reasonable to have a release for eg
> m68k without KDE or other large package sets. It's not as if debian/m68k
> would be unusable without KDE packages for example. 

This whole argument is bogus.  Up to before Vancouver, we always said:
"A package should be Architecture: any if it can in principle be
compiled on every arch; the fact that it might not be useful there does
not justify excluding it from that arch."  And AFAIK the rationale for
this was overall quality of the distribution.

Now with the requirement for 98% compiled (and N<=2 buildd's being able
to take the workload) the focus has shifted: From overall quality to
timely release and quality of individual architectures.

For the porters to a specific architecture, this means they have an easy
way to get nearer to the 98% and the N<=2 criteria: Just convince the
maintainers of heavy-loaded desktop stuff, of big self-bootstrapping
numbercrunching applications, and whatever, to take your architecture
out of the Architecture field.

And this is not "cheating".  If KDE is of no use on m68k or for most
mips applications; or if 98% of sparc users[1] don't need a desktop, then
it's not unjust if those are simply excluded.  Remember, in the old days
before Vancouver ;-) it was mainly compiled for the benefit of the
_other_ arches.

And for the 2% of sparc users that do use KDE, it would probably be okay
to have a separate archive for such stuff.  

Regards, Frank

[1] this is just an example, I have no idea how a sparc compares to
other machines; I just read that they are today manly used for server
tasks.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Marc Haber]

On 15 Mar 2005 12:01:40 GMT, Michael Ablassmeier <[EMAIL PROTECTED]>
wrote:
>On 2005-03-15, Julien BLACHE <[EMAIL PROTECTED]> wrote:
>> By destroying the Project ? Interesting approach.
>
>As this is just a _proposal_, you are free to suggest alternative
>approaches on how to solve the Problems the Project is currently facing.

Unfortunately, there is not enough information available to tackle the
real problems. Our core teams do not communicate.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Marc Haber]

On Tue, 15 Mar 2005 12:17:59 +0100, David Schmitt
<[EMAIL PROTECTED]> wrote:
>On Monday 14 March 2005 16:23, John Goerzen wrote:
>> On Mon, Mar 14, 2005 at 12:47:58PM +0100, Julien BLACHE wrote:
>> > Basically, you're just leaving a number of Debian users out in the
>> > cold. Users who choose Debian because we were the only distribution
>> > out of there to provide serious support for the architectures they
>> > care for, for various reasons.
>>
>> Indeed.  I am one such user.  I have always felt fortunate that I don't
>> have to really care what architecture a machine is, because "of course
>> it runs Debian".  I have run Debian on Alpha, x86, amd64, powerpc, and
>> sarc systems, both as a desktop and a server environment on most of
>> these.
>
>And if the security team is not able to support those arches as-is, someone 
>will have to step up and do the work.

That someone will have to be allowed in. Which is the problem for the
majority of our core teams. They are very protective about their turf.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834