Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 6:06 PM, Steve Langasek <vorlon@debian.org> wrote:
> On Fri, Oct 26, 2012 at 03:10:30PM -0400, Michael Gilbert wrote:
>> On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote:
>> > On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote:
>> >> I think this is where language is important. In my opinion, the term
>> >> "adoption" will continue to mean taking on full responsibility for a
>> >> package as its new maintainer. The term "salvage", in my opinion, we
>> >> can define as a process for becoming a co-maintainer on a package with
>> >> a long-term possibility of becoming its maintainer.
>
>> > This is an unhelpful redefinition of the term. The term "salvage" was
>> > introduced to *mean* orphaning/adopting a package when the maintainer is no
>> > longer fulfilling their responsibilities.
>
>> Why do we need two different terms defined as the exact same thing?
>> In other words, if both salvaging and orphaning mean the same thing,
>> then what's the point of salvaging?
>
> They don't mean the same thing. Maintainers orphan their own packages;
> adopters adopt orphaned (or RFAed) packages. Salvaging is the process of
> identifying packages that *should* be orphaned in the *absence* of the
> maintainer.
We already orphan packages without the maintainer's consent, and it's
already called "orphaning".
Salvaging is still undefined; until we come to consensus on its
definition. Some vague notion of the idea was started at debconf, and
we should be willing to be open to discussing the best definition that
achieves the most optimum result. If we limit the scope of our
thinking, then we box ourselves into a much smaller and likely less
optimum set of solutions.
So let's keep the term's definition open for debate.
>> In my opinion salvaging (under the above definition) is something that
>> would be able to happen a lot sooner than orphaning because it is
>> initial a co-mainainter process, rather than a maintainer replacement
>> process.
>
> Comaintenance is irrelevant to the question at hand.
Again, co-maintenance is a proposed solution to the question at hand,
so it is quite apropos to the discussion. There is now vast evidence
within the archive that co-maintained packages tend to be much
healthier than strongly maintained ones. This adds an additional
avenue for becoming a co-maintainer while injecting health into often
neglected parts of the archive.
Wrapping up, I'd like to state my concern about how we continue to
allow a certain culture of strong voices to effectively limit the
scope of discussions. This isn't how a meritocracy should work. I've
developed a solution, shown that it works, and now I would like to
document it to make it available to help others as a guide in similar
situations. Criticism from those that haven't demonstrated their own
solutions should fail in a real meritocracy.
Best wishes,
Mike
Reply to: