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: 2744150@sipgate.de
gpg pubkey: http://www.juergensmann.de/ij/public_key.asc
Attachment:
signature.asc
Description: Digital signature