On Di Mai 19 2009, Bill Nottingham wrote: > Till Maas (opensource@xxxxxxxxx) said: > > > There is an easier option 3, which is no flags in Fedora period, > > > regardless of what spin. Far easier to implement. > > > > This is not easier for package maintainers who want to maintain a package > > in Fedora that contains flags, because additional work has to be done by > > the package maintainer. Adding some flag to the spec that indicates that > > the package contains political flags is a log easier. > > We carry patches all the time, and if people can't manage to apply patches And in other cases we strictly stick to upstream or push patches to upstream. > And really... it's not about being 'easier for package maintainers'. I'm > really tired of hearing that trope applied any time any sort of policy > is applied or suggested, whether it be: > > - not having flags in packages Not having flags in Fedora is not a technical improvement. Also does having flags in Fedora not stop its existence in its current way, which would happen if it violates US law. > - having actual update notes in bodhi (or even using bodhi at all) I guess there is no majority of packagers that says that actual update notes are bad. But still the process of creating these update notes could be improved to make it easier for packagers. E.g. changes are tracked in three disjunct places, the CVS changelog, the rpm changelog and the bodhi updates notes, which are also disjunct for each Fedora release of the same NVR update in different Fedora releases. Easy workflows will make mistakes less likely and therefore improve the quality of packages or Fedora. With making it easy for package maintainers I do not mean to remove all rules or policies, but to make it as easy as possible to follow to them. And about not using bodhi at all: When bodhi and koji were enrolled, they made package maintainance a lot harder, without these obstacles improving packages. E.g. buildlogs were hidden after a lot more links in koji (and the patch to fix this took several months to be applied) and there was no commandline client for bodhi. > - not pushing new libraries to every release immediately The problem are not new libraries per se, but the problems that they way produce, e.g. broken dependencies. Here it would also help to make it easier for package maintainers to detect these problems to avoid them. > To suggest as prima facie evidence that anything that makes things not > as easy for packagers is bad implies a view where the package maintainer > feels that his needs, his preferred workflow, or his convenience somehow > supercedes the needs of the project itself, or the needs of its users. This is not what I am suggesting. I suggest that if there is anything that can be changed to make Fedora or its packages better, it should be made as easy as possible for packagers to do this. And there were several suggestions to improve this for the flag policy here in this thread. - use a good name for the wiki page - mark packages that use flags in an easier way than to move the flag images to a -flag subpackage - use a yum plugin to make it easier for users to install or not install flags - make the wiki page visible in the wik, mention and link it in the right places Regards Till
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
