On 5/16/07, Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote:
/me really wonders if all those people that are discussing here about the drawbacks of the new updates system actually took a look at it
I can't speak for people who have a 100+ packages, and since I've no desire to maintain 100+ packages regardless of the workflow structures, I'm not going to start maintaining 100+ packages just to see if I can substantiate or refute any workflow disruption claims. Regardless of how well any of us eventually learn to conform to the new tool, it is a new tool and it will disrupt workflow. Every policy or tool change disrupts workflow, its just a fact of life. I don't notice the impact of a single change so much because my package maintainership burden is still small enough so that I pretty much assume that package policy/toolsets have changed since the last time I had to do something significant with my packages, so I end up re-reading wikipages every couple of months. Hell a webinterface that walks me through crap is probably going to make it easier for me. The real question is.. can you have a one-size-fits-all interface that caters to low package count,high package count maintainers and everyone in between? I doubt you can. So in an imperfect world, how do we measure how well the new tool decreases or increases the overall workload burden for the entire set of maintainers? What's the mean and the median number of packages per maintainer that we have right now? What is the ideal mean and median number of packagers per maintainer that the tool/policy is designed for? And how do we make sure the infrastructure group gets feedback about the new update system from maintainers in the current/ideal mean/median group? -jef -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly