[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: architecture-specific release criteria - requalification needed

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

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

Reply to: