On Sat, 13 May 2006 10:10:58 +1200, Michael J Knox wrote: > >> The over all aim is to avoid "stale" packages in Extras, more swiftly > >> pick up on unmaintained packages and hopefully encourage people to work > >> on these packages by providing a process in which people can fix them. > > > > First of all, I think you mix a few things. Specifically, the NMU talks > > about "fixes", "bugs" and "serious problems", while you talk about > > "stale", "unmaintained" packages and "the take over of a package". Not > > sure whether you want to merge all that into a single policy. > > Possibly, I sort of see them one in the same. The "fixes, bugs and > serious problems" can only apply if the package owner has been contacted > and had no response. Okay. That, of course, is quite different from [and more detailed than] "avoiding stale packages". I just wanted to make sure that the reason for NMU-activity is given in _actual problems_ with a package and not just due to some contributors preferring to engage in a release-race with upstream. Those tickets like "version 1.2.3 is available, please upgrade", which are easily forgotten by packagers, who didn't like a new release when they evaluated/tried it. "Unmaintained packages" was another vague term you used above, which I didn't comment on. _Packages without a maintainer_ (= orphans) can be taken over very "swiftly", because there is no maintainer you need to try to contact. Hence no need for complicated policies in that area. > I see it as more of a taking small steps to ownership on a package where > the original owner is no longer contactable. Right, and where a package is broken. That's exactly where we should start. > > I would appreciate if we started bottom-up with a procedure for "Adoption > > of Packages" and the corresponding tracking of MIA/AWOL maintainers. Then > > we enhance the procedure in order to permit certain actions (like > > requesting (re-)builds, fixing grave bugs) while it is still being waited > > for a response by the maintainer. It will probably, except for security > > issues, look like: > > > > - notify maintainer > > - wait X days > > - notify maintainer about planned take-over and > > planned actions [e.g. (re-)builds, fixes] > > - wait another X-Y days > > - touch the package > > - maybe wait another Z days > > - take over the package in owners.list > > > > Thats exactly what I was meaning. But its important that the "X, Y, Z" > time frames are well known and defined. Let's start with X, maximum packager response time for a bugzilla ticket, in which a serious (or normal) bug was reported. Would X=14 days be too short? X+Y would cover at least two weekends. I mean, if a packager is on a long vacation (several weeks or more) and is neglecting package maintenance knowingly, the package would be suitable for shared maintainership anyway. And in cases where a packager has had an accident or is facing temporary illness (and similar things), we're back at what I've written before -- that it should be in the packager's best interest that other contributors help. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
