Re: Let's start salvaging packages -- Summary of the BoF Session.
On August 5, 2018 6:17:12 AM UTC, Tobias Frost <tobi@debian.org> wrote:
>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
Since it's explicitly in the Debian constitution that the TC is the decider of package maintainership, how does a dev-ref change overcome that?
Scott K
Reply to: