On 01/09/17 14:36, Cág wrote:
> Timo Teras wrote:
>
>> New aports should start in 'testing'. We don't usually accept
>> direct contributions to 'main' or 'community'. In most cases
>> 'community' will be the right place for package, and I suspect
>> this will be datamash's place when matured. Packages in 'main'
>> are expected to have long maintained stable release branches.
>
> I think that these conditions are vague. When should a testing
> port become a community one and a community one become main?

There is no formal policy as of yet to handle when a package moves
from testing to community. Usually it is after multiple people test
it and see that it is working. Perhaps that will be defined better
after the docs are updated, which is a WIP.

>
> How about splitting ports into categories, so gcc would be
> lang/gcc, vim would be editors/vim and firefox would be
> www/firefox? Those that aren't stable could land in wip, like in
> pkgsrc.
>

Short version: packages fit in to multiple categories. This wouldn't
make sense.

Long version: Speaking from experience having been involved with
multiple systems (Gentoo, FreeBSD, and NetBSD, to name a few), package
categories were always a pain point. Some great examples:

Does OpenSSH belong in security/, net/, admin/, or something else?

Are we going to put every desktop/graphical package under "x11/"? Or
is that just for X.Org and base libraries? Do we add "gnome/",
"kde/", "lxqt/", and so on as categories? Where do packages like
Pidgin go, which are strictly Gtk+ but have integration with both
Gnome and KDE?

Is "www/" for clients like Firefox? Servers like Apache? Both?
Would a user really want to scroll through a bunch of nginx modules to
see what browsers are available?

Also, packages are categorised the way they are to show the level of
support they have. "main" is reserved for packages that have
upstreams committed to maintaining stability, as Timo stated.
"community" is for packages that may not be so stable. This way you
know exactly what you are getting yourself in to (and can even disable
community repo if you really need stability guarantee).

A much better solution to package /discovery/, OTOH, would be to add
tags to the package metadata. Free-form text field, as many as you
want, and we should have a list of ones that we use but allow users to
come up with their own for new types of packages that we may not have
even thought up yet. "Web Browser", "Text Editor: CLI", "Text Editor:
GUI", etc. I'm thinking something akin to PyPI, but haven't fleshed
out the details just yet.