2011/6/13 Philip Brown <[email protected]>: > 2011/6/13 Maciej Bliziński <[email protected]>: >> 2011/6/11 Philip Brown <[email protected]>: >> >>> (...) >>> If anything, this incident shows *more strongly*, the benefit of >>> having at least 2 humans carefully look at a package before release. >>> >>> The "new system" does not in any way ensure that. >> >> I expect that your position can be described as "the release manager >> position ensures that packages are always examined". > > yes. > > >> Our aim is to build a culture in which peer review is one of the key >> elements. There needs to be an environment which encourages peer >> reviews and makes them easy. >>.... > > you took the time to write a lot of things in your email. Thank you. > However, while the things you wrote were "good", and "true"... they > still did not concretely address the issue :(
I'm still unsure about your use of quotes or scare quotes, when you quote the word good, which of the three you mean: - something somebody else said that you quote here - the literal: g, o, o, d - not good > I think the rest of what you wrote, can be summed up, with a minor > insert, as follows: > >> It is important that the senior members of the project actively >> participate in code and package reviews, serving as a good example to >> more junior members. >> [ So we **hope** that people will review packages] > > This is exactly the problem that I see. > There have been a few people complaining about "lack of consistency" > with the current release process. > But how is a release strategy built around "hope", more consistent???? Let's consider three separate issues: 1. Package review 2. Policy development 3. Policy enforcement The inconsistency that the proposal refers to, and attempts to improve, is in point 3 above. It seems to me that in your paragraph above, you refer to point 1. How would you define consistency in the context of a human examining a svr4 file? >> While this strategy does not claim to "ensure that X number of humans >> will always do Y", it addresses the underlying issue of getting people >> involved in the release process and quality assurance through peer >> review. > > It does not seem like it _adequately_ addresses the issue. > Providing people an optional mechanism to improve quality, does not > mean they will use it. "consistently". > Providing people an optional mechanism to "get involved", does not > mean they *will* get involved. > > Some people.. including *you* Maciej... keep pressing the claims that > everything should be automated, for "consistency". > So why are you not automating a 2nd party validation check? Do you have any specific solution in mind? How would it work? Maciej _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
