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

Re: Architecture qualification



On 05/28/2012 08:57 PM, Andreas Barth wrote:
> * Adam D. Barratt (adam@adam-barratt.org.uk) [120528 14:22]:
>> hurd-i386
>> ---------
>>
>> Is there time to add it to testing and get it out of  
>> {break,fucked}_arches?  Would it make sense to release if it was still  
>> in break_ and/or fucked_arches?
> 
> Depending on the number of issues that pop up, it might still be
> technical possible. However, as a non-linux arch, I have my doubts.
> Also, as soon as we consider it a full release architecture, any bugs
> relevant to only hurd-i386 are considered RC.
> 
> I don't think there is any (technical) harm in adding it to testing as
> long as it's in both break and fuck archs - however, from the feedback
> I got from different people, it might be felt different, so if we add
> it, we need to deliver a very clear message.
> 
> We can't release if it still is in any of break/fucked arches (at
> least that would be my recommendation, due to technical and legal
> issues, e.g. we might need to preserve multiple source code versions
> if we have different binary versions within a stable release).
> 
> All in all, my recommendation for hurd-i386 would be that (as long as
> this is agreed by all involved, and communicated clearly to the
> developers at large before doing it) we add hurd-i386 to testing with
> break/fucked, but we don't expect it to make the release. I.e. bugs
> for hurd-i386 are not RC. We don't do unblocks for hurd-i386. Etc. But
> also I think keeping at as part of proper Debian would be good for the
> open source community at large, so we keep it even after the next
> stable release in testing and unstable.

I don't think it's good to add an architecture to testing now when it's
not going to be released in wheezy. Technically you not only have to
consider the binary packages that will have to filtered out, but also
some source packages that are hurd only. It would also be very confusing
to users and developers and will give them false hope or possibly
distract them of what matters for the upcoming release. I would rather
recommend adding hurd to testing right after the release.

Cheers

Luk


Reply to: