On Fri, Jun 24, 2011 at 6:42 PM, Philip Brown <[email protected]> wrote: > On Fri, Jun 24, 2011 at 8:30 AM, Jonathan Craig <[email protected]> wrote: >> On Thu, Jun 23, 2011 at 8:53 PM, Philip Brown <[email protected]> wrote: >>.... > Your reply about motivations, actually aligns with what I'm trying to > highlight. > A person who "just wants to get a package published", and doesnt care > about the finer points of issues... well.. doesnt care. They "just > want to get it published" as quickly as possble, without necessarily > looking at whether it meshes well with opencsw as a whole. > It is beneficial to overall opencsw package quality and consistency, > that someone else, with an objective eye also looks at the package. > >
That the reality of volunteer maintainers. I pay attention to what I have time to pay attention which is not the same as being unconcerned with quality. I'm not just flopping out my own packages, I'm trying to use the tools and documentation to turn out the best package I can. For me better tools that provide "code coverage" and better documentation is what I need. >>> 11. technical implementation issue: >>> >>> "By opening up the QA process such that multiple people can easily >>> participate and have equal standing on the matters at hand, we feel >>> that overall package quality will improve;" >>>[...] >> >>> At the moment, a release manager is guaranteed to at least glance at >>> it. Whereas with the "new process", a package may (and I claim, will >>> *usually*) get released with no-one but the maintainer ever looking at >>> it. >> >> I glance at every release already, then I mark the email "read" unless >> its a package that holds interest to me. > > It seems you are saying that you "look at the pkgsubmissions mailing > list already". > But that is missing the point of what I'm bringing up in this issue. > How many times do you actually look at the package directly? > I would guess very rarely. > Do some experimental math for a moment. > think of how many times you actually look at a package, compared to > how many are released. > Then compare to how many active maintainers we have. We'll charitably > assume that they look at "someone else's package" with the same > frequency that you do. > add up (number of maintainers) * ( number of other packages looked at /year) > Ah, but the reality is that I pay greater attention to list emails that are associated with bug reports. Thats were I really feel I can learn something. Package submissions are only of interest if the package is of interest. When I look at others packages its usually because I'm trying to determine how they've solved a similar packaging issue in the past. > > >> The automated system does allows for more/better QA as indicated >> above. If quality suffers then we can look at this enforcement. > > If no-one is LOOKING at organization-wide quality, then no-one will > realize that quality is suffering. > If you're making the assumption "if something is wrong, someone will > file a bug", unfortunately that is not true. > A package can have very bad bugs,and still no-one may report it for a > long time. Hopefully, some of the other long time maintainers will > back me up on this, if they are reading. > "no bugs filed" does not neccessarily mean "no one wants that > software". It often means "they chose to get it from someplace else, > that works, instead" If you lose your maintainer group because the process of publication is too cumbersome then you end up with no packages. Lack of new and updated packages will drive away customers even faster in my opinion. > > Also, once quality of a "product" suffers below some point... > "customers" tend to go elsewhere. irreversibly. > So an attitude of "well if it makes a mess, we can always fix it > later", can cause harm to the overall popularity of opencsw long term. > I have no reason to believe that the core of maintainers would let things fall that far or the belief that enforced human inspection would prevent it. >>> If on the other hand, the goal is really "to allow packages to be >>> released with no one but the maintainer ever looking at it", then all >>> claims about better QA should be removed from the proposal, and the >>> stated "benefits" of the proposal should be updated to reflect that. >> >> No the goal is to determine the problems and teach an automated system >> to apply this to every package, all the time. > > you say "no" to start, but the rest of your post seems to resonate > strongly with an actual practice of > ([you] just want to get your packaged out there, with automated checks > only, as fast as possible. Without being hindered by 2nd party checks > on it) You seem to continuously ignore the reality that the proposed process allows anyone to review any package and seek corrections prior to publication. IMO, this is a form of intellectual dishonesty. You haven't said it but from your posts I can only assume that if you can't be the "human" in human centric then you have no wish to participate. You can provide the same level of human oversight of the current system in the proposed solution. The only difference is you need to do it as a customer of the package maintainer instead of lord and master. As to human vs automated processes you are ignoring that an automated process can apply the same level of scrutiny to every package regardless of the number submitted. Further, the process of teaching the system to check our packages provides a great deal of insight into how to improve the overall process. Much more so than a single individual eye balling a subset and then one-off resolving problems with a couple of keystrokes. > > If so, fine, that's your opinion and wish. I believe it is the wish of > some other maintainers also. If that's' what the majority of voters > want, so be it. I'm just saying lets be honest about what we're > voting for. Your implying others haven't been honest in their portrayal of the desired solution, while I submit you could be accused of this very thing. I've never said that manual inspection isn't beneficial I'm simply arguing that a subjective inspection by a small group (or one individual) shouldn't be a gate in the production of new packages. Reading your email I've only seen a mild attack on my motives and an empty complaint that the new system inhibits one's ability to critique submitted packages. As to support for status quo vs an automated system I've yet to see any support beyond yourself for the status quo. At some point you will need to come to grips with the proposed change an either embrace it or move on. If you can't be vested in developing a better automated process then I fear you will be marginalized and left in the past. Another victim of progress much like those who once made buggy whips and rail against the noisy new fangled contraptions called cars. Again, do you honestly believe that there is insufficient support for moving forward with an automated approach. Once we determine this direction, and I feel its been determined, the rest can fall into place with all parties vested in achieving the same goal. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
