Re: FTP Team -- call for volunteers
On Thursday, March 19, 2020 10:31:55 AM EDT Luca Filipozzi wrote: > On Thu, Mar 19, 2020 at 11:42:39AM +, Neil McGovern wrote: > > On Wed, Mar 18, 2020 at 12:25:24PM -0400, Theodore Y. Ts'o wrote: > > > > 2) We would be very limited in what checks we could actually do on new > > > > packages. If we look too closely at packages, we stop being a > > > > distributor, and start being a publisher. I'm not sure that we want to > > > > move towards just being a distribution platform, rather than actually > > > > doing QA checks. > > > > > > I'm confused. As near as I can tell, we already are looking super > > > closely at new packages. > > > > Yes, and there's the problem. To move from a situation where we try and > > say "we're a distributor, not a publisher", then we would need to stop > > doing some of those checks, or at least work out a way of automating > > them. > > [snip very useful explanation - thanks for that, Neil!] > > > So, to ease the burden on ftp-masters by trying to say that > > > > > the responsibility of the right to redistribute of the uploaded > > > software be moved on the uploader instead > > > > as suggested by Alexis, means we need to be very careful about /not/ > > looking too closely at what we put out. > > Isn't part of Debian's charm the quality that we attempt to bring to the > packages that we publish? > > How does our coorindation for things like py2->py3 impact our position > as publisher vs distributor? I think it's an essential element of the value proposition that Debian brings to the table. We're an integrator that is working to deliver a coherent set of capabilities in a release. If we aren't going to do that, we may as well dump all the (for example) Python packages and tell people to use pypi (CPAN, pick your language specific publishing mechanism). Scott K signature.asc Description: This is a digitally signed message part.
Re: FTP Team -- call for volunteers
On Thu, Mar 19, 2020 at 11:42:39AM +, Neil McGovern wrote: > On Wed, Mar 18, 2020 at 12:25:24PM -0400, Theodore Y. Ts'o wrote: > > > 2) We would be very limited in what checks we could actually do on new > > > packages. If we look too closely at packages, we stop being a > > > distributor, and start being a publisher. I'm not sure that we want to > > > move towards just being a distribution platform, rather than actually > > > doing QA checks. > > > > I'm confused. As near as I can tell, we already are looking super > > closely at new packages. > > > > Yes, and there's the problem. To move from a situation where we try and > say "we're a distributor, not a publisher", then we would need to stop > doing some of those checks, or at least work out a way of automating > them. [snip very useful explanation - thanks for that, Neil!] > So, to ease the burden on ftp-masters by trying to say that > > the responsibility of the right to redistribute of the uploaded > > software be moved on the uploader instead > as suggested by Alexis, means we need to be very careful about /not/ > looking too closely at what we put out. Isn't part of Debian's charm the quality that we attempt to bring to the packages that we publish? How does our coorindation for things like py2->py3 impact our position as publisher vs distributor? -- Luca Filipozzi
Re: FTP Team -- call for volunteers
On Wed, Mar 18, 2020 at 12:25:24PM -0400, Theodore Y. Ts'o wrote: > > 2) We would be very limited in what checks we could actually do on new > > packages. If we look too closely at packages, we stop being a > > distributor, and start being a publisher. I'm not sure that we want to > > move towards just being a distribution platform, rather than actually > > doing QA checks. > > I'm confused. As near as I can tell, we already are looking super > closely at new packages. > Yes, and there's the problem. To move from a situation where we try and say "we're a distributor, not a publisher", then we would need to stop doing some of those checks, or at least work out a way of automating them. Apologies if the below is stuff you already know, but it may be useful for others. Please also note, this is an oversimplification of the way that this all works. There are two models of getting software from third parties into the hands of users - one is to be a "publisher", and one is to be a "distributor". Both are ways of trying to reduce the risk of putting on the web some bad software (as in, trademark infringing, copyright infringing etc). In the "publishing" model, you accept some software from a third party. You then run various checks on it, making sure it has a good licence, it complies with trademark and copyright law, and then we publish it. This is the way that Debian works at the moment. In the "distribution" model, you accept some software from a third party, and put it on the web. You don't look at it closely, but rely on your terms of service which says that the initial uploader is responsible for everything they upload, and making sure it is distributable etc. This is the way that sals/github/google play store etc work. To relieve the work on ftpmasters, some people are suggesting we move from the former to the latter. Now, imagine you have a law suit where Debian has shipped some proprietary code to millions of users. The upstream for this isn't happy. They come to Debian and complain. Debian says "oh, but we're just a distributor. The liability lies with the person who uploaded it". Unfortunately, we're doing checks on the package. Upstream can then claim that becasue we're looking at and approving packages, we're not just a platform who distributes software, we're actively publishing it by having editorial control over what gets published or not. So, to ease the burden on ftp-masters by trying to say that > the responsibility of the right to redistribute of the uploaded > software be moved on the uploader instead as suggested by Alexis, means we need to be very careful about /not/ looking too closely at what we put out. Sorry for the long mail, but hoepfully this clarifies. Neil -- signature.asc Description: PGP signature
Re: ***UNCHECKED*** Re: FTP Team -- call for volunteers
Hi, On 18.03.20 17:25, Theodore Y. Ts'o wrote: > The uploader has *already* distributed the package by uploading it to > ftp.debian.org. So the uploader already has any (99.99% of the time, > completely non-existent) liability. Yes and no. The uploader has distributed it to Debian, and Debian then can decide if they distribute it further. >> 2) We would be very limited in what checks we could actually do on new >> packages. If we look too closely at packages, we stop being a >> distributor, and start being a publisher. I'm not sure that we want to >> move towards just being a distribution platform, rather than actually >> doing QA checks. > I'm confused. As near as I can tell, we already are looking super > closely at new packages. Yes, which is why we are expected to make diligent decisions on whether we want to distribute it further. We could move towards a fully automated process like GitHub's and assert that we should be awarded the same protections against liability for copyright infringement (i.e. DMCA rules with a requirement to remove after notification). Simon signature.asc Description: OpenPGP digital signature
Re: FTP Team -- call for volunteers
On Sun, Mar 15, 2020 at 07:52:06PM +, Neil McGovern wrote: > > In theory, yes - this would move the liability to the uploader. However, > there are two issues with this: > 1) The liability now rests with the uploader. This isn't something that > has really been done before, and we'd need to make sure that we're > comfortable with this. The uploader has *already* distributed the package by uploading it to ftp.debian.org. So the uploader already has any (99.99% of the time, completely non-existent) liability. If the uploader is using github, or salsa, they've also *already* distributed it. And I'll note that the salsa admins don't be as concerned about potential liability to Debian compared to the ftp team when a maintainer uploads a package with a shared library version bump so that there's a new package, libfoo4 instead of libfoo3. > 2) We would be very limited in what checks we could actually do on new > packages. If we look too closely at packages, we stop being a > distributor, and start being a publisher. I'm not sure that we want to > move towards just being a distribution platform, rather than actually > doing QA checks. I'm confused. As near as I can tell, we already are looking super closely at new packages. - Ted
Re: FTP Team -- call for volunteers
Hi Scott, On Sat, Mar 14, 2020 at 10:43:33PM +, Scott Kitterman wrote: > As long as there are people involved, a certain amount of it is > inevitable. Putting it in the requirements is bowing to reality. The > FTP Team sometimes has to make unpopular decisions and it's inevitable > that people won't always react well. > > If Sean hadn't mentioned it, I think it would have been a disservice > to potential volunteers. People should know what they are signing up > for. Honestly it's not a lot of the feedback, most of what we get > back is positive, but it's enough that it's worth mentioning. > I think that mentioning it is absolutely the right thing to do, and I'm certainly aware (having been release manager for *mumble* years) that unpopular decisions can lead to unpleasant reactions. I think my point is that we should strive to reach the point where it's not inevitable, and that our reality can change. It should never be the case that making a hard decision leads to abusive messages, and I believe as a project we must act to try and achieve this goal. For leadership roles, such as release manager, or ftp master, I think it's doubly important. Putting aside the issue of current volunteers, and the project's duty to ensure a safe and welcoming environment, this affects the overall ability for the project to attract new volunteers at all. These key posts can be aspirational for new contributors - the concept that one day you could be an ftp-master is attractive. However, if we accept that in order to reach one of these key roles you have to be willing to accept a certain level of abuse, then we have failed to produce that welcoming community, and will fail to attract and retain a diverse and thriving team. This is obviously not something that ftp-masters can solve, but I think it is useful to highlight this issue for the wider project. Thanks, Neil -- signature.asc Description: PGP signature
Re: FTP Team -- call for volunteers
On Sat, Mar 14, 2020 at 05:41:38PM -0400, Roberto C. Sánchez wrote: > The fact is that given the length of time packages can wait for NEW > processing and the amount of effort package maintainers put into > packaging, it is understandable that they would be frustrated at the > rejection of a package. That said, it does not make flaming the FTP an > acceptable response and is certainly not going to produce any positive > result. But it is not clear that it would be possible to prevent such a > thing. I would like to change the strategy we currently use in Debian to deal with structural issues, from what seems like "people yell abuse out of frustration and teams survive by bearing with it", to something else. I would ideally like to cut on the abuse, and invest in help (both asking for, offering, and accepting help) in dealing with both routine and structural issues. I mean, *abuse in the project cannot possinly be part of routine work*. Please let the Community Team know of instances so they can talk to people, and please let DAM know of particularly bad instances, like personal threats, if they happen. However, if we have a structural issue that causes frustration, having the community team helping people in keeping their cool and DAM taking action on people with a tendency to losing it bad, does not make the structural issue sustainable. For this reason, thank you for asking for help! I hope people who volunteer can expect better working conditions than what was offered in the call, and I hople that one can have a path of growth in the team from something that looks like grunts who do the routine work under enemy fire, to someone who can get appreciation for their work, over time develop understanding and agency in the team, and eventually can help to shape it. I don't mean for this to be specific to the FTP team. I guess this thread gave me an opportunity to voice my more general thoughts. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: FTP Team -- call for volunteers
On 14.03.20 22:41, Roberto C. Sánchez wrote: > On Sat, Mar 14, 2020 at 09:18:48PM +, Neil McGovern wrote: >> Hi debian-project and ftpmaster folks, >> >> On Sat, Mar 14, 2020 at 01:37:59PM -0700, Sean Whitton wrote: >>> - cope well with flames in response to your decisions >> >>> - after training, comfortable with being on the other end of the >>> ftpmaster@ alias, which receives a huge volume of >>> not-always-pleasant messages daily. >> >> I hope I am not the only one to be deeply concerned that this should be >> a requirement on volunteers. For me, it is absolutely unacceptable that >> people should put up with unplesentness or flames that come from doing a >> difficult job. Putting this in the requirements is, for me, a failure of >> the project. >> >> Sean: do you have any ideas on how we can reduce this aspect of the >> valuable work that ftpmasters do? Do you have some (anonymised) examples >> of the areas of abuse that you receive perhaps? >> > The fact is that given the length of time packages can wait for NEW > processing and the amount of effort package maintainers put into > packaging, it is understandable that they would be frustrated at the > rejection of a package. That said, it does not make flaming the FTP an > acceptable response and is certainly not going to produce any positive > result. But it is not clear that it would be possible to prevent such a > thing. > > It seems like if NEW processing only took a short time (perhaps 1 or 2 > weeks), then a rejection would be less frustrating. However, a > rejection after waiting 11 or 12 months (or longer) and no response to > requests for additional guidance when something is unclear are difficult > to deal with from the package maintainer side. > > The delays may be unavoidable, but any measures to minimize them would > go a long way to reducing the likelihood of flame responses to rejection > mails. In theory, "given enough eyeballs, all bugs are shallow", making the *packaging process* more visible would alleviate this problem. Not having a package accepted can be interpreted as a bug on the packagers side, so if the culture of Debian packaging would be amended so that packagers do the packaging in public, f.ex. on Salsa, then those "packaging bugs" could be spotted and fixed earlier, relieving the ftp masters. The packagers can then invite the public to have a look and to criticize, making the packaging more fit for the strict judgement of the ftp masters... *t *t
Re: FTP Team -- call for volunteers
Hello, On Sun 15 Mar 2020 at 10:48PM +01, Philipp Kern wrote: > Now we could also fix that using a whitelist approach. But I have not > seen much openness to tackling this part of NEW review and I am unsure > why. From the public NEW tooling (I don't know dak's side) it pretty > clearly does not look like a de novo review, as the diff to the archive > is highlighted. Maybe another way would be to split the queue using a > weighting function. Not sure what diff you have in mind, aside from the fact that https://ftp-master.debian.org/new.html does indicate whether it's source-NEW or binary-NEW. On the other side you just get a whole source package and a list of which files in the .changes are NEW. > But I am not aware of public documentation on how the review process > is organized currently. Is there any? Yes: https://salsa.debian.org/ftp-team/manpages For the mc extensions mentioned there, you can see my dotfiles: https://git.spwhitton.name/dotfiles/tree/.config/mc?h=fasolo https://git.spwhitton.name/dotfiles/tree/.local/share/mc/extfs.d?h=fasolo -- Sean Whitton signature.asc Description: PGP signature
Re: FTP Team -- call for volunteers
Hello Sean. I want to be a volunteer. Please give me next steps. Kind regards Obtener Outlook para Android<https://aka.ms/ghei36> De: Alexandre Viau Enviado: domingo, 15 de marzo de 2020 21:24 Para: spwhit...@spwhitton.name Cc: debian-devel-annou...@lists.debian.org Asunto: Re: FTP Team -- call for volunteers On Sat, Mar 14, 2020 at 4:38 PM Sean Whitton wrote: > > Hello everyone, > > The FTP Team is seeking volunteers to train to become FTP Assistants. Hello Sean, I'd like to volunteer. I remember answering to a call for volunteers in 2018. I was told that I would be contacted for the next steps and it never happened. I hope this time is different! Thank you for taking the time to help bring in new blood to this team. Cheers, -- Alexandre Viau av...@debian.org
Re: FTP Team -- call for volunteers
On Sun, Mar 15, 2020 at 10:02 PM Philip Hands wrote: > I know times have changed, but are we not still notionally informing > someone of every package that goes through NEW? Telling them (perhaps > in a queued email that doesn't get sent any more) that each and every > package in Debian may well include crypto at some future date, if it > doesn't already, and declaring an initial point of distribution. IIRC, the US government got bored of receiving mails for every upload to Debian and requested that we stop the notifications. -- bye, pabs https://wiki.debian.org/PaulWise
Re: FTP Team -- call for volunteers
On Sat, Mar 14, 2020 at 4:38 PM Sean Whitton wrote: > > Hello everyone, > > The FTP Team is seeking volunteers to train to become FTP Assistants. Hello Sean, I'd like to volunteer. I remember answering to a call for volunteers in 2018. I was told that I would be contacted for the next steps and it never happened. I hope this time is different! Thank you for taking the time to help bring in new blood to this team. Cheers, -- Alexandre Viau av...@debian.org
Re: FTP Team -- call for volunteers
Alexis Murzeau writes: ... > 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 ? How well does that work if someone outside the USA uploads software to this USA based server which is legal in their own jurisdiction, but falls foul of US law either by being on the server, or perhaps by being distributed or (re)exported, say. ISTR that uploading the ssh binaries from the UK seemed likely to involve me crossing one or other of those lines back in the days of the non-US archive (what with the RSA patent, and the export restrictions on crypto at the time). I know times have changed, but are we not still notionally informing someone of every package that goes through NEW? Telling them (perhaps in a queued email that doesn't get sent any more) that each and every package in Debian may well include crypto at some future date, if it doesn't already, and declaring an initial point of distribution. I would suspect that we might want to check that technical changes to this process remain compatible with the paperwork, because the paperwork may well be harder to change than the technology, and keeping the paperwork in good working order may be a useful shield if some capricious maniac ever managed to be in charge of things. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: FTP Team -- call for volunteers
On 2020-03-15 18:25, Theodore Y. Ts'o wrote: The bigger thing which we might be able to do is to require minimal review if the source package is already in the distribution, but the main reason why it is in the ftp-master tar pit is because upstream has bumped the major version number of a shared library, and so there is a new binary package triggering what appears to be de novo review by the ftp master team. I understand there is a super-abundance of caution which seems to drive all ftp-master team decisions, but perhaps this could be eased, in the interests of reduce a wait time of, in some cases greater than a year? It also drives technical decisions. A much cleaner way from a deployment perspective would be to version kernel packages (and another pet peeve, nvidia packages) for every upload. That way updates and rollbacks can be managed more cleanly. (E.g. old kernel remaining in the boot menu, just like Ubuntu bumps with every upload these days.) Now we could also fix that using a whitelist approach. But I have not seen much openness to tackling this part of NEW review and I am unsure why. From the public NEW tooling (I don't know dak's side) it pretty clearly does not look like a de novo review, as the diff to the archive is highlighted. Maybe another way would be to split the queue using a weighting function. But I am not aware of public documentation on how the review process is organized currently. Is there any? (I'm happy to look at potential whitelisting code, but I think last time someone tried a big refactoring and introduction of tests was required of them prior to the contribution - which is a high bar after getting dak to run properly for development purposes first.) Kind regards Philipp Kern
Re: FTP Team -- call for volunteers
On Sun, Mar 15, 2020 at 08:13:37PM +0100, Alexis Murzeau wrote: > 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. > I am also not a lawyer, but have consulted with lawyers over similar questions. This doesn't mean that Debian should consider this legal advice, as Debian's situation is different than the one I have asked about. In theory, yes - this would move the liability to the uploader. However, there are two issues with this: 1) The liability now rests with the uploader. This isn't something that has really been done before, and we'd need to make sure that we're comfortable with this. 2) We would be very limited in what checks we could actually do on new packages. If we look too closely at packages, we stop being a distributor, and start being a publisher. I'm not sure that we want to move towards just being a distribution platform, rather than actually doing QA checks. Neil -- signature.asc Description: PGP 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
Re: FTP Team -- call for volunteers
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? Il giorno dom 15 mar 2020 alle ore 18:25 Theodore Y. Ts'o ha scritto: > > On Sun, Mar 15, 2020 at 01:53:44PM +0100, Simon Richter wrote: > > > > > Personally, I was shocked when I found out we do review on the same > > > server that > > > hosts the archive. I would have expected a separate server for review. > > > However, > > > my expectation comes from younger environments, where CD/CI and extensive > > > code > > > review processes are expected. When I try to picture how the current > > > system > > > evolved (more evident as you dig into dak source...), it makes sense. > > > > There are two aspects to distribution: a license from the copyright > > holders, and export permissions from the country where the archive is > > hosted. > > > > Both of these are *currently* rather relaxed in the US, with DMCA safe > > harbor provisions and a blanket permission to export cryptography (the > > existence of which Debian had a large hand in), which allows places like > > Github to operate. > > > > It is unclear how much the DMCA protects us if we have a review process > > before publication (i.e. are we still good if we have any manual step, > > or must publication be fully automated?), and there is also a bill > > underway that would tighten requirements on cryptography software again > > if not defeated. > > Personally I think this worry that a private copying from > ftp-master.debian.org constitutes a legal risk is really way > overblown. However, if we want to assume this highly paranoid > reading, one thing we could do is have an *optional* way where someone > who is uploading a package which is going to end up in the ftp-master > tar pit^H^H^H^H^H^H^H queue can pass a URL where ftp master assistants > can download the various artifacts to their own local laptop. > Sha256sum can be used to make sure what has been uploaded to debian > matches what has been downloaded from the sideload URL. > > That way, *Debian* is not distributing, but the uploader is > distributing from their server. So the legal risk (if any) isn't on > Debian. > > The bigger thing which we might be able to do is to require minimal > review if the source package is already in the distribution, but the > main reason why it is in the ftp-master tar pit is because upstream > has bumped the major version number of a shared library, and so there > is a new binary package triggering what appears to be de novo review > by the ftp master team. I understand there is a super-abundance of > caution which seems to drive all ftp-master team decisions, but > perhaps this could be eased, in the interests of reduce a wait time > of, in some cases greater than a year? > > - Ted > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Re: FTP Team -- call for volunteers
On Sun, Mar 15, 2020 at 01:53:44PM +0100, Simon Richter wrote: > > > Personally, I was shocked when I found out we do review on the same server > > that > > hosts the archive. I would have expected a separate server for review. > > However, > > my expectation comes from younger environments, where CD/CI and extensive > > code > > review processes are expected. When I try to picture how the current system > > evolved (more evident as you dig into dak source...), it makes sense. > > There are two aspects to distribution: a license from the copyright > holders, and export permissions from the country where the archive is > hosted. > > Both of these are *currently* rather relaxed in the US, with DMCA safe > harbor provisions and a blanket permission to export cryptography (the > existence of which Debian had a large hand in), which allows places like > Github to operate. > > It is unclear how much the DMCA protects us if we have a review process > before publication (i.e. are we still good if we have any manual step, > or must publication be fully automated?), and there is also a bill > underway that would tighten requirements on cryptography software again > if not defeated. Personally I think this worry that a private copying from ftp-master.debian.org constitutes a legal risk is really way overblown. However, if we want to assume this highly paranoid reading, one thing we could do is have an *optional* way where someone who is uploading a package which is going to end up in the ftp-master tar pit^H^H^H^H^H^H^H queue can pass a URL where ftp master assistants can download the various artifacts to their own local laptop. Sha256sum can be used to make sure what has been uploaded to debian matches what has been downloaded from the sideload URL. That way, *Debian* is not distributing, but the uploader is distributing from their server. So the legal risk (if any) isn't on Debian. The bigger thing which we might be able to do is to require minimal review if the source package is already in the distribution, but the main reason why it is in the ftp-master tar pit is because upstream has bumped the major version number of a shared library, and so there is a new binary package triggering what appears to be de novo review by the ftp master team. I understand there is a super-abundance of caution which seems to drive all ftp-master team decisions, but perhaps this could be eased, in the interests of reduce a wait time of, in some cases greater than a year? - Ted
Re: FTP Team -- call for volunteers
Hi, On 15.03.20 12:55, Michael Lustfield wrote: > Personally, I was shocked when I found out we do review on the same server > that > hosts the archive. I would have expected a separate server for review. > However, > my expectation comes from younger environments, where CD/CI and extensive code > review processes are expected. When I try to picture how the current system > evolved (more evident as you dig into dak source...), it makes sense. There are two aspects to distribution: a license from the copyright holders, and export permissions from the country where the archive is hosted. Both of these are *currently* rather relaxed in the US, with DMCA safe harbor provisions and a blanket permission to export cryptography (the existence of which Debian had a large hand in), which allows places like Github to operate. It is unclear how much the DMCA protects us if we have a review process before publication (i.e. are we still good if we have any manual step, or must publication be fully automated?), and there is also a bill underway that would tighten requirements on cryptography software again if not defeated. Simon signature.asc Description: OpenPGP digital signature
+1 (Re: FTP Team -- call for volunteers)
On Sun, Mar 15, 2020 at 06:55:43AM -0500, Michael Lustfield wrote: > > > > > (packages in NEW must not be downloaded from ftp-master.d.o to > > > > > your > > > > > local machine) > > > > Just curious: Why is that the case? > > > Out of an abundance of caution. Until after the package has been > > > reviewed, > > > there's no knowing if it's distributable and downloading a package from > > > ftp- > > > master.d.o to another machine outside debian.org is a distrubution. > > [...] > > This "abundance of caution" rule is utterly obsolete this millenium. It > > made some sense when distributing software was done by snail-mailing a > > floppy or a stack of them. > > My knee-jerk response is to agree. There is a lock which also applies to > reviewing a package. This means only one person can be looking at it at a > time. > We often just open a github/gitlab/etc. page if multiple people need to > discuss > the package (usually team member asking a trainee something). The content has > already been distributed. Why should this be any different from mentors.d.n, > where such practice is required? > > The problem is that this server is *the* distribution point for the Debian > archive. This feels like a weird gray area that shouldn't be messed around > with. > > Personally, I was shocked when I found out we do review on the same server > that > hosts the archive. I would have expected a separate server for review. +1, though talk is cheap :) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: FTP Team -- call for volunteers
On Sun, 15 Mar 2020 05:10:21 +0100 Adam Borowski wrote: > On Sat, Mar 14, 2020 at 08:04:01PM -0400, Scott Kitterman wrote: > > On Saturday, March 14, 2020 6:37:46 PM EDT Martin wrote: > > > On 2020-03-14 13:37, Sean Whitton wrote: > > > > (packages in NEW must not be downloaded from ftp-master.d.o to your > > > > local machine) > > > Just curious: Why is that the case? > > Out of an abundance of caution. Until after the package has been reviewed, > > there's no knowing if it's distributable and downloading a package from ftp- > > master.d.o to another machine outside debian.org is a distrubution. > [...] > This "abundance of caution" rule is utterly obsolete this millenium. It > made some sense when distributing software was done by snail-mailing a > floppy or a stack of them. My knee-jerk response is to agree. There is a lock which also applies to reviewing a package. This means only one person can be looking at it at a time. We often just open a github/gitlab/etc. page if multiple people need to discuss the package (usually team member asking a trainee something). The content has already been distributed. Why should this be any different from mentors.d.n, where such practice is required? The problem is that this server is *the* distribution point for the Debian archive. This feels like a weird gray area that shouldn't be messed around with. Personally, I was shocked when I found out we do review on the same server that hosts the archive. I would have expected a separate server for review. However, my expectation comes from younger environments, where CD/CI and extensive code review processes are expected. When I try to picture how the current system evolved (more evident as you dig into dak source...), it makes sense. Making a new server to push reviews to would remove that gray area, since it would effectively be identical to mentors.d.n; especially considering how easily one could upload to ftp-master instead of mentors... (guilty) Something like this would take a pretty deep dive into dak, and a new server, and all the goodies that would go along with such a transition. Unfortunately, from my view, such a change would be nearly impossible. I can't even get documentation fixes merged into dak or even reviewed. I don't imagine such a large change would ever get accepted. If we could even just do something like an DNA, saying we will definitely destroy everything we download, we'd at least be able to write our own review tools. :/
Re: FTP Team -- call for volunteers
Thank you Sean. I believe what you do is significantly meaningful for our FTP team and the whole project. The recruitment cycle of FTP team is "notoriously" slow, and any effort put on it is much appreciated! On Sat, Mar 14, 2020 at 01:37:59PM -0700, Sean Whitton wrote: > Hello everyone, > > The FTP Team is seeking volunteers to train to become FTP Assistants. > > This is almost entirely a matter of learning how to process the NEW > queue -- learning how to process requests for removals, override changes > etc. is typically something one does *after* becoming an Assistant. > Contributing code to DAK is not a requirement for team members and > contributing code to DAK does not require team membership. > > I have been tasked with supervising both trainees and the training > process, but you can expect to receive feedback from all of the team > members who work NEW. > > Requirements: > > - must be a DD > > - can work with all existing team members > > - comfortable with browsing source packages over SSH using text tools > (packages in NEW must not be downloaded from ftp-master.d.o to your > local machine) > > - willing to wade through legal texts and endure any resultant > headaches > > - cope well with flames in response to your decisions > > - should be an experienced packager. In addition to > licensing/copyright issues, NEW review attempts to catch bugs where > the package entering the archive would make life difficult for > contributors > > - after training, comfortable with being on the other end of the > ftpmaster@ alias, which receives a huge volume of > not-always-pleasant messages daily. > > Some other info in these old calls for volunteers: > > - https://lists.debian.org/debian-devel-announce/2010/03/msg3.html > - https://lists.debian.org/debian-devel/2017/08/msg00408.html > > And in our docs: > > - https://ftp-master.debian.org/REJECT-FAQ.html > - https://salsa.debian.org/ftp-team/manpages > > Write to if interested. > > For the FTP Team, > > -- > Sean Whitton
Re: FTP Team -- call for volunteers
On Sat, Mar 14, 2020 at 08:04:01PM -0400, Scott Kitterman wrote: > On Saturday, March 14, 2020 6:37:46 PM EDT Martin wrote: > > On 2020-03-14 13:37, Sean Whitton wrote: > > > (packages in NEW must not be downloaded from ftp-master.d.o to your > > > local machine) > > > > Just curious: Why is that the case? > > Out of an abundance of caution. Until after the package has been reviewed, > there's no knowing if it's distributable and downloading a package from ftp- > master.d.o to another machine outside debian.org is a distrubution. Ok then. Instead of a place accessible to a single digit of trusted people that's write-only to a thousand of well-wetted people, I'll grab the package from public git, on project machines. I'm also personally on the path used to submit uploads by contributors least likely to get copyright correctly (ie, project non members), with packages going first to the mentors repository, which has no access controls beyond being able to follow simple instructions about gpg. This "abundance of caution" rule is utterly obsolete this millenium. It made some sense when distributing software was done by snail-mailing a floppy or a stack of them. Even REJECTed packages would be good to keep -- for diffing with a new version. > > > - cope well with flames in response to your decisions > > > > Flames equal emotional expression of frustration or > > flames equal inappropriate swearing at volunteers? > > Yes. :) You could've been a bit more informative by saying "and". :) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Re: FTP Team -- call for volunteers
On Saturday, March 14, 2020 6:37:46 PM EDT Martin wrote: > On 2020-03-14 13:37, Sean Whitton wrote: > > (packages in NEW must not be downloaded from ftp-master.d.o to your > > local machine) > > Just curious: Why is that the case? Out of an abundance of caution. Until after the package has been reviewed, there's no knowing if it's distributable and downloading a package from ftp- master.d.o to another machine outside debian.org is a distrubution. > > - cope well with flames in response to your decisions > > Flames equal emotional expression of frustration or > flames equal inappropriate swearing at volunteers? Yes. Scott K signature.asc Description: This is a digitally signed message part.
Re: FTP Team -- call for volunteers
On March 14, 2020 9:18:48 PM UTC, Neil McGovern wrote: >Hi debian-project and ftpmaster folks, > >On Sat, Mar 14, 2020 at 01:37:59PM -0700, Sean Whitton wrote: >> - cope well with flames in response to your decisions > >> - after training, comfortable with being on the other end of the >> ftpmaster@ alias, which receives a huge volume of >> not-always-pleasant messages daily. > >I hope I am not the only one to be deeply concerned that this should be >a requirement on volunteers. For me, it is absolutely unacceptable that >people should put up with unplesentness or flames that come from doing >a >difficult job. Putting this in the requirements is, for me, a failure >of >the project. As long as there are people involved, a certain amount of it is inevitable. Putting it in the requirements is bowing to reality. The FTP Team sometimes has to make unpopular decisions and it's inevitable that people won't always react well. If Sean hadn't mentioned it, I think it would have been a disservice to potential volunteers. People should know what they are signing up for. Honestly it's not a lot of the feedback, most of what we get back is positive, but it's enough that it's worth mentioning. Scott K
Re: FTP Team -- call for volunteers
On 2020-03-14 13:37, Sean Whitton wrote: > (packages in NEW must not be downloaded from ftp-master.d.o to your > local machine) Just curious: Why is that the case? > - cope well with flames in response to your decisions Flames equal emotional expression of frustration or flames equal inappropriate swearing at volunteers?
Re: FTP Team -- call for volunteers
Hello Neil, On Sat 14 Mar 2020 at 09:18PM +00, Neil McGovern wrote: > Hi debian-project and ftpmaster folks, CCing ftpmaster@. > On Sat, Mar 14, 2020 at 01:37:59PM -0700, Sean Whitton wrote: >> - cope well with flames in response to your decisions > >> - after training, comfortable with being on the other end of the >> ftpmaster@ alias, which receives a huge volume of >> not-always-pleasant messages daily. > > I hope I am not the only one to be deeply concerned that this should be > a requirement on volunteers. For me, it is absolutely unacceptable that > people should put up with unplesentness or flames that come from doing a > difficult job. Putting this in the requirements is, for me, a failure of > the project. > > Sean: do you have any ideas on how we can reduce this aspect of the > valuable work that ftpmasters do? Do you have some (anonymised) examples > of the areas of abuse that you receive perhaps? The FTP Team has a robust understanding of (a) what the DFSG requires, and (b) what is required to ensure we're complying with the terms of common free licenses. A good example of (a) is ensuring that *all* preferred forms for modification are included in source packages, and a good example of (b) is [1]. Not everyone in the project agrees with the FTP Team on these sorts of issues. Further, there are not enough people processing NEW, so packages sometimes stay there for a long time. Put these two things together, and you can see why people might be more likely to respond in a way that's less than ideal when their uploads are rejected from NEW. Thus, one way to improve things would be to have more people processing NEW, such that there is less frustration all round -- which is what I'm trying to achieve by supervising a batch of new trainees :) [1] https://lists.debian.org/debian-devel-announce/2018/10/msg4.html -- Sean Whitton signature.asc Description: PGP signature
Re: FTP Team -- call for volunteers
On Sat, Mar 14, 2020 at 09:18:48PM +, Neil McGovern wrote: > Hi debian-project and ftpmaster folks, > > On Sat, Mar 14, 2020 at 01:37:59PM -0700, Sean Whitton wrote: > > - cope well with flames in response to your decisions > > > - after training, comfortable with being on the other end of the > > ftpmaster@ alias, which receives a huge volume of > > not-always-pleasant messages daily. > > I hope I am not the only one to be deeply concerned that this should be > a requirement on volunteers. For me, it is absolutely unacceptable that > people should put up with unplesentness or flames that come from doing a > difficult job. Putting this in the requirements is, for me, a failure of > the project. > > Sean: do you have any ideas on how we can reduce this aspect of the > valuable work that ftpmasters do? Do you have some (anonymised) examples > of the areas of abuse that you receive perhaps? > The fact is that given the length of time packages can wait for NEW processing and the amount of effort package maintainers put into packaging, it is understandable that they would be frustrated at the rejection of a package. That said, it does not make flaming the FTP an acceptable response and is certainly not going to produce any positive result. But it is not clear that it would be possible to prevent such a thing. It seems like if NEW processing only took a short time (perhaps 1 or 2 weeks), then a rejection would be less frustrating. However, a rejection after waiting 11 or 12 months (or longer) and no response to requests for additional guidance when something is unclear are difficult to deal with from the package maintainer side. The delays may be unavoidable, but any measures to minimize them would go a long way to reducing the likelihood of flame responses to rejection mails. Regards, -Roberto -- Roberto C. Sánchez
Re: FTP Team -- call for volunteers
Hi debian-project and ftpmaster folks, On Sat, Mar 14, 2020 at 01:37:59PM -0700, Sean Whitton wrote: > - cope well with flames in response to your decisions > - after training, comfortable with being on the other end of the > ftpmaster@ alias, which receives a huge volume of > not-always-pleasant messages daily. I hope I am not the only one to be deeply concerned that this should be a requirement on volunteers. For me, it is absolutely unacceptable that people should put up with unplesentness or flames that come from doing a difficult job. Putting this in the requirements is, for me, a failure of the project. Sean: do you have any ideas on how we can reduce this aspect of the valuable work that ftpmasters do? Do you have some (anonymised) examples of the areas of abuse that you receive perhaps? Thanks, Neil -- signature.asc Description: PGP signature
FTP Team — call for volunteers
Dear -devel, It has been quite a while since the last call for volunteers to join the the FTP team. As Ganneff put it so well in the last request[0], I will hereby quote him below. (I would only add that such work is rather under appreciated; don't do this for the glory or public recognition.) ~ Have you ever felt compelled to do the hard groundwork? Ever wanted to help at a nicely central place inside Debian? Or just want to write some Python code and still look for a good place to stick it in? Here we are. Come join the Nav^Wteam. Just sign over there to the right, or even easier, mail us. We won't bite you, thats for sure. At least not right away. :) The criteria are the same as always: You need to be a DD (except for coding only, though it helps to know the usual flow of a package) and you need to be able to deal with the existing team members. An occasional flame should also not disturb you, if you are working in the NEW queue you will stand between the people uploading and the packages entering the archive, rejecting something is not always liked much. (But you often get positive replies and thanks, to keep your spirits up :) ). And - if you get headaches when reading legal texts - we all do. But it is needed and things like NEW are mainly about that, the ftpteam is *the* one place to decide if something is ok for Debian to distribute or not, and you will have to take this decision. (Yes, there is more, but this is the main point you are going to check). Obviously the other points we made in earlier mails, like [1], still apply too. ~ As it happens, there will be an IRC meeting on #debian-ftp this Friday 8pm UTC, ie: $ date --date="Fri Oct 12 20:00:00 UTC 2018" [2] If you would like to join, or have any quick questions, please email ftpmas...@debian.org. [0] https://lists.debian.org/debian-devel/2017/08/msg00408.html [1] https://lists.debian.org/debian-devel-announce/2010/03/msg3.html [2] https://time.is/compare/2000_12_Oct_2018_in_UTC Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
