Hi Sam, Sam Hartman <hartm...@debian.org> writes:
>>>>>> "Andrey" == Andrey Rakhmatullin <w...@debian.org> writes: > > Andrey> On Wed, Dec 04, 2024 at 03:30:23PM -0800, Xiyue Deng wrote: > >> It would be great to have a group of DDs that are willing to > >> regularly check for RFS bugs / mentors.d.n and offer sponsorship > > Andrey> Sure. This is true since the beginning of the RFS process, > Andrey> and as nothing stops people from doing this, but based on my > Andrey> observations such a group was never larger than 1-3 people, > Andrey> just knowing that this is a good idea is not enough. > > Perhaps sharing reasons why people don't do this would help us > understand what a change might look like. > > For myself, my reasons for not being involved in RFS have varied across > my Debian Journey. > > 1) Right now, I am behind on Debian work I have committed to, and I'd > rather get that done than work on picking up new obligations. > > 2) Sponsoring a package if you do it right is a lot of work. If it is > going through new, it's really important that you review all the > copyright and license statements and make a determination about whether > it fits the DFSG. I firmly believe that work needs to be done by a DD > and should never be outsourced to someone who hasn't been trusted to do > that work by the project. > I hate doing that. tooling has made it easier over the years. > > 3) I think it is important to grab a pristine copy of the upstream > 3) I think it's important to make sure that all changes are documented. > If not in Debian, that means going back to the upstream, grabbing > pristine upstream sources and diffing what is proposed at the upstream > source for Debian against those. If it is already in Debian, it means > effectively doing a debdiff between the version already in Debian and > the version proposed. The tooling for all that isn't great, and used to > be really bad. > > 4) At least back in the day there was an expectation that if you > sponsored a package you would test it. So it would involve learning how > to use the software and then testing to make sure it worked. Perhaps we > care about this less today. > > 5) At least back in the day there was an expectation that if you > sponsored an upload you would be available to sponsor any fixes to bugs > introduced in the upload. > For me, promising future availability was a big ask. > > 6) I felt there was an obligation to work with the person you were > sponsoring to get the package into shape. Sometimes that was a long > process. If they didn't have good email turn-around time I got into the > situation above where I had inadvertantly made a longer term commitment > than I was ready for. > > There are many points in my Debian journey where if I could have made a > 2-3 hour commitment to sponsoring packages without taking on future > responsibilities at future times, I would have been willing to do so. > (Not today unfortunately). > As I understand it there never has been (and is not today) a responsible > way to sponsor without at least taking on some chance of future > commitments. > These are valid concerns. I think the tooling from Phil should help with your point 2 and 3. For 4-6, I personally never expect the same DD would provide long-term support after sponsoring. Maybe making that clear on the Debian wiki[1] would help with aligning the expectations. [1] https://wiki.debian.org/DebianMentorsFaq -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
