Hello everyone,
tl;dr: at the BoF the proposal seems to be uncontroversial at the
session. So we will go forward with discussing it and propose a patch
to e.g dev-ref (if we're still aiming for dev-ref then)
Generally, the people at the BoF seemed to be supportive of the
proposal, but a few things needed a bit more of explaining or being more
explicit in wording:
- Team-maintained packages are not special and are covered by this
process.
- dev-ref seems to be an appropriate place for this process.
(similarities to the NMU)
- ITS as an abbreviation for Intend To Salvage seems to stick somehow...
- A clarification of what to be counted as activity on the package would
be useful. Example: If there is a new upstream version bug pending
making it salvageable, a mail to the bug ("I've seen this mail, but I
will not find only time in the next
month" or a "this version is not suitable because of …") is to be
counted as activity and invalidates the eligibility of salvaging.
- Salvaging timings should be balanced, so that (especially) new
contributors can get attracted to salvage packages without being put
off by a too long waiting time, but a (minimum) waiting time ensures
some commitment from them; and we want them to maintain the package
for a prolonged time.
- The time requirements fulfill also another purposes: New contributors
will need guidelines, just to be on the safe side as they cannot tell
otherwise what is acceptable in the project and what not.
- The guidelines will help new contributors to find sponsors more
easily, once the ITS is established (like NMUs are today)
- Sponsorees could use the abbreviation ITS to mark the RFS bug (e.g as
part of the RFS title)
- The process foundation is on "honest" maintainers and not wanting to
harm Debian on purpose. (for which we'd have other kind of processes)
- We're talking about this problem already since a long time. Why has it
not yet implemented? Is this because there are not enough salvageable
packages, not enough people looking for new packages, or people afraid
of doing so because of the traditional strong ownership of packages?
IOW, What is holding us up to adopting this?
One reason for this could be that we do not have at the moment a
process for changing the maintainer of a package, except voluntarily
or via the TC. But on the other hand, if we get only 10 new people one
step into Debian, that'll be a win already.
- Gregor's mail [1], with input from enrico: Vagueness could be a good
thing, and the worst that can happen if someone does a bad call on
salvaging is that an ITS bug gets opened and closed, and something
that was unclear gets documented. The number of months and so on that
are currently in the proposal are still useful to empower a new
maintainer to make the call without fear, and could be put as an
example reference in the wiki, rather than in the dev-ref.
IMHO I'd avoid to remove the explicit rules altogether, as this will
be difficult for new contributors to judge whether it is ok or not (as
said above), but why not open it for the more experienced/thick
skinned who want to take a shortcut? As enrico said: Worst thing that
happens is an ITS opened and shortly closed afterwards when a package
was over-eagerly selected. (I hope this covers also Guillem's
concerns at least partially)
[1] https://lists.debian.org/debian-devel/2018/08/msg00008.html
Next steps:
- All: Please provide feedback.
- Draft the text for the dev-ref patch
-- tobi
Attachment:
signature.asc
Description: PGP signature