armeb (was: architecture-specific release criteria - requalification needed)

[Andreas Barth]

Hi,

* Lennert Buytenhek ([EMAIL PROTECTED]) [050925 11:32]:
> So far we have (for sarge):
> - patches for apt, build-essential, cdrdao, dpkg, gcc, glibc, kaffe,
>   libsdl, linux-kernel-headers, ltrace, makedev, mozilla, strace and
>   util-linux to teach their config scripts/files et al. about the
>   armeb architecture;
> - patches for gal, libgc, quagga to hack around build/runtime failures;
> - patches for "all ARMs are little-endian" assumptions: apt, glibc, gmp,
>   modutils, ocaml (hackish), openssl, xfree86;
> - patches for gcc to make arm*b-*-* default to big-endian;
> - a patch for gcc 3.3 to work around PR22528 which (only) happens on
>   big-endian;

Can you please submit bug reports with patches for all such cases?


Cheers,
Andi


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

Re: architecture-specific release criteria - requalification needed

[Lennert Buytenhek]

On Sat, Sep 24, 2005 at 09:11:55AM +0200, Adrian von Bidder wrote:

> > We are keeping patches[7] for the armeb port separate, and are ready to
> > contribute them now, or at any future time that is more appropriate.
> > Another chicken-and-egg - are package maintainers expected to accept
> > patches for architectures that are not yet official?
> 
> What kind of patches are these?
> 
>  - general porting issues uncovered by armeb (and not uncovered on other 
> bigendian arches for some reason):  I guess these should be immediately 
> submitted.
>  - things like configure scripts etc.:  these are normally quite small and 
> isolated, so I don't see a reason to not submit these.

So far we have (for sarge):
- patches for apt, build-essential, cdrdao, dpkg, gcc, glibc, kaffe,
  libsdl, linux-kernel-headers, ltrace, makedev, mozilla, strace and
  util-linux to teach their config scripts/files et al. about the
  armeb architecture;
- patches for gal, libgc, quagga to hack around build/runtime failures;
- patches for "all ARMs are little-endian" assumptions: apt, glibc, gmp,
  modutils, ocaml (hackish), openssl, xfree86;
- patches for gcc to make arm*b-*-* default to big-endian;
- a patch for gcc 3.3 to work around PR22528 which (only) happens on
  big-endian;

We're slowly starting to compile stuff for unstable, beginning with
binutils/gcc/glibc, and we'll port these patches to unstable as we go
along.

The patches we have so far can be found at:

http://ftp.debonaras.org/patches/


cheers,
Lennert


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

Re: architecture-specific release criteria - requalification needed

[Adrian von Bidder]

On Thursday 22 September 2005 11.15, Debian-armeb Porting Team wrote:
> We are keeping patches[7] for the armeb port separate, and are ready to
> contribute them now, or at any future time that is more appropriate.
> Another chicken-and-egg - are package maintainers expected to accept
> patches for architectures that are not yet official?

What kind of patches are these?

 - general porting issues uncovered by armeb (and not uncovered on other 
bigendian arches for some reason):  I guess these should be immediately 
submitted.
 - things like configure scripts etc.:  these are normally quite small and 
isolated, so I don't see a reason to not submit these.

So there remain (very few?) cases where the patch is bigger (for whatever 
reason) - these will probably need more discussion.

Even then:  it's your stated goal for armeb to become a regular Debian 
architecture, so having your patches in the bts is one step closer to the 
goal.  Obviously, some maintainers will not want to apply some of these 
patches, but a 'wontfix' bug doesn't hurt nobody...

cheers
-- vbi


-- 
Computer programmers don't byte, they nibble a bit.


pgprsnwBBBoWT.pgp
Description: PGP signature

Re: architecture-specific release criteria - requalification needed

[Adrian von Bidder]

On Wednesday 21 September 2005 15.30, Petter Reinholdtsen wrote:
[arch release criteria]

> Personally, I find the list of requirements sensible, and very
> understandable after the clarifying rounds on the lists.  This colors
> my view of the discussion.

AOL!!1!

The only thing I'd modify is the 50 users thingy - drop that, because - as 
Ingo says - it's hard to tell, on the assumption that if there are enough 
Debian *and* upstream people to maintain kernel, toolchain, libc, 
boot-loader and Debian installer (d-i or other), there is enough 
justification for the port.

So 'm68k is having difficulty showing 50 users' becomes 'will m68k get a 
working gcc4 within a reasonable timeframe' which is easier to demonstrate.

(I'm *not* just bashing m68k here.  There are other arches where gcc4 ICEs, 
too, and there was quite a bit discussion about non-working kernels on 
certain SPARC variants IIRC.)

That said, I can live with the 50 users idea.

cheers
-- vbi

-- 
featured link: http://fortytwo.ch/smtp


pgpOuukWoMwCM.pgp
Description: PGP signature

Re: architecture-specific release criteria - requalification needed

[Goswin von Brederlow]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Thu, Sep 22, 2005 at 02:15:57PM +0200, Ingo Juergensmann wrote:
>> > graphics/gem_1:0.90.0-17: Dep-Wait by buildd_m68k-kiivi 
>> > [optional:out-of-date]
>> >   Dependencies: libjack0.80.0-0 (>= 0.99.0)
>> >   Previous state was Building until 2005 Aug 10 08:44:01
>> > This is a sampling of screwy dep-waits I was able to find by glancing
>> > through the buildd.debian.org webpages, and excludes those that I've 
>> > already
>> > specifically asked the m68k porters to remove in the recent past because
>> > they were holding up transitions.
>
>> So, what is better: to set a dep-wait and maybe do something wrong or
>> setting no dep-wait at all and let the package in Building state for weeks? 
>
> Which is more likely to get attention from a porter who happens to be in a
> position to correctly diagnose the build failure:  a package which is listed
> as "Building" with a failure build log to be looked at, or a package which
> has already had its build log processed and marked as Dep-Wait?

I think with simple Dep-Waits set to Dep-Wait and clear FTBFS set to
failed the remaining mystery failures (left in building) get much more
attention as well as the FTBFS do.

With everything just left in building (as other archs have) the
intresting cases drown in the trivial ones and nobody cares to even
look anymore.


Maybe W-B could send out a weekly mail listing all Dep-Waits older
than 2 weeks or something to make wrong entries more visible.

Or buildd.net could add "stale" lists for each w-b state listing only
packages that remained in each state for more than 2 weeks.

Ingo: How about that?

> Maybe the issue is that neither gets much attention; maybe that's why wrong
> Dep-Waits happen in the first place. ;)  Then again, maybe the m68k buildd
> maintainers do have time to periodically review stale dep-waits that they've
> set, to check them for correctness; that would be a pleasant surprise.
> Either way, it's only an issue for *me* when I notice it before someone else
> does. :)  And I know it takes me longer to notice a wrong dep-wait than it
> takes me to notice a maybe-failed package that could be requeued.

Practice, practice. :)

> Anyway, this isn't end-of-the-world stuff, it's just a simple observation
> about how having more people involved does bring a corresponding cost of
> team coordination.

MfG
Goswin


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

Re: architecture-specific release criteria - requalification needed

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Thu, Sep 22, 2005 at 02:15:57PM +0200, Ingo Juergensmann wrote:
>> On Thu, Sep 22, 2005 at 01:52:06AM -0700, Steve Langasek wrote:
>> > And sure, other buildd maintainers occasionally set a bogus dep-waits, but
>> > it seems to be m68k where I most frequently have to ask for their 
>> > removal...

If you look at the number of Dep-Waits and the number of packages in
state Building on other archs you will see that on most the admin
doesn't even set Dep-Wait at all but just reschedules packages manualy
or every now and then just returns all packages for another try.

Obviously if the Dep-Wait feature isn't used you won't get wrong
entries. But check how often people have asked for something to be
rescheduled because now their build-depends are available (or some
other buildd related reason).


If you think that broken Dep-Waits are a big problem you could supply
a patch to sanity check them. Most of the time you can check if the
package exists, that the version will be provided once some missing
source is build (or check against other archs) and so on. In case one
of them can't be verified to be sane w-b could ask for extra
confirmation.

This could also be used in junction with automaticaly adding all
Build-Depends as Dep-Wait for every source upload (all sane ones
anyway).

MfG
Goswin


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

Re: architecture-specific release criteria - requalification needed

[Wouter Verhelst]

On Fri, Sep 23, 2005 at 04:12:45AM -0700, Steve Langasek wrote:
> Then again, maybe the m68k buildd maintainers do have time to
> periodically review stale dep-waits that they've set, to check them
> for correctness; that would be a pleasant surprise.

We do this, but it gets deprioritized when there's a backlog. As is the
case right now.

> Either way, it's only an issue for *me* when I notice it before
> someone else does. :)  And I know it takes me longer to notice a wrong
> dep-wait than it takes me to notice a maybe-failed package that could
> be requeued.
> 
> Anyway, this isn't end-of-the-world stuff, it's just a simple observation
> about how having more people involved does bring a corresponding cost of
> team coordination.

I'm also convinced that the way we do things in our team currently isn't
the optimal way to do team-based buildd maintenance; I do have some
observations I'm considering to share with my fellow buildd maintainers.

Most of these involve optimizing a few things, making better agreements,
and pushing some things we're already doing right now to more extremes.
Just need to flesh out my thoughts on that a bit before I go ahead.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: architecture-specific release criteria - requalification needed

[Steve Langasek]

On Thu, Sep 22, 2005 at 02:15:57PM +0200, Ingo Juergensmann wrote:

> > > I still believe this definition is far too strict (without being precise).
> > > You can't say, you have to be 98% uptodate without saying what you
> > > understand by "being uptodate". As already outlined during the last
> > > discussion: when all m68k buildds are building package, that can easily be
> > > more than 110 packages marked as building and therefore missing as 
> > > installed
> > > (given a total of 5500 packages). 
> > Once again, what I'm hearing here is a plea for latitude towards certain
> > ports because they're slow, instead of an acknowledgement that being slow
> > (and therefore, failing to keep up) is what causes extra work for the
> > release team.

> No. Looking at s390, which ought to be no slow arch, there are currently 90
> packages in Needs-Build, 116 in Building, 6 Failed, 39 Dep-Wait, 1
> Failed-Removed and 28 Not-For-Us. So, a total of 251 (+29) packages marked
> as not Installed. That's >2% as well. 

Sure it is.  Do you think it matters *how* the arch falls below 98%?  The
impact on the release team is the same, whether it's due to the architecture
being slow, or due to unprocessed build failures and unsigned .changes files
(s390 seems to actually have plenty of both of these right now).

> That's why I asked how this number will be obtained. 

Grab the total number of source packages; exclude those packages which
should be excluded for the architecture (ideally, this can be done using
P-a-s only); count how many of these packages don't have binary packages
matching the current source version in unstable.  Once this has been done
for all archs and we have some historical data, calibrate our cutoff.

Whether this causes porters to evaluate the speed of their buildd hardware,
the availability of their buildd admins, or the amount of attention they pay
to build failures on their archs, it's a win for release predictability
because it means the release team doesn't have to be in the business of
micromanaging ports.

> > > Currently m68k has ~650 packages listed that are not in state Installed 
> > > (203
> > > Needs-Build, 142 Building, 180 Failed, 123 Dep-Wait (+ 5 Failed-Removed + 
> > > 25
> > > Not-For-Us)). That's roughly 6% of all packages. 
> > Yes, and a week ago the m68k porter lists were informed that the current
> > state of m68k is unacceptable and that if significant progress wasn't made
> > soon, we would ask for m68k to be ignored for all testing propagation.

> Yes, and although there are at least two buildds that are not running
> currently (because the local admin was very busy in the past) and even one
> of them has a broken boot disk, the port is keeping up fairly well now. 

Ok, fair enough; but AIUI the rebound happened when new buildds were brought
on-line, so the port *didn't* have excess buildd capacity beforehand, and
still doesn't until that local admin is available again.

> > If an architecture fails the release candidate criteria for whatever
> > reason, and is demoted to a non-release arch, I believe the sensible course
> > of action is to give the porters a fixed two-month period to remedy the
> > lapses before being re-evaluated by the release team.  That leaves the
> > porters free to focus on fixing whatever the issues are instead of scurrying
> > to get re-qualified ASAP, and it also ensures the release team's time isn't
> > wasted re-approving a port which qualifies at the instant but immediately
> > becomes a liability again after being approved.

> When a port isn't keeping up, it's already free to decide for the release
> team to release that port or not.

Is it?  Then why are we having this conversation about whether 98% is a
proper line to draw for "not keeping up"?

The reality is that historically, there have been several occasions where
I've felt that one architecture or another has been behind to the point that
it was making it harder to do release work, but I haven't been comfortable
bouncing the arch due to lack of clear precedent.  This is as much about
setting expectations as it is about anything else, so that we don't have to
have a flamewar (or people holding grudges) any time an arch gets ignored by
britney.  (Instead, we front-load the flamewars and grudges in the interest
of efficiency.)

> > graphics/gem_1:0.90.0-17: Dep-Wait by buildd_m68k-kiivi 
> > [optional:out-of-date]
> >   Dependencies: libjack0.80.0-0 (>= 0.99.0)
> >   Previous state was Building until 2005 Aug 10 08:44:01
> > This is a sampling of screwy dep-waits I was able to find by glancing
> > through the buildd.debian.org webpages, and excludes those that I've already
> > specifically asked the m68k porters to remove in the recent past because
> > they were holding up transitions.

> So, what is better: to set a dep-wait and maybe do something wrong or
> setting no dep-wait at all and let the package in Building state for weeks? 

Which is more likely to get attention from a porter wh

Re: architecture-specific release criteria - requalification needed

[Marc Haber]

On Wed, 21 Sep 2005 16:22:27 +0200, Ingo Juergensmann
<[EMAIL PROTECTED]> wrote:
>That's not only "must have 50 users" but more a "must have 50 users that do
>stuff on those machines". 

Dormant accounts do not qualify as "users", I think.

Greetings
Marc

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

Re: architecture-specific release criteria - requalification needed

[Andreas Barth]

Hi,

* Debian-armeb Porting Team ([EMAIL PROTECTED]) [050922 14:26]:
> On 9/21/05, Andreas Barth <[EMAIL PROTECTED]> wrote:
> > These criteria do _not_ control addition of an architecture to unstable,
> > but rather apply to architectures which the ftp-masters have accepted
> > into unstable and are targetting testing and the next stable release.
> > In other words, an architecture that fails these criteria can still be
> > part of unstable.
> 
> Andreas,
> 
> Can you outline the requirements for a new architecture (e.g.
> debian-armeb[1]) to be added to unstable ?  Or at least be added to the
> existing buildd infrastructure?


Both questions need to be asked to the ftp-masters.

Please allow me a personal remark: I personally have a lot of symphatie
for getting armeb into debian, also if compared to some of the other
suggested architectures. However, in the end, IMHO the most priority is
currently with amd64.


Cheers,
Andi


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

Re: architecture-specific release criteria - requalification needed

[Wouter Verhelst]

On Thu, Sep 22, 2005 at 06:45:35PM +0930, Debian-armeb Porting Team wrote:
> We are keeping patches[7] for the armeb port separate, and are ready to
> contribute them now, or at any future time that is more appropriate. 
> Another chicken-and-egg - are package maintainers expected to accept
> patches for architectures that are not yet official?

It is generally accepted to file wishlist bugs with patches if you're
working on a new port; though there is no actual requirement to accept
those, most package maintainers will easily include them if they don't
break other things.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: architecture-specific release criteria - requalification needed

[Wouter Verhelst]

On Thu, Sep 22, 2005 at 02:15:57PM +0200, Ingo Juergensmann wrote:
> On Thu, Sep 22, 2005 at 01:52:06AM -0700, Steve Langasek wrote:
> > And sure, other buildd maintainers occasionally set a bogus dep-waits, but
> > it seems to be m68k where I most frequently have to ask for their removal...
> 
> Which is usually corrected asap, right?

Yes, but that's not the point.

Steve is right if he says that the kiivi buildd admin (i.e., me) is
screwing up build-depends. I need to fix that, and I will.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: architecture-specific release criteria - requalification needed

[Henrique de Moraes Holschuh]

On Thu, 22 Sep 2005, Goswin von Brederlow wrote:
> Before you talk about the color of the car could we maybe first say
> what kind of car we are building?
> 
> What I mean is that there are several issues overlapping here and you
> are attacking the last and least urgent issue first.

Well, it is the release team speaking, they deal only with the last issue.
And there is absolutely no reason for them to wait on any of the other
issues at all, if they already know what they want.  SCC might not even be
under the release team's umbrella, for all we know of the future.

IMHO it is much better to get the release criteria out NOW, and thus let
people adapt and react to it with enough time to actually manage to fix
problems, so that an arch that would not be released ends up being released.

> 3. Define criteria for releases
> 
> This should realy be done after 2 is implemented and some experience
> has been made. There is hardly a point in deciding what gets released

Not really.  It just depends on how well the release team knows about what
is going to cause them trouble without the need for SCC insight.

> a) this is needed for the RM team to include the arch
> b) this is needed if the port team wants to make a release (and call
>it official)

IMHO (b) is quite tied to SCC, and it is better discursed along with SCC.

-- 
  "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: architecture-specific release criteria - requalification needed

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> Hi all,
>
> It has been discussed for a while already.  While we have release
> criteria for packages, up until now we don't have any for the
> architectures.  However, decisions made about an architecture affect
> both our users (and developers) and the release cycle much more than
> decisions about an individual package.
>
> For that reason, we discussed in multiple meetings, together with porters,
> ftp-masters and other people more than once how the criteria should
> look.  Also, there was more than one discussion on debian-devel. [1, 2]

Before you talk about the color of the car could we maybe first say
what kind of car we are building?

What I mean is that there are several issues overlapping here and you
are attacking the last and least urgent issue first.

Here is how I see the current urgencies:

1. split the mirror system into required and optional archs.

Specify what criteria an arch has to meat to be required on all
mirrors. This seems to be nearly exclusivly an "how many downloads
does the arch generate" criteria.

The split must be implemented for the archive and the mirror
infrastructure has to adapt to this. The reason amd64 wasn't added to
sid over a year ago was that mirrors are running out of bandwith,
mirror pusles take too long and are too expensive for some. With the
growth of Debian in the last year this must be even more of a problem
now than ever.


2. Define criteria for scc archs

Define what levels of archs there will be, e.g.:

- new ports with just unstable (could be hosted as alioth projects)
- ports that don't have stable (no releases)
- slow/incomplete ports that don't block testing but are release
  candidates if they can catch up during freeze
- full ports

Implement this in the archive software.

Will ports that don't block testing have their own britney runs or
just be continiously out of sync unless the port can keep up?


3. Define criteria for releases

This should realy be done after 2 is implemented and some experience
has been made. There is hardly a point in deciding what gets released
and then having to delay etch for 2 years till the archive implements
the infrastructure to make that even possible.

Also who makes the release and what makes it official?

For sarge amd64 basicaly was in the "doesn't block testing" section
from above and did the unofficial release with a small delay to the
official sarge and only minimal deviation from sarge source where
absoluetly neccessary. I think there should be some criteria for the
porting team to pull of a release like that and declare it
official. The work for this should fall to the porting team and they
should organize security for that port as well (like amd64 did).


So I suggest 2 release criteria:

a) this is needed for the RM team to include the arch
b) this is needed if the port team wants to make a release (and call
   it official)


As for what exactly each criteria should be keep fighting.

MfG
Goswin


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

Re: architecture-specific release criteria - requalification needed

[Kurt Roeckx]

On Thu, Sep 22, 2005 at 06:45:35PM +0930, Debian-armeb Porting Team wrote:
> 
> We *really* need to be hooked into the buildd system to be able to
> automatically build the rest of the stable, testing and unstable
> releases.  This is our top-most priority, and we hope to get help on
> this point from the Debian infrastructure teams.  We have buildd clients
> ready and running, but we need a server to feed them build requests.

There is nothing that prevents you from setting up wanna-build
and dak yourself.  Other ports (amd64, m32r?) and projects
(experimental, volatile, secure-testing?) already do this.  

However, I agree that it would be easier to start a new port if
we had some central place where new ports could start out without
the need to already be in the main archive.


Kurt


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

Re: architecture-specific release criteria - requalification needed

[Petter Reinholdtsen]

[Debian-armeb Porting Team]
> However, how does one get "armeb" recognised as a valid option for
> the graphs on http://popcon.debian.org?  Will simply sending in
> valid survey results with armeb as the architecture cause the graphs
> on that page to list armeb separately?

Yes.  The url to the port page might be incorrect, but that is a minor
detail.  Report a bug against the popularity-contest package with the
port page URL to have this fixed.

So, please enable popularity-contest on the machines in question, so
we can get a count on them. :)

> We are keeping patches[7] for the armeb port separate, and are ready
> to contribute them now, or at any future time that is more
> appropriate.  Another chicken-and-egg - are package maintainers
> expected to accept patches for architectures that are not yet
> official?

It depend on the patch.  Personally, I welcome patches making the
software more portable and less buggy, and I consider compile problems
or unable to run on any platform a bug.  On the other hand, if the
patch is cludgy, it will need to be rewritten.

> Chicken-and-egg again.  We need automatic support for keeping the
> autobuilders busy.  The machines we currently use run 24x7, but the
> feeding of items to build and the determination of build
> dependencies is currently done manually (which is very tedious).  We
> really need to be hooked into the buildd infrastructure.

You know it is possible to set up your own buildd infrastructure?  It
has been done in the past, and will probably happen in the future too.
You do not need to wait for the buildd.debian.org people to have time
to help you to set up your own buildd. :)


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

Re: architecture-specific release criteria - requalification needed

[Ingo Juergensmann]

On Thu, Sep 22, 2005 at 01:52:06AM -0700, Steve Langasek wrote:
> On Wed, Sep 21, 2005 at 02:52:57PM +0200, Ingo Juergensmann wrote:
> > Although it was discussed several times, I have still no idea how those
> > users should be counted? 
> > Who has to show those numbers? The users? The porters?
> "someone".  That someone is probably a porter by definition, I'd say.

"Someone" is not necessarily a porter. That's why I asked. So, it should be
said that a porter has to do the reports.

> > So, a little more info is needed, how those numbers are counted. 
> > Are users just meant to be ordinary users of does that included developers?
> Developers are users too.

Great if you see it that way, but it could've been different, though. :)

> > Uh, well, I hope that slower archs will be given a large time frame to fix
> > things than faster archs? It would be unfair to give just a week time to fix
> > a problem, when the recompilation of the package would take 10 days,
> > wouldn't it? ;)
> Why would it be in Debian's interest to be lenient with slower architectures
> here?  The whole point of these architecture requirements is to prevent an
> individual architecture from dragging the release down, and "this
> architecture is too slow to debug effectively" is *definitely* an instance
> of dragging the release down.  You're making a very good argument in *favor*
> of dropping such ports, I think.

Oh well, then again you could argue that every port that is slower than the
fastest port should be dropped, i.e. drop all archs. Is that what you want?

> > I still believe this definition is far too strict (without being precise).
> > You can't say, you have to be 98% uptodate without saying what you
> > understand by "being uptodate". As already outlined during the last
> > discussion: when all m68k buildds are building package, that can easily be
> > more than 110 packages marked as building and therefore missing as installed
> > (given a total of 5500 packages). 
> Once again, what I'm hearing here is a plea for latitude towards certain
> ports because they're slow, instead of an acknowledgement that being slow
> (and therefore, failing to keep up) is what causes extra work for the
> release team.

No. Looking at s390, which ought to be no slow arch, there are currently 90
packages in Needs-Build, 116 in Building, 6 Failed, 39 Dep-Wait, 1
Failed-Removed and 28 Not-For-Us. So, a total of 251 (+29) packages marked
as not Installed. That's >2% as well. 
That's why I asked how this number will be obtained. 

> > Currently m68k has ~650 packages listed that are not in state Installed (203
> > Needs-Build, 142 Building, 180 Failed, 123 Dep-Wait (+ 5 Failed-Removed + 25
> > Not-For-Us)). That's roughly 6% of all packages. 
> Yes, and a week ago the m68k porter lists were informed that the current
> state of m68k is unacceptable and that if significant progress wasn't made
> soon, we would ask for m68k to be ignored for all testing propagation.

Yes, and although there are at least two buildds that are not running
currently (because the local admin was very busy in the past) and even one
of them has a broken boot disk, the port is keeping up fairly well now. 

> If an architecture fails the release candidate criteria for whatever
> reason, and is demoted to a non-release arch, I believe the sensible course
> of action is to give the porters a fixed two-month period to remedy the
> lapses before being re-evaluated by the release team.  That leaves the
> porters free to focus on fixing whatever the issues are instead of scurrying
> to get re-qualified ASAP, and it also ensures the release team's time isn't
> wasted re-approving a port which qualifies at the instant but immediately
> becomes a liability again after being approved.

When a port isn't keeping up, it's already free to decide for the release
team to release that port or not. Instead, new, arbitrary numbers and rules
are raised. 
And I still think this is a proposal? Shouldn't it be voted about before it
becomes reality?

> graphics/gem_1:0.90.0-17: Dep-Wait by buildd_m68k-kiivi [optional:out-of-date]
>   Dependencies: libjack0.80.0-0 (>= 0.99.0)
>   Previous state was Building until 2005 Aug 10 08:44:01
> This is a sampling of screwy dep-waits I was able to find by glancing
> through the buildd.debian.org webpages, and excludes those that I've already
> specifically asked the m68k porters to remove in the recent past because
> they were holding up transitions.

So, what is better: to set a dep-wait and maybe do something wrong or
setting no dep-wait at all and let the package in Building state for weeks? 

> And sure, other buildd maintainers occasionally set a bogus dep-waits, but
> it seems to be m68k where I most frequently have to ask for their removal...

Which is usually corrected asap, right?
 
> > Ok, let's have a look at http://release.debian.org/etch_arch_qualify.html:
> > - 5 devs (porters): think so, yes: cts, adconrad, smarenka, smurf, rnhodek,
> > wout

Re: architecture-specific release criteria - requalification needed

[Christoph Berg]

Re: Petter Reinholdtsen in <[EMAIL PROTECTED]>
> Personally, I find the list of requirements sensible, and very
> understandable after the clarifying rounds on the lists.  This colors
> my view of the discussion.

AOL.

(Though I would like to see something like "at least N+1 buildd
_admins_" added.)

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: architecture-specific release criteria - requalification needed

[Debian-armeb Porting Team]

On 9/21/05, Andreas Barth <[EMAIL PROTECTED]> wrote:
> These criteria do _not_ control addition of an architecture to unstable,
> but rather apply to architectures which the ftp-masters have accepted
> into unstable and are targetting testing and the next stable release.
> In other words, an architecture that fails these criteria can still be
> part of unstable.

Andreas,

Can you outline the requirements for a new architecture (e.g.
debian-armeb[1]) to be added to unstable ?  Or at least be added to the
existing buildd infrastructure?

Below are representative responses to the requalification criteria for
the debian-armeb port, and the debian-armeb porting team is very
interested in understandig how to move forward to be added to the buildd
infrastructure and eventually be able to contribute to Debian unstable.

> |  * Availability:
> | The architecture needs to be available for everybody, i.e.

The Linksys NSLU2 is available for USD$80 at various online retail
outlets.  Other consumer-level armeb machines suitable for running
Debian can be readily purchased for less than USD$200.  Other high-end
armeb machines can range into the tens of thousands of dollars ...

> |  * Developer availability: The architecture must have a
> |developer-available (i.e. debian.org) machine that contains the
> |usual development chroots (at least stable, testing, unstable).

We can easily afford (from user contributions of money) to donate two or
three machines for Debian developers to use.

> |  * Users: The architecture needs to prove that developers and users
> |are actually using it. Five Developers needs to certify in that
> |they're actively developing on this architecture, and it needs to
> |be demonstrated that at least 50 users are using the platform.

We have no DDs on the team at the moment, but we do have a number of
DDs interested, and expect to be able to meet the requalification
requirement of 5 DDs actively developing after some period of time
(either by recruiting existing DDs, and/or by the DD applications of the
core armeb porting team progressing to approval).  We are tracking
installations now[2] and are half-way to the goal of 50 in less than two
months of operation.  We also intend using the popularity-contest to
assist in tracking progress towards meeting this requirement.

However, how does one get "armeb" recognised as a valid option for the
graphs on http://popcon.debian.org?  Will simply sending in valid survey
results with armeb as the architecture cause the graphs on that page to
list armeb separately?

> |  * Installer: The architecture must have a working, tested installer.

We have a fairly easy method of bootstrapping Debian on an NSLU2 right
now[3], and have people working on porting the standard debian-installer
(we need one that works across the network out of the box, since the
NSLU2 does not have a console without modifying the hardware[4]).

> |  * Porters and Upstream support: There is support by the porters and
> |upstream. This is especially true for the toolchain and the
> |kernel.

There is a very active team supporting Linux on the NSLU2, and other
armeb devices[5].  We are running the 2.6.12 kernel at the moment.

> |  * Archive coverage: The architecture needs to have successfully
> |compiled the current version of the overwhelming part of the
> |archive, excluding architecture-specific packages.

We currently have 2500+ stable packages released[6] (including all of
important, required and standard), and we have started building the same
set (important, required and standard) for unstable as well.

This is where the chicken-and-egg situation comes into play.

We *really* need to be hooked into the buildd system to be able to
automatically build the rest of the stable, testing and unstable
releases.  This is our top-most priority, and we hope to get help on
this point from the Debian infrastructure teams.  We have buildd clients
ready and running, but we need a server to feed them build requests.

> |  * Archive cleanliness: All binary packages need to be built from
> |unmodified sources (i.e. from the source found in the
> |ftp archive), and all binary packages need to be built by Debian
> |developers.

None of the current team building the armeb packages are DDs, but we
have at least two DDs who may be willing to sponsor the port.  The
question is whether we can get some armeb boxes into the buildd
infrastructure now, and therefore have packages built automatically, or
whether we have to rebuild all our packages after one of our team
becomes a DD (or a DD takes on the task of building the packages for
us).

We are keeping patches[7] for the armeb port separate, and are ready to
contribute them now, or at any future time that is more appropriate. 
Another chicken-and-egg - are package maintainers expected to accept
patches for architectures that are not yet official?

> |  * Autobuilder support:
> |The architecture is able 

Re: architecture-specific release criteria - requalification needed

[Steve Langasek]

On Wed, Sep 21, 2005 at 02:52:57PM +0200, Ingo Juergensmann wrote:
> Although it was discussed several times, I have still no idea how those
> users should be counted? 
> Who has to show those numbers? The users? The porters?

"someone".  That someone is probably a porter by definition, I'd say.

> Is it intended that a user should mail debian-release to say "Hi! I'm using
> port X!"? I doubt so. 

No, please assemble a list of users willing to vouch for their use of the
port and submit it to the release team when it's complete.

> So, a little more info is needed, how those numbers are counted. 
> Are users just meant to be ordinary users of does that included developers?

Developers are users too.

> > |  * Porters and Upstream support: There is support by the porters and
> > |upstream. This is especially true for the toolchain and the
> > |kernel.
> > Obviously, we cannot keep a port alive if there is nobody doing support for
> > it.  Of course, it is quite possible that Debian and upstream support is
> > done by the same persons.  And our experiences with support of gcc-4.0
> > on m68k have shown that it is possible to get such issues fixed, if the
> > porters are notified in time and are really interested in their port (and
> > if there are enough porters).

> Uh, well, I hope that slower archs will be given a large time frame to fix
> things than faster archs? It would be unfair to give just a week time to fix
> a problem, when the recompilation of the package would take 10 days,
> wouldn't it? ;)

Why would it be in Debian's interest to be lenient with slower architectures
here?  The whole point of these architecture requirements is to prevent an
individual architecture from dragging the release down, and "this
architecture is too slow to debug effectively" is *definitely* an instance
of dragging the release down.  You're making a very good argument in *favor*
of dropping such ports, I think.

> > |  * Archive coverage: The architecture needs to have successfully
> > |compiled the current version of the overwhelming part of the
> > |archive, excluding architecture-specific packages.
> > Our back-of-the-envelope number for this criterion is 98%.  As pointed
> > out multiple times during recent discussions, we don't have a good way
> > to measure an architecture's compliance with this yet, but we'll work on
> > figuring that out; of course we will exclude hardware-specific packages and
> > buggy optional/extra packages with severe portability issues, but
> > porters must take responsibility for working with maintainers to fix
> > portability issues.

> I still believe this definition is far too strict (without being precise).
> You can't say, you have to be 98% uptodate without saying what you
> understand by "being uptodate". As already outlined during the last
> discussion: when all m68k buildds are building package, that can easily be
> more than 110 packages marked as building and therefore missing as installed
> (given a total of 5500 packages). 

Once again, what I'm hearing here is a plea for latitude towards certain
ports because they're slow, instead of an acknowledgement that being slow
(and therefore, failing to keep up) is what causes extra work for the
release team.

> Currently m68k has ~650 packages listed that are not in state Installed (203
> Needs-Build, 142 Building, 180 Failed, 123 Dep-Wait (+ 5 Failed-Removed + 25
> Not-For-Us)). That's roughly 6% of all packages. 

Yes, and a week ago the m68k porter lists were informed that the current
state of m68k is unacceptable and that if significant progress wasn't made
soon, we would ask for m68k to be ignored for all testing propagation.

Your percentage is a bit off, btw; 650 is 7% of all source packages in
unstable, and if you *exclude* packages that are in P-a-s, the percentage
would be higher.  This is reflected on
.

> And when does that percent mark need to be reached? After freeze or at any
> time before a release?

The intent was that the threshold should be met on an ongoing basis.  Yes,
there will be times when a glut of uploads ensures that all ports are
struggling to meet it, and there may be times when one port or another dips
below the mark for particular reasons, but it really only becomes
significant when the release team *notices* it because it's impacting our
ability to process updates for testing, proceed with a multi-tier ABI
transition, etc.

If an architecture fails the release candidate criteria for whatever
reason, and is demoted to a non-release arch, I believe the sensible course
of action is to give the porters a fixed two-month period to remedy the
lapses before being re-evaluated by the release team.  That leaves the
porters free to focus on fixing whatever the issues are instead of scurrying
to get re-qualified ASAP, and it also ensures the release team's time isn't
wasted re-approving a port which qualifies at the instant but immediately
be

Re: architecture-specific release criteria - requalification needed

[Kalle Kivimaa]

"Ingo Juergensmann" <[EMAIL PROTECTED]> writes:
> The proposal make some very exact guidelines like the 98% rule whereas
> it is very unprecise in other regards. I find this quite irrating and
> thus asking for clarification.

Actually, the 98% rule is not in the proposal. It was given as a
possible rule of thumb when you asked for more concrete guidelines.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Re: architecture-specific release criteria - requalification needed

[Daniel Stone]

On Wed, 2005-09-21 at 17:05 +0200, Ingo Juergensmann wrote:
> Petter Reinholdtsen wrote:
> > I'm starting to suspect you do not trust the release team nor the
> > porters to make good judgement [...]
   ^^^

> Nono... of course not!
> It's just my personal experience that this sort of guidelines need
> either to be precise or need to be judged by a common sense.
  ^^^


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

Re: architecture-specific release criteria - requalification needed

[W. Borgert]

Quoting Andreas Barth <[EMAIL PROTECTED]>:
> * Ingo Juergensmann ([EMAIL PROTECTED]) [050921 16:53]:
> > What about such ports like m32r? Some embedded devices might run that port,
> > but the user doesn't even know about which arch he's using nor that he's
> > using Debian and certainly not that he is intended to give a "hey, i'm using
> > that port" message to Debian...
>
> Well, it doesn't necessarily be the user himself. But if a port is only
> used on embedded devices, the question arrises if it is necessary to
> include that port in testing and stable.

1. If the user theirself don't know about using Debian on the
   embedded device, I'm sure that someone knows about the fact
   and can easily provide information about it.  E.g. we all
   know about the Nokia 770 arm machines.  If we can believe
   that Nokia sold more than fifty gadgets, the goal is reached.

2. Even for embedded systems, stable releases are a good thing.
   (Easier to follow GPL rules of having sources available for
   some years.  Easier to build/install additional software, if
   one knows, which Debian release is used.  Easier to clone.)

Btw., IMHO, the new release criteria are very sensible, maybe
with the exception of the 98%-rule, which might be too strict.

Cheers, WB


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

Re: architecture-specific release criteria - requalification needed

[Ingo Juergensmann]

Petter Reinholdtsen wrote:
> [Ingo Juergensmann]
>> As I tried to say: there need more exact quidelines for
>> this. Currently they are very vague in my eyes.
> You failed to say why the guidelines need to be more exact.  In my
> view, the guidelines are good enough.  This is probably colored by the
> fact that I trust the good judgement of the release team, and the good
> will of both the release team and the porters to make sure any unclear
> issues are resolved together.
>
> I'm starting to suspect you do not trust the release team nor the
> porters to make good judgement and be able to work together to figure
> this out based on the given guidelines.  Is this so?

Nono... of course not!
It's just my personal experience that this sort of guidelines need
either to be precise or need to be judged by a common sense.
The proposal make some very exact guidelines like the 98% rule whereas
it is very unprecise in other regards. I find this quite irrating and
thus asking for clarification.
And I want to prevent misunderstandings. I want to know with what I'll
be faced in the future, especially because I think that the current
ruleset is sufficient and have other opinions in some areas (number of
buildds, eg.).
I would prefer a different approach to the release problem, which I
already have outlined in some older discussions.

Please do not expect bad things when someone asks questions.

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


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

Re: architecture-specific release criteria - requalification needed

[Andreas Barth]

* Ingo Juergensmann ([EMAIL PROTECTED]) [050921 16:53]:
> What about such ports like m32r? Some embedded devices might run that port,
> but the user doesn't even know about which arch he's using nor that he's
> using Debian and certainly not that he is intended to give a "hey, i'm using
> that port" message to Debian...  

Well, it doesn't necessarily be the user himself. But if a port is only
used on embedded devices, the question arrises if it is necessary to
include that port in testing and stable.


Cheers,
Andi


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

Re: architecture-specific release criteria - requalification needed

[Ingo Juergensmann]

On Wed, Sep 21, 2005 at 04:28:07PM +0200, Steinar H. Gunderson wrote:
> On Wed, Sep 21, 2005 at 04:22:27PM +0200, Ingo Juergensmann wrote:
> > That's not only "must have 50 users" but more a "must have 50 users that do
> > stuff on those machines". 
> > See, that's the problem, when you don't define those rules exactly: what
> > qualifies for a "user" - how often needs the user on the machine, how much
> > time must he waste there, and so on and so on?
> Come on -- seriously, if a port has a problem demonstrating 50 users in a
> form that is acceptable to the release team, it has a problem anyhow. Heck,
> almost every port I can think of (perhaps except s390) should be able to
> easily gather 50 people on IRC from a machine running that architecture,
> announcing ???hey, I'm a user!??? :-) I do not seriously think this will be a
> blocked for any realistic architecture.

No, seriously, I don't know how to achieve this for m68k yet. 
I think many m68k users out there are running there m68ks as it is, without
contact to any list related to debian. They might upgrade from time to time
their boxes, but how will you reach them, when you don't know how to contact
them? And not everyone will be hooked up to IRC anyway. 
I once made a poll on debian-68k about the usage of the machines there. IIRC
there were around 30 votes, but I don't believe that everyone answered in
that poll who's using a m68k machine. 
The problem still exists: how will you reach those users and get them to
give a live sign? 
What about such ports like m32r? Some embedded devices might run that port,
but the user doesn't even know about which arch he's using nor that he's
using Debian and certainly not that he is intended to give a "hey, i'm using
that port" message to Debian...  

-- 
Ciao...//Fon: 0381-2744150 
  Ingo   \X/ SIP: [EMAIL PROTECTED]

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc


signature.asc
Description: Digital signature

Re: architecture-specific release criteria - requalification needed

[Petter Reinholdtsen]

[Ingo Juergensmann]
> As I tried to say: there need more exact quidelines for
> this. Currently they are very vague in my eyes.

You failed to say why the guidelines need to be more exact.  In my
view, the guidelines are good enough.  This is probably colored by the
fact that I trust the good judgement of the release team, and the good
will of both the release team and the porters to make sure any unclear
issues are resolved together.

I'm starting to suspect you do not trust the release team nor the
porters to make good judgement and be able to work together to figure
this out based on the given guidelines.  Is this so?

If so, it might be an idea to work on your lack of trust, instead of
spending the time trying to formulate the guidelines in a waterproof
way, as no guidelines will ever be able to cover all possible corner
cases if the lack of trust between the users of the guidelines are
present.


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

Re: architecture-specific release criteria - requalification needed

[Ingo Juergensmann]

On Wed, Sep 21, 2005 at 03:37:25PM +0200, Andreas Barth wrote:

> > > |  * Developer availability: The architecture must have a
> > > |developer-available (i.e. debian.org) machine that contains the
> > > |usual development chroots (at least stable, testing, unstable).
> > > This criterion is there so that any developer can actually find out what 
> > > the
> > > issue is if his package fails to work on a specific architecture.  Of
> > > course, when adding a new architecture, there will be a time without a
> > > stable release, and there will be some special arrangement how such a
> > > machine can be provided without having even some packages in testing.  But
> > > that's not meant as a no-go, as long as we are quite optimistic that 
> > > adding
> > > the new machine will actually work in time.
> > Well, for established ports, that shouldn't be a big deal, right?
> I so wish this would be true ...

*giggle*
Yes, I've heard stories where someone wanted to use such a machine, but
wasn't allowed to built a package there, because that machine (a SMP box)
was running a buildd as well. So, there was actually a machine available,
but of no big use. 

> > I still believe this definition is far too strict (without being precise).
> > You can't say, you have to be 98% uptodate without saying what you
> > understand by "being uptodate". As already outlined during the last
> > discussion: when all m68k buildds are building package, that can easily be
> > more than 110 packages marked as building and therefore missing as installed
> > (given a total of 5500 packages). 
> > Currently m68k has ~650 packages listed that are not in state Installed (203
> > Needs-Build, 142 Building, 180 Failed, 123 Dep-Wait (+ 5 Failed-Removed + 25
> > Not-For-Us)). That's roughly 6% of all packages. 
> > And when does that percent mark need to be reached? After freeze or at any
> > time before a release?
> Basically any time. However, we might need to readjust the number. If it
> makes you feel better, please read the number above as "a very high
> number".

I think it would be better to concentrate that high value for essential
or important packages and to judge upon the rest on a rational sense. That
sounds quite fuzzy, but makes more sense IMHO than an abstract high number.

> > I think (and believe that many DDs will agree) that m68k, although being one
> > of the slowest archs, is one of the most responsive ports within Debian and
> > that having that many buildds is nothing negative at all. 
> As I said: We think the m68k port is doing well, and for this reason, we
> consider to grandfather it in. But that won't happen without a mail from
> one of the porters asking us to do it, and providing some facts why this
> is a good idea. :)

Uhm, that raises the next question: who qualifies as a porter? ;)
Questions over questions. ;)

> > Sometimes it seems problematic to find a porting machine, though, because
> > db.debian.org/machines.cgi is not always very uptodate. 
> And that is why we require to have a available porting machine (see
> above).

See above. Maybe machines.cgi lists a machine as available, but it still can
be unavailable, because of some strange machine related policies or the data
on machines.cgi is simply wrong/outdated. 
Well, then again there might be other resources where you can see if a
porting machine is up and running *dumdidums* ;o)

> > For m68k: 
> > [...]
> don't go so fast :)
> Well, it's of course the decision of the m68k porters team who of them
> will do the mail. But I think some more bits than just "it's available"
> would be good.

As I tried to say: there need more exact quidelines for this. Currently they
are very vague in my eyes.
Maybe setting up website with a reporting form might be a good idea, dunno,
but you should know how and what you want to know from the porters before
setting a dead line. 

-- 
Ciao...//Fon: 0381-2744150 
  Ingo   \X/ SIP: [EMAIL PROTECTED]

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc


signature.asc
Description: Digital signature

Re: architecture-specific release criteria - requalification needed

[Steinar H. Gunderson]

On Wed, Sep 21, 2005 at 04:22:27PM +0200, Ingo Juergensmann wrote:
> That's not only "must have 50 users" but more a "must have 50 users that do
> stuff on those machines". 
> See, that's the problem, when you don't define those rules exactly: what
> qualifies for a "user" - how often needs the user on the machine, how much
> time must he waste there, and so on and so on?

Come on -- seriously, if a port has a problem demonstrating 50 users in a
form that is acceptable to the release team, it has a problem anyhow. Heck,
almost every port I can think of (perhaps except s390) should be able to
easily gather 50 people on IRC from a machine running that architecture,
announcing “hey, I'm a user!” :-) I do not seriously think this will be a
blocked for any realistic architecture.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: architecture-specific release criteria - requalification needed

[Ingo Juergensmann]

On Wed, Sep 21, 2005 at 03:46:14PM +0200, Andreas Barth wrote:

> > Well, I'm already running popcon on my two m68ks, but that doesn't say much
> > about how many users are using that machines, as you state yourself. ;)
> Well, it's up to the porters to count the users, but of course, if you
> state that you have two m68ks with 10 users each, that counts as 20
> users.
> Of course, I might get curious how big the m68ks are, or how much work
> the people really do on them, and we may ask on further input. :)

Aha! 
That's not only "must have 50 users" but more a "must have 50 users that do
stuff on those machines". 
See, that's the problem, when you don't define those rules exactly: what
qualifies for a "user" - how often needs the user on the machine, how much
time must he waste there, and so on and so on?
Is it ok when a user only logins every half year or is it needed that he is
there on a daily basis? Does it qualify as a user when there's an IMAP
folder that the user is using or maybe a uucp account?
It's difficult to judge when a user is a user sometimes... ;)

-- 
Ciao...//Fon: 0381-2744150 
  Ingo   \X/ SIP: [EMAIL PROTECTED]

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc


signature.asc
Description: Digital signature

Re: architecture-specific release criteria - requalification needed

[Petter Reinholdtsen]

[Kalle Kivimaa]
> It's actually pretty easy. Count the number of posters that seem to
> disagree. If this number is over half of the current developer
> count, then yes, a majority of the developers are in
> opposition. What you _cannot_ do is say "because over 50% of the
> people participating in the discussion disagree with the proposal,
> over 50% of the developers disagree."

Counting and verifying that the number of participants in the
discussion was less then half the number of DDs will not really tell
us anything, as we can not reasonably claim anything about the meaning
of the silent majority.

There is no doubt that most of the debian developers did not
participate in the discussion.  This does not tell anything about
those not participating.  They could agree, disagree, or not care.

I suspect your retorical suggestion would lead you to conclude that
there only was a vocal minority protesting against the suggestion, but
it could equally well lead to the conclusion that there was a vocal
minority proposing this list of requirements.

It is probably safe to avoid drawing any conclusions based on these
criteria, and instead use ones own judgement when weighting the
arguments previosly presented in the way too long mailing list thread.


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

Re: architecture-specific release criteria - requalification needed

[Kalle Kivimaa]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> I guess that depends on the viewpoint of the reader what the results
> were.  It is hard to tell if there is a vocal minority making a lot of
> noise, or if there is a majority disagreeing with the criteria.

It's actually pretty easy. Count the number of posters that seem to
disagree. If this number is over half of the current developer count,
then yes, a majority of the developers are in opposition. What you
_cannot_ do is say "because over 50% of the people participating in
the discussion disagree with the proposal, over 50% of the developers
disagree."

> Personally, I find the list of requirements sensible, and very
> understandable after the clarifying rounds on the lists.  This colors
> my view of the discussion.

Me too.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Re: architecture-specific release criteria - requalification needed

[Andreas Barth]

* Ingo Juergensmann ([EMAIL PROTECTED]) [050921 15:28]:
> On Wed, Sep 21, 2005 at 03:19:16PM +0200, Petter Reinholdtsen wrote:
> > [Ingo Juergensmann]
> > > Although it was discussed several times, I have still no idea how those
> > > users should be counted? 
> > Two ideas.
> >  - Get them to install popularity-contest.  This will make their
> >machine show up on popcon.debian.org, and we would assume there are
> >users of the given machine.  Not very accurate, as machines !=
> >individuals.  Easy to fool, but I believe we should assume people
> >are honest.

> Well, I'm already running popcon on my two m68ks, but that doesn't say much
> about how many users are using that machines, as you state yourself. ;)

Well, it's up to the porters to count the users, but of course, if you
state that you have two m68ks with 10 users each, that counts as 20
users.

Of course, I might get curious how big the m68ks are, or how much work
the people really do on them, and we may ask on further input. :)


Cheers,
Andi


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

Re: architecture-specific release criteria - requalification needed

[Andreas Barth]

* Josselin Mouette ([EMAIL PROTECTED]) [050921 15:25]:
> Le mardi 20 septembre 2005 à 23:41 +0200, Andreas Barth a écrit :
> > For that reason, we discussed in multiple meetings, together with porters,
> > ftp-masters and other people more than once how the criteria should
> > look.  Also, there was more than one discussion on debian-devel. [1, 2]

> This has been indeed discussed to death. The result of the discussion
> seems to be that a large majority of the developers doesn't agree with
> all your criteria. Why are you trying to force this change regardless of
> that? It will only result in resurrecting the neverending discussion on
> debian-devel.

I disagree with you. All of the discussions that I had have shown me
that most of the developers agree with the basic goals. Of course, some
of the discussions were unnecessary heated through presenting the ideas
in a too mixed way with other ideas.

And, BTW, there is no "trying to force". We need to explicitly set
architecture requirements, or etch will become even worse manageable
than sarge was. For this reason, the release team decided that this list
is now part of the release policy, as well as the RC criteria list is
part of our release policy.


Cheers,
Andi


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

Re: architecture-specific release criteria - requalification needed

[Andreas Barth]

* Ingo Juergensmann ([EMAIL PROTECTED]) [050921 14:54]:
> On Tue, Sep 20, 2005 at 11:41:13PM +0200, Andreas Barth wrote:
> > |  * Developer availability: The architecture must have a
> > |developer-available (i.e. debian.org) machine that contains the
> > |usual development chroots (at least stable, testing, unstable).
> > This criterion is there so that any developer can actually find out what the
> > issue is if his package fails to work on a specific architecture.  Of
> > course, when adding a new architecture, there will be a time without a
> > stable release, and there will be some special arrangement how such a
> > machine can be provided without having even some packages in testing.  But
> > that's not meant as a no-go, as long as we are quite optimistic that adding
> > the new machine will actually work in time.

> Well, for established ports, that shouldn't be a big deal, right?

I so wish this would be true ...

> > |  * Installer: The architecture must have a working, tested installer.
> > Obviously, we need an installer. Though that doesn't say "debian
> > installer", we think that our users expect that there are not too many
> > different ways for them to install the released version of Debian etch one
> > day.

> Some obscure bootloader and a tarball of a mini-installation would be fine
> as well?

Well, probably not. As I said, we think that our users expect that there
are not too many different ways for them to install the released version
of Debian etch one day. So, there shouldn't be ten different and obscure
installers. But in the end, that will be of course a case-by-case
decision.


> > |  * Porters and Upstream support: There is support by the porters and
> > |upstream. This is especially true for the toolchain and the
> > |kernel.
> > Obviously, we cannot keep a port alive if there is nobody doing support for
> > it.  Of course, it is quite possible that Debian and upstream support is
> > done by the same persons.  And our experiences with support of gcc-4.0
> > on m68k have shown that it is possible to get such issues fixed, if the
> > porters are notified in time and are really interested in their port (and
> > if there are enough porters).
> 
> Uh, well, I hope that slower archs will be given a large time frame to fix
> things than faster archs? It would be unfair to give just a week time to fix
> a problem, when the recompilation of the package would take 10 days,
> wouldn't it? ;)

I think the current way with m68k really works for all involved parties
(at least it does from my point of view :).

> > |  * Archive coverage: The architecture needs to have successfully
> > |compiled the current version of the overwhelming part of the
> > |archive, excluding architecture-specific packages.
> > Our back-of-the-envelope number for this criterion is 98%.  As pointed
> > out multiple times during recent discussions, we don't have a good way
> > to measure an architecture's compliance with this yet, but we'll work on
> > figuring that out; of course we will exclude hardware-specific packages and
> > buggy optional/extra packages with severe portability issues, but
> > porters must take responsibility for working with maintainers to fix
> > portability issues.
> 
> I still believe this definition is far too strict (without being precise).
> You can't say, you have to be 98% uptodate without saying what you
> understand by "being uptodate". As already outlined during the last
> discussion: when all m68k buildds are building package, that can easily be
> more than 110 packages marked as building and therefore missing as installed
> (given a total of 5500 packages). 
> Currently m68k has ~650 packages listed that are not in state Installed (203
> Needs-Build, 142 Building, 180 Failed, 123 Dep-Wait (+ 5 Failed-Removed + 25
> Not-For-Us)). That's roughly 6% of all packages. 
> And when does that percent mark need to be reached? After freeze or at any
> time before a release?

Basically any time. However, we might need to readjust the number. If it
makes you feel better, please read the number above as "a very high
number".


> > When reviewing the past however, m68k as the architecture with the most
> > autobuilders isn't performing too bad regarding the availability of the
> > autobuilders.  So, there is the chance for m68k to get grandfathered in
> > for this clause.  However, we expect that they explain why the higher
> > numbers of buildds they use are not as bad increasing the maintenance
> > overhead.
> 
> I think (and believe that many DDs will agree) that m68k, although being one
> of the slowest archs, is one of the most responsive ports within Debian and
> that having that many buildds is nothing negative at all. 

As I said: We think the m68k port is doing well, and for this reason, we
consider to grandfather it in. But that won't happen without a mail from
one of the porters asking us to do it, and providing some facts why this
is a good idea. :)


> > |

Re: architecture-specific release criteria - requalification needed

[Petter Reinholdtsen]

[Josselin Mouette]
> This has been indeed discussed to death. The result of the
> discussion seems to be that a large majority of the developers
> doesn't agree with all your criteria.

I guess that depends on the viewpoint of the reader what the results
were.  It is hard to tell if there is a vocal minority making a lot of
noise, or if there is a majority disagreeing with the criteria.

Personally, I find the list of requirements sensible, and very
understandable after the clarifying rounds on the lists.  This colors
my view of the discussion.


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

Re: architecture-specific release criteria - requalification needed

[Ingo Juergensmann]

On Wed, Sep 21, 2005 at 03:19:16PM +0200, Petter Reinholdtsen wrote:
> [Ingo Juergensmann]
> > Although it was discussed several times, I have still no idea how those
> > users should be counted? 
> Two ideas.
>  - Get them to install popularity-contest.  This will make their
>machine show up on popcon.debian.org, and we would assume there are
>users of the given machine.  Not very accurate, as machines !=
>individuals.  Easy to fool, but I believe we should assume people
>are honest.

Well, I'm already running popcon on my two m68ks, but that doesn't say much
about how many users are using that machines, as you state yourself. ;)

>  - Set up a wiki page, and get people to put up their name and mail
>address (perhaps slightly obfuscated to make it harder for address
>harwesters), and count the number of names on the page.  When the
>count is reached, send email to all the addresses asking them to
>confirm that the list is correct.  Easy to fool, but I believe we
>should assume people are honest.  If we start to suspect
>non-existing people on the list, we can start asking for GPG
>signatures.
> I would recommend the last option myself, but would like all m68k
> machines to report to popcon.debian.org too. :)

I'm already in the progress of setting up such a webpage... 
I think I can finish it this evening.

> > Is it intended that a user should mail debian-release to say "Hi!
> > I'm using port X!"? I doubt so.
> That is probably not necessary, yes. :)

... and can be faked easily, too. ;)

-- 
Ciao...//Fon: 0381-2744150 
  Ingo   \X/ SIP: [EMAIL PROTECTED]

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc


signature.asc
Description: Digital signature

Re: architecture-specific release criteria - requalification needed

[Josselin Mouette]

Le mardi 20 septembre 2005 à 23:41 +0200, Andreas Barth a écrit :
> For that reason, we discussed in multiple meetings, together with porters,
> ftp-masters and other people more than once how the criteria should
> look.  Also, there was more than one discussion on debian-devel. [1, 2]

This has been indeed discussed to death. The result of the discussion
seems to be that a large majority of the developers doesn't agree with
all your criteria. Why are you trying to force this change regardless of
that? It will only result in resurrecting the neverending discussion on
debian-devel.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: architecture-specific release criteria - requalification needed

[Petter Reinholdtsen]

[Ingo Juergensmann]
> Although it was discussed several times, I have still no idea how those
> users should be counted? 

Two ideas.

 - Get them to install popularity-contest.  This will make their
   machine show up on popcon.debian.org, and we would assume there are
   users of the given machine.  Not very accurate, as machines !=
   individuals.  Easy to fool, but I believe we should assume people
   are honest.

 - Set up a wiki page, and get people to put up their name and mail
   address (perhaps slightly obfuscated to make it harder for address
   harwesters), and count the number of names on the page.  When the
   count is reached, send email to all the addresses asking them to
   confirm that the list is correct.  Easy to fool, but I believe we
   should assume people are honest.  If we start to suspect
   non-existing people on the list, we can start asking for GPG
   signatures.

I would recommend the last option myself, but would like all m68k
machines to report to popcon.debian.org too. :)

> Is it intended that a user should mail debian-release to say "Hi!
> I'm using port X!"? I doubt so.

That is probably not necessary, yes. :)


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

Re: architecture-specific release criteria - requalification needed

[Ingo Juergensmann]

On Tue, Sep 20, 2005 at 11:41:13PM +0200, Andreas Barth wrote:

> Now, looking more into details, the criteria are:
> |  * Availability:
> | The architecture needs to be available for everybody, i.e.
> The reason for this should be obvious

The requirement of "available as new" has been dropped? Good. 

> | it must be available without NDAs and
> Same for this. We're about free software.
> | it must be possible to buy machines on the market.
> The reason should be obvious: Our users should be able to use the
> architecture.

And it doesn't matter if you can buy that piece of hardware in shops or on
ebay? Good.

> |  * Developer availability: The architecture must have a
> |developer-available (i.e. debian.org) machine that contains the
> |usual development chroots (at least stable, testing, unstable).
> This criterion is there so that any developer can actually find out what the
> issue is if his package fails to work on a specific architecture.  Of
> course, when adding a new architecture, there will be a time without a
> stable release, and there will be some special arrangement how such a
> machine can be provided without having even some packages in testing.  But
> that's not meant as a no-go, as long as we are quite optimistic that adding
> the new machine will actually work in time.

Well, for established ports, that shouldn't be a big deal, right?
For new ports this could be a chicken/egg problem, but you mentioned "some
special arrangements", so I guess, that's no problem as well. 

> |  * Users: The architecture needs to prove that developers and users
> |are actually using it. Five Developers needs to certify in that
> |they're actively developing on this architecture, and it needs to
> |be demonstrated that at least 50 users are using the platform. We
> |are counting users, not machines; e.g., one s390-installation
> |with 50,000 users fullfils the user criterion just fine.
> As already discussed multiple times, the "50 users" really means "50
> individuals using that architecture".  Both criteria are there to make
> sure that an architecture gets just enough usage so that
> architecture-specific bugs are found in time.

Although it was discussed several times, I have still no idea how those
users should be counted? 
Who has to show those numbers? The users? The porters?
Is it intended that a user should mail debian-release to say "Hi! I'm using
port X!"? I doubt so. 
So, a little more info is needed, how those numbers are counted. 
Are users just meant to be ordinary users of does that included developers?
Are developers meant to be DDs or are other developers count as well? 
F.e. Roman Zippel on m68k does a lot of development work and even hinted
Wouter Verhelst to a solution for the gcc 4.0 ICE bugs, but he's not a DD. 

> |  * Installer: The architecture must have a working, tested installer.
> Obviously, we need an installer. Though that doesn't say "debian
> installer", we think that our users expect that there are not too many
> different ways for them to install the released version of Debian etch one
> day.

Some obscure bootloader and a tarball of a mini-installation would be fine
as well?

> |  * Porters and Upstream support: There is support by the porters and
> |upstream. This is especially true for the toolchain and the
> |kernel.
> Obviously, we cannot keep a port alive if there is nobody doing support for
> it.  Of course, it is quite possible that Debian and upstream support is
> done by the same persons.  And our experiences with support of gcc-4.0
> on m68k have shown that it is possible to get such issues fixed, if the
> porters are notified in time and are really interested in their port (and
> if there are enough porters).

Uh, well, I hope that slower archs will be given a large time frame to fix
things than faster archs? It would be unfair to give just a week time to fix
a problem, when the recompilation of the package would take 10 days,
wouldn't it? ;)

> |  * Archive coverage: The architecture needs to have successfully
> |compiled the current version of the overwhelming part of the
> |archive, excluding architecture-specific packages.
> Our back-of-the-envelope number for this criterion is 98%.  As pointed
> out multiple times during recent discussions, we don't have a good way
> to measure an architecture's compliance with this yet, but we'll work on
> figuring that out; of course we will exclude hardware-specific packages and
> buggy optional/extra packages with severe portability issues, but
> porters must take responsibility for working with maintainers to fix
> portability issues.

I still believe this definition is far too strict (without being precise).
You can't say, you have to be 98% uptodate without saying what you
understand by "being uptodate". As already outlined during the last
discussion: when all m68k buildds are building package, that can easily be
more than 110 packages marked as building and t