On Fri, Jul 12, 2013 at 02:17:28PM +0000, "Jóhann B. Guðmundsson" wrote: > On 07/12/2013 12:08 PM, David Tardon wrote: > >>I dont argue that this should be a blocker for architectures quite > >>>the opposite as far as I see it the only requirement for an > >>>architecture to be come a "primary" ( thou arguably those are > >>>outdated concepts as well ) is that all package currently build ( > >>>with the execption if they simply cannot work on a spesific > >>>architecture ) and be available for the community to use as lego > >>>bricks to shape and present to the world as they image in for that > >>>relevant hw. > >It is only a few weeks you argued that we should drop all packages that > >are not "properly maintained". Before that, you wanted to limit the > >number of packages a person can maintain, (by your words) to ensure that > >he (or she) has enough time to maintain them. Now you think it is a good > >idea to add a whole new architecture, which means additional maintenance > >load for_every_ package. Could you try to be at least a bit consistent? > > > I still think... > > We should drop all packages that are not "properly maintained" since > it affect many communities including the hardware architects ones
How? If a package fails to build (on PA), there are several means to resolve it less severe than dropping the package (provenpackagers, unresponsive maintainer process, escalation to FESCo). > since they would have ensure those packages that are not "properly > maintained" would build for their architecture before they would > become an primary architecture. They have to do it for all packages anyway. There is no requirement that a maintainer be able to fix arch-specific build problems himself and upstream might not be interested. > > I would think their time in the project would be better spent on > components that are actively maintained but you apparently dont. I have not said anything like that. I just think your definition of the meaning of actively maintained (or properly maintained) is completely unrealistic. That is why I write it in quotes. > > I still think... > > We should limit the number of packages that individuals can maintain > so that they can effectively maintain them and as has been pointed > out many times with the arm architecture sub community that they are > willing to help with arm specific bugs not general ones bug the ones > but let's assume they don't which results in higher maintenance on > the relevant component which would results in fewer components that > individual could maintain since it would take more if his or her > time to maintain it. Could you try to use some punctuation? It is quite hard to parse your paragraph-long sentences... > > If you dont think maintainers are already overburden and them being > so does not directly affect not only those maintainers directly but > also the community in whole, let's just take Peter Jones for an > example an newly re-elected FESCO member. > > Not only does he not respond to bug reports like [1] Sorry, but that example is unconvincing. AFAIK there is no policy saying that every package must be kept at the newest version at every price. There might be a very good reason why it has not been updated. (Conversely, you have not provided any reason why it should be updated in the bug...) And syslinux is not exactly a key part of the distro. An example: there has been a new release of mdds. I have not updated it in Fedora, because there has been an API change and libreoffice 4.1 does not build with it. By your reasoning this means mdds is not "actively maintained"... Seriously, world is not black and white, even if you are trying to see it that way. > but he also > ignores infrastructures tools [2] that exist for the sole purpose to > notify maintainers about new upstream releases ( and this is just The tool exists to _notify_ maintainers about new releases, not to _force_ them to update. > one of his components which has 18 bugs assigned to it by my account > ) but he thinks he has enough time to serve on fesco at the same > time which requires him to do at least research into at least each > ticket filed in the fesco tracker and review of system wide features > and how ack/nack those features will affect the community in whole. This is disrespectful to Peter. > > Do you honestly think this is healthy for him or for the project in whole? I am not his nanny, so I cannot tell him what is good for him. And I am not in the habit of extrapolating from one accidental sample, > > My solution to address problem like this and prevent "burnouts" in > the project ( although not officially concreted and proposed ) is > that we implement a form of a time share program for the project ( > which arguably should not be limited to package maintenance since > this in essence does affect all participants in the project ) and > maintainers simple sign in how much free time they have or are > willing to spare daily/weekly/monthly in the project and based on > those free hours he or she has, we should be able to calculate how > many components he or she can maintain which could be one if it has > an high maintenance burden or 10, 20 100 with low maintenance. This is completely unrealistic. There is no metric to measure a maintenance cost of a package. And how could anyone know how much time he will be able to spend regularly on the project this week? Next month? Six months from now? The packagers here are _volunteers_. We need to motivate them, not force arbitrary rules on them. > > As more sign up to co-maintain component the more free time do the > existing maintainers get, which they in turn can use to (co ) > maintain another component or spend elsewhere in the project. You have just sketched a perpetuum mobile. > > Implementing something like this would have significantly reduce the > number of components we have available with the increased stability > and not only healthier project but healthier participants as well. This is what you claim, but you have nothing to prove it. I claim that the process you envisioned would result in increasingly disgruntled maintainers and a decrease in the number of users, as Fedora starts to drop packages they use. > > In any case i'm not following how I was somehow being "inconsistent" > with myself with my response I try to restate it, then. On one side: 1. you have proposed to drop packages that fail to meet some arbitrary maintenance standards 2. you have proposed to limit the number of packages a person can maintain, to make sure that maintainers are not overloaded. On other side: A. you are fine with adding a whole new primary architecture, which contradicts point 2/ from the previous list (by increasing maintenance load for _all_ maintainers) B. you propose that the criterium for doing this is that all packages build, which very probably contradicts point 1/ (that something builds does not mean that it _works_ too. And if it does not work, it shifts the responsibility to make it work on its maintainer, which is against point 2/ again). tl;dr: You aim to increase 1/ quality of the package base and 2/ healthiness of the maintainers. Inclusion of ARM as PA immediately decreases both of these. Therefore, by supporting inclusion of ARM as PA, you are contradicting your previous claims. > and if you have any proposal to solve > the previous mentioned problem in the distribution I'm all ears. I do not, because I do not think it is as big a problem as you make it. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
