Let's start salvaging packages!

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Let's start salvaging packages!

Tobias Frost-3
Dear fellow Debinites,

tl;dr: Let's bring the package salvage process discussed some years earlier to
life!

There will be a BoF at DebConf18 Thursday, August 2nd 11:00 in Room Xueshan [a]
for dicussion and fine tuning. (We will likely have video coverage.)

I'm sending out our proposal draft already now so you will be able to
come well-prepared to the to the BoF, as we want to have as much time
as possible for the discussion.

There will be a also a gobby document for the BoF [b].

[a] https://debconf18.debconf.org/talks/149-lets-start-salvaging-packages/
[b] gobby infinote://gobby.debian.org/debconf18/bof/lets-start-salvaging-packages

Why is a salvaging process necessary?
=====================================

Most of the packages within Debian are well maintained and you -- our
maintainers do a tremendous job to keep it that way.  Let me start by
saying a big thanks for that!

However, we have to be honest: we've got also quite some packages which
are not so well cared for. For these packages, unpackaged upstream
versions and unreplied bugs are often seen.  As a result those packages
are not quite up to the quality level our users expect when using
Debian.

I'm not talking about orphaned packages, as we have processes for those,
but about packages that have fallen through the gaps, especially when
the maintainer is otherwise active.

As a project, we do not have effective processes to deal with such
"neglected" packages.

Even if someone shows up wanting to improve such a package, they are
usually not entitled to do so without explicit consent of the current
maintainer, which might be difficult to obtain.

Salvaging Process Proposal
==========================

<proposal>

Salvaging a package
-------------------

Salvaging is the process by which, one attempts to save a package that,
while not officially orphaned, appear poorly maintained or completely
unmaintained.  This is a weaker and faster procedure than orphaning a
package officially through powers of the MIA team.  Salvaging a package
is not meant to replace MIA handling, and in contrast to it, it does not
comment about the overall activity of a maintainer. Instead, it handles
a package maintainership transition for a single package only, leaving
any other package or Debian membership or upload rights (when
applicable) untouched.

Reasons to salvage a package
----------------------------

A package is eligible for salvaging if it is in clear need of some love
and care, i.e. there are open bugs, missing upstream releases, or there
is work needed from a quality-assurance perspective; AND there is the
need to upload the package to deal with these issues; AND at least one
of these criteria applies:

* There is no visible activity regarding the package [c] for /six
  months/, OR

* A previous NMU was not acknowledged, and a bug justifying another NMU
  is pending for /one month/ [c,d], OR

* The last upload was an NMU and there was no maintainer upload within
  /one year/, OR

* Bugs exist for more than one major missing upstream version and the
  first bug is older than /one year/, OR

* The package blocks a sourceful transition for /six months/ after a
  transition bug was filed against the package in question.

Procedure to salvage a package
------------------------------

If the criteria described above are fulfilled, anyone interested can
start the following salvage procedure.

1) A bug with severity "important" against the package in question must
be filed, expressing the intent to take over maintainership of the
package.  The reporter may also offer to only take co-maintenance of the
package.  When filing the bug, all maintainers (incl. Team) and uploaders
should be put explicitly in X-Debuggs-CC.
(Note if the maintainer(s) seems to be generally inactive, it is
also a good idea to inform the MIA team in this step by X-Debbugs-CC'ing
[hidden email] )

2) The maintainer, any current uploader or any member of the associated
packaging team of the package in question may object publicly in
response to the bug filed within 21 days, and this terminates the
salvaging process.

The current maintainers may also agree to the intent to salvage a
package by filing a (signed) public response to the bug. The maintainer
also might offer the reporter co-maintainership instead.  On team
maintained packages, the associated team might also send out an signed
agreement notice to the reporter, inviting him to become Co-Maintainer
of the package if the team believes that this would beneficial for the
package and the the current maintainer does not object to it.  In those
three cases, a new package can be uploaded immediately by the new
(co-)maintainer(s).

3) The upload replacing the former maintainers of the package can be
made can be prepared already after 21 days, but needs to go to
DELAYED/7.  The salvage bug should be closed by the upload and an
nmudiff sent to the bug. The nmudiff should also explictly CC the
maintainer, the packaging team and all uploaders.


[c] Level of activity should be defined in favor of the maintainer if in
doubt.  A maintainer may ask for help or welcome a NMU. This counts as
activity with respect to salvage criteria. If a package lacks uploads,
there is no visible bug triaging, and - if applicable - the source
package's VCS does not show commits this is an indication, that the
package is not well maintained.

[d] A NMU is automatically ACKED if there is a subsequent upload of the
maintainer including the content/fixes of the NMU.

</proposal>

Thoughts behind the proposal.
=============================

The salvaging idea was written by Arno Töll in 2012 [e] and have been
mentioned during the "if you love a package let it go" BoF held by David
Bremner and myself at last years DebConf [f], and the audience at the
BoF suggested that we should give this idea a spin.

I've talked already with several people @DebCamp18 and everyone so far
encouraged me to bring this idea forward.

The idea is to create a procedure based on _clear_ rules defining when
it will be acceptable to salvage a package and bring it back into
maintainance by a new interested contributor -- and when it is not.

The rules should be balanced to protect the interests of the current
maintainer, but on the other hand  they should not make it too hard to
actually take over a package if it is indeed neglected and needs love.

Clear rules are important for several reasons:
  - It will ensure that everyone knows when it is allowed to salvage a
    package.
  - This will lower the (mental) barrier to salvage a package, maybe
    even attracting new contributors. Teams will also be able to recruit
    new contributors.
  - The rules puts an emphasis on communication -- to help avoid
    misunderstandings.
  - The rules will protect the potential contributor (new or otherwise)
    to Debian, to avoid that someone who came to give a helping hand is
    shouted at. As Arno wrote in the original thread:  "I think the most
    important rationale is to get people not to be afraid to take over
    packages anymore, if their intentions are meant well."
  - They also protect a maintainer from finding his packages
    unreasonably hijacked by someone else.

One particularly important issue that could be (partially) addressed by
salvaging is the following.  Outdated dependencies might make it
impossible to update a certain package to the latest version. This is
not only bad because now we have two outdated packages, but also easily
can generated frustration that does even more damage: Lately I was
handling a MIA process where the one being MIA cited exactly this as an
reason why he threw in the towel and ceased activities within Debian.

Another aspect I want to share with you is, during my MIA work, I
noticed that this might help when someone reporting someone MIA is doing
so because they are interested in a package. Currently we must say
"please wait around half a year" even on cases were no one really expects
a response from the former maintainer.  With the proposed process we can
encourage them to take over the package accordingly and have it
maintained well again. Making the reporter wait 1/2 year makes it
unlikely they will take over a package.

The severity of the "intend to salvage" bug is intentionally non-RC.
While RC bugs would have a better visibility, package auto-removals could
kick in and remove the package in question from testing.

If a package is team-maintained, the team should also be able to veto a
request, but should also be able to pave the way for a new
maintainership, but not against the expressed will of the current
maintainer. The team is also encouraged to invite the reporter to join
the team.

[e] https://lists.debian.org/debian-devel/2012/09/msg00654.html
[f] https://gobby.debian.org/export/debconf17/bof/if_you_love_a_package_let_it_go

Why NMUs and MIA aren't the solution.
=====================================

You might say that we have an NMU process and an MIA process for this,
but both are not the silver bullet for this situations.

Granted, the NMU process is great to handle urgent problems, to get a
package in a (frankly, often barely) suitable state for the next
release, but it has severe limitations: New upstream versions are out of
scope, not-as-important-but-still-annoying bugs, etc…

But even if those problems could be fixed by NMUs this is not very
sustainable.  Especially if packages are solely NMU-maintained years
after years, release after release.  As often those NMUs are done by the
very same people I think it is realistic to assume that those would be a
candiate for taking over the package and maybe do so if it would be easy
for them. This would serve for sure also as some appreciation for their
work and also is an nice opportunity to acquire new contributors to the
project.

On the other side, the MIA process is not a package based process. We
only follow up if someone noticed that a person is no longer active.
IOW, People which are mostly taking care of their packages are not in
the scope of the MIA team. Additionally, the MIA process is a lengthy
one. Even if everything looks like that the person is indeed MIA, and
they do reply to our pings at all, it will take *months* until we can
orphan the package.  If the one notifying us is interested in taking
over the package, we have to tell him to come back months later, even if
the package has not been touched for years. (In my experience, telling
someone to wait for so long will likely lead to another opportunity lost
to get it back into maintainance.) On the other hand, even if the MIA
candidate is answering it still happens too often that there will be
lots of well-intentioned words but zero action.

Frequently Asked (Anticipated) Questions
========================================

Q: I'm not convinced that this is a problem. Can you show me some
examples.
A: I tried hard to come up with examples, but I really want to avoid any
impression of finger pointing and it is hard to name specific examples
without that. But I'm pretty sure that you have encountered
sloppiliy/bad/un- maintained packages, maybe even wanted to improve them
but then figured out that this would have been an hijack.

Q: Isn't it _MY_ package, so I can do and not do as I please?
A: Sure, Debian has a tradition of strong ownership of packages, so
traditionally you have the say on the package. This proposal does not
change that, so you can still do anything you want with your package.
But remember that maintaining a packaging also brings responsibilities
it and that means that you want to want the best for it. Actually, I
hope you want the $best, whatever $best is, _for the  Debian project_.

Q: Don't we have the MIA process for this?
A: As I elaborated above already, the MIA process can only help if a
persons disappears completely. The MIA team cannot work on a per-package
basis, because of limited capacity and also because it is out of the
scope of the team.  And especially in cases where the maintainer is
active overall there might be still packages that are deprived of love
and those won't be helped by the MIA procedure.

Q: Don't we have the NMU process for this?
Q: I'm on the LowNMU page.
A: NMU has some really limited scope, it needs to fix at least
"important" bugs and won't really help e.g with new upstream versions.
It will not get a new maintainer on board, which would especially boost
a long neglected package. It is also difficult for new contributors to
get packages NMUed, especially for non-RC bugs.

Q: But I did a new upstream version as NMU?
A: I did that too, and it is possible to do. But then you also need to
be prepared to take the pushback from this and not everyone has the
thick skin required to survive a possible outbreak of a heated
discussion.  IOW, The proposal adds some procedural safety for the
salvager as well. But it also underlines the importance protecting
maintainer from hijacks.

Q: My packages are all team maintained, so this process is unnecessary
as the team will take care of my neglected packages.
A: A team can help to collaboratively maintain packages, but that does
not mean that the team is capable to work on all the team's packages.
But frankly, by just listing a team as maintainer makes it not magically
maintained.

Q: Theres the "LowThresholdAdoption" [g] list. Wouldn't that help?
A: Personally I don't think so: Those on the list are likely already the
people how anyway take good care about their packages but not those
that simply lost interest.

Q: Wouldn't be the ctte another possibilty?
A: The ctte is another possiblity, but as this process is not
lightweight at all, I think it isnot suitable to solve this problem, due
to scalability and because the ctte process is designed to be a
last-resort possiblity. Many people also do not have the time and energy
to deal with a tech ctte bug.

Q: How long will this process take?
A: In total 28 days. After the salvaging bug is filed, the reporter has
to wait 21 days for a reply, and the package must sit for 7 days in
the DELAYED queue.

Q: I like the proposal. How to implement it?
A: Help discussing it. Help implementing it. Come to the BoF.

[g] https://wiki.debian.org/LowThresholdAdoption

Thanks for reading all the text,

--
tobi
with lots of kudos to bremner, spwhitton and lamby for their valuable input and co-editing.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages!

Chris Lamb -2
Dear Tobi,


> There will be a BoF at DebConf18 Thursday, August 2nd 11:00 in Room Xueshan [a]
> for dicussion and fine tuning. (We will likely have video coverage.)
>
> I'm sending out our proposal draft already now so you will be able to
> come well-prepared to the to the BoF, as we want to have as much time
> as possible for the discussion.

Just as a point of order, I would just like to be sure that enough notes get taken at

>
> There will be a also a gobby document for the BoF [b].
>
> [a]
> https://debconf18.debconf.org/talks/149-lets-start-salvaging-packages/
> [b] gobby
> infinote://gobby.debian.org/debconf18/bof/lets-start-salvaging-packages
>
> Why is a salvaging process necessary?
> =====================================
>
> Most of the packages within Debian are well maintained and you -- our
> maintainers do a tremendous job to keep it that way.  Let me start by
> saying a big thanks for that!
>
> However, we have to be honest: we've got also quite some packages which
> are not so well cared for. For these packages, unpackaged upstream
> versions and unreplied bugs are often seen.  As a result those packages
> are not quite up to the quality level our users expect when using
> Debian.
>
> I'm not talking about orphaned packages, as we have processes for those,
> but about packages that have fallen through the gaps, especially when
> the maintainer is otherwise active.
>
> As a project, we do not have effective processes to deal with such
> "neglected" packages.
>
> Even if someone shows up wanting to improve such a package, they are
> usually not entitled to do so without explicit consent of the current
> maintainer, which might be difficult to obtain.
>
> Salvaging Process Proposal
> ==========================
>
> <proposal>
>
> Salvaging a package
> -------------------
>
> Salvaging is the process by which, one attempts to save a package that,
> while not officially orphaned, appear poorly maintained or completely
> unmaintained.  This is a weaker and faster procedure than orphaning a
> package officially through powers of the MIA team.  Salvaging a package
> is not meant to replace MIA handling, and in contrast to it, it does not
> comment about the overall activity of a maintainer. Instead, it handles
> a package maintainership transition for a single package only, leaving
> any other package or Debian membership or upload rights (when
> applicable) untouched.
>
> Reasons to salvage a package
> ----------------------------
>
> A package is eligible for salvaging if it is in clear need of some love
> and care, i.e. there are open bugs, missing upstream releases, or there
> is work needed from a quality-assurance perspective; AND there is the
> need to upload the package to deal with these issues; AND at least one
> of these criteria applies:
>
> * There is no visible activity regarding the package [c] for /six
>   months/, OR
>
> * A previous NMU was not acknowledged, and a bug justifying another NMU
>   is pending for /one month/ [c,d], OR
>
> * The last upload was an NMU and there was no maintainer upload within
>   /one year/, OR
>
> * Bugs exist for more than one major missing upstream version and the
>   first bug is older than /one year/, OR
>
> * The package blocks a sourceful transition for /six months/ after a
>   transition bug was filed against the package in question.
>
> Procedure to salvage a package
> ------------------------------
>
> If the criteria described above are fulfilled, anyone interested can
> start the following salvage procedure.
>
> 1) A bug with severity "important" against the package in question must
> be filed, expressing the intent to take over maintainership of the
> package.  The reporter may also offer to only take co-maintenance of the
> package.  When filing the bug, all maintainers (incl. Team) and uploaders
> should be put explicitly in X-Debuggs-CC.
> (Note if the maintainer(s) seems to be generally inactive, it is
> also a good idea to inform the MIA team in this step by X-Debbugs-CC'ing
> [hidden email] )
>
> 2) The maintainer, any current uploader or any member of the associated
> packaging team of the package in question may object publicly in
> response to the bug filed within 21 days, and this terminates the
> salvaging process.
>
> The current maintainers may also agree to the intent to salvage a
> package by filing a (signed) public response to the bug. The maintainer
> also might offer the reporter co-maintainership instead.  On team
> maintained packages, the associated team might also send out an signed
> agreement notice to the reporter, inviting him to become Co-Maintainer
> of the package if the team believes that this would beneficial for the
> package and the the current maintainer does not object to it.  In those
> three cases, a new package can be uploaded immediately by the new
> (co-)maintainer(s).
>
> 3) The upload replacing the former maintainers of the package can be
> made can be prepared already after 21 days, but needs to go to
> DELAYED/7.  The salvage bug should be closed by the upload and an
> nmudiff sent to the bug. The nmudiff should also explictly CC the
> maintainer, the packaging team and all uploaders.
>
>
> [c] Level of activity should be defined in favor of the maintainer if in
> doubt.  A maintainer may ask for help or welcome a NMU. This counts as
> activity with respect to salvage criteria. If a package lacks uploads,
> there is no visible bug triaging, and - if applicable - the source
> package's VCS does not show commits this is an indication, that the
> package is not well maintained.
>
> [d] A NMU is automatically ACKED if there is a subsequent upload of the
> maintainer including the content/fixes of the NMU.
>
> </proposal>
>
> Thoughts behind the proposal.
> =============================
>
> The salvaging idea was written by Arno Töll in 2012 [e] and have been
> mentioned during the "if you love a package let it go" BoF held by David
> Bremner and myself at last years DebConf [f], and the audience at the
> BoF suggested that we should give this idea a spin.
>
> I've talked already with several people @DebCamp18 and everyone so far
> encouraged me to bring this idea forward.
>
> The idea is to create a procedure based on _clear_ rules defining when
> it will be acceptable to salvage a package and bring it back into
> maintainance by a new interested contributor -- and when it is not.
>
> The rules should be balanced to protect the interests of the current
> maintainer, but on the other hand  they should not make it too hard to
> actually take over a package if it is indeed neglected and needs love.
>
> Clear rules are important for several reasons:
>   - It will ensure that everyone knows when it is allowed to salvage a
>     package.
>   - This will lower the (mental) barrier to salvage a package, maybe
>     even attracting new contributors. Teams will also be able to recruit
>     new contributors.
>   - The rules puts an emphasis on communication -- to help avoid
>     misunderstandings.
>   - The rules will protect the potential contributor (new or otherwise)
>     to Debian, to avoid that someone who came to give a helping hand is
>     shouted at. As Arno wrote in the original thread:  "I think the most
>     important rationale is to get people not to be afraid to take over
>     packages anymore, if their intentions are meant well."
>   - They also protect a maintainer from finding his packages
>     unreasonably hijacked by someone else.
>
> One particularly important issue that could be (partially) addressed by
> salvaging is the following.  Outdated dependencies might make it
> impossible to update a certain package to the latest version. This is
> not only bad because now we have two outdated packages, but also easily
> can generated frustration that does even more damage: Lately I was
> handling a MIA process where the one being MIA cited exactly this as an
> reason why he threw in the towel and ceased activities within Debian.
>
> Another aspect I want to share with you is, during my MIA work, I
> noticed that this might help when someone reporting someone MIA is doing
> so because they are interested in a package. Currently we must say
> "please wait around half a year" even on cases were no one really expects
> a response from the former maintainer.  With the proposed process we can
> encourage them to take over the package accordingly and have it
> maintained well again. Making the reporter wait 1/2 year makes it
> unlikely they will take over a package.
>
> The severity of the "intend to salvage" bug is intentionally non-RC.
> While RC bugs would have a better visibility, package auto-removals could
> kick in and remove the package in question from testing.
>
> If a package is team-maintained, the team should also be able to veto a
> request, but should also be able to pave the way for a new
> maintainership, but not against the expressed will of the current
> maintainer. The team is also encouraged to invite the reporter to join
> the team.
>
> [e] https://lists.debian.org/debian-devel/2012/09/msg00654.html
> [f]
> https://gobby.debian.org/export/debconf17/bof/if_you_love_a_package_let_it_go
>
> Why NMUs and MIA aren't the solution.
> =====================================
>
> You might say that we have an NMU process and an MIA process for this,
> but both are not the silver bullet for this situations.
>
> Granted, the NMU process is great to handle urgent problems, to get a
> package in a (frankly, often barely) suitable state for the next
> release, but it has severe limitations: New upstream versions are out of
> scope, not-as-important-but-still-annoying bugs, etc…
>
> But even if those problems could be fixed by NMUs this is not very
> sustainable.  Especially if packages are solely NMU-maintained years
> after years, release after release.  As often those NMUs are done by the
> very same people I think it is realistic to assume that those would be a
> candiate for taking over the package and maybe do so if it would be easy
> for them. This would serve for sure also as some appreciation for their
> work and also is an nice opportunity to acquire new contributors to the
> project.
>
> On the other side, the MIA process is not a package based process. We
> only follow up if someone noticed that a person is no longer active.
> IOW, People which are mostly taking care of their packages are not in
> the scope of the MIA team. Additionally, the MIA process is a lengthy
> one. Even if everything looks like that the person is indeed MIA, and
> they do reply to our pings at all, it will take *months* until we can
> orphan the package.  If the one notifying us is interested in taking
> over the package, we have to tell him to come back months later, even if
> the package has not been touched for years. (In my experience, telling
> someone to wait for so long will likely lead to another opportunity lost
> to get it back into maintainance.) On the other hand, even if the MIA
> candidate is answering it still happens too often that there will be
> lots of well-intentioned words but zero action.
>
> Frequently Asked (Anticipated) Questions
> ========================================
>
> Q: I'm not convinced that this is a problem. Can you show me some
> examples.
> A: I tried hard to come up with examples, but I really want to avoid any
> impression of finger pointing and it is hard to name specific examples
> without that. But I'm pretty sure that you have encountered
> sloppiliy/bad/un- maintained packages, maybe even wanted to improve them
> but then figured out that this would have been an hijack.
>
> Q: Isn't it _MY_ package, so I can do and not do as I please?
> A: Sure, Debian has a tradition of strong ownership of packages, so
> traditionally you have the say on the package. This proposal does not
> change that, so you can still do anything you want with your package.
> But remember that maintaining a packaging also brings responsibilities
> it and that means that you want to want the best for it. Actually, I
> hope you want the $best, whatever $best is, _for the  Debian project_.
>
> Q: Don't we have the MIA process for this?
> A: As I elaborated above already, the MIA process can only help if a
> persons disappears completely. The MIA team cannot work on a per-package
> basis, because of limited capacity and also because it is out of the
> scope of the team.  And especially in cases where the maintainer is
> active overall there might be still packages that are deprived of love
> and those won't be helped by the MIA procedure.
>
> Q: Don't we have the NMU process for this?
> Q: I'm on the LowNMU page.
> A: NMU has some really limited scope, it needs to fix at least
> "important" bugs and won't really help e.g with new upstream versions.
> It will not get a new maintainer on board, which would especially boost
> a long neglected package. It is also difficult for new contributors to
> get packages NMUed, especially for non-RC bugs.
>
> Q: But I did a new upstream version as NMU?
> A: I did that too, and it is possible to do. But then you also need to
> be prepared to take the pushback from this and not everyone has the
> thick skin required to survive a possible outbreak of a heated
> discussion.  IOW, The proposal adds some procedural safety for the
> salvager as well. But it also underlines the importance protecting
> maintainer from hijacks.
>
> Q: My packages are all team maintained, so this process is unnecessary
> as the team will take care of my neglected packages.
> A: A team can help to collaboratively maintain packages, but that does
> not mean that the team is capable to work on all the team's packages.
> But frankly, by just listing a team as maintainer makes it not magically
> maintained.
>
> Q: Theres the "LowThresholdAdoption" [g] list. Wouldn't that help?
> A: Personally I don't think so: Those on the list are likely already the
> people how anyway take good care about their packages but not those
> that simply lost interest.
>
> Q: Wouldn't be the ctte another possibilty?
> A: The ctte is another possiblity, but as this process is not
> lightweight at all, I think it isnot suitable to solve this problem, due
> to scalability and because the ctte process is designed to be a
> last-resort possiblity. Many people also do not have the time and energy
> to deal with a tech ctte bug.
>
> Q: How long will this process take?
> A: In total 28 days. After the salvaging bug is filed, the reporter has
> to wait 21 days for a reply, and the package must sit for 7 days in
> the DELAYED queue.
>
> Q: I like the proposal. How to implement it?
> A: Help discussing it. Help implementing it. Come to the BoF.
>
> [g] https://wiki.debian.org/LowThresholdAdoption
>
> Thanks for reading all the text,
>
> --
> tobi
> with lots of kudos to bremner, spwhitton and lamby for their valuable
> input and co-editing.
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)


Regards,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] / chris-lamb.co.uk
       `-

Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages!

Chris Lamb -2
In reply to this post by Tobias Frost-3
Dear Tobi,

> There will be a BoF at DebConf18 Thursday, August 2nd 11:00 in Room Xueshan [a]
> for dicussion and fine tuning. (We will likely have video coverage.)
>
> I'm sending out our proposal draft already now so you will be able to
> come well-prepared to the to the BoF, as we want to have as much time
> as possible for the discussion.

Just as a point of order I would like to be 100% sure that enough notes
are taken at the BoF and reposted here so that anyone "only" on debian-
devel will be able to participate in any discussion.

DebConf is obviously a place where a lot of things can get done but
naturally it cannot be the only venue for Project-wide consensus
building. :)

Now, I'm sure this would happen anyway, but just to reassure.


Best wishes,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] / chris-lamb.co.uk
       `-

Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages!

Tobias Frost-3
On Mon, 2018-07-30 at 03:25 +0100, Chris Lamb wrote:

> Dear Tobi,
>
> > There will be a BoF at DebConf18 Thursday, August 2nd 11:00 in Room
> > Xueshan [a]
> > for dicussion and fine tuning. (We will likely have video
> > coverage.)
> >
> > I'm sending out our proposal draft already now so you will be able
> > to
> > come well-prepared to the to the BoF, as we want to have as much
> > time
> > as possible for the discussion.
>
> Just as a point of order I would like to be 100% sure that enough
> notes
> are taken at the BoF and reposted here so that anyone "only" on
> debian-
> devel will be able to participate in any discussion.
>
> DebConf is obviously a place where a lot of things can get done but
> naturally it cannot be the only venue for Project-wide consensus
> building. :)
>
> Now, I'm sure this would happen anyway, but just to reassure.
Rest assured, we'll take plenty of notes on gobby, have video
recordings to revisit* everything then transfer the consensus finding
to -devel.

But just to avoid ambiguity: Use any channel avaible to you to
participate to the discussion! Whether in person, at the BoF, using
gobby, IRC, debian-devel, private email, etc… The important thing is
that the discussion takes place. This is absolutley not limited to
DebConf participants.

* very useful for a non-native English speaker like me ;-)

--
tobi

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages!

Guillem Jover
In reply to this post by Tobias Frost-3
Hi!

I think the proposal sounds very good in general. I just might see a
problem with one of the requirements, which seems open to potential
conflict.

On Sun, 2018-07-29 at 17:40:49 +0800, Tobias Frost wrote:
> Reasons to salvage a package
> ----------------------------

> A package is eligible for salvaging if it is in clear need of some love
> and care, i.e. there are open bugs, missing upstream releases, or there
> is work needed from a quality-assurance perspective; AND there is the
> need to upload the package to deal with these issues; AND at least one
> of these criteria applies:
>
> * There is no visible activity regarding the package [c] for /six
>   months/, OR

[…]

> [c] Level of activity should be defined in favor of the maintainer if in
> doubt.  A maintainer may ask for help or welcome a NMU. This counts as
> activity with respect to salvage criteria. If a package lacks uploads,
> there is no visible bug triaging, and - if applicable - the source
> package's VCS does not show commits this is an indication, that the
> package is not well maintained.

Some packages might not show activity for longish periods of time,
because maintainers batch changes, for example to do at least one
upload per release, with general packaging and QA updates/improvements,
etc.

Also there might be bugs open that are difficutl to fix (with no
patch), etc, that might show no activity for a long time.

So I'd probably qualify the requirement above. I'm not entirely sure
how though. I mean [c] kind of covers it superficially, but I'm not
sure that's clear enough or if the intention was something along these
lines. For example, if there's a difficult bug open, and then a patch
is sent and gets no reply, that could count as inactivity in my book,
but not otherwise.

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages!

David Bremner
Guillem Jover <[hidden email]> writes:

> Some packages might not show activity for longish periods of time,
> because maintainers batch changes, for example to do at least one
> upload per release, with general packaging and QA updates/improvements,
> etc.
>
> Also there might be bugs open that are difficutl to fix (with no
> patch), etc, that might show no activity for a long time.
>
> So I'd probably qualify the requirement above. I'm not entirely sure
> how though. I mean [c] kind of covers it superficially, but I'm not
> sure that's clear enough or if the intention was something along these
> lines. For example, if there's a difficult bug open, and then a patch
> is sent and gets no reply, that could count as inactivity in my book,
> but not otherwise.

Would it be a big hassle for you to reply to a hypothetical salvaging
bug saying essentially what you just wrote, or maybe some short form? As
far as I understand that would be enough to stop any salvaging process.
I agree that it's a bit of busywork for the maintainer, but maybe that
bug could be left open and marked wontfix to avoid too much opening and
closing of bugs.

David

Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages!

gregor herrmann-3
In reply to this post by Tobias Frost-3
On Sun, 29 Jul 2018 17:40:49 +0800, Tobias Frost wrote:

> tl;dr: Let's bring the package salvage process discussed some years earlier to
> life!

Indeed!
Thanks for picking up this topic.
 
> There will be a BoF at DebConf18 Thursday, August 2nd 11:00 in Room Xueshan [a]
> for dicussion and fine tuning. (We will likely have video coverage.)

I won't be there, so just some quick thoughts in advance:
 

> Reasons to salvage a package
> ----------------------------
>
> A package is eligible for salvaging if it is in clear need of some love
> and care, i.e. there are open bugs, missing upstream releases, or there
> is work needed from a quality-assurance perspective; AND there is the
> need to upload the package to deal with these issues; AND at least one
> of these criteria applies:
>
> * There is no visible activity regarding the package [c] for /six
>   months/, OR
>
> * A previous NMU was not acknowledged, and a bug justifying another NMU
>   is pending for /one month/ [c,d], OR
>
> * The last upload was an NMU and there was no maintainer upload within
>   /one year/, OR
>
> * Bugs exist for more than one major missing upstream version and the
>   first bug is older than /one year/, OR
>
> * The package blocks a sourceful transition for /six months/ after a
>   transition bug was filed against the package in question.
I think that's maybe a bit too complicated.
It all makese sense somehow in itself (and I guess I was involved in
coming up with these conditions some years ago) but reading it I have
the impression that I'll never remember it and will have to very
carefully and concentrated re-read it in every case where I might
want to salvage a package and hope that I get the result of several
ANDs and ORs right.
 
> Procedure to salvage a package
> ------------------------------
>
> If the criteria described above are fulfilled, anyone interested can
> start the following salvage procedure.

This looks good in general.
 
> 3) The upload replacing the former maintainers of the package can be
> made can be prepared already after 21 days, but needs to go to
> DELAYED/7.  The salvage bug should be closed by the upload and an
> nmudiff sent to the bug. The nmudiff should also explictly CC the
> maintainer, the packaging team and all uploaders.

Totally minor point: Why the nmudiff?


Another thing that came to my mind is:
The proposal talks (also in the last quoted paragraph) about
"replacing the former maintainers"; what I in practice would like to
do usually is to move a package which is under-maintained and has a
single individuum in Maintainer to a team, with or without keeping
this person in Uploaders. (I've also seen cases where the person is
already a member of the team but maintains (or neglects) packages
outside.)
Maybe this is not relevant as it's covered by "changing the Maintainer
field"; or maybe it is because it allows the future ex-maintainer to
still work on the package, together with others in a team? Or maybe
I'm just making things more complicated when I was asking for simpler
guidelines before :)
 

Thanks again for working on this, and a successful BoF in some hours!


Cheers,
gregor



PS: Some nightly thoughts, not relevant for the BoF per se:


Semi-radical proposal
---------------------

"Salvaging a Package, the simple version"

If a package is apparently un(der)-maintained (e.g. RC bugs without
reply, several NMUs in a row, etc.) it can be salvaged, i.e. the
maintainership transfered to another person or team.

An ITS (Intent to Salvage) bug is raised against the package stating
the intent. If the bug is closed by the maintainer or an uploader,
the process is finished.
Otherwise, after 1 month, the package can be taken over by a new
maintainer person or team.

= Less radical variant =

If a package, which falls into the area of competence of a packaging
team, is apparently un(der)-maintained (e.g. RC bugs without
reply, several NMUs in a row, etc.) it can be salvaged, i.e. the
maintainership transfered to the respective team.

An ITS (Intent to Salvage) bug is raised against the package stating
the intent. If the bug is closed by the maintainer or an uploader,
the process is finished.
Otherwise, after 1 month, the package can be taken over by the team;
the previous maintainer is kept in Uploaders and invited to join the
team and help in the maintenance of the package.



Radical proposal
----------------

Q: What is the worst that could happen if there was no package
ownership in Debian?


--
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Trio Infernal: bottle of wine

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages!

Guillem Jover
In reply to this post by David Bremner
On Wed, 2018-08-01 at 12:42:35 +0800, David Bremner wrote:

> Guillem Jover <[hidden email]> writes:
> > Some packages might not show activity for longish periods of time,
> > because maintainers batch changes, for example to do at least one
> > upload per release, with general packaging and QA updates/improvements,
> > etc.
> >
> > Also there might be bugs open that are difficutl to fix (with no
> > patch), etc, that might show no activity for a long time.
> >
> > So I'd probably qualify the requirement above. I'm not entirely sure
> > how though. I mean [c] kind of covers it superficially, but I'm not
> > sure that's clear enough or if the intention was something along these
> > lines. For example, if there's a difficult bug open, and then a patch
> > is sent and gets no reply, that could count as inactivity in my book,
> > but not otherwise.
>
> Would it be a big hassle for you to reply to a hypothetical salvaging
> bug saying essentially what you just wrote, or maybe some short form?

For me personally, I guess not, mostly because I don't maintain many
packages which follow this pattern. But this was more of a global view
comment, not as how it might affect me.

> As
> far as I understand that would be enough to stop any salvaging process.
> I agree that it's a bit of busywork for the maintainer, but maybe that
> bug could be left open and marked wontfix to avoid too much opening and
> closing of bugs.

I guess the root problem is that everything else in the proposal seems
so concrete and clear-cut, all other conditionals for triggering the
process are very explicit, except for this one, which seems fuzzy and
loop-holey, which gives the impression that in contrast to the other
points there's much room for the initiation process on conditions that
might not be appropriate.

Also while this (dealing with such bugs) might be fine for someone who
maintains few packages, consider, say, something like a huge team, like
perl :), that might batch changes for many packages and perform uploads
just once per release or similar. Also my feeling is that if we have to
keep bugs open as a notice for something that might actually be a normal
pattern, that looks like the conditions are not correct.

In comparison, what gregor proposed (the simple version) in the other
thread, while less explicit, seems apparently more internally consistent
and less loop-holey! Because it just gives some rough guidelines and
delegates to the initiator's good judgement. I'm not sure that's better,
though because in cases like this, where these might be contentious
issues perhaps we'd better be more explicit than implicit, dunno. Hope
that this helps explain the issue I see. :)

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages!

Jonathan Dowland
In reply to this post by Tobias Frost-3
On Mon, Jul 30, 2018 at 12:29:48PM +0800, Tobias Frost wrote:
>Rest assured, we'll take plenty of notes on gobby, have video
>recordings to revisit* everything then transfer the consensus finding
>to -devel.
>
>But just to avoid ambiguity: Use any channel avaible to you to
>participate to the discussion! Whether in person, at the BoF, using
>gobby, IRC, debian-devel, private email, etc… The important thing is
>that the discussion takes place. This is absolutley not limited to
>DebConf participants.

It sounds like, perhaps after/if consensus at DebConf, this would be a
good candidate for the DEP process  dep.debian.net, which hasn't had
much exercise in recent months.



--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages!

Tobias Frost-3
In reply to this post by Tobias Frost-3
Dear all,

The BoF has happened, thanks for your participation and all your
valuable input!

Thanks to the Video Team, the BoF recording is now available at [1], and
the html version of the gobby document can be found by following [2].

I did not yet find the time to condense the input from the BoF, but I
plan to do so in the next few days, but I wanted to share the links with
you already.

Best regards,
--
tobi

[1] https://meetings-archive.debian.net/pub/debian-meetings/2018/DebConf18/2018-08-02/let-s-start-salvaging-packages.webm
[2] https://gobby.debian.org/export/debconf18/bof/lets-start-salvaging-packages

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages!

David Bremner
In reply to this post by Guillem Jover
Guillem Jover <[hidden email]> writes:

>
>> [c] Level of activity should be defined in favor of the maintainer if in
>> doubt.  A maintainer may ask for help or welcome a NMU. This counts as
>> activity with respect to salvage criteria. If a package lacks uploads,
>> there is no visible bug triaging, and - if applicable - the source
>> package's VCS does not show commits this is an indication, that the
>> package is not well maintained.
>
> Some packages might not show activity for longish periods of time,
> because maintainers batch changes, for example to do at least one
> upload per release, with general packaging and QA updates/improvements,
> etc.
>
> Also there might be bugs open that are difficutl to fix (with no
> patch), etc, that might show no activity for a long time.
>
> So I'd probably qualify the requirement above. I'm not entirely sure
> how though. I mean [c] kind of covers it superficially, but I'm not
> sure that's clear enough or if the intention was something along these
> lines. For example, if there's a difficult bug open, and then a patch
> is sent and gets no reply, that could count as inactivity in my book,
> but not otherwise.

At least for me it was clear that replying to bugs counts as activity,
but maybe that was more my preconceptions than the wording of [c]. I
would be fine with replacing/augmenting the wording about bug triaging
to cover all BTS activity related to the package in question. On the
other hand the wording "if in doubt" covers the case you mention.

Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages!

David Bremner
In reply to this post by gregor herrmann-3
gregor herrmann <[hidden email]> writes:

> On Sun, 29 Jul 2018 17:40:49 +0800, Tobias Frost wrote:
>
>> A package is eligible for salvaging if it is in clear need of some love
>> and care, i.e. there are open bugs, missing upstream releases, or there
>> is work needed from a quality-assurance perspective; AND there is the
>> need to upload the package to deal with these issues; AND at least one
>> of these criteria applies:

[...]

>
> I think that's maybe a bit too complicated.
> It all makese sense somehow in itself (and I guess I was involved in
> coming up with these conditions some years ago) but reading it I have
> the impression that I'll never remember it and will have to very
> carefully and concentrated re-read it in every case where I might
> want to salvage a package and hope that I get the result of several
> ANDs and ORs right.

I sympathize with wanting simpler conditions (they did get simpler
during debcamp), and it might be that these can further simplified
without harming anything. On the other hand, at least for me, one of the
main motivations is to make this process accessible to new contributors
to Debian. In this context I think it is much better to explicit, both
to shield would be salvagers from negative reactions and to shield
package maintainers from "unreasonable" [1] salvaging attempts.


[1]: the scare quotes acknowledge that the current discussion is rooted
in the idea of package ownership, and doesn't seek to radically change
that notion.


Reply | Threaded
Open this post in threaded view
|

Let's start salvaging packages -- Summary of the BoF Session.

Tobias Frost-3
In reply to this post by Tobias Frost-3
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages -- Summary of the BoF Session.

Scott Kitterman-5


On August 5, 2018 6:17:12 AM UTC, Tobias Frost <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages -- Summary of the BoF Session.

Tobias Frost-3
On Sun, Aug 05, 2018 at 06:50:28AM +0000, Scott Kitterman wrote:
>
> 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?
>

Yes, the TC has the power to decide ultimately about maintainership when
there is an dispute and if involved parties failed find consesus. The
proposed process does not change that.

As an additional data point, we have processes in place to change
maintainership without involving the TC, e.g the MIA process.

--
tobi

Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages -- Summary of the BoF Session.

Scott Kitterman-5


On August 5, 2018 7:41:41 AM UTC, Tobias Frost <[hidden email]> wrote:

>On Sun, Aug 05, 2018 at 06:50:28AM +0000, Scott Kitterman wrote:
>>
>> 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?
>>
>
>Yes, the TC has the power to decide ultimately about maintainership
>when
>there is an dispute and if involved parties failed find consesus. The
>proposed process does not change that.
>
>As an additional data point, we have processes in place to change
>maintainership without involving the TC, e.g the MIA process.

Yes, that's sort of true, but not really.  The MIA process doesn't actually determine anything about who a maintains a package.  It determines who is no longer active in the project.  The impact on who the maintainer is is a secondary effect of the MIA process.

Package 'salvaging' is about an involuntary change of maintainer involving someone who is sufficiently active in the project not to be MIA.  It's fundamentally different.

I suspect it's constitutionally sufficient for the TC to approve the salvaging process as long as the process allows them to resolve related disputes.  I'm not trying to shoot down the concept, but we need to be mindful of the responsibilities of different roles in the structure of the project as it is established.

Scott K

Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages -- Summary of the BoF Session.

Adam Borowski-3
On Sun, Aug 05, 2018 at 01:20:47PM +0000, Scott Kitterman wrote:
> Package 'salvaging' is about an involuntary change of maintainer involving
> someone who is sufficiently active in the project not to be MIA.  It's
> fundamentally different.
>
> I suspect it's constitutionally sufficient for the TC to approve the
> salvaging process as long as the process allows them to resolve related
> disputes.

But there is _no_ dispute.  All the maintainer has to do is to close the ITS
bug within a month.  Thus, if the bug remains unanswered, there is no one
who would want to dispute the bug.  And not even a temporary incapacitation
is a problem: for an ITS to be filed, you'd need to neglect the package
quite a while, thus the package was effectively unmaintained for much longer
than a month.

Involving the TC is a heavyweight process, and is fit for when there's an
actual disagreement.  A disagreement requires two parties, with ITS one of
them is gone.


Meow!
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages -- Summary of the BoF Session.

Scott Kitterman-5


On August 5, 2018 2:17:04 PM UTC, Adam Borowski <[hidden email]> wrote:

>On Sun, Aug 05, 2018 at 01:20:47PM +0000, Scott Kitterman wrote:
>> Package 'salvaging' is about an involuntary change of maintainer
>involving
>> someone who is sufficiently active in the project not to be MIA.
>It's
>> fundamentally different.
>>
>> I suspect it's constitutionally sufficient for the TC to approve the
>> salvaging process as long as the process allows them to resolve
>related
>> disputes.
>
>But there is _no_ dispute.  All the maintainer has to do is to close
>the ITS
>bug within a month.  Thus, if the bug remains unanswered, there is no
>one
>who would want to dispute the bug.  And not even a temporary
>incapacitation
>is a problem: for an ITS to be filed, you'd need to neglect the package
>quite a while, thus the package was effectively unmaintained for much
>longer
>than a month.
>
>Involving the TC is a heavyweight process, and is fit for when there's
>an
>actual disagreement.  A disagreement requires two parties, with ITS one
>of
>them is gone.

So a maintainer misses one email and anything goes?  

I have packages that look somewhat unmaintained that aren't.  I may seem somewhat oversensitive on this, but I recently discovered a 'maybe we should remove this package' bug on one of my packages that I'd missed the mail when it came in.

TC is also supposed to set technical policy (including "contents of ... developers' reference materials").  I agree that invoking the TC for each salvaging decision is heavyweight, likely excessively so, but that isn't what I am suggesting.  I'm suggesting that they review and approve the salvaging POLICY (once and done, assuming they approve).

Scott K

Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages -- Summary of the BoF Session.

Tobias Frost-3
On Sun, Aug 05, 2018 at 02:47:58PM +0000, Scott Kitterman wrote:

>
>
> On August 5, 2018 2:17:04 PM UTC, Adam Borowski <[hidden email]> wrote:
> >On Sun, Aug 05, 2018 at 01:20:47PM +0000, Scott Kitterman wrote:
> >> Package 'salvaging' is about an involuntary change of maintainer
> >involving
> >> someone who is sufficiently active in the project not to be MIA.
> >It's
> >> fundamentally different.
> >>
> >> I suspect it's constitutionally sufficient for the TC to approve the
> >> salvaging process as long as the process allows them to resolve
> >related
> >> disputes.
> >
> >But there is _no_ dispute.  All the maintainer has to do is to close
> >the ITS
> >bug within a month.  Thus, if the bug remains unanswered, there is no
> >one
> >who would want to dispute the bug.  And not even a temporary
> >incapacitation
> >is a problem: for an ITS to be filed, you'd need to neglect the package
> >quite a while, thus the package was effectively unmaintained for much
> >longer
> >than a month.
> >
> >Involving the TC is a heavyweight process, and is fit for when there's
> >an
> >actual disagreement.  A disagreement requires two parties, with ITS one
> >of
> >them is gone.
>
> So a maintainer misses one email and anything goes?  
No, they needs to miss >2 mails, but in reality more:
- Before the package becomes eligble, it'd have bugs reported against
  it.
- The ITS bug
- The NMUdiff.

(And even then, just talk wich each other; but this is a gerneal life
thing, not really related only to this process here).

> I have packages that look somewhat unmaintained that aren't.  I may
> seem somewhat oversensitive on this, but I recently discovered a
> 'maybe we should remove this package' bug on one of my packages that
> I'd missed the mail when it came in.

> TC is also supposed to set technical policy (including "contents of
> ... developers' reference materials").  I agree that invoking the TC
> for each salvaging decision is heavyweight, likely excessively so, but
> that isn't what I am suggesting.  I'm suggesting that they review and
> approve the salvaging POLICY (once and done, assuming they approve).

David Bremner co-authored the process. Gunnar was present in
the BoF. So, yes, TC members are already (informally) involved in this.

--
tobi

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Let's start salvaging packages -- Summary of the BoF Session.

Niels Thykier
In reply to this post by Scott Kitterman-5
Scott Kitterman:
> [...]
>
> So a maintainer misses one email and anything goes?  
>

The maintainer would get no less than two emails AFAICT:

 * One when the ITS is filed.
 * Another one after 21 days when the maintainer is *explicitly* CC'ed
   on the nmudiff for the NMU (that is required to complete the ITS).
   - *explicitly* is highlighted because it is mentioned directly in the
     proposal that maintainer must be CC'ed at that point.

So you would have to miss at least two emails with one of them being an
nmudiff.

I hope that alleviates your worries with the proposal.

Thanks,
~Niels

123