On Wed, Nov 24, 2010 at 00:56, Jake Goerzen <[email protected]> wrote:
> On 11/23/2010 4:08 AM, Maciej (Matchek) Blizinski wrote: > >> No dia 20 de Novembro de 2010 19:46, Philip Brown<[email protected]> >> escreveu: >> >>> On Sat, Nov 20, 2010 at 6:26 AM, Maciej (Matchek) Blizinski >>> <[email protected]> wrote: >>> >>>> (Apologies, I hit "send" too early. Here's a proofread version.) >>>> ... >>>> >>>> For example, package consulting is hugely important. Dissecting a >>>> package, analyzing the contents, looking for direct and potential >>>> problems, and providing feedback, is an immensely valuable activity. >>>> >>>> Choosing the option of "no human release manager", is saying exactly >>>>> that. >>>>> (if one presumes that people are choosing that option, with the >>>>> assumption that quality of packages will not suffer as a result) >>>>> >>>> No human release manager means that there is no single person in >>>> power. It does not mean that packages aren't examined by a human. >>>> >>> (I will point out that this is EXACTLY what Peter proposed: no-one >>> other than the maintainer would directly examine them before release, >>> >> Yes and no. No one other than the maintainer would _have_ to directly >> examine packages before putting the package into unstable. However, >> the maintainer could ask another maintainer for a review of his package. >> >> Once the package gets into experimental and/or unstable, anybody who >> uses the package and notices a problem with it, can file a bug against >> the package, saying: "this package does not follow the policy in this >> place." If we then use the bug statistics to gate packages between, >> say, unstable and testing, or testing and stable, everyone can be a >> release manager. >> >> How will they ever get examined by someone other than the maintainer, >>> then? >>> Please propose something that is actually practical, rather than just >>> ideal. >>> In the Real World, how will you ensure that packages are examined "by >>> a human[that is not just the maintainer themselves]" before release to >>> 'current'? >>> >> I think it was about a release to unstable, rather than current. >> You're probably still thinking in the old model, while many people >> already think in terms of staged package catalogs. >> >> I don't think that the goal of providing high quality packages is >> contradictory with the idea of human-free release process. >> >> What you wrote, seems to be contradictory. >>> if there is no human release manager, then there is no human looking >>> at packages before release. >>> >> The term "release" needs to be slightly redefined. Instead of a >> quantum leap from "does not exist in the outer world" to "released to >> everyone", we would have stages that each package undergoes, at each >> stage reaching a slightly wider audience. >> >> perhaps you meant "no SINGLE release manager", but that's not what you >>> wrote :-) >>> >> Yes, it's about many people participating in staged releases. I >> believe that there being a single person with discretionary control >> over releases is not a good thing. >> >> What about the experimental branch? Isn't the experimental branch > exactly what you are getting at? The package maintainer can "release" here > directly themselves and the package is available world wide through the > automatically generated experimental catalog every 5 minutes. In my opinion > having release manager with lots of experience and dedication is a good > thing. > > i'd support this as well. then we have two stages, experimental and current/unstable. broken packages make users look for alternatives - many of them do not like to file bugs. rupert.
_______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
