How *could* we make it more easy to deliver late-breaking deliverables?

Adam Miller maxamillion at fedoraproject.org
Fri Apr 24 15:50:02 UTC 2015


On Thu, Apr 23, 2015 at 7:39 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
<SNIP>

>>> We have a space it is called rawhide. We are working to a place where
>>> thing will be more flexible. But we will likely always say no to
>>> adding things late in the release cycle. people should not be scared
>>> of running rawhide. now if we know that something is coming and is
>>> just not quite ready we can plan for it. The main things needed are
>>> communication, we have extremely limited resources., but a lot more
>>> than we used to have. Longer term it has to be easier to add things,
>>> but just as the route to RHEL is supposed to be Fedora, the route to
>>> being in a Fedora release is rawhide.
>>
>> I think one of the main things is that people expect the accepted,
>> official Fedora Changes to _themselves_ serve as communication to
>> release engineering. I think in an ideal world, that would be very
>> nice, and not just release engineering. Once the changes are accepted
>> by FESCo, everyone would look at them and say "okay, I see this needs
>> to be done, and that's in my area, so I'll make sure that goes on my
>> worklist".
>
> Everyone look at them every time they change? There are days I barely
> get time to read my email! Sorry I don't believe that to be scalable.
>
<SNIP>

I actually agree with this, I don't think it's realistic. We had an
issue with this when I was on the OpenShift Online Team where we had a
Release Ticket that was in the wiki and sometimes people would forget
to check it (either because they were too busy or $other) at certain
points in the release cyclle and it would cause issues. I think with
the breadth of span that Fedora has, this would just be amplified.
What we ended up doing is changing things to use GitHub issue tickets
and have the primaries for the release be tagged on them, this could
be analogous to having trac tickets for items needing attention from
Rel-Eng but I feel that's not really something people want to do since
that's basically what's in place today.

I recently sent an RFC/Proposal email to the Rel-Eng list about using
a kanban-style approach to projects[0] and using a task board with
cards. I was curious if this is something that maybe would be useful
for FESCo also to plan/track Releases on? Then Rel-Eng could be tagged
on cards in the board that need attention, then that could trigger the
discussion about what's needed. This would kind of centralize the
discussion in one place and might help, thoughts?

I proposed the use of Cantas[1] for this purpose and look forward to
general feedback on that thread and here.

-AdamM

[0] - https://lists.fedoraproject.org/pipermail/rel-eng/2015-April/019806.html
[1] - https://github.com/onepiecejs/nodejs-cantas


More information about the rel-eng mailing list