Re: etch release target: SELinux?? (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[paddy]

On Tue, Apr 12, 2005 at 06:07:13AM -0400, Kevin Mark wrote:
> If a tee-shirt with 'I
> fixed the oldest bug in Debian, and all I got was this lousey tee-shirt'
> helps to motivate folks -- great by me! And great for our users and
> Debian!

And then, as if by magic 

On Tue, Apr 12, 2005 at 01:40:25AM -0400, Milton Campis wrote:
> Dear Debian Devel,

 

repeat after me "wining lottery ticket, winning lottery ticket ..."

Regards,
Paddy
-- 
Careless talk costs lines


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

Re: etch release target: SELinux?? (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Kevin Mark]

On Tue, Apr 12, 2005 at 03:24:48AM -0400, Joey Hess wrote:
> Kevin Mark wrote:
> > > Given the fact that the current standard installation installs both gcc, 
> > > gdb and other development packages weighting more than that (see #301138, 
> > > which nobody wants to fix) 
> > Sorry to interupt, just got a stupid idea, if as Javier suggests, there
> > are bugs that no one wants to fix, why not try an idea called a 'bounty'
> 
> If you'll read the log to #301138, you'll see not much evidence of not
> wanting to fix it now, and a lot of evidence of people who want to fix
> it, but do not care to make such a large change and destabilise what
> sarge installs this close to a release.
> 
> -- 
> see shy jo
Hi Joey,
I did not delve into the details of what you suggests is a change that
would seriously affect Sarge and its release schedule. I was just
thinking about possible other means to get years old bugs or other
release stoppers from getting some looking at. If a tee-shirt with 'I
fixed the oldest bug in Debian, and all I got was this lousey tee-shirt'
helps to motivate folks -- great by me! And great for our users and
Debian!
Cheers,
Kev


signature.asc
Description: Digital signature

Re: etch release target: SELinux?? (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Thijs Kinkhorst]

On Mon, April 11, 2005 21:46, Javier Fernández-Sanguino Peña said:
> Given the fact that the current standard installation installs both gcc,
> gdb and other development packages weighting more than that (see #301138,
> which nobody wants to fix) I don't find that an issue.

After reading that bug I must agree with Jeroen that changing that in this
stage of the release is just not wise. It doesn't really matter when you
became aware of the problem - there's not enough time now to thoroughly
test for any adverse effects of that change, while the gain is relatively
minimal (rather have sarge use more diskspace than delay it yet again
because of new bugs).

This is definately worth looking at - for etch.


Thijs


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

Re: etch release target: SELinux?? (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Joey Hess]

Kevin Mark wrote:
> > Given the fact that the current standard installation installs both gcc, 
> > gdb and other development packages weighting more than that (see #301138, 
> > which nobody wants to fix) 
> Sorry to interupt, just got a stupid idea, if as Javier suggests, there
> are bugs that no one wants to fix, why not try an idea called a 'bounty'

If you'll read the log to #301138, you'll see not much evidence of not
wanting to fix it now, and a lot of evidence of people who want to fix
it, but do not care to make such a large change and destabilise what
sarge installs this close to a release.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: etch release target: SELinux?? (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Kevin Mark]

On Mon, Apr 11, 2005 at 09:46:37PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Mon, Apr 11, 2005 at 11:50:23PM +1000, Russell Coker wrote:
> > 
> > For people who don't use SE Linux the support in those programs will only 
> > take 
> > a few K of disk space and will not give a performance overhead.
> 
> Given the fact that the current standard installation installs both gcc, 
> gdb and other development packages weighting more than that (see #301138, 
> which nobody wants to fix) 
Sorry to interupt, just got a stupid idea, if as Javier suggests, there
are bugs that no one wants to fix, why not try an idea called a 'bounty'
(these have been floating around by 'certain' groups x-) ). The idea is
to either make these: a Debian 'bug' check ala Knuth, actaully dinero, a
mention on a webpage, an invite to a local gathering of the debian tribe
in your area, a gift certificate from ThinkGeek, a beer-of-the-month
club subscription or something to get the cat accross the great tundra.
now back to your regularly schedule programming
Cheers,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
_,   _,  ,'`.
  `$$' `$$' `.  ,'
   $$   $$`'
   $$   $$ _,   _
 ,d$$$g$$  ,d$$$b.  $$,d$$$b.`$$' g$b.`$$,d$$b.
,$P'  `$$ ,$P' `Y$. $$$'  `$$ $$  "'   `$$ $$$' `$$
$$'$$ $$'   `$$ $$'$$ $$  ,g$$ $$'   $$
$$ $$ $$g$$ $$ $$ $$ ,$P"   $$ $$$$
$$,$$ $$.   $$,$P $$ $$'   ,$$ $$$$
`$g. ,$$$ `$$._ _., $$ _,g$P' $$ `$b. ,$$$ $$$$
 `Y$$P'$$. `YP',P"'  ,$$. `Y$$P'$$.$$.  ,$$.


signature.asc
Description: Digital signature

Re: etch release target: SELinux?? (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Javier Fernández-Sanguino Peña]

On Mon, Apr 11, 2005 at 11:50:23PM +1000, Russell Coker wrote:
> 
> For people who don't use SE Linux the support in those programs will only 
> take 
> a few K of disk space and will not give a performance overhead.

Given the fact that the current standard installation installs both gcc, 
gdb and other development packages weighting more than that (see #301138, 
which nobody wants to fix) I don't find that an issue.

Regards

Javier


signature.asc
Description: Digital signature

Re: etch release target: SELinux?? (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Russell Coker]

On Wednesday 16 March 2005 22:14, David Schmitt <[EMAIL PROTECTED]> 
wrote:
> Just that it is not lost: SELinux soft support (patched utilities available
> in main). There seems to be a repository that mostly works (I'm not in the
> loop about currentness though) and it'd is probably an important step
> forward to bringing SELinux more into the mainstream.

The general aim is that libselinux1 will be in base for Etch.  When that 
happens sysvinit, cron, pam, ssh, and every xdm type program can depend on 
libselinux1 and therefore can provide the required SE Linux functionality.

For people who don't use SE Linux the support in those programs will only take 
a few K of disk space and will not give a performance overhead.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

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

[Henrique de Moraes Holschuh]

On Tue, 15 Mar 2005, Sven Luther wrote:
> Since when are you following these issues ? and what experience do you have
> with how debian works ? And did you read Anthony's post on how this worked
> out.

Since 1998 I think, and I experienced first hand how difficult is to get
something through some tick heads while trying to get invoke-rc.d accepted
(I was not even a DD yet at that time, I think).  I have been following a
lot of debian MLs (including private, devel, users and policy) since then.

Long enough to know how these things play out most of the time.

> > Well, if it is done the other way, you get utter lack of respect from
> > maintainers that can't even read the damn thing twice and think about it
> > before firing their guns (and you end up with a flamewar just as well).
> 
> Yep, as for NEW processing, lack of response from ftp-masters, lack of
> response from the centralized buildd admins when porters propose their help,
> or the AMD64 flamewar we had all those month ago, and so on ... It is always
> the same scheme, and then we are accused of being ungratefull bitchers,

Well, I certainly did not say anything about biching or ungrateful.  And I
won't go into the other points since they are not particular to this thread
anyway.  We all know what a LOT of DDs think of the way these things have
been handled so far.

> Yep, but is it a symptom of a profund lack of understanding (or caring), of
> how these things are received by the rest of the DDs, and a dismissal of the

True.  But can you honestly say you expected anything different?  It is damn
good progress that we are having this thread at all (and it will be a damn
really great thing if all the issues raised here are heard and fixed...).  I
hope things keep getting better.

> work they do who is somehow considered as less important, or in the case of
> the minor arches, as maybe troublesome even in light of this report.

The minor arches are NOT a problem.  The current buildd structure is a major
sore point with MANY DDs and we *do* know this is not the fault of the minor
arches themselves OR of most porters.  That will have to change sooner or
later.

> Yep, but that means a bit of humility from their part first, and an
> aknowledgement of their mistake, as well as an explanation on how this came to
> be in correspondence of all the help they rejected from the arch porters part.

I would rather we just fix it.  The egos here are too big for any apologies
from any side to show up, and I'd better get some work done that improve
things rather than wait for Hel to freeze over :-)   As long as the issues
raised with the proposal are addressed, that will be enough IMO.  For now,
anyway.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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 Greenland]

On 21-Mar-05, 14:45 (CST), Adrian Bunk <[EMAIL PROTECTED]> wrote: 
> HP still produces both workstations and servers with PA-RISK processors.
  

Yeah, we had one of those. I'm surprised they're still making them; the
PA-RISC series is lot more reliable...

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

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

[Guido Guenther]

n Wed, Mar 16, 2005 at 10:44:15AM -0500, Kyle McMartin wrote:
> On Wed, Mar 16, 2005 at 03:06:19PM +, Rob Taylor wrote:
> > Yes, that makes total sense. Would there likely be major objections to
> > this?
> >
> 
> Even less (likely zero) testing of packages by the maintainer before they
> upload? This is definitely a serious problem...
The binary deb that comes with the source only ensures that the package
is buildable on at least one arch. So don't allow for source only
uploads, rebuild on the uploaded arch and discard the uploaded binary. 
 -- Guido

> 
> Famous last words...
> "Oh, I'll just make this one change, rebuild source and upload."
> 
> --Kyle 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [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

[Adrian Bunk]

On Tue, Mar 22, 2005 at 03:20:04PM -0800, Steve Langasek wrote:
> On Tue, Mar 22, 2005 at 12:14:17PM +0100, Adrian Bunk wrote:
> > On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote:
> > >...
> > > The top three things I've spent release management time on that I 
> > > shouldn't
> > > have had to are, in no discernable order:
> 
> > > 1) processing new RC bug reports to set sarge/sid tags appropriately, so
> > > that the RC bug list for sarge bears some resemblance to reality
> 
> > > 2) prodding maintainers to get all packages associated with library soname
> > > transitions synchronized so that they can progress into testing together
> > > (seems to require an average of 2-3 iterations, and 3-4 weeks)
> 
> > > 3) chasing down, or just waiting on (which means, taking time to poll the
> > > package's status to find out why a bug tagged 'testing' is still open),
> > > missing builds or fixes for build failures on individual architectures 
> > > that
> > > are blocking RC bugfixes from reaching testing
> 
> > > Taken together, these probably account for more of my release management
> > > time than anything else, including actual work on release-critical bugs.
> > >...
> 
> > Is it correct that none of these three points that account for most of 
> > your release management time would exist in a release process without 
> > testing?
> 
> Misfiled bugs would be a problem in a freeze/unstable configuration, just as
> they are in a testing/unstable configuration.

In a freeze/unstable configuration, this starts after the freeze.
(Or if you keep unstable frozen, even later.)

And during a freeze, I wouldn't expect much activity in unstable, making 
the problem in the freeze/unstable configuration even smaller.

In a testing/unstable configuration, this affects all bugs including 
bugs that were filed many months before the freeze.

> Getting binaries up-to-date across all architectures for RC bugfixes would
> be a problem in a frozen suite, just as it is in testing.

But even if the autobuilders of an architecture have a problem with 
keeping up with unstable, they are much more likely being able to keep 
up with frozen since the amount of changes is much smaller.

And it wasn't a problem if there was no autobuilder for an architecture 
for two weeks during a non-freeze time.

> Library soname transitions would be unlikely to happen in a freeze, but that
> just means any transitions that are in progress at the time all have to be
> dealt with *when* we freeze, even if they aren't necessary transitions.

Transitions in unstable are easy.

The problem is usually only getting a transition into testing.

Assuming a freeze is announced early enough, it shouldn't be a big deal 
ensuring that all transitions are completed before the freeze in a 
freeze/unstable configuration.

> In any case, this overlooks one of the principal advantages of testing,
> which is that it avoids releasing software that's already 1 year out of date
> at the time of release.

This was a goal of testing.

The woody freeze took 7 months.

Depending on how you count, the current freeze of sarge started more 
than one and a half years ago, or it started "only" seven and a half 
months ago - and sarge still isn't released.

As things are today, sarge will release with an X11 being more than two 
years old.

This is the second release with the testing release process, and the 
assumed advantages of testing still aren't visible through shorter 
release cycles.

You yourself signed that statement that the testing release process is 
not capable of a release cycle on the order of 12-18 months with
11 architectures.

And now two thirds of the Debian architectures should be removed from 
Debian releases because you still prefer a release process that has 
twice failed to show that it was superior to the former release process? 

> Steve Langasek

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
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 Tue, Mar 22, 2005 at 12:14:17PM +0100, Adrian Bunk wrote:
> On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote:
> >...
> > The top three things I've spent release management time on that I shouldn't
> > have had to are, in no discernable order:

> > 1) processing new RC bug reports to set sarge/sid tags appropriately, so
> > that the RC bug list for sarge bears some resemblance to reality

> > 2) prodding maintainers to get all packages associated with library soname
> > transitions synchronized so that they can progress into testing together
> > (seems to require an average of 2-3 iterations, and 3-4 weeks)

> > 3) chasing down, or just waiting on (which means, taking time to poll the
> > package's status to find out why a bug tagged 'testing' is still open),
> > missing builds or fixes for build failures on individual architectures that
> > are blocking RC bugfixes from reaching testing

> > Taken together, these probably account for more of my release management
> > time than anything else, including actual work on release-critical bugs.
> >...

> Is it correct that none of these three points that account for most of 
> your release management time would exist in a release process without 
> testing?

Misfiled bugs would be a problem in a freeze/unstable configuration, just as
they are in a testing/unstable configuration.

Getting binaries up-to-date across all architectures for RC bugfixes would
be a problem in a frozen suite, just as it is in testing.

Library soname transitions would be unlikely to happen in a freeze, but that
just means any transitions that are in progress at the time all have to be
dealt with *when* we freeze, even if they aren't necessary transitions.

In any case, this overlooks one of the principal advantages of testing,
which is that it avoids releasing software that's already 1 year out of date
at the time of release.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

[Adrian Bunk]

On Tue, Mar 22, 2005 at 02:55:17PM +, Michael K. Edwards wrote:
> On Tue, 22 Mar 2005 12:14:17 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote:
> > >...
> > > The top three things I've spent release management time on that I 
> > > shouldn't
> > > have had to are, in no discernable order:
> > >
> > > 1) processing new RC bug reports to set sarge/sid tags appropriately, so
> > > that the RC bug list for sarge bears some resemblance to reality
> 
> To the extent that maintainers accept upstream's crack-of-the-day into
> sid, relying on a not-for-sarge mechanism instead of letting the bugs
> pile up upstream, the testing scripts do worsen the traffic late in
> the release cycle.  Beats binge-purge, if you ask me, but YMMV. 
> During a freeze-by-whatever-mechanism, becoming informed about whether
> allowing a given update would improve or worsen the situation takes
> effort; sarge/sid tags are part of that analysis.  I think Steve is
> mostly saying that scrubbing the raw bug report data by disambiguating
> sarge and sid bugs shouldn't be the release manager's job.

Without testing, there was no need for anyone to do such a 
distinguishing before the freeze starts.

And if you'd (in a relesase process without testing) freeze unstable for 
some time after the beginning of the freeze, you could get the point 
when frozen starts diverging from unstable even later.

> > > 2) prodding maintainers to get all packages associated with library soname
> > > transitions synchronized so that they can progress into testing together
> > > (seems to require an average of 2-3 iterations, and 3-4 weeks)
> 
> Yep, this is a lot of work.  The alternatives are unbuildable packages
> (left behind by a transition) or multiple versions of core libraries. 
> The relevant packaging teams are getting the hang of it, though, and
> testing is a good tool for measuring progress towards an engineered
> release.  Again, I think Steve wants this to be more of a
> maintainer/porter responsibility during more of the cycle.

As I've already said in another email:

Transitions of API-compatible libraries are a pain _only_ due to 
testing. In unstable, such a transition can easily be done within a few 
days.


Remember the libtiff transition.
Look at the various libexif transitions.
...

The transition in unstable is trivial (changing the build dependencies 
in the packages).

The complete transition into testing is a pain (in the libtiff case 
Steve cheated by introducing a second libtiff source package but it 
still took some time).

> > > 3) chasing down, or just waiting on (which means, taking time to poll the
> > > package's status to find out why a bug tagged 'testing' is still open),
> > > missing builds or fixes for build failures on individual architectures 
> > > that
> > > are blocking RC bugfixes from reaching testing
> 
> Comments elsewhere; but I certainly don't think this is caused by
> testing.  Don't shoot the messenger.
>...

Steve's talking about bugs already fixed in unstable that might still be 
present in testing.

Why do you think this wasn't caused by testing?

> Cheers,
> - Michael

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
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 Nusinow]

On Mon, Mar 21, 2005 at 07:55:18AM +0100, Sven Luther wrote:



> having a common kernel package will greatly simplify the parts of this process
> which involve the kernel-team, and let you just do the security fix, build and
> upload (either auto-built or hand-built), and then pass the baby to the
> debian-boot people to handle as usual.
> 
> Hope this clarifies things a bit.

Thanks Sven, it certaintly does. It's much appreciated.

 - David Nusinow


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

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

[Michael K. Edwards]

On Tue, 22 Mar 2005 12:14:17 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote:
> >...
> > The top three things I've spent release management time on that I shouldn't
> > have had to are, in no discernable order:
> >
> > 1) processing new RC bug reports to set sarge/sid tags appropriately, so
> > that the RC bug list for sarge bears some resemblance to reality

To the extent that maintainers accept upstream's crack-of-the-day into
sid, relying on a not-for-sarge mechanism instead of letting the bugs
pile up upstream, the testing scripts do worsen the traffic late in
the release cycle.  Beats binge-purge, if you ask me, but YMMV. 
During a freeze-by-whatever-mechanism, becoming informed about whether
allowing a given update would improve or worsen the situation takes
effort; sarge/sid tags are part of that analysis.  I think Steve is
mostly saying that scrubbing the raw bug report data by disambiguating
sarge and sid bugs shouldn't be the release manager's job.

> > 2) prodding maintainers to get all packages associated with library soname
> > transitions synchronized so that they can progress into testing together
> > (seems to require an average of 2-3 iterations, and 3-4 weeks)

Yep, this is a lot of work.  The alternatives are unbuildable packages
(left behind by a transition) or multiple versions of core libraries. 
The relevant packaging teams are getting the hang of it, though, and
testing is a good tool for measuring progress towards an engineered
release.  Again, I think Steve wants this to be more of a
maintainer/porter responsibility during more of the cycle.

> > 3) chasing down, or just waiting on (which means, taking time to poll the
> > package's status to find out why a bug tagged 'testing' is still open),
> > missing builds or fixes for build failures on individual architectures that
> > are blocking RC bugfixes from reaching testing

Comments elsewhere; but I certainly don't think this is caused by
testing.  Don't shoot the messenger.

> > Taken together, these probably account for more of my release management
> > time than anything else, including actual work on release-critical bugs.

Well, if it were efficient for the RM to be doing bug fixes himself,
something would be broken.  :-)

> Is it correct that none of these three points that account for most of
> your release management time would exist in a release process without
> testing?

Doubtless the timing patterns would be different; but if you want
sarge not to suck, it has to follow a meaningful bug metric down to
(near) zero, contain a choreographed release of libraries and desktop
integration, and the polish that comes from fixing bugs all the way
instead of ignoring corner cases.  None of these challenges is unique
to a testing-mediated release process.

Cheers,
- Michael


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

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

[Adrian Bunk]

On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote:
>...
> The top three things I've spent release management time on that I shouldn't
> have had to are, in no discernable order:
> 
> 1) processing new RC bug reports to set sarge/sid tags appropriately, so
> that the RC bug list for sarge bears some resemblance to reality
> 
> 2) prodding maintainers to get all packages associated with library soname
> transitions synchronized so that they can progress into testing together
> (seems to require an average of 2-3 iterations, and 3-4 weeks)
> 
> 3) chasing down, or just waiting on (which means, taking time to poll the
> package's status to find out why a bug tagged 'testing' is still open),
> missing builds or fixes for build failures on individual architectures that
> are blocking RC bugfixes from reaching testing
> 
> Taken together, these probably account for more of my release management
> time than anything else, including actual work on release-critical bugs.
>...

Is it correct that none of these three points that account for most of 
your release management time would exist in a release process without 
testing?

> Steve Langasek

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

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

[Tollef Fog Heen]

* Sven Luther 

| And what is the size of the fan, and how much noise does it generate ? 

My home box is a 92mm which generates < 20dB.  The other one I'm not
sure about, but probably a noisy 60mm (since it's in a server room and
I don't care about noise there).

-- 
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: Bits (Nybbles?) from the Vancouver release team meeting

[Wouter Verhelst]

On Mon, Mar 21, 2005 at 11:23:05PM +0100, Tollef Fog Heen wrote:
> * Wouter Verhelst 
> | Because it's cool. In both senses of the word (have you ever had to
> | measure the temperature of an i386 box?)
> 
> (amd64, but I guess the point still applies):

Not exactly, as I assume the amd64 designers took more care about heat
and cooling than the (original) i386 designers did. But yeah, I didn't
expect this.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
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 Mon, Mar 21, 2005 at 11:23:05PM +0100, Tollef Fog Heen wrote:
> * Wouter Verhelst 
> 
> | On Sun, Mar 20, 2005 at 12:00:23PM +1000, Anthony Towns wrote:
> | > Darren Salt wrote:
> | > >I demand that Anthony Towns may or may not have written...
> | > >>Put them behind a firewall on a trusted LAN, use them to develop 
> software
> | > >>for arm chips, and then just follow unstable or run 
> non-security-supported
> | > >>snapshots. Apart from writing software for embedded arm things, I can't 
> | > >>see
> | > >>the value
> | > >"Linux desktop box" comes to mind...
> | > 
> | > But why would you spend over 1000 pounds on an arm Linux desktop box 
> | > instead of a few hundred pounds on a random i386 desktop box?
> | 
> | Because it's cool. In both senses of the word (have you ever had to
> | measure the temperature of an i386 box?)
> 
> (amd64, but I guess the point still applies):
> 
> : [EMAIL PROTECTED] ~ > acpi -V
>  Thermal 1: ok, 26.0 degrees C
> 
> I think the room temperature is 19°C.
> 
> : [EMAIL PROTECTED] ~ > acpi -V
>  Thermal 1: ok, 34.0 degrees C
> 
> (This is my home box, so a little less air circulation there.)
> 
> Not exactly hot, are they?

And what is the size of the fan, and how much noise does it generate ? 

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]

Hi Bill,

On Fri, Mar 18, 2005 at 06:50:05AM -0600, Bill Allombert wrote:
> On Thu, Mar 17, 2005 at 09:47:42PM -0800, Steve Langasek wrote:
> > Well, the release team are not the only Debian developers with credibility,
> > surely?  Not everything needs to go through us; if the project has the will
> > to do stable releases of these architectures, in spite of the release team
> > being unwilling to delay other architectures while waiting for them, then
> > it should be very possible to provide full stable releases for these
> > architectures.  

> And still Steve and Colin, I think that you have made a wonderful job so
> far.  The Vancouver plan looks like you feel yourself a failure because
> your initial sarge release plan was stretched unreasonnably, but it is
> completly unwarranted, and you have shown us all how to handle testing
> transition in a faster and more controled way several[1] times already,
> and I am sure we will benefit from this experience in the future.  But
> don't despair! Etch will start on a much more solid ground than Sarge.
> It is much too soon to give up, Debian has enormous resource that has
> yet to come into play.

On the contrary, I don't feel myself a failure at all; I think there have
been some unforeseen problems during the release that I wish we had been
aware of sooner so that they could be planned for or dealt with earlier, but
I think that sarge is going to be a solid release in good Debian tradition,
and I don't think we have very far left to go.

However, this has come with a high personal cost for me.  The amount of
effort I've been putting into the sarge release is not something that I am
able to sustain for etch, and so much of it is spent on things that should
*not* be the release team's direct responsibility, that I don't think we
should be asking anyone else to put in this kind of effort as RM either.
You pointed out in another mail that it's been asserted previously that
buildd outages haven't impacted the release schedule; while that's generally
true, they *have* impacted the workload of the release team, and this is
what needs to change.

The top three things I've spent release management time on that I shouldn't
have had to are, in no discernable order:

1) processing new RC bug reports to set sarge/sid tags appropriately, so
that the RC bug list for sarge bears some resemblance to reality

2) prodding maintainers to get all packages associated with library soname
transitions synchronized so that they can progress into testing together
(seems to require an average of 2-3 iterations, and 3-4 weeks)

3) chasing down, or just waiting on (which means, taking time to poll the
package's status to find out why a bug tagged 'testing' is still open),
missing builds or fixes for build failures on individual architectures that
are blocking RC bugfixes from reaching testing

Taken together, these probably account for more of my release management
time than anything else, including actual work on release-critical bugs.

The first of these issues will, I fervently hope, be addressed after sarge's
release when the BTS gains support for version tracking; the code has
existed for some time now and has been running elsewhere, AIUI, but hasn't
been deployed to avoid delaying the sarge release.

The second of these was discussed at Vancouver, but no mention was made of
it in the report because there's no code to show for it; with AJ's will and
enough red wine, though, we should have something else to talk about here
soon.

The third item is the one currently under (heated) discussion.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Mon, Mar 21, 2005 at 08:38:11AM -0800, Thomas Bushnell BSG wrote:
> > Matthias Urlichs <[EMAIL PROTECTED]> writes:
> 
> > > The choice is to either restrict the required client-side fanciness to
> > > what most of our mirrors are willing to accept, or go without mirrors 
> > > (OK, OK ... fewer mirrors anyway), which is something I don't think we'd
> > > want.
> 
> > The whole point of SCC was to go without mirrors.
> 
> *No*, the point is to not require all mirrors to carry all ports.

I'm sorry, I was over-brief.  My understanding is the same as what you
report here.  What I'm saying is that a complaint that SCC is too
heavy to carry should be met with "so don't carry it".  We can't solve
every problem.  I think separating the ports to a different server
allows mirrors one easy solution.  If they want other solutions
(because, say, they want to "carry everything" and then complain that
"everything" is too heavy) then they will need to implement them
themselves.  


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

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

[Hamish Moffatt]

On Sun, Mar 20, 2005 at 04:39:21PM +0100, Thiemo Seufer wrote:
> Hamish Moffatt wrote:
> > Most work for embedded systems would be cross-compiled from faster
> > systems anyway.
> 
> The price for that is a serious lack of testing. Debian stable provides
> known good binaries.

I didn't mean that we should cross-compile Debian packages for arm, only
that embedded systems development hosting is not a compelling reason to
produce releases for that platform.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[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

[Hamish Moffatt]

On Sun, Mar 20, 2005 at 03:45:00PM +0100, Sven Luther wrote:
> On Sun, Mar 20, 2005 at 10:53:57PM +1100, Hamish Moffatt wrote:
> > On Sun, Mar 20, 2005 at 09:56:05AM +0100, Sven Luther wrote:
> > > On Sun, Mar 20, 2005 at 12:00:23PM +1000, Anthony Towns wrote:
> > > > But why would you spend over 1000 pounds on an arm Linux desktop box 
> > > > instead of a few hundred pounds on a random i386 desktop box?
> > > Because you don't want a 100+W dissipating screaming monster on your desk 
> > > ?
> > 
> > You can get low power x86 systems that have much better performance (> 1
> > GHz).
> 
> They would be too slow for autobuilder work though.

No more so than the 600 MHz ARM in the Iyonix desktop.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[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

[Tollef Fog Heen]

* Wouter Verhelst 

| On Sun, Mar 20, 2005 at 12:00:23PM +1000, Anthony Towns wrote:
| > Darren Salt wrote:
| > >I demand that Anthony Towns may or may not have written...
| > >>Put them behind a firewall on a trusted LAN, use them to develop software
| > >>for arm chips, and then just follow unstable or run non-security-supported
| > >>snapshots. Apart from writing software for embedded arm things, I can't 
| > >>see
| > >>the value
| > >"Linux desktop box" comes to mind...
| > 
| > But why would you spend over 1000 pounds on an arm Linux desktop box 
| > instead of a few hundred pounds on a random i386 desktop box?
| 
| Because it's cool. In both senses of the word (have you ever had to
| measure the temperature of an i386 box?)

(amd64, but I guess the point still applies):

: [EMAIL PROTECTED] ~ > acpi -V
 Thermal 1: ok, 26.0 degrees C

I think the room temperature is 19°C.

: [EMAIL PROTECTED] ~ > acpi -V
 Thermal 1: ok, 34.0 degrees C

(This is my home box, so a little less air circulation there.)

Not exactly hot, are they?

-- 
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: Bits (Nybbles?) from the Vancouver release team meeting

[Steve Langasek]

On Mon, Mar 21, 2005 at 08:38:11AM -0800, Thomas Bushnell BSG wrote:
> Matthias Urlichs <[EMAIL PROTECTED]> writes:

> > The choice is to either restrict the required client-side fanciness to
> > what most of our mirrors are willing to accept, or go without mirrors 
> > (OK, OK ... fewer mirrors anyway), which is something I don't think we'd
> > want.

> The whole point of SCC was to go without mirrors.

*No*, the point is to not require all mirrors to carry all ports.

-- 
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)

[Ola Lundqvist]

On Sat, Mar 19, 2005 at 09:36:38AM -0600, Gunnar Wolf wrote:
> Ola Lundqvist dijo [Tue, Mar 15, 2005 at 09:19:45PM +0100]:
> > > And would a larger discussion at debconf'05 not have been more appropriate
> > > than handing done a couple of taken decision disguised as proposal ? 
> > > 
> > > It is not too late for this yet, but there needs to be a real discussion 
> > > with
> > > real facts, and not just a list of resolution letting 8/11th of the 
> > > project in
> > > the cold.
> > 
> > Please take this kind of discussions on debian-devel as it is possible
> > for people not attending on debconf be a part of the discussion.
> 
> I do believe that Debconf is an ideal place for this - Having 150 of
> us together might mean having 40 of us interested in joining this
> discussion, brainstorming (and shouting at each other) for ~2hr
> instead of over 600 messages, and coming up with something similar to
> the Vancouver stuff - a summary of the points reached, not a firm
> decision... But a summary with more adherents. And more people
> convinced by the release and ftp teams on what and why (or people in
> those teams convinced back, or... whatever :) )
> 
> Of course, if you cannot make it to Debconf, you will know about the
> discussion results. In fact, Debconf plans to capture audio/video of
> the sessions at the auditoriums, so you might even participate via
> IRC. 

That would be good. I'm probably interested in that.

> I intended to propose this topic for a round table, but was asked to
> wait on this by one of the release members, as they were close to
> announcing the Vancouver stuff... Anyway, I am not formally proposing
> it, but I do expect it to happen - After all, we will be in HEL ;-)

:)

Regards,

// Ola

> Greetings,
> 
> -- 
> Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
> PGP key 1024D/8BB527AF 2001-10-23
> Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Annebergsslingan 37  \
|  [EMAIL PROTECTED] 654 65 KARLSTAD  |
|  +46 (0)54-10 14 30  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---


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

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

[Adrian Bunk]

On Mon, Mar 21, 2005 at 12:50:03PM +0100, Wouter Verhelst wrote:
> On Fri, Mar 18, 2005 at 12:06:08PM +1000, Anthony Towns wrote:
> > So, I'd just like to re-emphasise this, because I still haven't seen 
> > anything that counts as useful. I'm thinking something like "We use s390 
> > to host 6231 scientific users on Debian in a manner compatible to the 
> > workstations they use; the software we use is ; we rely on having 
> > security support from Debian because we need to be on the interweb 2; 
> > ...". At the moment, the only use cases I'm confident exist are:
> > 
> > m68k, mips, mipsel, hppa: I've got one in the basement, and I like 
> > to brag that I run Debian on it; also I occassionally get some work out 
> > of 
> > it, but it'd be trivial to replace with i386.
> 
> Aren't the first three of these also actively being used in embedded
> applications? (not sure about that one; I'm not /that/ much involved
> with embedded stuff)
> 
> I can also imagine some hppa boxes being used as test or development
> platform in the enterprise. Note that they were still being sold as new
> only a few years ago.
>...

HP still produces both workstations and servers with PA-RISK processors.

Note that 50 out of the 500 fastest computers in the world [1] are 
computers with PA-RISK processors manufactured by HP in 2004.

cu
Adrian

[1] http://www.top500.org/

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

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

[Wouter Verhelst]

On Tue, Mar 22, 2005 at 02:04:35AM +1000, Anthony Towns wrote:
> Wouter Verhelst wrote:
> >Joey Schulze has already said that doing security support for two
> >architectures is exactly as hard as doing security support for twenty
> >architectures, so the point about supporting stable is kindof moot. The
> >same isn't true for testing, obviously.
> 
> Joey gets to say this because others have done all the work to handle 
> that support for him and the security team.

Yes, which is why I said "kindof" and "the same isn't true for testing".

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

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

[Wouter Verhelst]

On Wed, Mar 16, 2005 at 04:49:48PM +0100, Bastian Blank wrote:
> On Wed, Mar 16, 2005 at 04:11:21PM +0100, Wouter Verhelst wrote:
> > > How many *.debian.org machines are actually *owned* by the project or DDs?
> > All of them. Otherwise they wouldn't be *.debian.org.
> 
> Please define "owned".

Okay, I see where you're coming from. That wouldn't work; forget what I
said.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

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

[Wouter Verhelst]

On Thu, Mar 17, 2005 at 07:22:37PM -0800, Steve Langasek wrote:
> There would definitely be duplication of arch:all between ftp.debian.org
> and ports.debian.org (let's call it ports), as well as duplication of the
> source.

I don't think this is a good idea. I'm thinking something like this
could work:

deb http://$MIRROR/debian stable main
deb-src http://$MIRROR/debian-source stable main

or (if you're on a minority architecture)

deb http://$MIRROR/debian-nybbles stable main
deb-src http://$MIRROR/debian-source stable main

with a requirement for mirror operators to always have debian-source if
they want to have either of debian-nybbles or plain 'debian'.

This doesn't address _all yet; but I guess it could be done in the same
way.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

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

[Wouter Verhelst]

On Wed, Mar 16, 2005 at 08:14:59PM -0800, Steve Langasek wrote:
> This proposal is, first and foremost, about setting concrete criteria that
> we can hold the ports to for etch, to get away from wishy-washy, "one more
> week for kernel updates on $arch", "$arch2 isn't doing so well, maybe we
> should drop it from testing" problems that the release team is currently
> suffering from.  The idea of setting criteria should not be controversial,
> though I can understand that specific criteria we've suggested may be.

True. The specific criteria as have been suggested are most certainly
controversial; but setting criteria for ports to keep up with should not
necessarily be.

It may be a bad idea to suddenly set a whole bunch of criteria at once;
big and controversial changes are not how Free Software in the 'bazaar'
model generally works.

For that reason, why not reduce the whole proposal to...

* The separate mirror stuff is implemented (I don't think anyone has any
  problems with that, except for its name which should be 'nybbles'
  IMO)
* All ports need to
  * build packages within (to be defined) days, on average, of them
getting in the 'Needs-Build' state (this may require applying the
patch by Matthias Ulrichs to wanna-build)
  * have some basic UNIX functionality, such as resolving DNS names,
firewall capacity, and some (to be defined) subset of POSIX.

...and address any problems after that as they come up?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

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

[Thomas Bushnell BSG]

Matthias Urlichs <[EMAIL PROTECTED]> writes:

> The choice is to either restrict the required client-side fanciness to
> what most of our mirrors are willing to accept, or go without mirrors 
> (OK, OK ... fewer mirrors anyway), which is something I don't think we'd
> want.

The whole point of SCC was to go without mirrors.


-- 
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 Mon, Mar 21, 2005 at 12:17:45PM +0100, Thiemo Seufer wrote:
> Sven Luther wrote:
> [snip]
> > > For sarge, kernels are built in a two-stage process. First is to create
> > > a dsfg-free .deb from the upstream source which contains a source
> > > tarball, second is to build kernel images from another (arch-specific)
> > > .deb which build-depends on the source .deb. In the second stage,
> > > arch-specific patches can be added.
> > 
> > You forgot the third stage of the .udebs built.
> 
> They can be "built" immediately after the kernel images were accepted,
> there's little potential for a delay.

Only if they get forgotten to build, which happens from time to time.

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

[Anthony Towns]

Wouter Verhelst wrote:
Joey Schulze has already said that doing security support for two
architectures is exactly as hard as doing security support for twenty
architectures, so the point about supporting stable is kindof moot. The
same isn't true for testing, obviously.
Joey gets to say this because others have done all the work to handle 
that support for him and the security team.

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

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

[Thiemo Seufer]

Wouter Verhelst wrote:
[snip]
> > m68k, mips, mipsel, hppa: I've got one in the basement, and I like 
> > to brag that I run Debian on it; also I occassionally get some work out 
> > of 
> > it, but it'd be trivial to replace with i386.
> 
> Aren't the first three of these also actively being used in embedded
> applications? (not sure about that one; I'm not /that/ much involved
> with embedded stuff)

Just to throw another URL in, http://www.linuxdevices.com/ is a good
starting point to find out what's currently used with embedded linux.


Thiemo


signature.asc
Description: Digital signature

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

[Wouter Verhelst]

On Sat, Mar 19, 2005 at 04:19:03AM -0800, Steve Langasek wrote:
> On Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote:
> > I do still doubt that testing actually is an improvement compared to the 
> > former method of freezing unstable, and even more do I doubt it's worth 
> > sacrificing 8 architectures.
> 
> If the proposal already gives porters the option to freeze ("snapshot")
> unstable to do their own releases, in what sense is this "sacrificing"
> architectures?

Have you seen one porter who believes that taking an unstable snapshot
and make a release off of that will actually be enough? Those porters
that I've seen participating in this thread actually said it would be
entirely useless. Even more so, Joey Schulze told us that this idea
would not work in terms of supporting it from his part, so it's a
bad idea in general.

Obviously the porters could all do their own releases, but then you're
duplicating work that does not need duplication in a single project; you
could just as well ask us to go to sourceforge.net and release there,
because the net effect would be the same.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

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

[Wouter Verhelst]

On Sat, Mar 19, 2005 at 01:48:42AM -0800, Steve Langasek wrote:
> On Tue, Mar 15, 2005 at 02:10:47PM -0500, Greg Folkert wrote:
> > I am currently in the process of acquiring rotated out of production
> > machines for 3 of the 5 architectures I support. I make a run to the
> > right-coast of the US once every 2 months and pickup sometimes 10 - 4-16
> > processor machines with disk and typically a dozen of GB of memory and
> > gaggles of disk. I rebuild/recondition most of these machines and
> > distribute them to NPOs that need this kind of horsepower but can't
> > afford current stuff or even used stuff from those same suppliers. I put
> > Debian on them and this makes a huge investment in the long term health
> > of these Orgs.
> 
> > If these machines are no longer fully supported by Debian... how can I
> > continue to do this.

Of course I can't speak for Greg, but let me answer these questions how I
think they will have to be answered for most m68k users:

> What does "fully supported" mean to you?

'there is a stable with security updates for the architecture, that is
in sync with the rest of Debian'

> What are the use cases for these machines?

Hobbyists playing with old hardware; people running home servers on
them; people running firewalls on them; possibly also embedded
development.

> Which aspects of stable are required by these users?

The low amount of updates that are produced by an average daily 'apt-get
update; apt-get upgrade'. The fact that you can test and develop your
scripts on your more modern hardware before installing them on the old
machines, without having to modify them to run on the different versions
of the software available for the old hardware.

> > How much is the difference between Debian running on "Humidifier in the
> > Basement" reputation, and a "We release more often than Ubuntu"
> > reputation?
> 
> > But, serious, how much do you think Debian will be hurt with:
> 
> > Compare these:
> > 1. Debian the "Universal OS"
> > 2. Debian the "Almost-Sorta-Kinda-used-to-be Universal OS"
> 
> > 3. "Old as fossilized dinosaur poo, and as stable, but runs on
> > everything including the humidifier in the basement"
> > 4. "Very recent, since it doesn't really support NON-big 4
> > processors anyway, so why not run Fedora Core"
> 
> > Personally, I like 1 and 3. They are the 2nd and 3rd most important
> > technical reasons I chose Debian. 1st technical reason is the Debian's
> > maintainability. Please oh please let us not change my mind for me.
> 
> I'm assuming your humidifier isn't connected to the public Internet, and
> doesn't need ongoing security support...?

'domotics system'. Some of those /are/ connected to the Internet (but
then again, usually you have a firewall in between).

> We're also constantly hearing from users who are using Debian in settings
> where they *would* benefit from security support, but are running testing
> or unstable because woody's fossilization factor is too high for them.  How
> would you suggest that we balance these users' needs for a more frequent
> stable release, against the needs of users like yourself who need broader
> arch coverage?

I'm not yet convinced that the only way to reach a higher release
frequency is to drop support for 80% of our architectures...

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

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

[Wouter Verhelst]

On Sun, Mar 20, 2005 at 12:00:23PM +1000, Anthony Towns wrote:
> Darren Salt wrote:
> >I demand that Anthony Towns may or may not have written...
> >>Put them behind a firewall on a trusted LAN, use them to develop software
> >>for arm chips, and then just follow unstable or run non-security-supported
> >>snapshots. Apart from writing software for embedded arm things, I can't 
> >>see
> >>the value
> >"Linux desktop box" comes to mind...
> 
> But why would you spend over 1000 pounds on an arm Linux desktop box 
> instead of a few hundred pounds on a random i386 desktop box?

Because it's cool. In both senses of the word (have you ever had to
measure the temperature of an i386 box?)

My current laptop is not a powerpc-based one because it's cheap as
compared to equally fast i386-based hardware...

> A reasonable answer is because you're developing for arm's for embedded 
> applications; but if so, what's the big deal with using unstable or 
> snapshots, and running your public servers on other boxes?

Because you want to focus on fixing bugs in /your/ software rather than
in the toolchain that breaks it in different ways with every upgrade?

> >>-- and if an arch is just going to be used for development, does it really
> >>need all the support we give stable in order to make it useful for servers
> >>and such?
> >Probably not, but ISTM that you'll first have to ascertain that it *is* 
> >only
> >being used for development before you can say that that support definitely
> >isn't needed.
> 
> Uh, you've got that round the wrong way: you don't do something because 
> you can't say support definitely isn't needed, you do something because 
> you *can* say support definitely *is* needed.

Joey Schulze has already said that doing security support for two
architectures is exactly as hard as doing security support for twenty
architectures, so the point about supporting stable is kindof moot. The
same isn't true for testing, obviously.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

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

[Wouter Verhelst]

On Fri, Mar 18, 2005 at 12:06:08PM +1000, Anthony Towns wrote:
> So, I'd just like to re-emphasise this, because I still haven't seen 
> anything that counts as useful. I'm thinking something like "We use s390 
> to host 6231 scientific users on Debian in a manner compatible to the 
> workstations they use; the software we use is ; we rely on having 
> security support from Debian because we need to be on the interweb 2; 
> ...". At the moment, the only use cases I'm confident exist are:
> 
>   m68k, mips, mipsel, hppa: I've got one in the basement, and I like 
>   to brag that I run Debian on it; also I occassionally get some work out 
> of 
> it, but it'd be trivial to replace with i386.

Aren't the first three of these also actively being used in embedded
applications? (not sure about that one; I'm not /that/ much involved
with embedded stuff)

I can also imagine some hppa boxes being used as test or development
platform in the enterprise. Note that they were still being sold as new
only a few years ago.

>   sparc, alpha: We've bought some of these a while ago, they're useful 
> running Debian, we'd really rather not have to stress with switching to 
> i386, but whatever.
> 
>   arm: We're developing some embedded boxes, that won't run Debian 
> proper, but it's really convenient to have Debian there to bootstrap 
> them trivially.

Also note that having a supported port to a processor which is mainly
being used in embedded situations is useful even to people who don't
necessarily use Debian themselves, in that it ensures a level of quality
in the kernel, the toolchain, and Free Software running on that
platform.

This is what I would call 'indirect use': people not directly using
Debian, but still benefitting from Debian's efforts on supporting that
architecture. Dropping such architectures would likely result in
GNU/Linux losing popularity in the embedded area -- one of the areas
where GNU/Linux has a great momentum currently.

>   s390: Hey, it's got spare cycles, why not?

I honestly think it's more than that. s390 systems are way too expensive
for the average hobbyist; only large corporations can afford its price
and power consumption. I would be genuinely surprised if there weren't
one of those enterprises running their website off a Debian VM running
apache, or so.

> None of those are enough to justify effort maintaining a separate 
> testing-esque suite for them; but surely someone has some better 
> examples they can post...

Testing is never interesting for people in many of the above scenarios,
but that doesn't mean we have to drop it.

Debian stable usually /is/ interesting for people in the above
scenarios; but the only way Debian stable can currently reach the
quality it is known for, is by using testing.

Unless you have a different view. And no, unstable snapshots isn't a
workable alternative, IMO.

> The questions that need to be answered by the use case are "what useful 
> things are being done with the arch" and "why not just replace this with 
> i386/amd64 hardware when support for sarge is dropped, which won't be 
> for at least 12-18 months (minimum planned etch release cycle) plus 12 
> months (expected support for sarge as oldstable)". Knowing why you're 
> using Debian and not another distribution or OS would be interesting too.

 lists many of them.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

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

[Matthias Urlichs]

Hi, Thomas Bushnell BSG wrote:

> Matthias Urlichs <[EMAIL PROTECTED]> writes:
> 
>> We can't. AFAIK: One or two rsync commands, and *that's*it*.
>> 
>> Any required fanciness need to be done on the master server.
> 
> But that's your choice.
> [ Rather silly dialogue deleted ]

The choice is to either restrict the required client-side fanciness to
what most of our mirrors are willing to accept, or go without mirrors 
(OK, OK ... fewer mirrors anyway), which is something I don't think we'd
want.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [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

[Thiemo Seufer]

Sven Luther wrote:
[snip]
> > For sarge, kernels are built in a two-stage process. First is to create
> > a dsfg-free .deb from the upstream source which contains a source
> > tarball, second is to build kernel images from another (arch-specific)
> > .deb which build-depends on the source .deb. In the second stage,
> > arch-specific patches can be added.
> 
> You forgot the third stage of the .udebs built.

They can be "built" immediately after the kernel images were accepted,
there's little potential for a delay.


Thiemo


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

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

[Anthony Towns]

Steve Langasek wrote:
One _might_ consider to have ports.d.o with the full package pool,
whereas ftp.d.o only consists the most wanted architectures. As a mirror
operator, you can than choose to either just have the most wanted
architectures, all or both.
Why not go the full way? What I've outlined in [1] is too obvious to
never have been thought before, but what is the reason not to do it
that way?
I have no idea one way or another; neither Andi nor I are involved in the
mirror implementation details.
There's no particular reason not to do it that way; and indeed it might 
well end up being done that way. Or it might end up being done a 
slightly different way again. I don't think any of those details are 
crucial or complicated enough to need to be nutted out months in advance.

Cheers,
aj
--
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 Mon, Mar 21, 2005 at 04:31:57AM +0100, Thiemo Seufer wrote:
> David Nusinow wrote:
> [snip]
> > > > If you have a single source package for 12 different architectures
> > > > that's great, because when you have a security fix you can take
> > > > care of that more easily. That's awesome.
> > > 
> > > We have that already.
> > 
> > Great to hear. Then what is this new plan that the kernel team
> > has? I'm definitely confused.
> 
> For sarge, kernels are built in a two-stage process. First is to create
> a dsfg-free .deb from the upstream source which contains a source
> tarball, second is to build kernel images from another (arch-specific)
> .deb which build-depends on the source .deb. In the second stage,
> arch-specific patches can be added.

You forgot the third stage of the .udebs built.

> Post-sarge, it will be a one-stage process, which builds all kernel
> images from a single package.
> 
> > > > But then you'll be trading off for the same problems that every
> > > > single other packge faces: namely that if a kernel on a single arch
> > > > has an RC bug then it affects the kernels on every arch. This strikes
> > > > me as being very problematic, and the only way I see around it is
> > > > to downgrade actual RC bugs, which isn't really a solution at all.
> > > 
> > > Most kernel security bugs hit either generic code, or all architectures
> > > equally.
> > 
> > Yeah, but I'm talking about non-security RC bugs. From what
> > little Sven has described I feel like the new kernel plan will
> > make it so these platform-specific bugs are problematic for all
> > architectures. Does the new integration from upstream take care
> > of this and if not, how does the kernel team plan to deal with
> > this issue?
> 
> Those bugs are felt to be seldom enough, especially for already
> released kernels. For active development, there's a constant stream
> of fixes anyway, platform-specific things won't make much difference.

And a kernel-team with people from each architecture will make resolving of
them easier than a single maintainer in his corner who may or may not have the
knowledge for this actual fix, and may or not have time/whatever to fix it.

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 Sun, Mar 20, 2005 at 12:13:13PM -0500, David Nusinow wrote:
> On Sun, Mar 20, 2005 at 10:05:15AM +0100, Sven Luther wrote:
> > On Fri, Mar 18, 2005 at 12:06:15PM -0500, David Nusinow wrote:
> > > On Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote:
> > > > [1] The installer might be a point, but since all sarge architectures
> > > > will have a working installer and I hope there's not another
> > > > installer rewrite planned for etch this shouldn't be a big issue.
> > > 
> > > This is still an issue. Joey Hess's mails have indicated very clearly 
> > > that it's
> > > difficult to get an installer release out even when all arches are already
> > > supported.
> > 
> > This is a non-issue. The main problem was the kernel situation, which will 
> > be
> > streamlined for etch into a single package, and maybe build issues, which
> > could be solved by a separate build queue or priority for d-i issues.
> 
> You know, you keep saying this and I have a really hard time
> believing it, although I don't follow the kernel list so please
> enlighten me if I'm wrong. 

Ok.

> If you have a single source package for 12 different architectures
> that's great, because when you have a security fix you can take
> care of that more easily. That's awesome.

Indeed. And better yet, you build the .udebs from the same package, so you
don't need to build the kernel and then build the .udebs.

> But then you'll be trading off for the same problems that every
> single other packge faces: namely that if a kernel on a single arch
> has an RC bug then it affects the kernels on every arch. This strikes
> me as being very problematic, and the only way I see around it is
> to downgrade actual RC bugs, which isn't really a solution at all.

Then we rebuild. This has some implications for slower arches, and this is
post-sarge issue anyway, so there is time for it, but the only solution for
this is to do partial rebuilds, and have a testing override for kernels on
slower arches.

Still, my claim is that delays like the ones joeyh complained about would
mostly dissapear. A bit of context about them :

  1) a security fix causes an abi change.

  2) a new kernel-source gets uploaded.

  3) all arches need to individually upload kernel-images.

  4) since there was an abi change, the package name gets modified, and thus 
 has to wait in NEW for NEW processing.

  5) .udeb packages have to be built (usually by the debian-boot team), and
 uploaded. (don't know if this implicates a second NEW processing).

  6) the .udebs and .debs have to move into testing simultaneously to avoid
 GPL violation, and general messy dependency and rebuild issues.

  7) the debian-installer daily images need to be built out of SVN using the
 above .udebs and tested.

  8) the debian-installer package is upgraded in sarge, and uploaded.

  9) each individual autobuilders need to process this package, which may or
 may not be fast dependending on the actual auto-builder situation.

Doing this for all arches, with unsynchronized (and maybe off for a couple of
days) per-arch kernel/debian-boot maintainer causes no end of trouble,
especially with the additional delay the NEW processing imposes, is what
causes upto two month upgrade times which joeyh speaks about.

having a common kernel package will greatly simplify the parts of this process
which involve the kernel-team, and let you just do the security fix, build and
upload (either auto-built or hand-built), and then pass the baby to the
debian-boot people to handle as usual.

Hope this clarifies things a bit.


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

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

[Thiemo Seufer]

David Nusinow wrote:
[snip]
> > > If you have a single source package for 12 different architectures
> > > that's great, because when you have a security fix you can take
> > > care of that more easily. That's awesome.
> > 
> > We have that already.
> 
> Great to hear. Then what is this new plan that the kernel team
> has? I'm definitely confused.

For sarge, kernels are built in a two-stage process. First is to create
a dsfg-free .deb from the upstream source which contains a source
tarball, second is to build kernel images from another (arch-specific)
.deb which build-depends on the source .deb. In the second stage,
arch-specific patches can be added.

Post-sarge, it will be a one-stage process, which builds all kernel
images from a single package.

> > > But then you'll be trading off for the same problems that every
> > > single other packge faces: namely that if a kernel on a single arch
> > > has an RC bug then it affects the kernels on every arch. This strikes
> > > me as being very problematic, and the only way I see around it is
> > > to downgrade actual RC bugs, which isn't really a solution at all.
> > 
> > Most kernel security bugs hit either generic code, or all architectures
> > equally.
> 
> Yeah, but I'm talking about non-security RC bugs. From what
> little Sven has described I feel like the new kernel plan will
> make it so these platform-specific bugs are problematic for all
> architectures. Does the new integration from upstream take care
> of this and if not, how does the kernel team plan to deal with
> this issue?

Those bugs are felt to be seldom enough, especially for already
released kernels. For active development, there's a constant stream
of fixes anyway, platform-specific things won't make much difference.


Thiemo


-- 
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 Sun, Mar 20, 2005 at 06:06:56PM +0100, Andreas Metzler wrote:
> On 2005-03-15 Steve Langasek <[EMAIL PROTECTED]> wrote:
> > On Mon, Mar 14, 2005 at 10:56:51AM +0100, Aurélien Jarno wrote:
> [...]
> > > - 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.

> Hello,
> In that case you probably should *enforce* that you have got both >2
> local admins and >2 buildd admins for each arch.

> Afair there have been significant delays due to (overworked, ill,
> etc.) buildd admins in the past and if you are starting to enforce
> reliable buildds not going all the way seems to be strange.

Requiring two local admins for all buildds is going to greatly limit our
pool of potential buildd sponsors.  Requiring N+1 buildd capacity is a much
more efficient and effective way of ensuring reliability.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

[Steve Langasek]

On Sun, Mar 20, 2005 at 05:46:44PM +0100, Thiemo Seufer wrote:
> Andreas Barth wrote:
> > * Marco d'Itri ([EMAIL PROTECTED]) [050319 03:50]:
> > > On Mar 18, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > 
> > > > There would definitely be duplication of arch:all between ftp.debian.org
> > > > and ports.debian.org (let's call it ports), as well as duplication of 
> > > > the
> > > > source.
> > 
> > > As a mirror operator, I think that this sucks. Badly.
> > 
> > One _might_ consider to have ports.d.o with the full package pool,
> > whereas ftp.d.o only consists the most wanted architectures. As a mirror
> > operator, you can than choose to either just have the most wanted
> > architectures, all or both.

> Why not go the full way? What I've outlined in [1] is too obvious to
> never have been thought before, but what is the reason not to do it
> that way?

I have no idea one way or another; neither Andi nor I are involved in the
mirror implementation details.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

[David Nusinow]

On Sun, Mar 20, 2005 at 09:06:23PM +0100, Thiemo Seufer wrote:
> David Nusinow wrote:
> > You know, you keep saying this and I have a really hard time
> > believing it, although I don't follow the kernel list so please
> > enlighten me if I'm wrong. 
> 
> The plan is to profit from better upstream architecture integration
> since 2.6 and build all kernel images from a single package. Sven, btw,
> is a member of the kernel team.

Yes, I know Sven is a member of the kernel team which is why I'm
more than happy to give him, and everyone else on it the benefit
of the doubt.

> > If you have a single source package for 12 different architectures
> > that's great, because when you have a security fix you can take
> > care of that more easily. That's awesome.
> 
> We have that already.

Great to hear. Then what is this new plan that the kernel team
has? I'm definitely confused.

> > But then you'll be trading off for the same problems that every
> > single other packge faces: namely that if a kernel on a single arch
> > has an RC bug then it affects the kernels on every arch. This strikes
> > me as being very problematic, and the only way I see around it is
> > to downgrade actual RC bugs, which isn't really a solution at all.
> 
> Most kernel security bugs hit either generic code, or all architectures
> equally.

Yeah, but I'm talking about non-security RC bugs. From what
little Sven has described I feel like the new kernel plan will
make it so these platform-specific bugs are problematic for all
architectures. Does the new integration from upstream take care
of this and if not, how does the kernel team plan to deal with
this issue?

 - David Nusinow


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

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

[Darren Salt]

I demand that Bill Gatliff may or may not have written...

> Not my preference to jump in the middle of something, but...

It's not my preference to be Cc'd, particularly when I'd set the
Mail-Followup-To header accordingly... :-\

[snip]
-- 
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| Debian, | Northumberland | s zap,tartarus,org
| RISC OS | Toon Army  | @
|   You too can roll your own kernel...

Is it a game of chance? Not the way I play 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

[Thomas Bushnell BSG]

Matthias Urlichs <[EMAIL PROTECTED]> writes:

> We can't. AFAIK: One or two rsync commands, and *that's*it*.
> 
> Any required fanciness need to be done on the master server.

But that's your choice.  

--I want to do this thing which you tell me not to do, and it hurts
  when I do it.

--So stop doing it.

--But I decided I want to do it.

--Then why are you complaining?

--Because it hurts when I do it.


Thomas


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

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

[Thiemo Seufer]

David Nusinow wrote:
[snip]
> > This is a non-issue. The main problem was the kernel situation, which will 
> > be
> > streamlined for etch into a single package, and maybe build issues, which
> > could be solved by a separate build queue or priority for d-i issues.
> 
> You know, you keep saying this and I have a really hard time
> believing it, although I don't follow the kernel list so please
> enlighten me if I'm wrong. 

The plan is to profit from better upstream architecture integration
since 2.6 and build all kernel images from a single package. Sven, btw,
is a member of the kernel team.

> If you have a single source package for 12 different architectures
> that's great, because when you have a security fix you can take
> care of that more easily. That's awesome.

We have that already.

> But then you'll be trading off for the same problems that every
> single other packge faces: namely that if a kernel on a single arch
> has an RC bug then it affects the kernels on every arch. This strikes
> me as being very problematic, and the only way I see around it is
> to downgrade actual RC bugs, which isn't really a solution at all.

Most kernel security bugs hit either generic code, or all architectures
equally.


Thiemo


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

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

[Bill Gatliff]

Guys:
Not my preference to jump in the middle of something, but...
I have a fairly reliable DSL line, with an unused Sun Blade 100 and a 
number of ARM and MIPS boards behind it.  If anyone wants to help me get 
them set up for buildd, drop me an email.

b.g.
Darren Salt wrote:
I demand that Anthony Towns may or may not have written...
 

Darren Salt wrote:
   

I demand that Anthony Towns may or may not have written...
 

Put them behind a firewall on a trusted LAN, use them to develop software
for arm chips, and then just follow unstable or run
non-security-supported snapshots. Apart from writing software for
embedded arm things, I can't see the value
   

"Linux desktop box" comes to mind...
 

 

But why would you spend over 1000 pounds on an arm Linux desktop box
instead of a few hundred pounds on a random i386 desktop box?
   

Compatibility with what I already have and use? The older hardware won't 
last
forever (and this Risc PC, for example, is 10 years old)...
 

A reasonable answer is because you're developing for arm's for embedded
applications; but if so, what's the big deal with using unstable or
snapshots, and running your public servers on other boxes?
   

What's wrong with people just using them as desktop boxes, using both OSes?
[1]
 

-- and if an arch is just going to be used for development, does it
really need all the support we give stable in order to make it useful for
servers and such?
   

Probably not, but ISTM that you'll first have to ascertain that it *is*
only being used for development before you can say that that support
definitely isn't needed.
 

 

Uh, you've got that round the wrong way: you don't do something because you
can't say support definitely isn't needed, you do something because you
*can* say support definitely *is* needed.
   

That may well be, but ISTM that you implied that the arch isn't going to be
used for non-development tasks...
 

If so, why? If not, what level of support does it need, that goes beyond
"unstable + snapshotting facility", and why? Debian developers [...]
   

You're focusing too much on development here. There are users too, you
know... :-)
 

 

Haven't seen any evidence of it -- developers and vendors, yes, users, or
uses, no...
   

I can't answer all of that myself, but there are people who can.
(Adding debian-arm. Note followups to both lists.)
[1] Not at the same time, of course. ;-)
 


--
Bill Gatliff
Embedded Linux *is* user friendly, it just chooses its friends carefully.
[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

[Marco d'Itri]

On Mar 20, Andreas Barth <[EMAIL PROTECTED]> wrote:

> One _might_ consider to have ports.d.o with the full package pool,
> whereas ftp.d.o only consists the most wanted architectures. As a mirror
> operator, you can than choose to either just have the most wanted
> architectures, all or both.
This would be good.
Ideally, it should be possible to derive the popular archive from the
complete one with an rsync exclusions list.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[David Nusinow]

On Sun, Mar 20, 2005 at 10:05:15AM +0100, Sven Luther wrote:
> On Fri, Mar 18, 2005 at 12:06:15PM -0500, David Nusinow wrote:
> > On Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote:
> > > [1] The installer might be a point, but since all sarge architectures
> > > will have a working installer and I hope there's not another
> > > installer rewrite planned for etch this shouldn't be a big issue.
> > 
> > This is still an issue. Joey Hess's mails have indicated very clearly that 
> > it's
> > difficult to get an installer release out even when all arches are already
> > supported.
> 
> This is a non-issue. The main problem was the kernel situation, which will be
> streamlined for etch into a single package, and maybe build issues, which
> could be solved by a separate build queue or priority for d-i issues.

You know, you keep saying this and I have a really hard time
believing it, although I don't follow the kernel list so please
enlighten me if I'm wrong. 

If you have a single source package for 12 different architectures
that's great, because when you have a security fix you can take
care of that more easily. That's awesome.

But then you'll be trading off for the same problems that every
single other packge faces: namely that if a kernel on a single arch
has an RC bug then it affects the kernels on every arch. This strikes
me as being very problematic, and the only way I see around it is
to downgrade actual RC bugs, which isn't really a solution at all.

 - David Nusinow


-- 
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 Metzler]

On 2005-03-15 Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 14, 2005 at 10:56:51AM +0100, Aurélien Jarno wrote:
[...]
> > - 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.
[...]

Hello,
In that case you probably should *enforce* that you have got both >2
local admins and >2 buildd admins for each arch.

Afair there have been significant delays due to (overworked, ill,
etc.) buildd admins in the past and if you are starting to enforce
reliable buildds not going all the way seems to be strange.
 cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
   http://downhill.aus.cc/


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

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

[Thiemo Seufer]

Andreas Barth wrote:
> * Marco d'Itri ([EMAIL PROTECTED]) [050319 03:50]:
> > On Mar 18, Steve Langasek <[EMAIL PROTECTED]> wrote:
> 
> > > There would definitely be duplication of arch:all between ftp.debian.org
> > > and ports.debian.org (let's call it ports), as well as duplication of the
> > > source.
> 
> > As a mirror operator, I think that this sucks. Badly.
> 
> One _might_ consider to have ports.d.o with the full package pool,
> whereas ftp.d.o only consists the most wanted architectures. As a mirror
> operator, you can than choose to either just have the most wanted
> architectures, all or both.

Why not go the full way? What I've outlined in [1] is too obvious to
never have been thought before, but what is the reason not to do it
that way?


Thiemo


[1] http://lists.debian.org/debian-devel/2005/03/msg01985.html


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

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

[Thiemo Seufer]

Hamish Moffatt wrote:
> On Sun, Mar 20, 2005 at 09:56:05AM +0100, Sven Luther wrote:
> > On Sun, Mar 20, 2005 at 12:00:23PM +1000, Anthony Towns wrote:
> > > But why would you spend over 1000 pounds on an arm Linux desktop box 
> > > instead of a few hundred pounds on a random i386 desktop box?
> > Because you don't want a 100+W dissipating screaming monster on your desk ?
> 
> You can get low power x86 systems that have much better performance (> 1
> GHz).

Name one. I don't see any x86 which comes even close to a 64bit MIPS
SOC at 1GHz, with Gigabit Ethernets and Memory controller on-die, and
a maximum power consumption of 5 W (Core alone ~3.5 W).

The closest I know of is the VIA Eden with an advertized TDP (Core only)
of 7 W and the real maximum above that. They list only active cooling as
certified, it is 32bit only, the L2 cache is smaller, the FPU is slower,
and integer performance is also lower.

> > > A reasonable answer is because you're developing for arm's for embedded 
> > > applications; but if so, what's the big deal with using unstable or 
> > > snapshots, and running your public servers on other boxes?
> > 
> > Because using unstable is not a workable solution. Try to make a daily
> > unstable install, and count how many days it is broken on the tier1 arches,
> > and see how worse it can become on tier2 slower arches.
> 
> Most work for embedded systems would be cross-compiled from faster
> systems anyway.

The price for that is a serious lack of testing. Debian stable provides
known good binaries.


Thiemo


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

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

[Darren Salt]

I demand that Anthony Towns may or may not have written...

> Darren Salt wrote:
>> I demand that Anthony Towns may or may not have written...
>>> Put them behind a firewall on a trusted LAN, use them to develop software
>>> for arm chips, and then just follow unstable or run
>>> non-security-supported snapshots. Apart from writing software for
>>> embedded arm things, I can't see the value
>> "Linux desktop box" comes to mind...

> But why would you spend over 1000 pounds on an arm Linux desktop box
> instead of a few hundred pounds on a random i386 desktop box?

Compatibility with what I already have and use? The older hardware won't last
forever (and this Risc PC, for example, is 10 years old)...

> A reasonable answer is because you're developing for arm's for embedded
> applications; but if so, what's the big deal with using unstable or
> snapshots, and running your public servers on other boxes?

What's wrong with people just using them as desktop boxes, using both OSes?
[1]

>>> -- and if an arch is just going to be used for development, does it
>>> really need all the support we give stable in order to make it useful for
>>> servers and such?
>> Probably not, but ISTM that you'll first have to ascertain that it *is*
>> only being used for development before you can say that that support
>> definitely isn't needed.

> Uh, you've got that round the wrong way: you don't do something because you
> can't say support definitely isn't needed, you do something because you
> *can* say support definitely *is* needed.

That may well be, but ISTM that you implied that the arch isn't going to be
used for non-development tasks...

>>> If so, why? If not, what level of support does it need, that goes beyond
>>> "unstable + snapshotting facility", and why? Debian developers [...]
>> You're focusing too much on development here. There are users too, you
>> know... :-)

> Haven't seen any evidence of it -- developers and vendors, yes, users, or
> uses, no...

I can't answer all of that myself, but there are people who can.

(Adding debian-arm. Note followups to both lists.)


[1] Not at the same time, of course. ;-)

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)

This portion of UTS II is a trade secret of Amdahl Corporation.


-- 
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 Sun, Mar 20, 2005 at 10:53:57PM +1100, Hamish Moffatt wrote:
> On Sun, Mar 20, 2005 at 09:56:05AM +0100, Sven Luther wrote:
> > On Sun, Mar 20, 2005 at 12:00:23PM +1000, Anthony Towns wrote:
> > > But why would you spend over 1000 pounds on an arm Linux desktop box 
> > > instead of a few hundred pounds on a random i386 desktop box?
> > Because you don't want a 100+W dissipating screaming monster on your desk ?
> 
> You can get low power x86 systems that have much better performance (> 1
> GHz).

They would be too slow for autobuilder work though.

> > > A reasonable answer is because you're developing for arm's for embedded 
> > > applications; but if so, what's the big deal with using unstable or 
> > > snapshots, and running your public servers on other boxes?
> > 
> > Because using unstable is not a workable solution. Try to make a daily
> > unstable install, and count how many days it is broken on the tier1 arches,
> > and see how worse it can become on tier2 slower arches.
> 
> Most work for embedded systems would be cross-compiled from faster
> systems anyway.

Yeah, and most people doing it this way use windows as development platform
anyway, i know.

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

[Andreas Barth]

* Hamish Moffatt ([EMAIL PROTECTED]) [050320 15:25]:
> On Sun, Mar 20, 2005 at 09:56:05AM +0100, Sven Luther wrote:
> > On Sun, Mar 20, 2005 at 12:00:23PM +1000, Anthony Towns wrote:
> > > But why would you spend over 1000 pounds on an arm Linux desktop box 
> > > instead of a few hundred pounds on a random i386 desktop box?
> > Because you don't want a 100+W dissipating screaming monster on your desk ?

> You can get low power x86 systems that have much better performance (> 1
> GHz).

The reason why I'm interessted in !x86-systems is that the usual child
tools for cracking the systems don't work.


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

[Andreas Barth]

* Marco d'Itri ([EMAIL PROTECTED]) [050319 18:40]:
> On Mar 19, Daniel Kobras <[EMAIL PROTECTED]> wrote:
> 
> > What's wrong with splitting into ftp-full-monty.d.o, carrying all archs,
> > including the popular ones, and ftp.d.o, carrying only the most popular
> > subset? This way, there's no need to mirror from both of them, and
> > duplication is kept to a minimum. Slightly increased traffic from the
> > fullblown server is the only drawback I see compared to the ports
> > proposal.

> That on some servers I'd like to mirror both archives, and I'd rather
> not waste a few GB on duplicated files.

I don't know if it's a good idea, but it might make use to write a
customized "mirror" script that just creates the appropriate symlinks on
the partial mirrors on your machine again.


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

[Andreas Barth]

* Marco d'Itri ([EMAIL PROTECTED]) [050319 03:50]:
> On Mar 18, Steve Langasek <[EMAIL PROTECTED]> wrote:

> > There would definitely be duplication of arch:all between ftp.debian.org
> > and ports.debian.org (let's call it ports), as well as duplication of the
> > source.

> As a mirror operator, I think that this sucks. Badly.

One _might_ consider to have ports.d.o with the full package pool,
whereas ftp.d.o only consists the most wanted architectures. As a mirror
operator, you can than choose to either just have the most wanted
architectures, all or both.


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

[Sven Luther]

On Sun, Mar 20, 2005 at 09:34:01AM +0100, Matthias Urlichs wrote:
> Hi, Thomas Bushnell BSG wrote:
> 
> > [EMAIL PROTECTED] (Marco d'Itri) writes:
> > 
> >> That on some servers I'd like to mirror both archives, and I'd rather
> >> not waste a few GB on duplicated files.
> > 
> > So don't duplicate them and use fancier mirroring software.
> 
> We can't. AFAIK: One or two rsync commands, and *that's*it*.
> 
> Any required fanciness need to be done on the master server.

Rsync can take fancier arguments though :)

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

[Hamish Moffatt]

On Sun, Mar 20, 2005 at 09:56:05AM +0100, Sven Luther wrote:
> On Sun, Mar 20, 2005 at 12:00:23PM +1000, Anthony Towns wrote:
> > But why would you spend over 1000 pounds on an arm Linux desktop box 
> > instead of a few hundred pounds on a random i386 desktop box?
> Because you don't want a 100+W dissipating screaming monster on your desk ?

You can get low power x86 systems that have much better performance (> 1
GHz).

> > A reasonable answer is because you're developing for arm's for embedded 
> > applications; but if so, what's the big deal with using unstable or 
> > snapshots, and running your public servers on other boxes?
> 
> Because using unstable is not a workable solution. Try to make a daily
> unstable install, and count how many days it is broken on the tier1 arches,
> and see how worse it can become on tier2 slower arches.

Most work for embedded systems would be cross-compiled from faster
systems anyway.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[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

[Sven Luther]

On Sat, Mar 19, 2005 at 04:19:03AM -0800, Steve Langasek wrote:
> On Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote:
> > On Thu, Mar 17, 2005 at 09:47:42PM -0800, Steve Langasek wrote:
> > > On Mon, Mar 14, 2005 at 07:59:43PM +, Alastair McKinstry wrote:
> > > > > AFAI can tell, anybody can host an archive of packages built from 
> > > > > stable 
> > > > > sources for a scc or unofficial port. And - if I read the conditions 
> > > > > on 
> > > > > becoming a fully supported Debian arch right - then having security 
> > > > > support 
> > > > > for an external pool of this arch is a good indicator that it should 
> > > > > be a 
> > > > > fully supported stable release (amongst other things).
> 
> > > > The plan as proposed is that the Debian scc ports are purely builds of
> > > > unstable. Hence this build out of the last release (e.g. etch) becomes a
> > > > subproject of a second-class project of Debian. It effectively has
> > > > little credibility.
> 
> > > Well, the release team are not the only Debian developers with 
> > > credibility,
> > > surely?  Not everything needs to go through us; if the project has the 
> > > will
> > > to do stable releases of these architectures, in spite of the release team
> > > being unwilling to delay other architectures while waiting for them, then
> > > it should be very possible to provide full stable releases for these
> > > architectures.
> > >...
> 
> > Which delays are expected for etch, that are not only imposed by the 
> > usage of testing for release purposes? [1]
> 
> > I do still doubt that testing actually is an improvement compared to the 
> > former method of freezing unstable, and even more do I doubt it's worth 
> > sacrificing 8 architectures.
> 
> If the proposal already gives porters the option to freeze ("snapshot")
> unstable to do their own releases, in what sense is this "sacrificing"
> architectures?  It sounds to me like it's exactly what you've always wanted,
> to eliminate testing from the release process...

Because this means that all the job you do for testing has to be redone on a
per-arch basis without reason, and you perfectly know how much work that is.

And this means that the porter have less time to do their real job, which
means an additional push to the ports in question into an early grave.

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 Fri, Mar 18, 2005 at 12:06:15PM -0500, David Nusinow wrote:
> On Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote:
> > [1] The installer might be a point, but since all sarge architectures
> > will have a working installer and I hope there's not another
> > installer rewrite planned for etch this shouldn't be a big issue.
> 
> This is still an issue. Joey Hess's mails have indicated very clearly that 
> it's
> difficult to get an installer release out even when all arches are already
> supported.

This is a non-issue. The main problem was the kernel situation, which will be
streamlined for etch into a single package, and maybe build issues, which
could be solved by a separate build queue or priority for d-i issues.

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 Sat, Mar 19, 2005 at 01:48:42AM -0800, Steve Langasek wrote:
> Hi Greg,
> 
> On Tue, Mar 15, 2005 at 02:10:47PM -0500, Greg Folkert wrote:
> > > > 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.
> 
> > Okay, I have to comment here, seeing that I personally have at two
> > separate locations, two complete mirrors, that I use nearly everyday.
> > They only update when a change in the archive is detected. That means
> > *MY* $PRETTY_BIG_NUMBER of usages of my own mirrors in each locale will
> > mean nothing. I do my own mirror(s) so as to reduce the load on the
> > Debian network. I actually scaled back what I use, now only having 5
> > arches I support, SPARC(and UltraSPARC), Alpha, HPPA-RISC, PowerPC and
> > x86(Intel and otherwise). I dropped IA64 a while ago and will pickup
> > X86_AMD64 when it become part of Sid Proper.
> 
> > How would you address the fact the bulk of my usage is not even seen by
> > your network.
> 
> Hrm, in what sense is this something that needs to be "addressed" at all?
> If you use an internal mirror for your heavy internal usage, then surely
> you, as a user, don't need a diverse network of full public mirrors -- you
> just need one, solid mirror to download from, don't you?

Because there is a mess between the pure mirror issues and the
testing/security/release issues. And i get the impression (maybe wrongly) that
the lack of download may somehow influence the decision to drop those arches
from the testing/security/release side too, at least you have not hinted at
the contrary.

I think the mirror issues are fully non-problematic, and everyone agrees with
them, it is the other issues which are problematic.

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 Sat, Mar 19, 2005 at 11:25:22AM +1000, Anthony Towns wrote:
> Henning Makholm wrote:
> >The question is whether the *porters* think they have a sufficiently
> >good reason to do the work of maintaining a separate testing-esque
> >suite. If the porters want to do the work they should be allowed to do
> >it.
> 
> If they don't need any support from anyone else, they're welcome to do 
> whatever they like. If they want other people to help them, I don't 
> think it's unreasonable to expect an answer to a "What's the point?" 
> question.

as long as the replies don't get ignored.

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 Sun, Mar 20, 2005 at 12:00:23PM +1000, Anthony Towns wrote:
> Darren Salt wrote:
> >I demand that Anthony Towns may or may not have written...
> >>Put them behind a firewall on a trusted LAN, use them to develop software
> >>for arm chips, and then just follow unstable or run non-security-supported
> >>snapshots. Apart from writing software for embedded arm things, I can't 
> >>see
> >>the value
> >"Linux desktop box" comes to mind...
> 
> But why would you spend over 1000 pounds on an arm Linux desktop box 
> instead of a few hundred pounds on a random i386 desktop box?

Because you don't want a 100+W dissipating screaming monster on your desk ?

> A reasonable answer is because you're developing for arm's for embedded 
> applications; but if so, what's the big deal with using unstable or 
> snapshots, and running your public servers on other boxes?

Because using unstable is not a workable solution. Try to make a daily
unstable install, and count how many days it is broken on the tier1 arches,
and see how worse it can become on tier2 slower arches.

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 Sat, Mar 19, 2005 at 11:24:14AM +1000, Anthony Towns wrote:
> beyond "unstable + snapshotting facility", and why? Debian developers 
> manage to develop on unstable fairly well, eg, why isn't that enough? Is 
> this just a PR issue, in that "unstable" and "snapshot" aren't something 
> you can put on a brochure or brag about on slashdot?

I wanted to do a test-install on powerpc using sid yesterday (or was it
friday) using the desktop task, in order to test that the new udev/makedev
combo did indeed fix the RC bug (300166/300170). But for some obscure reason,
tasksel failed to install the the desktop task, didn't even provide a log or
something for the reason.

This exactly is why we need testing, because unstable can get hit by random
breakage, and using whatever snapshoting of unstable for those minority
arches, means the porters will get hit by any number of random problems, not
even arch specific, and thus in addition of doing their porters work, need to
do all the work done by the testing scripts and the release team right now.

Which is why i proposed a build-from-testing method instead, which has the
problem of porters needing to upload twice, once to unstable to fix the issue,
and once to arch-unstable if the upload to unstable fails to reach testing for
whatever issue.

So, could you, as the testing script master-mind :), give us some hints as of
a per-arch sub-testing script would be possible ? 

I mean, we have unstable where everyone uploads their packages, and then we
have testing which gets filled from unstable by the testing-scripts for the
tier1 arches.

The idea would be to have for each tier2 arch a separate testing script,
running on scc or whatever hardware, and filling a per-arch testing from
unstable, but with the added limitation that the package needs to be in
testing to go to the per-arch testing, and individual hinted overrides would
be possible for arch-specific problems, which could also be uploaded through
testing-proposed-updates.

This way, tier1 testing doesn't need to wait for tier2 arches at all, but
tier2 arches can still get the benefit of testing at a lesser cost.

I would look at the code, and implement this myself, but i don't speak python,
so i am utherly useless for this kind of things.

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 Fri, Mar 18, 2005 at 09:22:11PM +1000, Anthony Towns wrote:
> Sven Luther wrote:
> >I think the main reply is for developers using said archs.
> 
> Developers *developing* on those architectures need to use unstable 

But it could be an unstable chroot, while their day-to-day work is done with
testing, which is the best way to detect problems early.

> anyway. If there aren't any users, then there's no much point doing any 
> development. Are there any users? If so, what are they doing?

So, the DDs are just slaves of the release team/ftp masters, and don't count
as users ? 

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

[Matthias Urlichs]

Hi, Thomas Bushnell BSG wrote:

> [EMAIL PROTECTED] (Marco d'Itri) writes:
> 
>> That on some servers I'd like to mirror both archives, and I'd rather
>> not waste a few GB on duplicated files.
> 
> So don't duplicate them and use fancier mirroring software.

We can't. AFAIK: One or two rsync commands, and *that's*it*.

Any required fanciness need to be done on the master server.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [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

[Thomas Bushnell BSG]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> That on some servers I'd like to mirror both archives, and I'd rather
> not waste a few GB on duplicated files.

So don't duplicate them and use fancier mirroring software.


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

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

[Anthony Towns]

Darren Salt wrote:
I demand that Anthony Towns may or may not have written...
Put them behind a firewall on a trusted LAN, use them to develop software
for arm chips, and then just follow unstable or run non-security-supported
snapshots. Apart from writing software for embedded arm things, I can't see
the value
"Linux desktop box" comes to mind...
But why would you spend over 1000 pounds on an arm Linux desktop box 
instead of a few hundred pounds on a random i386 desktop box?

A reasonable answer is because you're developing for arm's for embedded 
applications; but if so, what's the big deal with using unstable or 
snapshots, and running your public servers on other boxes?

-- and if an arch is just going to be used for development, does it really
need all the support we give stable in order to make it useful for servers
and such?
Probably not, but ISTM that you'll first have to ascertain that it *is* only
being used for development before you can say that that support definitely
isn't needed.
Uh, you've got that round the wrong way: you don't do something because 
you can't say support definitely isn't needed, you do something because 
you *can* say support definitely *is* needed.

If so, why? If not, what level of support does it need, that goes beyond
"unstable + snapshotting facility", and why? Debian developers [...]
You're focusing too much on development here. There are users too, you
know... :-)
Haven't seen any evidence of it -- developers and vendors, yes, users, 
or uses, no...

Cheers,
aj
--
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 Matthias Urlichs <[EMAIL PROTECTED]>
> Hi, Marco d'Itri wrote:

>> That on some servers I'd like to mirror both archives, and I'd rather not
>> waste a few GB on duplicated files.

> This may be a stupid question, but if you already mirror full-monty, what
> would you gain by also mirroring ftp.d.o on the same server?

As far as I understand, this was in the context of an IRREGULAR
architecture making a "stable" release which contained package
versions that are not present in the official archive. Then the
special repository with the arch-specific stable would neither be a
subset of ftp.d.o nor vice versa; yet they could still have much
source in common.

-- 
Henning Makholm   "Jeg skrællet har kartofler; min ene tommeltot
  røg vistnok med i gryden. Jeg har det ellers got."

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

[Darren Salt]

I demand that Anthony Towns may or may not have written...

> Michael K. Edwards wrote:
[snip]
>> I think Sarge on ARM has the potential to greatly reduce the learning
>> curve for some kinds of embedded development, especially if Iyonix
>> succeeds in its niche (long live the Acorn!).

> So, I looked at the website, but all I can see are expensive PCs that
> happen to have an arm chip.

FWIW, they're not the only ARM-based desktop boxes which are currently
available, although I'm not sure about the situation wrt Linux.

> Put them behind a firewall on a trusted LAN, use them to develop software
> for arm chips, and then just follow unstable or run non-security-supported
> snapshots. Apart from writing software for embedded arm things, I can't see
> the value

"Linux desktop box" comes to mind...

> -- and if an arch is just going to be used for development, does it really
> need all the support we give stable in order to make it useful for servers
> and such?

Probably not, but ISTM that you'll first have to ascertain that it *is* only
being used for development before you can say that that support definitely
isn't needed.

> If so, why? If not, what level of support does it need, that goes beyond
> "unstable + snapshotting facility", and why? Debian developers [...]

You're focusing too much on development here. There are users too, you
know... :-)

[snip]
> I guess this is really the wrong place to ask for "we use these machines"
> answers instead of "we develop for these machines", but hey.

I don't think that there's any need to *guess*... ;-)

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   http://www.youmustbejoking.demon.co.uk/progs.linux.html>

You will spend the rest of your life in the future.


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

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

[Matthias Urlichs]

Hi, Marco d'Itri wrote:

> On Mar 19, Daniel Kobras <[EMAIL PROTECTED]> wrote:
> 
>> What's wrong with splitting into ftp-full-monty.d.o, carrying all archs,
>> including the popular ones, and ftp.d.o, carrying only the most popular
>> subset? This way, there's no need to mirror from both of them, and
>> duplication is kept to a minimum. Slightly increased traffic from the
>> fullblown server is the only drawback I see compared to the ports
>> proposal.
> That on some servers I'd like to mirror both archives, and I'd rather not
> waste a few GB on duplicated files.

This may be a stupid question, but if you already mirror full-monty, what
would you gain by also mirroring ftp.d.o on the same server?

But: if you insist: since filenames of the one are a subset of the other,
this sequence would save you from storing or downloading ftp.d.o twice:
- rsync ftp.d.o
- cp -rlu ftp/pool/* fullmonty/pool
- rsync fullmonty

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [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

[Adrian Bunk]

On Sat, Mar 19, 2005 at 04:19:03AM -0800, Steve Langasek wrote:
> 
> > Which delays are expected for etch, that are not only imposed by the 
> > usage of testing for release purposes? [1]
> 
> > I do still doubt that testing actually is an improvement compared to the 
> > former method of freezing unstable, and even more do I doubt it's worth 
> > sacrificing 8 architectures.
> 
> If the proposal already gives porters the option to freeze ("snapshot")
> unstable to do their own releases, in what sense is this "sacrificing"
> architectures?

Well, producing a release from a "snapshot" of unstable in a way that's 
at least roughly comparable with current stable releases on this 
architecture are:
- release management
- security support

Freezing for one architecture from some snapshot of unstable is roughly 
comparable to a complete release process you as a release team are 
doing. But it's worse. One email from you to d-d-a "We will freeze in 
two months, please don't do big changes and stabilize your packages 
instead." results in an unstable (and therefore a testing) that's in a 
relatively good shape at the start of the freeze [1]. And after the 
start of the freeze, most maintainers will work on stabilizing the 
frozen packages instead of putting new versions into unstable. Yes, this 
doesn't work 100%, but it still distributes a serious amount of work 
from the release team to all maintainers. How much of this work will be 
distributed away from the porters if they announce: "The m68k team will 
release based on an unstable snapshot taken two months from now."?

And assuming you want to use such port specific releases on computers 
that have more than one user and/or that are connected to any network, 
you need security support. Joey (who should know best) already explained 
that for the security team it doesn't matter whether much they have to 
support 2 or 20 architectures within a release, but every additional 
distribution causes a lot of extra work for them. Whom do you want to 
put the burden for security releases of the 8 sarge architectures you 
expect to not release with etch on? Should the security team carry this 
burden, or should every porter team form their own security team 
releasing their own DSA's?

That's so much extra work for every single port that makes it nearly 
impossible for architectures to achieve what they get if they are in the 
regular release process that it's nearly impossible.

> It sounds to me like it's exactly what you've always wanted,
> to eliminate testing from the release process...
>...

Yes, I'm not a fan of testing.

But I do understand how testing works.

Both my previous emails in these threads and this emails aren't emails 
simply "testing bashing" emails without real contents. I'm trying to 
point at the weaknesses of a release process with testing - like every 
other release process, it has both advantages and disadvantages.

Testing has it's advantages.
You know that all packages have there dependencies fulfilled [2], were 
built on all architectures, and some kinds of bugs are less likely to 
make it into testing.

There were many release updates the release team sent that mentioned as 
a major success that transition A is now finally into testing and it was 
hoped that transition B will go into testing soon. How many weeks did it 
took altogether that were spent getting transitions into testing that 
were already completed in unstable? And how many hours have members of 
the release team spent for hints, coordinating between maintainers etc. 
for getting these transitions into testing? These are extra costs of 
testing.

And you explained in your announcement that removing approx. 8 of the 
current architectures from the release process "... will drastically 
reduce the architecture coordination required in testing, giving us a 
more limber release process and (it is hoped) a much shorter release 
cycle on the order of 12-18 months."

IOW:
You are saying the current release process with testing has problems 
that make it impossible to achieve a release cycle on the order of 12-18 
months with many architectures.

One possible solution for this problem you observed is reducing the 
number of architectures.

Another possible solution for this problem is to switch to a release 
process without testing.

cu
Adrian

[1] This was more effective if freeze announcements weren't sent 6 days
before the freeze, but it's your choice as release manager to not
take the full advantages of early announcements.
[2] but build dependencies are still not tracked

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
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 
> Henning Makholm wrote:

>> The question is whether the *porters* think they have a sufficiently
>> good reason to do the work of maintaining a separate testing-esque
>> suite. If the porters want to do the work they should be allowed to do
>> it.

> If they don't need any support from anyone else, they're welcome to do
> whatever they like.

My apologies. I was just whining, long after I ought to have concluded
that I was whining from false premises.

-- 
Henning Makholm   "The great secret, known to internists and
 learned early in marriage by internists' wives, but
   still hidden from the general public, is that most things get
 better by themselves. Most things, in fact, are better by morning."


-- 
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 Daniel Kobras <[EMAIL PROTECTED]>
> On Sat, Mar 19, 2005 at 01:21:15AM +0100, Marco d'Itri wrote:
>> On Mar 18, Steve Langasek <[EMAIL PROTECTED]> wrote:

>> > There would definitely be duplication of arch:all between ftp.debian.org
>> > and ports.debian.org (let's call it ports), as well as duplication of the
>> > source.

>> As a mirror operator, I think that this sucks. Badly.

> What's wrong with splitting into ftp-full-monty.d.o, carrying all archs,
> including the popular ones, and ftp.d.o, carrying only the most popular
> subset?

It should be possible to mirror the whole shebang without duplicating
content. This means that there ought to be a way for a mirror to use a
common pool directory for source and _all packages, even if one also
mirrors IRREGULAR architectures with their own testing-like suites
that do not track the same versions as the REGULAR one.

Such functionality is, however, beyond what our current archive
scripts are capable of, so it won't happen unless somebody writes
and tests the code to achieve it.

I think it is fair enough for the ftpmasters and release team to
declare: "we are not going to develop that code". Unfortunately
the Vancouver text does not distinguish clearly between

  1. We are not going to do this. Others may, if they care enough.
  2. This will not get done.
  3. We're proposing rules which say nobody must do this.

which leads to misunderstandings [1]. I assume, however, that (1) is
what is really meant.

[1] See e.g. my own incessant whining about "unstable-only" earlier
this week (with an outlying relapse yesterday - sorry, Anthony).

-- 
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

[Marco d'Itri]

On Mar 19, Daniel Kobras <[EMAIL PROTECTED]> wrote:

> What's wrong with splitting into ftp-full-monty.d.o, carrying all archs,
> including the popular ones, and ftp.d.o, carrying only the most popular
> subset? This way, there's no need to mirror from both of them, and
> duplication is kept to a minimum. Slightly increased traffic from the
> fullblown server is the only drawback I see compared to the ports
> proposal.
That on some servers I'd like to mirror both archives, and I'd rather
not waste a few GB on duplicated files.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Thiemo Seufer]

Anthony Towns wrote:
[snip]
> So, I'd just like to re-emphasise this, because I still haven't seen 
> anything that counts as useful. I'm thinking something like "We use s390 
> to host 6231 scientific users on Debian in a manner compatible to the 
> workstations they use; the software we use is ; we rely on having 
> security support from Debian because we need to be on the interweb 2; 
> ...". At the moment, the only use cases I'm confident exist are:
> 
>   m68k, mips, mipsel, hppa: I've got one in the basement, and I like 
>   to brag that I run Debian on it; also I occassionally get some work out 
> of 
> it, but it'd be trivial to replace with i386.

Well, for mips/mipsel, this covers only the machines which aren't that
relevant nowadays. Mips is one of the most numerous 32/64bit architectures
currently in use, but most of the time it is hidden in things which aren't
commonly recognized as computers.

http://www.mips.com/

A significant portion of mips/mipsel usage is geared towards networked
devices. Note that MIPS, Inc. does not manufacuture devices or CPUs,
they sell CPU designs.

http://www.mips.com/content/Corporate/AboutUs/content_html#mips

While it would be fun to run Debian on your digital camera with a large
flashcard, I don't see a real use for it, so I will restrict the
following list to Products where a stable debian distribution can be
useful.

- Cheap/Lean/Silent desktop computer
  http://www.pmc-sierra.com/xiaohu/

- Digital TV/Media Player/Video Recorder
  http://www.ati.com/products/settopwonderxilleon/
  http://www.semicon.toshiba.co.jp/eng/prd/micro/prd_inf/tx49.html

  Those will commonly have USB/Ethernet, and in some cases storage,
  which means they can be used as X-termial/Network Client/Lightweight
  standalone machine.

- WAP/Small router/DSL Modem
  http://meshcube.org/index_e.html
  http://mycable.de/xxs1500/

  Devices in this class had ~8 MB RAM two years ago and could at best
  run a customized linux. Today they have ~32 MB, can run Debian, but
  it is still beneficial to use a customized version
  (http://sourceforge.net/projects/picodebian). They are likely to grow
  further in the near future.

  The main hindrance for Debian on these systems is the lack of
  available storage. The size of cheap flash memory grows much faster
  than the debian base installation, so this problem will go away over
  time as well.

- High-end prototype boards
  http://sibyte.broadcom.com/public/boards/index.html

  Those boards are used by vendors to evaluate/test the CPU they have
  chosen for their product (Cisco and NetApp are well-known names).

  Some Debian developers have such boards. While they aren't easy to
  come by, and the userbase outside Debian is small, they are valuable
  because of their speed.

[snip]
>   arm: We're developing some embedded boxes, that won't run Debian 
> proper, but it's really convenient to have Debian there to bootstrap 
> them trivially.

ARM is roughly in the same situation like the slower MIPS CPUs, but
with a large percentage of it used in mobile devices. With mobile
networking on the rise Debian gets more interesting there.

>   s390: Hey, it's got spare cycles, why not?

AFAIH there are some serious Debian users on s390, but they don't talk
about it publicly.

[snip]
> Knowing why you're 
> using Debian and not another distribution or OS would be interesting too.

Outside the non-free/commercial realm, there are three choices for
mips/mipsel:

 - NetBSD, with a small core of software, limited (build-)testing
   outside that, and reproducibility problems caused by the
   source-centric approach

- Gentoo, with all of the above, linux based, and still tagged as
  experimental, which means experimental by Gentoo standards

- Debian


Thiemo


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

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

[Daniel Kobras]

On Sat, Mar 19, 2005 at 01:21:15AM +0100, Marco d'Itri wrote:
> On Mar 18, Steve Langasek <[EMAIL PROTECTED]> wrote:
> 
> > There would definitely be duplication of arch:all between ftp.debian.org
> > and ports.debian.org (let's call it ports), as well as duplication of the
> > source.
> As a mirror operator, I think that this sucks. Badly.

What's wrong with splitting into ftp-full-monty.d.o, carrying all archs,
including the popular ones, and ftp.d.o, carrying only the most popular
subset? This way, there's no need to mirror from both of them, and
duplication is kept to a minimum. Slightly increased traffic from the
fullblown server is the only drawback I see compared to the ports
proposal.

Regards,

Daniel.


-- 
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)

[Gunnar Wolf]

Ola Lundqvist dijo [Tue, Mar 15, 2005 at 09:19:45PM +0100]:
> > And would a larger discussion at debconf'05 not have been more appropriate
> > than handing done a couple of taken decision disguised as proposal ? 
> > 
> > It is not too late for this yet, but there needs to be a real discussion 
> > with
> > real facts, and not just a list of resolution letting 8/11th of the project 
> > in
> > the cold.
> 
> Please take this kind of discussions on debian-devel as it is possible
> for people not attending on debconf be a part of the discussion.

I do believe that Debconf is an ideal place for this - Having 150 of
us together might mean having 40 of us interested in joining this
discussion, brainstorming (and shouting at each other) for ~2hr
instead of over 600 messages, and coming up with something similar to
the Vancouver stuff - a summary of the points reached, not a firm
decision... But a summary with more adherents. And more people
convinced by the release and ftp teams on what and why (or people in
those teams convinced back, or... whatever :) )

Of course, if you cannot make it to Debconf, you will know about the
discussion results. In fact, Debconf plans to capture audio/video of
the sessions at the auditoriums, so you might even participate via
IRC. 

I intended to propose this topic for a round table, but was asked to
wait on this by one of the release members, as they were close to
announcing the Vancouver stuff... Anyway, I am not formally proposing
it, but I do expect it to happen - After all, we will be in HEL ;-)

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
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 Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote:
> On Thu, Mar 17, 2005 at 09:47:42PM -0800, Steve Langasek wrote:
> > On Mon, Mar 14, 2005 at 07:59:43PM +, Alastair McKinstry wrote:
> > > > AFAI can tell, anybody can host an archive of packages built from 
> > > > stable 
> > > > sources for a scc or unofficial port. And - if I read the conditions on 
> > > > becoming a fully supported Debian arch right - then having security 
> > > > support 
> > > > for an external pool of this arch is a good indicator that it should be 
> > > > a 
> > > > fully supported stable release (amongst other things).

> > > The plan as proposed is that the Debian scc ports are purely builds of
> > > unstable. Hence this build out of the last release (e.g. etch) becomes a
> > > subproject of a second-class project of Debian. It effectively has
> > > little credibility.

> > Well, the release team are not the only Debian developers with credibility,
> > surely?  Not everything needs to go through us; if the project has the will
> > to do stable releases of these architectures, in spite of the release team
> > being unwilling to delay other architectures while waiting for them, then
> > it should be very possible to provide full stable releases for these
> > architectures.
> >...

> Which delays are expected for etch, that are not only imposed by the 
> usage of testing for release purposes? [1]

> I do still doubt that testing actually is an improvement compared to the 
> former method of freezing unstable, and even more do I doubt it's worth 
> sacrificing 8 architectures.

If the proposal already gives porters the option to freeze ("snapshot")
unstable to do their own releases, in what sense is this "sacrificing"
architectures?  It sounds to me like it's exactly what you've always wanted,
to eliminate testing from the release process...

> [1] The installer might be a point, but since all sarge architectures
> will have a working installer and I hope there's not another
> installer rewrite planned for etch this shouldn't be a big issue.

Getting the installer into a releasable state across all 11 architectures
simultaneously *is* an ongoing issue, whether it involves a rewrite or not.
So is getting a releasable toolchain, and a releasable kernel; so is getting
buildds on all architectures to attempt to build packages soon enough after
upload to give maintainers timely feedback about brokenness in their
packages.  None of this seems to be imposed by the usage of testing.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

[Marco d'Itri]

On Mar 19, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> > > There would definitely be duplication of arch:all between ftp.debian.org
> > > and ports.debian.org (let's call it ports), as well as duplication of the
> > > source.
> > As a mirror operator, I think that this sucks. Badly.
> So don't duplicate ports.  That's the whole point.
I'd still like to support them, on some of my mirrors.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Steve Langasek]

Hi Greg,

On Tue, Mar 15, 2005 at 02:10:47PM -0500, Greg Folkert wrote:
> > > 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.

> Okay, I have to comment here, seeing that I personally have at two
> separate locations, two complete mirrors, that I use nearly everyday.
> They only update when a change in the archive is detected. That means
> *MY* $PRETTY_BIG_NUMBER of usages of my own mirrors in each locale will
> mean nothing. I do my own mirror(s) so as to reduce the load on the
> Debian network. I actually scaled back what I use, now only having 5
> arches I support, SPARC(and UltraSPARC), Alpha, HPPA-RISC, PowerPC and
> x86(Intel and otherwise). I dropped IA64 a while ago and will pickup
> X86_AMD64 when it become part of Sid Proper.

> How would you address the fact the bulk of my usage is not even seen by
> your network.

Hrm, in what sense is this something that needs to be "addressed" at all?
If you use an internal mirror for your heavy internal usage, then surely
you, as a user, don't need a diverse network of full public mirrors -- you
just need one, solid mirror to download from, don't you?

It makes perfect sense to me that if i386(+amd64) represents 10x as many
downloads as all other archs combined, and the other archs combined
represent 10x as much disk space needed as i386(+amd64), it's to our
advantage to split the two so that we can benefit from mirror operators
with either high bandwidth and little disk space (i386) or lots of disk
space but less bandwidth (SCC).

> > > >architecture requirements:
> > > 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.
> > 
> > You could say that "there must be a developer-accessible machine for the
> > architecture" without specifying "debian.org"; but I'm not sure that we
> > should *require* this, either.  Particularly for ports that are waning
> > and are not expected to become RC architectures in the future, I think
> > porters should be free to decide whether to spend the effort on
> > maintaining such a machine since its absence only hurts that port, not
> > the release.

> I am currently in the process of acquiring rotated out of production
> machines for 3 of the 5 architectures I support. I make a run to the
> right-coast of the US once every 2 months and pickup sometimes 10 - 4-16
> processor machines with disk and typically a dozen of GB of memory and
> gaggles of disk. I rebuild/recondition most of these machines and
> distribute them to NPOs that need this kind of horsepower but can't
> afford current stuff or even used stuff from those same suppliers. I put
> Debian on them and this makes a huge investment in the long term health
> of these Orgs.

> If these machines are no longer fully supported by Debian... how can I
> continue to do this.

What does "fully supported" mean to you?  What are the use cases for these
machines?  Which aspects of stable are required by these users?

> How much is the difference between Debian running on "Humidifier in the
> Basement" reputation, and a "We release more often than Ubuntu"
> reputation?

> But, serious, how much do you think Debian will be hurt with:

> Compare these:
> 1. Debian the "Universal OS"
> 2. Debian the "Almost-Sorta-Kinda-used-to-be Universal OS"

> 3. "Old as fossilized dinosaur poo, and as stable, but runs on
> everything including the humidifier in the basement"
> 4. "Very recent, since it doesn't really support NON-big 4
> processors anyway, so why not run Fedora Core"

> Personally, I like 1 and 3. They are the 2nd and 3rd most important
> technical reasons I chose Debian. 1st technical reason is the Debian's
> maintainability. Please oh please let us not change my mind for me.

I'm assuming your humidifier isn't connected to the public Internet, and
doesn't need ongoing security support...?

We're also constantly hearing from users who are using Debian in settings
where they *would* benefit from security support, but are 

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

[Andrew M.A. Cater]

On Fri, Mar 18, 2005 at 03:23:18AM -0800, Michael K. Edwards wrote:
>  Just because a full Debian doesn't usually
> fit today's embedded footprint doesn't mean it won't fit tomorrow's,
> and in the meantime Debian's toolchain, kernel, and initrd-tools are
> probably the best embedded Linux development and packaging environment
> going.  
> 
> I think Sarge on ARM has the potential to greatly reduce the learning
> curve for some kinds of embedded development, especially if Iyonix
> succeeds in its niche (long live the Acorn!).  In particular I look
> forward to being able to woo certain mobile computing colleagues,
> currently doomed to PocketPC, with a proper native development
> environment.  The same goes for some apparent "doorstop" arches:
> mipsel in networking and storage (e. g., SoC from Broadcom in
> set-tops, wireless gateways, and micro-NAS) and m68k in device control
> (68332 peripheral support, anyone?).
> 
This is _exactly_ so: I've just had two colleagues get work to buy them
Xscale embedded processor boards - they'd just bought some slower boards
for themselves. The boards come with a cut down version of Debian stable
_BECAUSE OF THE TOOLCHAIN AND CROSS COMPILATION_ and because it all just
works :) One of them now want's testing .iso's.
> 
> Likewise, minority-architecture autobuilders are one reason why Debian
> is really the only organization I trust to QA a toolchain any more. 
> For instance, compiling KDE for all of them expands the C++ stress
> test in a really useful way.  Even better if at least a couple of
> people actually run big globs of GUI on their kotatsu and catch
> run-time problems like #292673 (grave glibc bug, spotted with
> evolution on ia64).
> 

I don't have an Alpha to run as a desktop any more or a Sparc32 - they
were loan machines from my workplace - when I did, it was insanely easy 
to install identical software across the three architectures and have 
the same environment, features and ease of administration.  
If you have to administer many machines, that familiarity saves man years.

> Although sarge's long cycle has been frustrating for many people, if
> you ask me it's just as well that Debian never put the label "stable"
> on kernel 2.6.<7 (i. e., pre-objrmap), gcc 3.<2.3+ (not just C++, but
> nagging C and optimizer problems, often exposed by non-i386 kernels,
> in all previous 3.x), or glibc 2.3.(before next week or so, given
> #292673).  
> 
Red Hat and Novell are putting big money into releasing Enterprise
versions _less often_ and then supporting them for five years or seven
years in order to assure stability. That's the model that Debian has 
(inadvertently) had for years. Their targetted release cycle is 18
months - 2 years. IMHO The quantity of software is minimal in these
enterprise distros, testing seems poor and the overall quality variable.  
When you need something like a library you're used to in Debian,it's 
normally not there and you have to dig round the net for  
and trust to luck. The RHEL point releases are not great - and may change 
underlying stuff without telling you. [There is a prerelease of gcc 4 in 
RHEL 4 - a snapshot version from 12122004 - I fully expect them to introduce 
full gcc4 on one of their point releases _without bumping the version 
number_ :( ]

> None of that says that the world has a right to put the burden of
> sysadmining the broadest single software QA effort in history on the
> Debian release team's shoulders.  But if specific technical problems
> can be identified and addressed to where the infrastructure equipment
> and teams can stand it, keeping Debian Universal for at least one more
> cycle would be Herculean but not impossible.  I think this is one of
> those cases where the last 20% of the effort invested (coaxing along
> minority architectures) provides 80% of the value (stable actually
> means something).
> 
> Or look at it this way:  supporting minority architectures has
> revealed all sorts of scalability problems in Debian.  Some of those
> problems will be really nasty if we wait until the major architectures
> are in crisis to face them.  The doorstops are the canaries in the
> coal mine that start to suffocate before the big guys notice air
> quality problems.  Don't like performing CPR on canaries?  Don't put
> 'em down in coal mines!  Wait, there's something wrong with that logic
> ...

Full ACK to the above. I can see where the Vancouver proposals are coming 
from but the cut of what's a valid top tier isn't quite right yet. 
I'm not sure that ia64, for example, is worth the candle at all - but we 
are virtually the only distribution supporting it well. We _are_ the only 
distribution supporting hppa - now if we could just get Debian running on 
Superdome, I could suggest a replacement for hpux :) Ditto sole major
distribution for mips and sundry others. 

I run testing _at work_ on several machines because I need the slightly 
more up to date software and relative stability but that's only pen

Re: iyonix [was Re: Bits (Nybbles?) from the Vancouver release team meeting]

[Matthew Garrett]

Bill Allombert <[EMAIL PROTECTED]> wrote:

> Is it possible to get one or two to run as buildd and/or developer
> machine ? Being stuck with netwinder when XScale are available is 
> a bit like trying to build Debian on a 586.

There's no shortage of ARM hardware available to Debian, but so far it
hasn't been added to the buildd setup. I'm not clear on the reasons for
this.

-- 
Matthew Garrett | [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

[Matthew Garrett]

Anthony Towns  wrote:

> So, I looked at the website, but all I can see are expensive PCs that 
> happen to have an arm chip. Put them behind a firewall on a trusted LAN, 
> use them to develop software for arm chips, and then just follow 
> unstable or run non-security-supported snapshots. Apart from writing 
> software for embedded arm things, I can't see the value -- and if an 
> arch is just going to be used for development, does it really need all 
> the support we give stable in order to make it useful for servers and 
> such? If so, why? If not, what level of support does it need, that goes 
> beyond "unstable + snapshotting facility", and why? Debian developers 
> manage to develop on unstable fairly well, eg, why isn't that enough? Is 
> this just a PR issue, in that "unstable" and "snapshot" aren't something 
> you can put on a brochure or brag about on slashdot?

This is very much a "What should Debian be" question, and I don't think
trying to answer it along purely practical lines is reasonable. A
moderately large number of our developers have become involved *because*
we support these niche architectures - how do we reasonably quantify
that and compare it to the effort required to keep them up to date?

I do very much sympathise with the idea that expecting the release team
to carry the burden of looking after under-maintained architectures is
entirely unreasonable, but that doesn't mean that the only two choices
are to drop architectures or to give up on releasing. We have more
choices than that, we're just not sure how practical they are yet. I'm
not going to agree with any "Oh, it's hard to release this many
architectures" argument - I /will/ agree with "This architecture is
holding us back, so we should drop it".

Debian is a community project. Many people are involved because they
want to be, not because they need to be. Implying that their work isn't
massively useful isn't helpful, and may well have the effect of
discouraging people who /aren't/ working on the potentially affected
ports. If we're going to fail to release architectures, then let's base
this on technical grounds rather than "I don't see any real reason why
you need to release this architecture".

-- 
Matthew Garrett | [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

[Thomas Bushnell BSG]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Mar 18, Steve Langasek <[EMAIL PROTECTED]> wrote:
> 
> > There would definitely be duplication of arch:all between ftp.debian.org
> > and ports.debian.org (let's call it ports), as well as duplication of the
> > source.
> As a mirror operator, I think that this sucks. Badly.

So don't duplicate ports.  That's the whole point.


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

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

[Anthony Towns]

Henning Makholm wrote:
The question is whether the *porters* think they have a sufficiently
good reason to do the work of maintaining a separate testing-esque
suite. If the porters want to do the work they should be allowed to do
it.
If they don't need any support from anyone else, they're welcome to do 
whatever they like. If they want other people to help them, I don't 
think it's unreasonable to expect an answer to a "What's the point?" 
question.

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

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

[Anthony Towns]

Michael K. Edwards wrote:
AJ's categorization has some traction, but I think it's a somewhat
short-term perspective.
I was kind-of hoping it wasn't even that: we've been supporting all 
these architectures for over two years now; are they really completely 
useless?

I think Sarge on ARM has the potential to greatly reduce the learning
curve for some kinds of embedded development, especially if Iyonix
succeeds in its niche (long live the Acorn!). 
So, I looked at the website, but all I can see are expensive PCs that 
happen to have an arm chip. Put them behind a firewall on a trusted LAN, 
use them to develop software for arm chips, and then just follow 
unstable or run non-security-supported snapshots. Apart from writing 
software for embedded arm things, I can't see the value -- and if an 
arch is just going to be used for development, does it really need all 
the support we give stable in order to make it useful for servers and 
such? If so, why? If not, what level of support does it need, that goes 
beyond "unstable + snapshotting facility", and why? Debian developers 
manage to develop on unstable fairly well, eg, why isn't that enough? Is 
this just a PR issue, in that "unstable" and "snapshot" aren't something 
you can put on a brochure or brag about on slashdot?

Seriously, I'm not really looking for comparisons to i386 (least of all 
in the "but i386 will be dead soon too!" sense), just "Yeah, we use 
these machines for this purpose; we're serious about it for these 
reasons; we need this level of support from our OS vendor because of 
these considerations (and, eg, FooBar provides it thus...)."

I guess this is really the wrong place to ask for "we use these 
machines" answers instead of "we develop for these machines", but hey.

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

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

[Marco d'Itri]

On Mar 18, Steve Langasek <[EMAIL PROTECTED]> wrote:

> There would definitely be duplication of arch:all between ftp.debian.org
> and ports.debian.org (let's call it ports), as well as duplication of the
> source.
As a mirror operator, I think that this sucks. Badly.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: iyonix [was Re: Bits (Nybbles?) from the Vancouver release team meeting]

[Steve McIntyre]

Bill Allombert wrote:
>On Fri, Mar 18, 2005 at 08:19:14PM +, Darren Salt wrote:
>> I demand that Anthony Towns may or may not have written...
>> 
>> [snip]
>> > At the moment, the only use cases I'm confident exist are:
>> [snip]
>> >arm: We're developing some embedded boxes, that won't run Debian
>> > proper, but it's really convenient to have Debian there to bootstrap
>> > them trivially.
>> 
>> Desktop ARM-based machines: http://www.iyonix.com/>
>> 
>> Will run Debian: http://www.iyonix.com/linux.html>
>
>Is it possible to get one or two to run as buildd and/or developer
>machine ? Being stuck with netwinder when XScale are available is 
>a bit like trying to build Debian on a 586.
>
>Maybe we should contact them ?  They are certainly interested in Debian
>supporting their hardware.

It'd be more useful getting the existing offered hardware up and
running before asking for more. We have several arm boxes waiting to
be used...

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"This dress doesn't reverse." -- Alden Spiess


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

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

[Adrian Bunk]

On Thu, Mar 17, 2005 at 09:39:10PM +0100, David Schmitt wrote:
> On Thursday 17 March 2005 00:21, Adrian Bunk wrote:
> > On Wed, Mar 16, 2005 at 07:51:16PM +0100, David Schmitt wrote:
> > "libraries transitioned" is a big point against testing:
> >
> > Transitions of API-compatible libraries are a pain _only_ due to
> > testing. In unstable, such a transition can easily be done within a few
> > days.
> 
> Which leaves one with the problem that the new library might break any or all 
> of the depending packages, which testing would catch, while transitioning 
> unstable might not. But I have to admit that I didn't follow debian 
> development as closely as I do now in the times before testing and thus might 
> be arguing against the wind.

This is possible (but see your own comment below).

The bigger problems from the point of view of users aren't transitions 
(which usually go smooth - you simply have two versions of a library 
installed) but breakages like accidential ABI changes without an so-name 
change. These aren't necessarily caught be testing (except through the 
RC bug count), and libtiff is a good example where such a usere-visible 
problem made it into testing.

> Perhaps the best would be to prepare the transition beforehand in 
> experimental 
> and push the packages together into unstable, like GNOME and KDE did their 
> respective last big updates? This also would be a step towards reducing 
> dependency on work from the central teams.

That's a good idea and already done.

But this is independent of the question whether testing is present or 
not.

> Regards, David

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

iyonix [was Re: Bits (Nybbles?) from the Vancouver release team meeting]

[Bill Allombert]

On Fri, Mar 18, 2005 at 08:19:14PM +, Darren Salt wrote:
> I demand that Anthony Towns may or may not have written...
> 
> [snip]
> > At the moment, the only use cases I'm confident exist are:
> [snip]
> > arm: We're developing some embedded boxes, that won't run Debian
> > proper, but it's really convenient to have Debian there to bootstrap
> > them trivially.
> 
> Desktop ARM-based machines: http://www.iyonix.com/>
> 
> Will run Debian: http://www.iyonix.com/linux.html>

Is it possible to get one or two to run as buildd and/or developer
machine ? Being stuck with netwinder when XScale are available is 
a bit like trying to build Debian on a 586.

Maybe we should contact them ?  They are certainly interested in Debian
supporting their hardware.

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

[Darren Salt]

I demand that Anthony Towns may or may not have written...

[snip]
> At the moment, the only use cases I'm confident exist are:
[snip]
>   arm: We're developing some embedded boxes, that won't run Debian
> proper, but it's really convenient to have Debian there to bootstrap
> them trivially.

Desktop ARM-based machines: http://www.iyonix.com/>

Will run Debian: http://www.iyonix.com/linux.html>

[snip]
> I'm speaking only for myself; please, cure my naivety.

The above links should help :-)

[snip]
-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| woody, sarge, | Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   Oh, sarge too...

Look, sir! 'Droids!


-- 
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 Greenland]

On 18-Mar-05, 05:22 (CST), Anthony Towns  wrote: 
> Sven Luther wrote:
> >I think the main reply is for developers using said archs.
> 
> Developers *developing* on those architectures need to use unstable 
> anyway. 

I think he's talking about people developing products for those
archs, not Debian Developers.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the 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

[Adrian Bunk]

On Fri, Mar 18, 2005 at 12:06:15PM -0500, David Nusinow wrote:
> On Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote:
> > [1] The installer might be a point, but since all sarge architectures
> > will have a working installer and I hope there's not another
> > installer rewrite planned for etch this shouldn't be a big issue.
> 
> This is still an issue. Joey Hess's mails have indicated very clearly that 
> it's
> difficult to get an installer release out even when all arches are already
> supported.

You are referring to his email regarding problems with getting updates 
kernel images for all architectures?

I agree that's a point.
But this problem is already being attacked by the kernel team.

There are also other areas where work on the installer might be easier 
if fewer architectures were supported, but are they heavy enough for 
dropping two thirds of the Debian architectures - or are they issues 
where improvements were possible?

>  - David Nusinow

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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