Hello Tobias, [no need to CC me, I'm subscribed] On 25.10.2014 17:12, Tobias Frost wrote: > Hi Markus, > > Am Samstag, den 25.10.2014, 15:57 +0200 schrieb Markus Koschany: [...] >> Pysolfc and Pysolfc-cardsets are both maintained by the Debian Games >> Team. In the past we considered it to be the appropriate way to announce >> the resignation from the team on this list and then ask other team >> members if they want to step up to become the Uploader of the package. >> In case nobody is immediately willing to take care of the package, we >> file a RFA bug report and request an adopter. See [1] for an example. >> The goal is to find more people who want to make a contribution by >> becoming a member of this team. If this is not successful, the package >> can always be orphaned in a subsequent step. > > If this a team-agreement, then it should be documented somewhere. (I > couln't find a reference, if I missed it, please send me pointers) It's not very common that we have to act on resignations. Personally I don't feel that this needs to be documented but it would not hurt if it was. My understanding of resignations from teams is that you just say goodbye, so everyone knows you are leaving, and that you remove yourself from Uploaders. That's it. Bonus points if you wait until all of your packages are either adopted by another team member or when you file a RFA yourself in case you were the only Uploader. > Yes, it makes sense first to see within the team if someone wants to > takes the package. > > However, as new to the team I want to share my thoughts about this > process: Not following the procedure as laid-out in the developer > reference or Policy bears also some problems/dangers/side-effects. For > example if the package is "handled" outside of the team, for example > when NMU'ed: A potential NMU-uploader might actually do a wrong type of > upload (NMU instead of QA, possibly restaining to only important fixes > while leaving minor problems aside...), it might even be a missed > opportunity to get the package adopted. It might even confuse people > "about the right way to go" > Note: no-human-maintainers is not a auto-reject-one. I can't see any downsides to the approach which I have outlined above. The developer reference are guidelines how things should be handled. It does not replace good practice. There is no problem as long as no further upload is necessary and a RFA bug is a good way to request more help for a certain package. In case the package is affected by serious bugs it is time to either fix it through a team effort or NMU and then decide whether it is time to orphan it or become the next uploader of the package. > >> The current package does not violate §3.3 as it fulfills all >> requirements demanded by the Policy. > > You are right: As long as the package is not uploaded, this is no Policy > violation. > However, if you mandate to commit a change remove the only human > uploader, you basically pulling a safety pin out and if the one > uploading the package does not recognize it, you end up being RC. > We had something like that recently: > https://bugs.debian.org/cgi-bin/762551 but luckily Fabian could be > convinced to adopt it additionally. We shouldn't hide that a package is without a human maintainer. What Fabian did was surely the best way. He could have also temporarily added himself to Uploaders and file a RFA or ask on the list for volunteers. If you discover such a case it is always best to discuss it on this mailing list. I skip your last part of the e-mail because I feel this kind of situation does not need to be covered by a lot of rules and paperwork. If others think differently, please speak up. Important to me is: - Say that you leave the team and remove yourself from Uploaders - One or more team members either step up to become the next Uploaders or we file a RFA bug. - If the package gets out of shape and is RC buggy we should fix it and decide whether we want to keep it, orphan it or remove it completely. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature