Re: Package Maintainers Flags policy

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

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [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