Re: Why keep upstream sources in Git at salsa.d.o?
Le 13/08/2019 à 01:17, Daniel Leidert a écrit : > Am Montag, den 12.08.2019, 19:53 +0200 schrieb Marc Haber: >> On Sun, 11 Aug 2019 15:03:51 +0200, Daniel Leidert >> wrote: >>> Am Sonntag, den 11.08.2019, 01:55 +0800 schrieb Drew Parsons: >>>> Upstreams are starting to use git lfs in their git repos. In some cases >>>> the git-lfs references files are retained in the source tarball, not >>>> replacing the reference with the actual files. This happens for >>>> instance with github repos (I gather it happens because the tarball is >>>> generated with 'git archive' [1]). An example is the mesh files [2] in >>>> pygalmesh 0.4.0 [3]. >>> >>> What I really don't understand is, why we duplicate upstream files (now >>> even >>> really large files) on salsa.d.o. The debian/-only approach (or "overlay" >>> layout in git-buildpackage) works fine. Salsa CI also works just fine. >> >> When I started with mantaining my packages in git, that layout way not >> yet available. Actually, this was my major beef against git since I >> had been using this approach happily with svn und svn-buildpackage for >> years. >> >> I haven't heard that a debian/ only repository layout is possible with >> git-buildpackage before today. > > Works nicely. I keep a file debian/gbp.conf usually with the content > >> [DEFAULT] >> pristine-tar = false >> debian-branch = master # or debian/sid >> verbose = true >> >> [buildpackage] >> overlay = true > > in Git for others; and I use debian/.gitattributes with this content: > >> .gitattributes export-ignore >> salsa-ci.yml export-ignore >> gbp.conf export-ignore > > to keep the Debian package clean. > > The default salsa-ci.yml works very well with this too. We use this layout for > most of our packages in the debichem team. As far as I heard, the KDE team > uses > it too. > > `gbp pq` doesn't work with this layout. > > Regards, Daniel > Hi, I'm curious about keeping only debian/ in git. How to build such git repository ? I've tried one of yours but failed like this: ``` $ gbp clone https://salsa.debian.org/ruby-team/ruby-html-proofer gbp:info: Cloning from 'https://salsa.debian.org/ruby-team/ruby-html-proofer' $ cd ruby-html-proofer/ $ gbp buildpackage "--git-builder=sbuild -v -As -d unstable" \ > --git-export-dir=../build-area gbp:error: upstream/3.11.1 is not a valid treeish ``` I guess I'm missing either a part of git history or just the orig tarball, but what's the normal way to get it ? (maybe there is a doc or wiki somewhere about this ?) -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Re: Consensus Call: Git Packaging Round 1
Le 01/09/2019 à 11:02, Bernd Zeimetz a écrit : > > > On 8/27/19 5:52 PM, Alf Gaida wrote: >> Nicer would be "lowest common nominator" but "stone age" describe the >> process of sending patches via BTS very well. Upps, sorry, not only the >> process, but the BTS also. > > Exactly. Working with the BTS is a waste of time compared to github or > gitlab workflows. I really appreciate to get bug reports and (mainly) > pull requests on my Debian work on salsa or github, as it is much faster > to discuss them and merge when ready. > I find both arguments quite valid: - The BTS is more future proof, stuff on it will probably last longer than whatever is on Salsa currently. There are bugs in the BTS still available to readers from 1996 like #4000. But 20 years old bugs might not be as useful to keep as not so old bugs. I don't know all uses cases that one can have when searching and reading old bugs, one might be to have an answer to "why program X is doing Y". Still, at work I already found me failing to find an answer to that question because of references to a older bug tracker that were not available anymore. - Salsa, more especially gitlab and similar tools, are more intuitive to the user, and the interface allows to organize information on the screen, especially for comments on a specific line of a patch or how one will change bugs metadata (mail with special keywords to control@b.d.o vs graphical buttons, textboxes and semantic highlighting). Maybe there can be a global gitlab hook to send notifications to n...@bugs.debian.org from merge requests that have a "Closes: nnn" somewhere in the description. I don't know much about feasibility of this however. I'm myself ok with the BTS but I have to send sometimes more than one mail to control@b.d.o before having the right action on the bug done (mistyped command, wrong syntax, bad bug status when merging bugs, ...). So it is not as easy to use as a graphical interface. Maybe I should just use command line tools instead of plain mails :) -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Re: Consensus Call: Git Packaging Round 1
Le 01/09/2019 à 19:15, Bernd Zeimetz a écrit : > > > On 9/1/19 6:41 PM, Alexis Murzeau wrote: >> I find both arguments quite valid: >> - The BTS is more future proof, stuff on it will probably last longer >> than whatever is on Salsa currently. > > Why? There is no real reason to remove MRs or bug reports in salsa after > some time. Because BTS is running and keeping history from 1996 at least, and Salsa is far younger than that. It may last for many years more, but given its code complexity (compared to the BTS), it might be replaced by something else later the same way Alioth base on FusionForge got replaced with Salsa with gitlab. ATM, its just a matter of probabilities, but still. In 20 years, maybe the way we work will change again and maybe gitlab will be outdated. But I clearly agree that as of now, gitlab seems to be perfectly good. It's just than stuff appear and disappear rather fast when looking at it on the range of several decades. Gitlab was born just 8 years ago. Gitlab can be forked if needed, but I'm not sure maintaining a fork of Gitlab for Debian own use would be feasible. Maybe we should just accept to leave some bug history behind and move on. Linux got jitterbug, bitkeeper and bugzilla. But on the patch side, it's still just mails but with tools like https://patchwork.kernel.org/. I think many project got the reflection of whether to move to newer tools to handle bugs and/or merge requests. As I see, this is the case, but the response to this largely depends on the context. > > That raises one question: is salsa being indexed by crawlers, at least > bug reports/MRs? Yes it seems ok, I've just searched for "debian salsa merge_requests" and it returned me results with merge requests of various projects. When searching with keywords in the MR, I get merge requests results. But I'm not sure these results are kept if the underlying page disappear. > > >> [] >> I'm myself ok with the BTS but I have to send sometimes more than one >> mail to control@b.d.o before having the right action on the bug done >> (mistyped command, wrong syntax, bad bug status when merging bugs, ...). >> So it is not as easy to use as a graphical interface. >> Maybe I should just use command line tools instead of plain mails :) > > Exactly. It is unnecessary hard for our uses to use the interface. > > From my own experience: since I have my bigger packages (like > open-vm-tools, gpsd...) on github/salsa, I've started to get *a lot* > more pull requests than I got patches in the bts on all of my packages. > Also it is much more easy to review pull/merge requests - I even do it > on the mobile phone sometimes - and merge them if possible. > > I think github and the like got popular because of these tracking features and collaboration tools like forks and pull/merge requests. And also automatic stuff like automatic CI run on every MR, test coverage diff and the like. Not all are applicable to Debian but still. I think this makes contributing easier for many users that don't use mails that much beside administrative/legal stuff. I think that: - easier way to submit bugs (without patch) can cause just more work to maintainers (which might not be really that better in the end if a maintainer is already somewhat busy) - easier way to submit patches can help users help more often maintainers even if a package has not the help flag set. It's just up to the maintainer to accept or not the patch (really, the merge request in gitlab) But as I see by re-reading other mails, is that there are some people that are better with the current way to handle patch (via mail and BTS) and others that prefer merge requests. I'm not sure it's possible for one to convince someone else about that. Letting maintainer allow the merge request feature seems a good way to me to actually "test" if that feature is really good. As a technical tool, maybe a gitlab webhook can help to make people of different though about patch workflow (mail vs MR) work together with less friction. As I said, not sure if this is possible or even that good, it might be just a "spam" tool. But it seems not possible to use a global gitlab instance webhook ATM. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On September 15, 2019 1:20:38 AM GMT+02:00, Scott Kitterman wrote: >> Besides this, there's something else I don't understand. How much >effort >> is it to use a free software based platform? It's not as if Github >was >> so much nicer than Gitlab (at least not anymore). What is it that >people >> hate about Gitlab so much, that they feel like they must use some >> non-free platform, even if they know some of us will hate it? > >I don't know. I don't use GitHub except as needed to support >collaboration >with others that use it. I think that 7% is too large a number just to >assume >there's not a reason. Speaking for myself, I'm currently using github as git repository for streamlink because salsa wasn't there when I started its packaging, and I was already familiar with it. I could have swithed over to salsa before but didn't. For sure, I don't mind about switching now and probably will do. I consider salsa as a comparable alternative to github functionality wise now, with the benefit that the git repo used for package development being internal to debian (in constrast to lost VCS of old packages that got lost) Now that there is salsa, I guess many package could move to it. Maybe a reason to use github, is travis.ci that can be used with github only IIRC. But I'm not using that functionality with debian package repository anymore in my case. Salsa gitlab's CI can be an alternative but for me debci is sufficient. and I run sbuild before pushing/releasing a version. -- Alexis Murzeau
Re: 64-bit time_t transition for 32-bit archs: a proposal
Hi, On 06/06/2023 12:45, Simon McVittie wrote: 2. i386 as a multiarch foreign architecture to run legacy binaries on modern x86_64 systems 2a. legacy native Linux i386 binaries 2b. legacy Windows i386 binaries via Wine (which requires a somewhat complete i386 Linux library stack) Windows already uses 64 bits time_t on i386 since Visual Studio 2005, unless _USE_32BIT_TIME_T is defined ([msvcrt-time]), and even if it is defined, Wine implementation of 32 bits time() will not use Linux' time_t. So I'm not sure Windows i386 binaries will be affected by a Linux-side change of time_t, unless you think about something else. For the same reason, this line in the wiki [wiki] may not be true: 32-bit wine (i386 only). This does not make much sense with 64-bit time. It's whole purpose is to run old i386-ABI binaries. The ABI for this arch (and thus wine-32) should not change. Also, as said in this interesting Wine-devel thread about i386 [wine-devel-32bits]: Many 64-bit applications still use either a 32-bit installer or some 32-bit components. In comparison 64-bit Windows will support 32-bit (probably) forever. And even if newer Wine versions supports WoW (32 bits Windows on 64 bits within the same Wine prefix), 64 bit Wine still require 32 bits Linux libraries to run 32 bits Windows programs. This means that Wine will probably require 32 bits Linux libraries for probably a long time and not only for legacy Windows binaries. [msvcrt-time] - https://sources.debian.org/src/wine/8.0~repack-4/include/msvcrt/time.h/#L92 - https://sources.debian.org/src/wine/8.0~repack-4/dlls/msvcrt/time.c/#L781 [wiki] https://wiki.debian.org/ReleaseGoals/64bit-time [wine-devel-32bits] https://www.winehq.org/pipermail/wine-devel/2019-June/147869.html -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F| OpenPGP_signature Description: OpenPGP digital signature
Re: CITL Releasing 7000 defects/vulnerabilities
Hi,
Le 01/11/2020 à 14:14, Ole Streicher a écrit :
> Hi all,
>
> I just stumbled upon the following web page:
>
> https://cyber-itl.org/2020/10/28/citl-7000-defects.html
>
> They claim to have found ~7000 defects in Ubuntu packages (a number of
> those are maintained by me).
>
> Does anyone have more information about this? Or did I miss a discussion
> here about this?
I don't have any information about this, but maybe try to contact them as
written
on their website:
- quote -
How do I get in touch to get the information?
cont...@cyber-itl.org
Subject: APT-REPOSITORY DEFECT REQUEST for ${XXX}
Please include your return e-mail and some way that easily shows you are
associated with the package. We will then respond with reproduction
information, tools and data that might be needed to identify the defects.
-- end quote -----
>
> Best
>
> Ole
>
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F|
signature.asc
Description: OpenPGP digital signature
Re: Salsa OIDC logins for debtags.debian.org
Hi, Le 10/01/2021 à 22:45, Enrico Zini a écrit : > Hello, > > I've enabled Salsa OIDC logins for debtags.debian.org. Thanks, I could login with Salsa and set debtags for my package :) -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F| signature.asc Description: OpenPGP digital signature
Re: Making Debian available
Hi, Le 12/01/2021 à 17:14, Sven Joachim a écrit : > On 2021-01-12 16:36 +0100, Geert Stappers wrote: > >> On Tue, Jan 12, 2021 at 02:48:22PM +, Dan Pal wrote: >>> Hello Debian Developers, >> >> Hello World, >> >> >>> I am writing to you from my Debian-Buster 10.6 laptop – that used >>> to be a Windows 10 laptop. I would not be using Debian at all except I >>> was able to find a dvd version at debian.org to install. I couldn’t >>> install from a net install version because of my wireless chipset not >>> being supported directly by Debian. The current policy of hiding other >>> versions of Debian is limiting the adoption of your OS by people like >>> me who are interested in moving from Windows 10. >> >> Seen the "I think it could be better", not yet seen the "how" >> >> >> Please elaborate the improvement. > > Provide a way to discover the working netinst with non-free firmware, > right now it seems to be impossible to find. > > The official netinst image advertised on the homepage is for servers and > virtual machines only. How is an average user of Windows or even other > GNU/Linux distributions supposed to know that official Debian images do > not offer network access during installation on desktops and laptops? > > Cheers, >Sven > Maybe by adding a "Other" link under the big Download link pointing to other places ? For example see attachment with "Other architectures and options" linking to: https://www.debian.org/distrib/ And maybe add a link from https://www.debian.org/distrib/ to images with non-free firmwares -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F|
Re: Making Debian available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, For reference, in fact both subjects appeared in the past as #bugs: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=www.debian.org;dist=unstable#_0_0_3 document/link to non official images including non-free firmware: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607193 Re-organise the CD / download pages to make them more useful: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819664 - -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F| -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEylfM0qe98o7UCRlrC5n5Lou0ZU0FAl/+A+sACgkQC5n5Lou0 ZU1OyhAAxrKmy9EfSPc6yPXD2+Mx90QEJP3jWm0ZcW109ffe6kUfy4j7mwKambf3 E/vw5RvLu9lEKk5/y3fznLINKbejWCqepHkwnPr7qPU+q9zN4E6y9GnvEX9ZU9/4 AFy+nkFIArBkUPbFervBeq53IkTjVFHCAoH4ouzMuEnDeVi7h+hSXpbju3vv7wKv BzPIW+3UPTLk3TY1dgB+9cAdcjCVtrHV1dTNU4nIMB6XMNZmtsxmCHuplDBJQ81t 9TXHgglhabqEsxgc+bkg989uAeC2CmxE+UVzN52YbAHMO0jhzcDU/4ToPhRcpoRb 1D3nEHUimRhxJ2G9LtGUqIuplLfI7UjValTZaalRt3lgaYdG4Ya+aBA9ZqlXv6ux SsY8AUCj6JVIyu2Ghkrh91D35PDaUdJ87DSfz8Bo5axcH8OoPwKvYn1Op8LcR+HR vkG2voXMjMlj/KnU8SZVS4k/W3cVkeRo8RKwkGJHSsblLe10yH+eKeWG580n0wgx PnHxDX7UVV3n5TGbsq5dCa8rVpsdQSojDpiGf+6sltzGEAfqmFSQcsQL9Blzlj9Z NEwo/yOFRrDx5uf9sWzktMPRnAZCvCCTQqjQGHANdAWi74aAyyrb0yFSsvt4qIIo s0mmgR0yrT348m/z1RPEnJ2136wUZSkP2KMjJatJhe+f1vETOdk= =wFnA -END PGP SIGNATURE-
Re: Making Debian available
Le 24/01/2021 à 22:11, Fabrice BAUZAC-STEHLY a écrit : > Kudos for your very fine summary, Bjørn! > > I don't know if the proposal to place non-free things into the Debian > installation image will be accepted. But if it is not, here is another > proposal that would clearly separate the free from the non-free: > > The installation image remains 100% free. But at some point the > installer asks the user if they wish to add another media containing > software. Users would then be able to put another CD or USB key (for > example) containing a bundle of non-free drivers. > > Bundles of non-free drivers would be generated regularly and provided on > a webpage which clearly indicates the downsides of having non-free > software installed. But it could give a clear tutorial on how to copy > the bundle to a USB key and how to tell the debian-installer to use it. > In fact, I think this already exists as stated here: https://www.debian.org/releases/stable/amd64/ch06s04.en.html But the issue is probably just to make it more easy to find for users. The OP just said: > I couldn’t install from a net install version because of my wireless > chipset not being supported directly by Debian. > The current policy of hiding other versions of Debian is limiting the > adoption of your OS by people like me who are interested in moving from > Windows 10. It seems all the information and required files to install Debian on any computer already exists, but is just too hard to find when the user is trying Debian for the first time. To me, proposals from Holger Wansing are a step to the right direction: For example (from "Re: Making Debian available - patch for webwml" thread): https://people.debian.org/~holgerw/webwml_non-free-firmware/english/distrib/index.en.html The added information at the end of the page shows were to find bundle of non-free firmwares (to put on a dedicated storage for use with free netinst) and also unofficial installer files bundling these non-free firmware. I personally think the main page could have also have a "Other downloads" link to one of the more complete download pages (like /distrib), so users not familiar with the wiki can find it one click away. Maybe I can propose a patch for at least this small link to /distrib -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F| signature.asc Description: OpenPGP digital signature
Re: Fixed release dates are hurting quality
Le 07/02/2021 à 19:27, Russ Allbery a écrit : > The more interesting question is what if there simply isn't resources to > adopt them and maintain them properly. In that case, are we better off > with them, or without them? > > I don't think this answer is obvious, but I would lean towards saying > we're better off with them. > The recent re-upload of xserver-xorg-video-* drivers is a good example of (maybe) unmaintained but useful packages. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955603 Several xserver-xorg-video-* (like xserver-xorg-video-r128) were removed by this bug because: > They are either unmaintained upstream or provide no value to the > distribution. But were still being useful for users as shown by these comments on #955603: > Please keep these drivers. They work as just fine, and many people > still use them. They have not been dropped by upstream X.org, and there > is no reason to drop them from Debian. Without these drivers, it will > make running Debian desktop on this hardware impossible. One of the > things that makes Debian great is the backward compatibility. It's very > sad to see destructive actions like this being taken. Please don't just > throw away all the work that people have put into these drivers over > the years, and please don't orphan their users! Another comment: > those modules are STILL IN RECENT SERVERS like r128 (rage) and > openchrome via boards > > proliant hp and DELL ones! These drivers were reintroduced last friday. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F| signature.asc Description: OpenPGP digital signature
How to receive a mail on new upstream version
Hi, Is there a way to receive a mail when a new upstream version is released ? I've subscribed to my package on https://tracker.debian.org but I don't receive mails for new upstream releases. Maybe there is other ways ? -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F| signature.asc Description: OpenPGP digital signature
Re: releasing major library change to unstable without coordination
Hi, Le 23/12/2021 à 14:51, Stéphane Blondon a écrit : > Le jeu. 23 déc. 2021 à 01:25, Sandro Tosi a écrit : > >>> rebuild 500 packages takes hardware resources not >> every dd is expected to have at hand (or pay for, like a cloud >> account), so until there's a ratt-as-as-service >> (https://github.com/Debian/ratt) kinda solution available to every DD > > > If providing an easy way to rebuild the reverse depencies by DD could solve > the problem, what blocks us to do it? We could spawn container including > ratt ; the DD uploads the new package ; rdepends are built ; compilation > report is sent to DD ; container is deleted. > Isn't ci.debian.net doing automated builds with experimental version of dependencies ? For my package, I'm seeing builds with dependencies from experimental suite, the latest being openssl 3.0.0-1 [1]. This would mean that just uploading to experimental and let ci.debian.net do all builds of reverse dependencies would be sufficient, but I'm not sure whether the FTBFS reports are made automatically. [1] https://ci.debian.net/packages/s/streamlink/unstable/amd64/ -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F| signature.asc Description: OpenPGP digital signature
Re: spammer closing bug report
Hi, > Most likely it has been BCC'ed, that's what spammers like to do when > they send the same mail to thousands of recipients. > Indeed, this can be seen by clicking on "full text" here in the bug report: --- Reply sent to nore...@no.com: You have taken responsibility. (Mon, 02 Mar 2020 14:00:05 GMT) (full text, mbox, link). --- Then on Message part 3 here (which is the original message sent by the spammer): --- [Message part 3 (message/rfc822, inline)] --- The first line contains 492400-done, so it was in Bcc: --- Received: (at 492400-done) by bugs.debian.org; 2 Mar 2020 13:56:49 + --- -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Re: FTP Team -- call for volunteers
Le 15/03/2020 à 19:59, Salvo Tomaselli a écrit : > If you think about it, even if you connect with ssh and use vim or > whatever remotely, the content of the files are reaching your screen, > so are being distributed anyway. Might as well just download them no? > I'm not a lawyer, but I'm thinking of this: If it's just about legal risk, couldn't the responsibility of the right to redistribute of the uploaded software be moved on the uploader instead ? So the uploader takes the responsibility of any redistribution of the uploaded software by Debian itself, the same way if he would have uploaded it to a social media are whatever. That way, the legal responsibility burden is distributed on many peoples instead of a small number. If one is not sure that the software is distributable, he can mail the upstream maintainers for a clue. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Why Vcs-* fields are not at least recommended ?
Hi, I'm wondering why Vcs-* fields in debian/control (Vcs-Browser and/or Vcs-) are not recommended (or maybe even strongly recommended) ? (I mean here that I think having Vcs-* fields should be recommended for active packages) There is no lintian tag for missing Vcs-* fields (not even a low severity one, but I don't know if it's because of lack of interest or because of the policy). Maybe the fact that we still have the package' source tarballs for each released version is enough, but this loose the VCS history and ongoing work in case someone else wants to contribute too. I acknowledge that previously, packages might not have been developed using a VCS as said in the policy. But I think now most packages have a VCS where it is developed. Also, I see some orphaned packages in the QA group now actively maintained without VCS, which seems counterproductive if someone else wants to contribute too. In that case, this would be almost like a NMU I guess, but against an "non official maintainer" with manual merges (or lost changes). Or maybe orphaned package with QA upload are not supposed to be always collaboratively maintained ? (I'm new to these concepts, but to me the response to this should be "no"). What do you think about actively developed packages without Vcs-* fields ? - Note: I've checked if it was already discussed before on -devel or -policy but did not find anything relevant for this exact subject. If there is still something somewhere, I would be happy to read it :) -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Re: Trying to get in touch with Sam Hocevar [MIA]
Hi, Le 24/08/2020 à 15:17, Samuel Thibault a écrit : > Sudip Mukherjee, le lun. 24 août 2020 14:09:21 +0100, a ecrit: >> On Mon, Aug 24, 2020 at 1:50 PM Holger Levsen wrote: >>> >>> On Mon, Aug 24, 2020 at 12:21:25PM +0100, Sudip Mukherjee wrote: >>>> If the maintainer is truly unavailable [...] >>> >>> well, yes, but here someone hasn't replied to an email within 7 days... >> >> Thats why the "if" in my reply. :) >> >> And besides, looking at >> https://github.com/troglobit/editline/issues/42#issuecomment-674494039 >> it seems its more than 7 days. > > I have mails in my mbox that are 9 years old. > > Yes, I still indend to address them some day, it does happen from times > to times that I dig back that long in the past. > > Samuel > While 7 days in summer is rather small (some may have a month in vacation), you can have something in your TODO list for 9 years, but still reply to anyone asking a mail just saying something like: - "I'm still here but this is on my TODO list / I'm working on it", - or "I don't have enough time nowadays, you can take over the package if you want" just to show you are present and reading mails (even if not processing the underlying work they ask for). -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F| signature.asc Description: OpenPGP digital signature
