On 9/27/10, Dagobert Michelsen <[email protected]> wrote: >... > Right. But in the meantime the submitted package should be > released. It is in package quality not worse than what we have > and better in terms of currentness. [...] it should not be possible to block a > maintainer from releasing a proper working package just > because the release manager thinks that specific issues > done in the past are wrong now or just need more research. > This has caused much frustration in the past.
Yes, it has. However, who says being a maintainer is supposed to be 100% frustration free? :-} > You will > say that a maintainer who is not willing to work with > the release manager to resolve this is not worthy to > be a maintainer. I say the release manager should > not have the power to force a maintainer to change > or investigate these package-specific things. "the release manager" is the only real point of quality control we have. Since packaging is a "volunteer effort", we cannot "force" a maintainer to rebuild a package. If we go with the "release now, argue about it later" methodology, then a maintainer may(and has in the past), simply say, 'well, in that case I dont care to update the package'. We then have a case where we have a package that has been agreed upon as "wrong", but does not get fixed. Maintainers put effort into packages, when they have the time and energy to do so. They have the time, when they are releasing a package. They may NOT have time later on. So in that sense also, I think that package release time in most cases works better for maintainers, since that when they have time and energy on-hand. I recognize that this may be true for some, but not all, maintainers. I welcome suggestions for alternative courses of action, that will result in the packages actually getting updated with agreed upon fixes in a timely manner. I HAVE also been quite flexible with people, who have told me up front, "okay, you might be right; I dont have time to rework the package right now,but I'll commit to rework it at (specific later date)". In those cases, I have gone ahead and released the "better than current, but not perfect" package. Did you want to make that commitment, to follow through on the research, AND rebuild mutt if research justifies it (by a specific date)? In which case, I'll release your current mutt package,and remind you down the road. > Don't get me wrong: I appreciate your (as "Phil") > commitment and care about the packages. However, > [...] You are IMHO misusing > your power as release manager in this case to force > discussion you drive as team member. I'll point out that I am not even "forcing" mutt to be done a certain way. I am only being sticky about the discussion on it. In my opinion, this is *exactly* what a release manager is for. (and I believe it parallels the functionality of release managers in other distributions) _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
