[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Resigning procdure (Was:Re: Resigning from the team, leaving two packages behind)



Hi Markus,

Am Samstag, den 25.10.2014, 15:57 +0200 schrieb Markus Koschany:
> On 25.10.2014 15:31, Tobias Frost wrote:
> [...]
> > Yes, always sad when someone leaves...
> > 
> > However, please file a orphaning bug as recommended in [1].
> > 
> > If you remove your name from d/control in the repository, the correct
> > procedure is also to set the Maintainer to the QA-Team, as otherwise the
> > package violates the Policy §3.3. 
> > (You can also leave your name there, if you want. The one adopting the
> > package will remove it then (in this case its recommended to file a
> > wishlist-bug against your package))
> > 
> > So, yes, well, thanks for your past contribtions to Debian. Be welcome
> > to come back if you feel so at any time.
> > 
> > --
> > tobi
> > 
> > [1]
> > https://www.debian.org/doc/manuals/developers-reference/developer-duties.html#s3.7
> >>
> 
> 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)

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. 

> 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.

So those are my 2cent. Maybe we can adopt the procedure a little bit to
avoid cases like in 762551 by an process update along with documentating
the process?

Maybe (to have something to dicsuss)
(Pre-Requisite: For the package we talk about: A is the only uploader.)

1) "A" decides to leave -- announing on d-devel-games@ asking for
adoption. 
2) If its okay for "A" not to immediatly remove her name from d/control:
	2a) (Preferable) A files an "RFA:" bug in behalf of the gamespackaging
team, with the invitation to join the team (one with better wording
skills than myself could propose a template :))
	2b) Filing a wishlist bug against the pacakge to remove the name from
Uploaders.
        2c) If noone ITAs it within "timout", retitle to "O:" )
	2c) process end
3) If "A" wants not to have its name in it any longer, (or if A is MIA)
	3a) Someone from the team, preferable "A" files an "O:" bug in
            behalf of the pkg-games team, inviting to join the team (as
above...)IF
	3b) "A" or someone else -- think MIA -- either leaves the repository or
remove the name, but then also make sure that the state of the
repository has the "safetypin" -- means QA-group as maintainer
        3c) Process end

I think, the mailing to wnpp could be actively used to advertise for the
team and maybe to recruit new members!

--
tobi


> Markus
> 
> 
> [1] https://bugs.debian.org/728193
> 
> 

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: