On 01. 04. 20 21:55, Stephen Gallagher wrote:
Well, Change Proposals aren't design documents. I would prefer to
change the document to read more like "This will need to be
implemented in such a way that contents of the ELN repository would be
preferred by the software management tools over the standard Fedora
packages, even when the latter are of a higher version." I prefer not
to put implementation details in places like this; I'd rather describe
the expected behavior and trust that those implementing it will find
an appropriate mechanism.
I get your point, but only to a certain level. It is import to know what we are
approving. See below.
Do you want me to list some of the other approaches we considered and
discarded before we settled on `priority`? I don't think that belongs
in a Change Proposal either, but since apparently we can't get Changes
approved anymore without having the complete implementation
beforehand, I guess we can add that too.
That is not true. However change proposals that have close-to-complete *design*
beforehand are really easier to comprehend and understand. High level "ideas"
change proposals are good for initial discussion, if the change owners will take
the feedback and docuement the design in a more concrete way before FESCo
actually votes about any of this.
* Instead of using `priority`, we*could* opt to provide all of the
ELN content as a large Module. That has overhead problems that make it
not worthwhile.
* We could force all ELN builds to have epoch+100 when they rebuild
(this has problems with future updates).
* We could modify the RPM/libdnf stack to automatically install
different versions of the RPMs based on available hardware. (We don't
have the available resources for another Modularity-level effort.)
As a FESCo member I'd be much more confident to approve a specific design
("we'll use repo cost/priorities to make ELN builds distro-sync over Rawhide
builds with higher evrs") than a goal that might end up like some of the things
listed here by you.
I strongly disagree that a change proposal should only describe the end goal.
What if somebody proposes a change that says "we will make Fedora Server
installation smaller" and goes into great depths about the benefits etc. but
won't actually list the things that will be removed to reduce the installation
size. Would we just discuss the end goal and when everybody agrees that smaller
Server is good, we would approve it?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
