Hi Charles, On Thu, Oct 11, 2012 at 06:44:53PM +0900, Charles Plessy wrote: > here are some comments. > > - It would be more straight to the point to submit an "Intend To Salvage" > (ITS) and > focus on such takeovers, because merly orphaning the package does not > guarantee > that it will be actively maintained.
I'm with Lucas on this. Lucas wrote : "That makes the assumption that the requester will be able to salvage the package. I would prefer if we stick to the fact: what's it's about is orphaning the package." I see two activities that can be done by different people. One activity is identifying unmaintained packages. Getting these packages marked as orphaned makes them more visible as needing a new maintainer. The second activity is the salvaging process itself. It already exists : it's adopting the package and bringing the package back in good shape. Anyone interested can choose to contribute on only one or both activities. > > - You may clarify that the bug is to be reported to the package, not to the > wnpp pseudo-package. I agree that this would be a useful clarification. > > - How about requesting that the explanation contains the plans for future > work on > the package ? See above, about the two activities. > > - I am not found of the voting procedure, and would rather propose to follow > a > similar process as for the modification of the Policy and the Developers > Reference, where at least three DDs need to indicate that, in their > conclusion, > a consensus has been reached. I'm OK with following a similar process as for the modification of the Policy and the Developers Reference. > I think that if a package is orphaned with for > instance a 16:3 majority, it indicates a problem rather than a consensus. I agree. Do you suggest to require an unanimous consensus ? That would be OK for me. Actually I would like to get a simple procedure started without too much discussion on which majority would be needed, because I expect that most cases will get unanimous consensus anyway. > Also > if the maintainer opposes, this shows lack of consensus and a vote can only > aggravate the situation. I would allow the maintainer to cancel the ITO simply by closing the ITO bug. (If the maintainer continues to sit on the package without updating it, we can still go to the TC.) > > - For response delay, it think that one month after the bug is opened would > be > a good compromise. I agree. Let's use this. > It also makes the deadline more predictable, as opposed > to voting or counting consensus assessments. We can not use private > information such as vacation flag of the LDAP database in public bug > records, > so we must assume that the maintainer may not be available. This said > perhaps > we can request that DDs must not post ITS on pacakges where the maintainer > has > declared being on vacation in the LDAP ? As I wrote above, I'm OK with following a similar process as for the modification of the Policy and the Developers Reference. That is in fact a form of voting, so I'm confused on the part "as opposed to voting or counting consensus assessments". I would keep the three required seconds from DDs for the ITO (not ITS, see above about the two activities) who can consult the MIA database and the information in LDAP to base their decision on. > > - Lastly, how about an expiration date ? If we all agree on a one-month > delay > for the maintainer's response, we can also use it as an expiration date. > If > within a month there is no reaction of the maintainer, but on the other > hand > the proposer does not manage to attract support or even positive comments, > then > it either signals unwritten problems, or it asks the question whether the > package > should really stay in Debian. I'm OK with adding an expiration date or a maximum duration. What maximum duration do you suggest ? I agree that the expiration would raise the questions you mentioned, to be looked at package per package. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121014072741.ge...@master.debian.org
