Wednesday 17 October 2007, Paul Mattal wrote: | 3) Some good criteria for classifying packages in one repo or | another are: | | a) Desire to maintain a package long-term. | b) Association with a particular group of people you trust. well written! | 4) There are many who actually do trust developers more than TUs. | This is not intended as a judgement, rather as an observation. | | My feeling is that we should have under the developer umbrella a | split of the existing [extra] into two repos: | | [main] | [...] | | [extra] | [...] my first thought was: again another repo? my second thought was: again another repo! :) with the [current]->[core] transition, we actually dumped a huge lot of pkgs to [extra] that are more than extra. they are main nodes in dependencies and essential to lots of software around (to take a wild example: libpng). extra had already a broad spectrum of pkgs inside. some falling in the same category mentioned above, others less essential but filling an otherwise big hole in arch. lets take an example: science/openbabel is a "niche" package, that is probably only to some use to people who work with molecule data. but for these people, it is kind of a tool they need like you need vim or gcc on your computer. linux is not only for developers of linux... it is broader. it got broader becuase of the great idea behind it. :) libpng and openbabel are in extra. they are both needed to be maintained by devs. not because they are better than TUs, but because they are official and can be run after, if they miss something. they are not so easy to walk away and the pkg is maintained continuously. the proposed [main] category, or lets say [mantle] (to be around the core - thinking geologically) would include all the pkgs that moved from [current] to [extra] in the first place and in addition will take some of the pkgs from [extra] to it. to a certain ammount i like the distinction - it clarifies things and actually should have been done while doing the current->core business ;) on the other hand, its again breaking backwards compatibility and making another ISO required. the question i am asking with this: can we live with an [extra] that holds also the mantle pkgs that are actually more than extra? or are we going to split extra into two repos? i'm against moving pkgs from extra to community that are for a reason maintained by devs already, except there is reason not to keep them in extra. all the pkgs that seem like niche pkgs may require to be seen as official pkgs of a distro not to everybody but to a certain target group of users. there are some (from my point of view around 6% of pkgs) pkgs in extra that may be removed or moved to community simply because the only reason they are in extra are historical (since earlier there was no such thing as community repos). about orphans: i'm against allowing any official pkg to stay orphan for a log time. besides the bad image we gain with this non-commitment to some pkgs it also is a risk to miss important updates and miss fixing things that should be done and that lots of users depend uppon. ---- i'm however not for any overreaction here, since our web-interface is still missing the assignment of maintainence people for x86_64 as well as missing the multiple assignment of people to one single package. this lots of orphans will get reduced to a big ammount with making our web-interface more modern. then the next step would be to go through all (not yet removed orphans by repo cleanup) and multiple-assign them to people who either want to maintain them or have to, because they are dependences to pkgs they maintain (i like this idea - i assigned myself e.g. to imake since some of the pkgs i maintain depend on a working imake... to take an example). to repeat the question i'm asking here: can we live with an [extra] that holds also the mantle pkgs that are actually more than extra (that were in current)? or are we going to split extra into two repos? - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><