On Mon, 2024-12-09 at 15:58 -0800, Xiyue Deng wrote: > 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 >
Morning Xiyue and all, Xiyue mentions tooling after Sam raised an issue. Xiyue, Many thanks for entering this conversation as I feel you are an ideal person (through our many interactions) to detail/discuss what you feel mentors is, is not, what is expected of the submitter and the reviewer; and what mentors should be. As a none DD I do basic build testing and validation of packages and their files in-order to bring them up to a minimum standard for a DD to then look at. This is to encourage Debian Developers to review and sponsor packages in mentors. A mentors package submission at the stage tagged 'confirmed' on the RFS bug means it is decent shape and be less of a strain on a DD's time. I use the sbuild using unshare[1] setup which can also run lintian, piuparts and autopkgtest test when configured. pbuilder I have historically used in the same minimal build VM sbuild for build after successful build tests. We use 'licenserecon' command 'lrc' to do validation checking of 'd/copyright'. This tool is new and improving. Manual checking are also used. I do not use scripts or have it automated. I do these tests manually across two laptops for each package I review. Automation and documentation is on the to-do list. My work on mentors is with primarily already available Debian tools and Visual Studio Code. The key thing is the time I am fortunate to be able to give to Debian due to my circumstances. An expectation that once a DD does an upload for you, they are obligated to do them for you from that point on I have seen in and around mentors. Unless a DD specifically makes a commitment to a package, I believe that all package uploads by a a DD are a one shot and there should be no expectation a DD will be available to do it in the future. All submitters I feel should file an RFS and an available DD can be canvassed for or waited for. [1] https://wiki.debian.org/sbuild#Setup Regard Phil -- Donations... Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Liberapay: https://liberapay.com/kathenas -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Wiki: https://wiki.kathenas.org Instagram: https://instagram.com/kathenasorg Threads: https://www.threads.net/@kathenasorg --
signature.asc
Description: This is a digitally signed message part
