2011/6/25 Maciej Bliziński <[email protected]>: > I've received a complaint for mixing technical and non-technical > issues in one email. Sorry about that. Here's the amended version of > the email. > > 2011/6/13 Philip Brown <[email protected]>: > >> 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?
No manual human process can be perfectly consistent, I grant that. My position is that "A person, or persons, have a specific responsability to at least glance at a package before release; if they dont, a package wont get released" is **more** consistent than "all packages will automatically be released within 2 weeks. Unless someone, maybe, possibly, decides to look at someone else's packages (without any prompting to do so) in that time window, and notices a problem, and files a bug about it" In the first example, it is guaranteed that a 2nd human has at least "touched" the package. guaranteed. that's 100% consistency right there. There is no such guarantee in the new proposal, as it currently stands. >> 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? Since I have had no visibility into the new system, it is rather difficult for me to suggest a "specific" solution. In a more general view, it could work possibly similar to below: * new package drop into "unstable". They are flagged somehow/somewhere as "needs review" * Any motivated maintainer can go look at [the list of packages that "needs review"], and.... (unsure what goes here, exactly. In an ideal-yet-simple world, perhaps click someplace, and have a browsable interface to show layout of files, and optional click-to-view-file interface?) If the maintainer wants to *really* check out details, they would just install it from the "unstable" tree. * if no problems seen, then after looking at above, the 3rd-party maintainer clicks checkbox, "yes looks okay to me". package then gets cleared for migration to "current", after the 2 week period also elapses. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
