The slip down memory lane

[Thomas Janssen]

On Thu, Aug 12, 2010 at 9:34 PM, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> Le jeudi 12 août 2010 à 13:51 -0500, Jason L Tibbitts III a écrit :
>
>> I guess I'm just saying that, if we had the developer time to do it, it
>> would be super nice if we could get the "pre-F15 rawhide is useless" bit over
>> and done with by the time F15 branches.  But back in reality, I know
>> that's a tough thing to ask for.
>
> Actually, rawhide is not useless and instable most of the year.
> Ironically, it is most instable at branch time when people wake up and
> try to cram as many new features as possible before freeze date (sadly,
> too few start their invasive changes after branch time as they should).
>
> So perhaps the delay between "invasive features autorized" and "alpha"
> is too short.
>
> Another big cause of pre-alpha instability is people who let packages
> rot in rawhide (because it is socially accepted to say rawhide eats
> babies, so why bother), and try to fix them at the last minute and
> branch point when it is way too late to sanely test the changes.

Very well worded. Looking at the daily rawhide report makes me think
that some maintainers need to be "educated" to fix/rebuild stuff
faster.

Since i'm curious, i will collect a list over the next weeks to see
who takes a long time there. Maybe that's good to find out if some
people need help (for whatever reason).

If it's really the late new features that causes slips, "we" could
move the feature freeze to an earlier point (two weeks maybe?). Having
FESCo to reject features not ready at this point with no exception
could help as well. Or maybe with exceptions if the risk of
breakage/slip is low. Probably together with "having an eye on it".
But the latter is most likely a problem due to not enough manpower.

Critpath feature freeze should be anyways a lot earlier than the rest
of the packages/system.

-- 
LG Thomas

Dubium sapientiae initium