On Wed, 30 Jan 2019 at 07:11, Matthew Miller <mattdm@fedoraproject.org> wrote:
On Wed, Jan 30, 2019 at 11:49:55AM +0100, Vít Ondruch wrote:
> > 1) Move System-Wide and Self-Contained proposal deadlines to be the
> > same date and allow FESCO/etc determine if the proposal needs to be
> > moved to SW or SC then?
> This split between SW and SC was artificial since the beginning and I'd
> be happy if we dropped it.

Well, sure, it's a process we made up. In that sense, _everything_ is
artificial when you get right down to it.

The difference really is supposed to be that self-contained changes are
"FYI" advertisements to the rest of the community and valuable for release
notes, talking points, and other docs -- they don't really need approval
(except when they actually exceed that scope). System-wide changes need
coordination and greater communication, which is why they are supposed to be
earlier.

We could make self-contained changes due earlier and go through the same
greater review process, but then we're gonna get a lot more "ugh Fedora is
so process-heavy and bureaucratic" and people just not doing it at all.


The problem is that people are not really seeing what a 'self-contained' change is and to entirely detail out what it means.. we are also a process-heavy and bureaucratic system. I can see why changing bash or removing yum both look like they are self-contained to the maintainers. I also can see why a lot of people can feel like this was a game to sneak in a change because to them it is clearly not self-contained. I can finally see that we are going to deal with this every release with more and more  band-aids. 

People have been complaining about how process-heavy and bureaucratic Fedora is since we called it fedora.us. I just don't have any patience  for it any more because many of the people who complain regularly and loudly... also complain about every other time someone skips the processes and breaks their stuff. We just need to face that an open distribution with multiple developers that releases continually requires some sort of detailed  process and bureaucracy to keep things flowing. The more developers and the more  packages, the larger the combinatorics that the processes are needed to keep things oiled.


--
Stephen J Smoogen.