On Mon, Aug 16, 2010 at 09:02:45PM -0400, Max Spevack wrote: > On Mon, 16 Aug 2010, Toshio Kuratomi wrote: > > > Poelcat was asking for examples where the Board interfered with things > > that were rightly in fesco's sphere of influence. > > This got me thinking: > > Let's forget the past for the moment, and worry about the present. How > well articulated is FESCo's *current* spheres of influence? > > http://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee > > "FESCo handles the process of accepting new features, the acceptance of > new packaging sponsors, Special Interest Groups (SIGs) and SIG > Oversight, the packaging process, handling and enforcement of maintainer > issues and other technical matters related to the distribution and its > construction." > > How good is this description? > So... if we go with this... FESCo seems to fit poelcat's view that it's middle management. FESCo isn't expected to be innovative here. They're expected to take care that the routines of creating the distribution are there and no wheels come off in the process. So how good is that description? I don't know -- did the current FESCo members run for FESCo with that understanding of what they were going to do? Despite your expectations, is that what you've ended up doing? I know that I lobied for the Feature Process to be delegated rather than handled directly by FESCo just before my term ended (way back when...) and it seems like this could have been when FESCo became more about keeping things rolling than making things new.... Now a days, the main coders for our applications are in infrastructure, the dist-git rollout was handled by releng (in particular, Jesse), the idea of what updates should go into the distribution was decided by the Board and not fesco.... > Where do things like Infrastructure, QA, Release Engineering, etc. live > in our structure (I use that word purposefully rather than saying > "hierarchy")? > Looking in on these, it seems like they live to the side. Having been on infrastructure, I think that Infrastructure always set itself up as a side group. We're everyone's servant but nobody's slave :-) Other groups can ask us to help them fulfill some need but we really don't get ordered to do anything (except, perhaps, not talk about the Incident which came down from the FPL so not a good indicator of where we stand wrt the Board or FESCo). releng and qa seem to operate on the side as well. Although the question of whether that's the way that FESCo operates or if it's an actual fact, I don't know. > Is there a place where the leaders (either individuals or leadership > committees) of all those different technical sub-sections of Fedora are > able to coordinate and communicate? > > Or is that what the release readiness meetings are used for? If so, is > that sufficient? > I don't think it's sufficient for running Fedora the Project but it may be sufficient for creating Fedora the distribution. I don't think that it's sufficient for being innovative about where our distribution is going -- I think that we sort of use FUDCon for that but not consciously or well. I think the FESCo meetings (in the pre-feature process-approval days) was a place for this type of cross-project coordination to happen... but much less so now. Most of the innovation that's seen there is in the Features and only reported at fesco, not discussed there. > At the end of the year when FESCo members look at each other and say > "what kind of year did we have?" how is that answer determined? > I think I've been too busy taking care of fires to have thought about this. Maybe we should make that an ice breaker at FUDCon hackfests -- Hi, I'm Toshio and this year I think the most important achievement I worked on for Fedora Infrastructure was: _____. -Toshio
Attachment:
pgpPAgIhdLxuU.pgp
Description: PGP signature
_______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board