2017-01-26 15:28 GMT+01:00 Florian Festi <notificati...@github.com>:
> While I have some sympathy for the idea as such I think just putting
> random stuff in a tags is a bad idea. We should at least force some
> key:value structure. This way someone parsing the tags has a fair chance of
> filtering out the entries of interest without other data littering the
> results.
>
Hm, what do you mean?
The idea isn't for filtering out unwanted entries from appearing in the
tag, but rather for other high end tools to do so.
If concerned about entries of no interest appearing, that's something left
to the tool to rather have whitelists for what tools deemed as interesting
in such a case.
If some packager has added some keyword/meta tag not approved per
distro-policy, then there could be good reasons for it (ie. cross distro
compatible specs), which the package maintainer should be entrusted to
decide, not the release engineer, which I assume is in control of the
fedora comps repository? As the repository only was available through ssh,
I wasn't able to clone it, but I saw 35 forks(!!!!) for this package,
that's a rather fucked up kind of bottleneck if there's 35 active forks
with changes in queue to be pushed to the upstream one.
And the fact that it's behind some ssh only git repos, doesn't really help
drive community participation or adoption of by other distros if they'd
like adopting the comps stuff..
While having key names does not provide guarantee if chosen decentralized
> they lower the risk significantly.only vag
>
Yes, distributing the collective efforts onto package maintainers are much
more sane than removing rather than replacing group tag in packages.
I only vaguely remember from looking at the comps repo a little while ago,
although after making some false assumptions of when posting about it
earlier :p , but I remember there being some icon stuff there as well,
although not the details, would it be considered herecy or perverse to
revive the icon tag for such a purpose, moving this collective
responsibilty into the hands of packagers as well? ;)
PS: The over-eager use of acls for git repos as seen in Fedora, with such
as the example illusterated above is extremely counter-productive and by
taking away community's freedom to easily participating in making changes
directly to all package repositories and various software repositories, you
only create bottlenecks and stunt active community participation in all
aspects of the distribution..
For Mandriva Linux cooker project, the more we opened up, the less of past
control freaks concerns turned out to be of great concern and we ended up
only operating with some rarely use blacklists for a very few individuals
for brief periods, even if given the possibility to commit to repositories
of critical packages, people rarely overstepped boundaries nor dared making
crap changes to stuff they didn't grasp, but could still make packaging
policy related changes etc. to packages, making it a less bureacratic
process of evolving packaging policies and enforce them rapidly etc..
Considering that mandriva linux cooker always only had a mere fragment of
contributors to compare with fedora & debian, nor as many people employed
to work on distro compared to debian/ubuntu|canonical & fedora/redhat, it
still managed to stay just as well maintained (packaging wise, far more
well maintained) than fedora & debian and competive throughout it's
commercial lifetime...
This only made possible by fully empowering the community..
A friendly advice from a veteran of the extint Mandriva SA and the former
Mandriva Linux project... :)
--
Regards,
Per Øyvind
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107#issuecomment-275594389
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
