| 1 |
On Thu, Jun 15, 2017 at 12:42:33AM +0200, Kristian Fiskerstrand wrote: |
| 2 |
> On 06/14/2017 06:11 PM, William Hubbs wrote: |
| 3 |
> > Is it time to start thinking about an app-containers category? |
| 4 |
> > If so, is it ok for me to start an app-containers category with these |
| 5 |
> > packages then we can look into moving other packages to it? |
| 6 |
> |
| 7 |
> Personally I don't see much value in introducing a new category at this |
| 8 |
> point. Package moves always introduce a certain degree of complexity |
| 9 |
> (e.g requiring maintainers in main tree and other repositories to update |
| 10 |
> dependency specifications), is there really value from introducing this |
| 11 |
> category vs the existing one? in the general case I'd like to see less |
| 12 |
> categories rather than more. |
| 13 |
|
| 14 |
In the main tree, imo, updating the dependencies should be handled by |
| 15 |
the person doing the package move, so it shouldn't affect other |
| 16 |
maintainers. |
| 17 |
|
| 18 |
As far as overlays go, it is true that overlay maintainers might have to |
| 19 |
adjust things, but overlay maintainers are on their own anyway. |
| 20 |
|
| 21 |
I see categories as a way to classify packages. If a category is too |
| 22 |
broad more categories should be created if possible. I can think of two |
| 23 |
other categories in the tree that may be able to be cleaned up in the |
| 24 |
future, but it would mean more categories. |
| 25 |
|
| 26 |
William |
Archives