From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id uCIEF9Mj3mRTNQEASxT56A (envelope-from ) for ; Thu, 17 Aug 2023 15:42:43 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 6L+wFdMj3mSHngAAG6o9tA (envelope-from ) for ; Thu, 17 Aug 2023 15:42:43 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id F2FF14A917 for ; Thu, 17 Aug 2023 15:42:42 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=bernoul.li header.s=sel2011a header.b=kfwccHRO; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=reject) header.from=bernoul.li ARC-Seal: i=1; s=key1; d=yhetil.org; t=1692279763; a=rsa-sha256; cv=none; b=S3n8Z+Sznlr4/r0eTDNzAbWbwJLw/x/GHGKOER/io4RN8ppnAGsWSS05+pkYJcsiqRHAJS VGBJf1cyI1whdeV9068tLxrefrGn95B+zd9V14HNy15ivvIszD6uQBMt+ld/pdU6Cq6JTv 61XBY3pBin0fNiXeBpVAy5rHN3nRdEHXUVgGWXFq9n+4iGvng4064GVviITMoH2Z/XTr+P S5Wbni9WaUoRq+wm7Q4NAbYKyN7SPMQoOIpeVW+LRkm7StW0e/b2O3QA+65J9j1vagqXTD AgJ5kv1Ron7hvWh0QqApnV9wq0McBTOemOdDRIJ7RmRm1rAYqaNpW/auEUHd7A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=bernoul.li header.s=sel2011a header.b=kfwccHRO; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=reject) header.from=bernoul.li ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1692279763; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=3oXTSInZg5aJlQolMGcE34FvkTXiko4Bg32xOeVnSIs=; b=Iy8fDB4pOcsc7IKwrNqN9WXDzf+CqX41y7wDUJE++12Dl+YnZfO/lcdh3nFGcYkx2I0YBe m57bksoYL4pPa6zlXhVdv+VoxtIoeQvBfXrmigRRRDuJLJ8ru1uqmd1PtDIIE5GlnCRzfK eknzlY/OnrppxkODZLQL9ZQuyECyGACZk1/VXD3OauDPeBBfdPBJZmusvcg4t7pufXXp54 5EECLtDDniQJ8Ilyd/AqZjKsEIF/DZo9ajSLlOuepoBts6Lr+oxlzOJEymoGz4RK4FiWw2 cgFdC9mkZfMhRwat/RSTdCq8AgRnSMyTXc9LJ4Bx099bPAasBe9Cz6dRGjMuBA== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qWdFt-0006Gh-09; Thu, 17 Aug 2023 09:41:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qWdFq-0006GN-Sq for emacs-orgmode@gnu.org; Thu, 17 Aug 2023 09:41:39 -0400 Received: from mail.hostpark.net ([212.243.197.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qWdFn-0001h0-IV; Thu, 17 Aug 2023 09:41:38 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 7C6BC16261; Thu, 17 Aug 2023 15:41:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from; s=sel2011a; t=1692279691; bh=q5SudYNV/B1vwXS5e3UFxgO0TMDMXuDjOt7JzLQDyIo=; b= kfwccHROnw/oLsPP8xkGQnLI+2cc2PuPVq92kukkGJd8epxGrVVUARmw4LHskPMe z0xZ0spVDT0Aup8h1Ee9LmwB8xwb2ENu/SwJXcntgapIbwjHFPX6shDUQ7pwQNdT BSrJ6xhcmAlhP4j7nBdWYECmt2tlFd64ybQ+DoQYD0w= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id mDwfSQlt7vnA; Thu, 17 Aug 2023 15:41:31 +0200 (CEST) Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 0A15A1625C; Thu, 17 Aug 2023 15:41:30 +0200 (CEST) From: Jonas Bernoulli To: Ihor Radchenko Cc: Bastien , emacs-orgmode@gnu.org, flexibeast@gmail.com Subject: Re: [MAINTENANCE] Org orphanage? In-Reply-To: <87y1i9q2fx.fsf@localhost> References: <874jusk9gg.fsf@localhost> <8735acr2og.fsf@gnu.org> <874ju2dyi9.fsf@localhost> <87wmxv81b6.fsf@bernoul.li> <87y1i9q2fx.fsf@localhost> Date: Thu, 17 Aug 2023 15:41:30 +0200 Message-ID: <87msyphjlh.fsf@bernoul.li> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: F2FF14A917 X-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: -8.72 X-Spam-Score: -8.72 X-TUID: vz8P/A2mpNVy Ihor Radchenko writes: > What about https://github.com/flexibeast/org-vcard and > https://github.com/nikclayton/ob-sql-mode ? Are you saying these packages are unmaintained and asking whether they should be moved to the orphanage? When I feel like that about a package, I usually open an issue on the stale upstream repository and/or send the author an email, introducing them to the orphanage, and offering them to do some light maintenance there. I try to avoid implying that this is the only or best option, pointing out that it might make more sense to give commit access to people who have made valuable contributions in the past. That can go along with creating a new "organization" for that repository, to make it more visible, that this is now a team effort, but keeping the repository under the user account of the original author is also an option. Only when there are no volunteers do I actually prefer moving to the repository to the orphanage. The name of this organization is quite apt: if there are packages in need, we offer to help out, but it is of course always better if they find a new permanent home. > Also, we might want to add org-json and org-redmine to > https://orgmode.org/worg/org-orphanage.html Yes. > I may miss more org-related repositories from emacsorphanage list. As you probably have, I entered "org" and similar terms into the search field at https://github.com/orgs/emacsorphanage/repositories and the packages you just mentioned and the once that are already listed at worg, is all I got. But it is of course possible (though probably not all that likely) that there are a few others in the orphanage that are hiding better. >> IMO it would be a good idea if Bastien and/or Ihor joined the >> emacsorphanage and explicitly added themselves to these packages as >> admins. >> >> I think I would have to make you owners of emacsorphanage to allow you >> to do this and other useful things on your own. I would happily give >> you those rights. You will know better than me who else should get >> write access or even admin rights. But I would ask you to not *delete* >> any repositories before consulting with me. Also, ping me after adding >> a new repository. How does that sound? > > That would make sense, yes. Done (as you know, just a note to others who only read here). As a side-note, the reason I don't want to delete repositories without careful consideration, is that I want to preserve the existing issues and pull-requests. When a package finds a new home outside of github, then we cannot migrate the existing issues there but they are still of value, not least because they are mentioned in commit messages. In the future we might be able to migrate issues and such to other forges; would be a shame if the data were lost by then. (In a sense my Forge package can already be used for this. It stores this data in a local sqlite database, but that is intended for use by a single, local, user. It could be used for disaster recovery, but if the plan is to publish the data, then it isn't the appropriate tool.) Unmaintained packages frequently come up on Melpa, so we have documented how we try to handle that. A lot of what is being said there, also applies when packages in need are brought up elsewhere. https://github.com/melpa/melpa/wiki/Unmaintained-Packages-and-Forks. Note in particular (picking up on a topic mentioned above): > The new maintainer must have experience. E.g. maintains/contributes to > an existing elisp package, has other visible community contributions, > or can be vouched for by such a person. When that is not the case, then it is preferable to move a package to the orphanage, at least initially, and give the volunteer access there. That way we maintain some control; IMO we have an obligation to do that. We already had to make use of that control and revoke access a few times.