Re: F30 Self-Contained Change proposal: Retire YUM 3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dne 30. 01. 19 v 13:10 Matthew Miller napsal(a):
> 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.
>

I don't dispute anything of this.

But I have always said, and it is exhibited by these cases, that we
should judge the importance of the changes and their impact by the
feedback on ML and not by anything else. If you want to make the change
proposal process less bureaucratic, removing the SC vs SW distinction
would be nice start.

It should work like this:


1) I propose some change I am working on. I should provide some basic
information.

2) The proposal is published on devel{,-announce} and feedback is solicited.

3a) If there is positive feedback, just some clarifications or no
feedback at all, change is automatically accepted.

3b) When the feedback is that this might involve other parties, then
additional information, which ensures all involved parties are informed
and collaborating, should be provided (unless the information is
provided already). FESCo approval might be needed if there is no consensus.


Honestly, if I were in Michal's position, I would be thinking next time
if I should propose the change at all, because if he did it without any
approval, we would live with it anyway. But I hope we don't want to go
in this direction.


Vít

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux