Sander van Grieken wrote:
> On Wednesday 24 September 2008 23:42:13 Rod Whitby wrote:
>> Sander van Grieken wrote:
>>>> Sander van Grieken wrote:
>>>>>>> That may be, but despite that I need a daily package for kernel I can
>>>>>>> point people to.
>>>>>>> Actually blocking current stable kernel from users by not packaging
>>>>>>> it, which seems to
>>>>>>> be the case, is completely backwards.
>>>>>> That may be the case, and you defintely should be able to point
>>>>>> experienced alpha testers to such isolated packages for testing, but
>>>>>> you don't want inexperienced Joe Random User permanently setting their
>>>>>> opkg feeds to a such a directory, so you don't really want it as part
>>>>>> of the official feeds ...
>>>>> Since it's the _stable_ tree testing should already have been done
>>>>> before merging
>>>> I have no doubt that Andy will have tested the kernel changes.
>>>>>>>> The question is how does that new kernel interoperate with the rest of
>>>> the rootfs. For instance, (and people will remember this one well), are
>>>> the modules packaged correctly into the rootfs. Has the userspace been
>>>> updated to match changing /sys file locations?
>>>>>>>> There's more to keeping a distribution consistent than just testing one
>>>> item in isolation ...
>>> I agree, and that's where sane-srcrevs.conf comes in, because it acts as
>>> a gatekeeper for distribution integration testing.
>>>>>> But the SD card corruption patch (and most others patches) have no impact
>>> on interfaces or integration and could have been pushed out into the
>>> world much earlier. They solve important problems users have.
>> Yes, and sane-srcrevs.inc is the file which needs to be changed by the
>> person who makes the guarantee that it has no impact on interfaces or
>> integration. Then it will appear in the testing feeds automatically.
>> And that person is on holiday?
Well, for the FSO distribution, it could be any person with OE commit
rights who feels they can make that "guarantee" (which is no more a
guarantee than any other developer making a release of software). There
would be at least 5 people I can think of in this position (including
myself).
For the Openmoko git repository, I dunno whether it's just one person or
a number of people who have the responsibility and access to do this.
-- Rod