On 24. 03. 20 16:23, Aleksandra Fedorova wrote:
I am going to answer generally in this mail, before we dive in into
discussing the details.
I think your approach to assessment of the Change is not fair.
Ouch. It's just that reading the proposal raises all of those questions. Sorry
if that's not fair.
It is an infrastructure change, not a code one. Figuring out all of
the questions you are asking is exactly what this change is about. And
you are requesting that we put the entire solution into the change
proposal. This is not going to work this way. And it shouldn't work
this way.
The way I see it, it, the change proposal currently describes an "idea".
I would like it to describe how things are planned to work (at least an initial
plan for that).
There is a reason why Change Template has Description section and does
not have Design or Implementation. Because design and implementation
are left for the owners of the change as we will figure out the
details on our way to it.
The goal of the Change process is to assess the idea, the impact, to
check whether there is a disruption this change brings, and to find
people who are interested in it. Then we can work on the change
together, working through all those questions you have mentioned.
I wasn't aware that this is the change process goal. Most of the (approved)
changes in Fedora actually describe what's going to happen. Changes that only
describe the end goal are often rejected or significantly amended.
"Change proposals should be shared as early as possible, before the change is
implemented and even in the very early state of the idea, to gather community
feedback and review."
https://docs.fedoraproject.org/en-US/program_management/changes_policy/
This exactly happened here and I am glad it did. But in my opinion, outright
rejecting the feedback is not fair either.
You are asking good questions and I value your feedback. But yes, the
current answer to most of them is "we do not know yet".
For example, even though the structure of the buildroot is proposed in
the releng ticket, and we would like it to inherit rawhide buildroot
at this point, we may want to change it later.
So I'd ask you to split the conversation into two parts:
1) what are the expectation, requirements, impact and risk for this Change
This is what we do need to add into the Change proposal, as it sets
the boundaries in which we should operate.
The main risk I see is that this will generate a need for mass pushing various
conditionals all over Fedora. And while some maintainers like those, some don't.
And I'm afraid this is not fair to them, if we approve this without knowing.
The change should at least describe what level of involvement is required from
other contributors. It it is "no involvement needed" and "we will not bother you
with conditionals" than I see no risk for Fedora (distro) (but I see a huge risk
for the ELN project, because it will be unable to fix itself).
2) how it is going to work
This goes to design docs and implementation. We will definitely take
all comments from the mailing thread into account. As soon as we
figure out the place where we track the effort (most likely, Taiga) we
will transfer it all there. But we would like to postpone making
decisions on those topics. Because things may change while we are
working on them. And it should be ok to change them, as soon as we
keep the boundaries.
I don't see a reason to postpone this discussion. It may affect critical design
decisions. And we have seen in the past that postponing some problems for later
(e.g. upgrade path or switching streams in Modularity) can lead to a serious
design issues that are very hard to fix later.
I think it would be unfair if this Change in fact has a large impact to average
contributors, but we only realize this once they are impacted (and discontented).
So, forgive me for being unfair, but I'd rather be unfair to a Change proposal,
than being unfair to our contributors.
I realize some will consider this "stop energy", but I'm not trying to stop or
fight ELN (in fact, I am quite exited about it) -- I just ask for more
information before we can assess it.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
