Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
[ please Cc:-me on replies if you want to get my attention, I'm not
subscribed to -mentors ]
On Wed, 18 Jan 2012 15:26:49 +0100, Martin Zobel-Helas wrote:
Second concern i have here is that (AFAIK) everyone can upload
everything to mentors.debian.net. Which would mean we then would/could
distribute non-distribiteable material under the debian.org
domain. How can this issue be resolved?
I've sought legal advice for a similar issue ~6 months ago, on behalf of
ftp-masters to study the feasibility of so called PPA (for Personal
Package Archive) in Debian. I've briefly reported back then [1] that it
can be done even without a NEW queue-like bottleneck. To that end, a
couple of conditions shall be met:
a) we have a well-advertised contact point that copyright owners can
email to request take down of (allegedly) unauthorizedly distributed
content + someone behind it that react quickly (as in: a couple of
days) if/when needed
b) the [ mentors.d.o ] service is opt-in, and uploaders must accept some
terms of use before getting access to it. The terms essentially say
uploaders take responsibility for the content they're uploading
The above is in the context of US copyright law. The feature of DMCA
the two conditions exploit is the so called safe harbor, already
mentioned by Michael van der Kolff in this thread [2].
To make it real, however, we should write proper terms of use and
preferably have SPI lawyers review them. As we're going to need a very
similar version of it for PPA, getting one for mentors.d.o won't be a
big deal.
Would this be enough to settle the second concern of yours?
If so, I'll be happy to look into this with SPI lawyers.
Let me know,
Cheers.
[1] http://lists.debian.org/debian-devel-announce/2011/06/msg0.html
[2] http://lists.debian.org/debian-mentors/2012/01/msg00508.html
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Tue, 24 Jan 2012, Piotr Ożarowski wrote: [Octavio Alvarez, 2012-01-24] Just a note, though: the non-automatic subscription behavior of the BTS could confuse new potential package maintainers, as they might not subscribe to the corresponding bug (this has happened to me). Is it a bad idea to modify BTS or reportbug to automatically subscribe submitter in this case? No, that's actually what needs to happen; I've been procrastinating on it primarily because it looks like doing it will require writing a mailing list manager. Don Armstrong -- N: Why should I believe that? B: Because it's a fact. N: Fact? B: F, A, C, T... fact N: So you're saying that I should believe it because it's true. That's your argument? B: It IS true. -- Ploy http://www.mediacampaign.org/multimedia/Ploy.MPG http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120124182941.gi21...@rzlab.ucr.edu
mentors.debian.org as the pseudopackage (Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests)
On Tue, 17 Jan 2012, Ansgar Burchardt wrote: SUMMARY === We plan to ask for the creation of a new pseudo-package debian-mentors or mentors.debian.org [3] (contact: debian-mentors@lists.debian.org) in Debian's bug tracking system (the name is still subject to change). A workflow for handling sponsoring requests is proposed below. It is based on an earlier discussion on the debian-mentors list[1]. The workflow will also be made available on [2]. [1] http://lists.debian.org/s2svcsm447s@bistromathics.mathi.uni-heidelberg.de [2] http://wiki.debian.org/Mentors/BTS I believe that mentors.debian.org is a better name for the pseudopackage. In a brief query with DSA, they are in principle ok with having mentors.debian.org point to www.debian.org/devel/mentors (or some similar subpage in the w.d.o hierarchy) explaining the mentoring process and the workflow for the mentors.debian.org pseudopackage. From my owner@bdo perspective, I am willing to create the pseudopackage mentors.debian.org in the BTS assuming that: 1) www.debian.org/devel/mentors (or similar) has been created 2) The requirements for a psuedopackage in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544192#10 coupled with a bug report against bugs.debian.org asking for the creation of the psuedopackage. 3) DSA gives a final OK on creating the mentors.debian.org name with a redirect to that subpage. Don Armstrong -- You think to yourself, hey, it's a test tube, for God's sake. Pretty soon, though, the rush from a test tube isn't enough. You want to experiment more and more. Then before you know it, you're laying in the corner of a lab somewhere with a Soxhlet apparatus in one hand, a three neck flask in the other, strung out and begging for grant money. -- Tim Mitchell, 1994 Ig Nobel Chemistry Prize Speech http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120123220119.gc21...@rzlab.ucr.edu
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Tue, 17 Jan 2012 13:59:14 -0800, Ansgar Burchardt ans...@debian.org wrote: We propose to use the BTS to handle sponsoring requests. Both sponsorees and sponsors should already be familiar with its usage and we hope it will improve the sponsoring process for both sides. It will also make it easier to analyse sponsoring (e.g. number of requests without a response). As a non-developer, I really like this idea. Just a note, though: the non-automatic subscription behavior of the BTS could confuse new potential package maintainers, as they might not subscribe to the corresponding bug (this has happened to me). This should be noted in the documentation. In other issue tracking systems, the requester is automatically notified of any response or follow-up in the reported case. Best regards. -- Octavio. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/op.v8j7kpqp4oyyg1@alvarezp-ws
Re: Making mentors.debian.net a .org (was: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests)
On Thu, Jan 19, 2012 at 12:47:59PM +0100, Arno Töll wrote:
DSA is the team which makes a DNS CNAME record, or provides a hosting
facility. In my interpretation they are not making facts by that. Making
mentors.debian.net a .org makes the project official part of Debian,
just like any other core team, e.g. ftp-master, security team, release
team and so on. That's not something which should be decided without
consensus among Debian Developers and, perhaps, a DPL which delegates
some people to a mentors task.
Leaving legal issues aside [1], I surely agree that turning mentors.d.o
into mentors.d.o is a worthwhile goal. In our eternal quest to have
enough contributors to keep up with Debian development, mentoring is a
fundamental tool. Giving even the tiniest impression that it is a 2nd
class citizen among Debian services is not good™.
But to do so there are several constraints. The first one is, of course,
getting into an agreement with DSA, as it is up to them to maintain the
*.debian.org DNS namespace. In this specific case this is related to [1]
and I hope we can find an agreement that make everybody happy, and free
of legal risks for all involved parties.
Regarding delegation, it can be done, but it is not necessarily a
requirement. For many technical services we simply have informal teams
that are in charge of maintaining the service. I don't see why the
mentors task can't simply be such a team as, say, the QA team that
currently maintains services like the PTS or DDPO.
(There are some advantages with delegations, such as clarifying
Constitution-wise stuff like why some DDs are in some *nix groups and
some others are not. But that comes with important disadvantages, such
as institutionalizing die hard powers we should live without in most
cases. Also, if we opt for delegations, then only the DPL can change
team composition and that can easily become a barrier for contributing
to service maintenance.)
Cheers.
[1] which are being discussed in a separate sub-thread, to which I'll
come back given that I've sought in the past very similar legal
advice for Debian's PPA [2]
[2] http://lists.debian.org/debian-devel-announce/2011/06/msg0.html
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Tue, Jan 17, 2012 at 10:59:14PM +0100, Ansgar Burchardt wrote: SUMMARY === We plan to ask for the creation of a new pseudo-package debian-mentors or mentors.debian.org [3] (contact: debian-mentors@lists.debian.org) in Debian's bug tracking system (the name is still subject to change). A workflow for handling sponsoring requests is proposed below. It is based on an earlier discussion on the debian-mentors list[1]. I would like to add that FreeBSD is successfully employing a very similar mechanism. Everyone can send patches to the ports tree (=~ Debian packages) to the bug tracker as problem reports (=~ bugs). The natural solution to these reports is that a committer (=~ Debian Developer) commits (=~ uploads) the patch (=~ package) and closes the report with a message most often looking like Thanks. Committed.. While I do agree that the Debian bts is difficult for new comers at times, it is also very convenient for long term usage. I would personally benefit from the implementation of this proposal. Helmut -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120120083939.ga26...@alf.mars
Re: Making mentors.debian.net a .org (was: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests)
Jan Hauke Rahm wrote: On Fri, Jan 20, 2012 at 01:07:02AM -0500, Michael Gilbert wrote: Like I've said before, this is not about eliminating ambiguity. Every single word in every single language is ambiguous. It's simply unavoidable. It's about choosing the word with the right context for the goals of the service. That's the primary goal, yes, absolutely. Though the past shows clearly how un ambiguous terms served us with confusion, may they have been as appropriate as possible (see the DM != DM != DD != maintainer debacle). My point being, we should look for a perfectly describing term, and then make sure it's not used already in a different (or worse: a similar) context. I can see the appeal of sorting out the confusion, but whatever the new .debian.org subdomain and BTS pseudo-package get called, aren't they still going to be tied to a debian-mentors mail archive? This should be a place for contributors to come together to collaborate and make their work better before pestering a DD about it; with minimal experienced intervention (mentoring). Well, I'm not a native english speaker, though what you're describing doesn't sound like mentoring but rather training. I suspect there's a misunderstanding here; the way I read it is that Michael would like the new service to advertise itself as a place where contributors assist one another *without* experienced developers needing to train them, because that's how debian-mentors currently works; despite the name, it's a place for finding an upload sponsor, not a mentor. To mentor, as I understand it, is an action someone skilled performs in order to teach or train another person. As you said, the service provided here is for those who still learn, who are being mentored, i.e. it's actually not for mentoring. Now, I'm not sure training is the right term, as it suggests (to me) the service is something like a playground, but I can be mistaken. A native speaker should probably say something here. Are you perhaps thinking of trainers (en_US sneakers)? -- JBR - and today's single word in West Greenlandic is: Allattuivvissaaliqisarsimaqaanga I was really short of notebooks -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120120151146.ga11...@xibalba.demon.co.uk
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Michael Gilbert michael.s.gilb...@gmail.com writes: On Thu, Jan 19, 2012 at 1:07 PM, Russ Allbery wrote: For the main archive, the NEW check I think is best thought of as a spot check to ensure maintainers are doing their jobs. The real responsibility of not uploading non-redistributable material lies with the Debian project members with upload rights. ftpmaster is just checking for mistakes (at the point at which most mistakes are made). The difference for mentors is that the uploaders are not (yet) Debian project members and are not guaranteed to be trained in our licensing policies, and have not agreed to follow our rules. So, I think these concerns can be abated by thinking of mentors more of an alternative NEW queue for newcomers; rather than as an alternative package pool, which it's not (binary packages are not served, and files hosted are not widely distributed since most users wouldn't know what to do with a source package even if they got one). The problem with thinking of mentors as a NEW queue is that one of the key properties of the NEW queue is that Debian does not distribute the files in that queue. In other words, they are not retrievable by people other than those doing NEW processing until they've been approved. As long as files are kept within the project, Debian is unlikely to get in much trouble (although historically we've had to be careful about US export regulations as well), even if the software is non-redistributable. But once Debian is serving out copies of the files to the general public, via whatever means, the project (insofar as the project has a legal existence, which is admittedly weird) is responsible for that distribution, could be sued, etc. So, it would work to think of mentors as a NEW queue provided that things uploaded to it are only available to Debian project members. If they're available to the general public, it's something else. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obtyyubr@windlord.stanford.edu
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
IANAL, etc., but how about getting some legal advice on this? It seems to me it wouldn't be nearly as cut and dried as all that; have you examined whether or not such a scheme could be set up in such a way that makes it a DMCA safe harbour? Cheers, Michael On Sat, Jan 21, 2012 at 7:47 AM, Russ Allbery r...@debian.org wrote: Michael Gilbert michael.s.gilb...@gmail.com writes: On Thu, Jan 19, 2012 at 1:07 PM, Russ Allbery wrote: For the main archive, the NEW check I think is best thought of as a spot check to ensure maintainers are doing their jobs. The real responsibility of not uploading non-redistributable material lies with the Debian project members with upload rights. ftpmaster is just checking for mistakes (at the point at which most mistakes are made). The difference for mentors is that the uploaders are not (yet) Debian project members and are not guaranteed to be trained in our licensing policies, and have not agreed to follow our rules. So, I think these concerns can be abated by thinking of mentors more of an alternative NEW queue for newcomers; rather than as an alternative package pool, which it's not (binary packages are not served, and files hosted are not widely distributed since most users wouldn't know what to do with a source package even if they got one). The problem with thinking of mentors as a NEW queue is that one of the key properties of the NEW queue is that Debian does not distribute the files in that queue. In other words, they are not retrievable by people other than those doing NEW processing until they've been approved. As long as files are kept within the project, Debian is unlikely to get in much trouble (although historically we've had to be careful about US export regulations as well), even if the software is non-redistributable. But once Debian is serving out copies of the files to the general public, via whatever means, the project (insofar as the project has a legal existence, which is admittedly weird) is responsible for that distribution, could be sued, etc. So, it would work to think of mentors as a NEW queue provided that things uploaded to it are only available to Debian project members. If they're available to the general public, it's something else. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obtyyubr@windlord.stanford.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFBbO2S_=+zpnpfrubx+oj8kz5k5g82zvgyebh7-tqj83d7...@mail.gmail.com
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Michael van der Kolff mvanderko...@gmail.com writes: IANAL, etc., but how about getting some legal advice on this? It seems to me it wouldn't be nearly as cut and dried as all that; have you examined whether or not such a scheme could be set up in such a way that makes it a DMCA safe harbour? DMCA safe harbor is a property of a US law and does nothing to prevent lawsuits in Europe. That's part of the complexity. I didn't say that debian-mentors would pose legal problems necessarily, only that it's not equivalent to NEW. I know that the way Debian handles NEW is fairly legally safe because it was set up that way on the advice of lawyers. I don't know if there are other ways to set this up with different requirements and a different profile that would be equally safe. I suspect that someone would need to ask. The Debian project gets pro bono legal counsel, but one of the disadvantages of that relationship is that it's very slow to get advice on specific subjects because we ask a lot of strange questions and the amount of legal advice we can get is fairly limited. I believe the DPL is already managing a fairly long backlog of legal questions, so I wouldn't be too hopeful about getting legal advice in a particularly timely fashion. The problem with all legal issues like this is that they're very much like security issues: doing things properly and doing things improperly are almost indistinguishable in practice until a problem occurs, at which point you discover you were doing things improperly. It's very difficult to distinguish between doing the right thing and being too cautious, since they both look exactly the same on a day-to-day basis (nothing happens), and very similar to doing the wrong things and just getting lucky (likewise, nothing happens). That's why people tend towards being conservative and doing exactly the same thing as was done somewhere else, since there *is* safety in numbers in legal precedent and even accepted best practice, and you have a better chance of being warned in advance by a lawsuit against someone else. Right now, my guess is that the current debian-mentors setup is doing the wrong thing (in that few effective precautions are being taken against distributing unredistributable material) and getting lucky, in that it's both not really a target and the people using the service are generally trying to do the right thing and any uploads of non-redistributable material is both by mistake and not of the sort of thing people would sue over. But in the current environment where nonsense like SOPA and PIPA in the US are actually being seriously considered (if, thankfully, not yet passed), it's probably worth being somewhat paranoid about things that get the official imprimatur of the project. And I'm certainly not a lawyer and this is just my guess. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5t2xc4w@windlord.stanford.edu
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
But in setting it up in the US, don't you only have to care about US law? Cheers, Michael On Sat, Jan 21, 2012 at 9:06 AM, Russ Allbery r...@debian.org wrote: Michael van der Kolff mvanderko...@gmail.com writes: IANAL, etc., but how about getting some legal advice on this? It seems to me it wouldn't be nearly as cut and dried as all that; have you examined whether or not such a scheme could be set up in such a way that makes it a DMCA safe harbour? DMCA safe harbor is a property of a US law and does nothing to prevent lawsuits in Europe. That's part of the complexity. I didn't say that debian-mentors would pose legal problems necessarily, only that it's not equivalent to NEW. I know that the way Debian handles NEW is fairly legally safe because it was set up that way on the advice of lawyers. I don't know if there are other ways to set this up with different requirements and a different profile that would be equally safe. I suspect that someone would need to ask. The Debian project gets pro bono legal counsel, but one of the disadvantages of that relationship is that it's very slow to get advice on specific subjects because we ask a lot of strange questions and the amount of legal advice we can get is fairly limited. I believe the DPL is already managing a fairly long backlog of legal questions, so I wouldn't be too hopeful about getting legal advice in a particularly timely fashion. The problem with all legal issues like this is that they're very much like security issues: doing things properly and doing things improperly are almost indistinguishable in practice until a problem occurs, at which point you discover you were doing things improperly. It's very difficult to distinguish between doing the right thing and being too cautious, since they both look exactly the same on a day-to-day basis (nothing happens), and very similar to doing the wrong things and just getting lucky (likewise, nothing happens). That's why people tend towards being conservative and doing exactly the same thing as was done somewhere else, since there *is* safety in numbers in legal precedent and even accepted best practice, and you have a better chance of being warned in advance by a lawsuit against someone else. Right now, my guess is that the current debian-mentors setup is doing the wrong thing (in that few effective precautions are being taken against distributing unredistributable material) and getting lucky, in that it's both not really a target and the people using the service are generally trying to do the right thing and any uploads of non-redistributable material is both by mistake and not of the sort of thing people would sue over. But in the current environment where nonsense like SOPA and PIPA in the US are actually being seriously considered (if, thankfully, not yet passed), it's probably worth being somewhat paranoid about things that get the official imprimatur of the project. And I'm certainly not a lawyer and this is just my guess. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5t2xc4w@windlord.stanford.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cafbbo2q5lj095vujzpc0j-zjhu0nkhyyrnbc8kggbinudcu...@mail.gmail.com
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Michael van der Kolff mvanderko...@gmail.com writes: But in setting it up in the US, don't you only have to care about US law? I think that because Debian itself has a legal presence (in the sense of having a bank account and therefore assets that can be confiscated in judgement) in Europe as well as the US (and in other countries as well), things that are officially blessed by the project have to care about multiple jurisdictions. In general, you can be sued in either the location where you're doing whatever it is that you're doing or in your home location. If debian-mentors is run as a private service by a few Debian project members but not as an official part of the project, then I think only the nationality of the server and of those project members would matter. But this is all based on my very vague understanding of the complexities of international civil law, which is of course a whole field of expertise in and of itself. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3aexaq6@windlord.stanford.edu
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Wed, 18 Jan 2012, Adam Borowski wrote: Anyway, I don't think closing RFS bugs manually would be big hassle to sponsors. An additional manual step that takes time, is error-prone and brings nothing new: if the upload fails somehow, the sponsor will be the first to get notified. Personally, I always notify the sponsoree when I proceed with the upload. It would be relatively trivial to add the CC to nnn-done at this point. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119083953.ge7...@rivendell.home.ouaza.com
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.01.2012 05:32, Michael Gilbert wrote: Second concern i have here is that (AFAIK) everyone can upload everything to mentors.debian.net. Which would mean we then would/could distribute non-distribiteable material under the debian.org domain. How can this issue be resolved? The webpage only very vague says: You can upload your package to this server (through special tools like 'dupload' or 'dput') and after a few checks it will be stored in our repository. What are these few checks?! So, given the first statement above, alioth may not be the best example, but its a .org machine that is already subject to this potential problem and it seems to get along just fine. For example, www space could potentially be used to host non-distributable files, and no one is really actively checking for that. I don't recall if new users have to agree to the DMUP when they create their alioth account, but that could be a solution to the problem (on alioth as well as for mentors); perhaps with some additional wording for this type of hypothetical misuse. Alioth users do not need to agree on the DMUP or any code of conduct on that matter. Talking with Jörg in IRC yesterday about this topic I got the impression, we'd need kind of a NEW queue processing for new, unknown uploads which should be used as an ingress filter to new packages. While I was kind of expecting this answer, I do not see the possibility to implement that in the near future. That approach lacks both, code support in mentors and a list of willing people to process Mentors NEW queues. However I agree with Jörg, that that's the only clean and feasible approach in the long time perspective. Answering zobel's question: Packages which are uploaded to mentors are being tested very rudimentary. We're basically testing the package for consistency (e.g. all files present, checksums match, ..., probably very similar to what dak does) and we're running Lintian on the package, but we're not using any Lintian auto-rejects as we're kind of an archive where packages are supposed to be broken from that perspective. We're not doing any license checks, although pabs was pushing use of automated license checks. We're aware of that problem, but we're not having any implementation right now. Yet we're deleting packages where we notice they're not distributable (i.e. not even non-free). Yes, that's a post-publishing removal. Note that alioth as a .org machine can even be used as a mentors alternative today: e.g. http://alioth.debian.org/~gilbert-guest/unstable. Right. But I think having one bad example is a poor rationale to get yet another. :) Also, I would imagine that at some point someone will automate it so that RFP bug closure causes a removal of the mentors package. Thus as bugs are closed out over time, anything non-distributable will just go away. Additionally, give reviews to outright close bugs that they find in such a situation so it goes away more immediately. Right. Currently I have code in beta-testing which removes packages from mentors which are announced by dak to be accepted into unstable. Ultimately this is a rather hypothetical concern and as such deserves to be treated more on a case-by-case basis; rather assuming there is going to be a lot of abuse leading the discussion toward a strong a priori solution (in this case rejecting officialization of mentors). The problem is existing in theory, but not a real problem. This does not mean it couldn't happen. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPF/32AAoJEMcrUe6dgPNtBzkP/Aol7bC9NwurdC3gQOCNWtlx nFQhUs+Omzb7ojZBQsW8eO3j86Cxk7XECq9Sxbbz60K5d/+jEhTDUOk8PkijWWni DTLbXwvtrcKnzBg5/gQyFH3Gtj4XYdfEwCiPsLhVHaAAemxL0DalIV3/o+yMjYze Mhs9ssQIGgYj1wA8Kw8UYwn24hJGphzpCNGixs4XVl/y2XE68QlKoQr6d4aqkG3P MVHh+tjpB8cIulS5tDhlCfbsw+a0ufi9rNMRJdkbeP/cyQlNXe0Bh3dDMxZ5EyR6 8qPp6yTU1FuPlht/VXOLXpHnpY+cayQG2pPmq1vqoZacuByiSJpjxPfFRFEvCBZd jHxrgkEGeUmRE8dZBg1fgmmZ33FKcyzJKckmBuzVNmVb/cx2cph+TjBlI1+4gzEz F6rD/UWCSX8FDthxisClUAgAPf3lM9CtokkIVGY0a7brlQVaA7fZSTWb034OML/r Goo2VbVjGgnCVwlICJfhQQbriXcbGVsv7A40rKfYY/fMukBiXKez3J7McidXxSSb +ErknNDM/0bNT5MMR05ZYR/44Q/crlb/QfFjKE/fiPgsnzvRw6mmTvm9EGnreLbl f6MXk8DBLC7xjpqAe7yx3SmciXNb/pY4/fSu8F3s+Y9WcOX8E5DulKw7wW1Pbt4D Tx5P7b7mxJ2Iob6bDYQ/ =pwr9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f17fdf6.3050...@toell.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.01.2012 05:32, Michael Gilbert wrote: Second concern i have here is that (AFAIK) everyone can upload everything to mentors.debian.net. Which would mean we then would/could distribute non-distribiteable material under the debian.org domain. How can this issue be resolved? The webpage only very vague says: You can upload your package to this server (through special tools like 'dupload' or 'dput') and after a few checks it will be stored in our repository. What are these few checks?! So, given the first statement above, alioth may not be the best example, but its a .org machine that is already subject to this potential problem and it seems to get along just fine. For example, www space could potentially be used to host non-distributable files, and no one is really actively checking for that. I don't recall if new users have to agree to the DMUP when they create their alioth account, but that could be a solution to the problem (on alioth as well as for mentors); perhaps with some additional wording for this type of hypothetical misuse. Alioth users do not need to agree on the DMUP or any code of conduct on that matter. Talking with Jörg in IRC yesterday about this topic I got the impression, we'd need kind of a NEW queue processing for new, unknown uploads which should be used as an ingress filter to new packages. While I was kind of expecting this answer, I do not see the possibility to implement that in the near future. That approach lacks both, code support in mentors and a list of willing people to process Mentors NEW queues. However I agree with Jörg, that that's the only clean and feasible approach in the long time perspective. Answering zobel's question: Packages which are uploaded to mentors are being tested very rudimentary. We're basically testing the package for consistency (e.g. all files present, checksums match, ..., probably very similar to what dak does) and we're running Lintian on the package, but we're not using any Lintian auto-rejects as we're kind of an archive where packages are supposed to be broken from that perspective. We're not doing any license checks, although pabs was pushing use of automated license checks. We're aware of that problem, but we're not having any implementation right now. Yet we're deleting packages where we notice they're not distributable (i.e. not even non-free). Yes, that's a post-publishing removal. Note that alioth as a .org machine can even be used as a mentors alternative today: e.g. http://alioth.debian.org/~gilbert-guest/unstable. Right. But I think having one bad example is a poor rationale to get yet another. :) Also, I would imagine that at some point someone will automate it so that RFP bug closure causes a removal of the mentors package. Thus as bugs are closed out over time, anything non-distributable will just go away. Additionally, give reviews to outright close bugs that they find in such a situation so it goes away more immediately. Right. Currently I have code in beta-testing which removes packages from mentors which are announced by dak to be accepted into unstable. Ultimately this is a rather hypothetical concern and as such deserves to be treated more on a case-by-case basis; rather assuming there is going to be a lot of abuse leading the discussion toward a strong a priori solution (in this case rejecting officialization of mentors). The problem is existing in theory, but not a real problem. This does not mean it couldn't happen. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPF/36AAoJEMcrUe6dgPNtZVcQALOR4EnExDlShgFOBa3azu37 T69tcGgFwPVCp1NfgMj9Tl6zYw+CAaGX2Vbwx1iJE5YEftQJvYWJAE+zUnOqimFF 2KjFk+xEU0mO4l4B5P+4vrUznGYTnBa4V/EFTNQLhOW1kOaTSQZ738i401/m6bHx X/li0ozLjyrgLVpEn6D84X832CrfbwdLKVyqf212HfmALT/32J9N/0/PRE/ZpaFI nouadIV4T70kqSHdbVJy7l3IAsnmSb2VeJXIH6HLdzc6cbKt2BQCru5DuYIk6g4K DWshRynLbLoMKQKLpulQ15dNFLhxE4lKCbp8NXbnqHujlJQW/ys9bKfRfRHf7dY+ 51wcTcT9D5p5QdvELfB6TK1vdJwoOanR/HTGcKR57+P4p8vR2NMMGJLtO6+ge6Ho YTafOCEj0d4no13dIc7/Wys/30rV1u3H/kD9X4egtwWjKBYNA6mKC6zbN9A41ym4 Nx9oi1qKazfc9E810kxv67FrKpC2TezOnikckoK8E1gZNSJ2X6NSOh2yWfwTSjfc abxhSimgYl9I/liimh9xL15d8LRxRJqsOdHrI6gK2zc7HtJG6hEOqg/4JPKQP7mQ CC4njf7XdmW8JM+tj6YzghIEJyUXO+jlYPyxinOmoQiN78+eDsF0GKyPPyRvktML HQav5Y1JkyaaPN05/bAt =lwHK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f17fdfa.1040...@toell.net
Making mentors.debian.net a .org (was: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 19.01.2012 05:54, Michael Gilbert wrote: On Wed, Jan 18, 2012 at 7:43 AM, Arno Töll wrote: On 18.01.2012 08:40, Raphael Hertzog wrote: Dear DSA, do you think it's possible to have a CNAME mentors.debian.org pointing to mentors.debian.net? It's currently not hosted on a .d.o machine but AIUI the mentors.debian.net admins are interested to move it to DSA-managed host at some point. as a maintainer of mentors.d.n I can confirm our interest to make mentors an official Debian service at some point. However, we are not in a hurry to do so immediately and I believe that's something which needs consensus among developers before we can seriously consider that. What consensus (and from whom) is required here? If I interpret things correctly, the DSA team [0] is the group that need to make the call. So lets start that discussion with them (well its already started with the CC's). DSA is the team which makes a DNS CNAME record, or provides a hosting facility. In my interpretation they are not making facts by that. Making mentors.debian.net a .org makes the project official part of Debian, just like any other core team, e.g. ftp-master, security team, release team and so on. That's not something which should be decided without consensus among Debian Developers and, perhaps, a DPL which delegates some people to a mentors task. Thus, I am sending this mail to -devel again. Maybe anyone wants to raise the voice on that matter. Moreover, we're lacking Debian Developers interested to join our team which is sort of a prerequisite to integrate a team into Debian's organizational structure. I am not a DD quite yet, but I'm finishing the NM process right now, and as soon as I'm done, I will be very happy to join this team. I would hope there are quite a few other existing DDs willing to be officially part of the team as well. Is there a list of the current official members? mentors.debian.net went through several generations of developers who coded parts of it. These days only me (in NM too, but no DD yet) and Asheesh Laroia (paulproteus) made notable code contributions in the recent past. I provided Paul Wise (pabs) a root shell last week but I guess his interest in participation is mostly front-desk-like, e.g. he helps people in #debian-mentors or writing to our support address who had technical problems. I'd be more than happy finding _anyone_ interested to work on our (Python/Pylon/sqlalchemy) code base. We have really long todo list. Anyway, I think if we can get people behind this, we would want to make it happen quickly, then the mentors.debian.org psuedo-package would be available, and we could straightforwardly implement the bug-based RFP process. That's the plan, but again: tracking sponsor requests as bugs, and integrate mentors.debian.net into Debian are unrelated problems. Any proposal can be implemented without touching the status-quo of the other. The term contributor conveys a much more welcoming message as it says this is the place where I can go to learn about start making contributions to debian, and this is where we can go to help people become contributors. That's the problem. A contributor can have many roles in Debian, it is overbooked just like terms such as DSA and maintainer (albeit zack suggested to come over the latter problem). That said, I don't mind any other, better name than debian-mentors or mentors.debian.tld, but contributor probably isn't. YMMV. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPGALvAAoJEMcrUe6dgPNt8poQAIN14n/rxWcax7NQsYraW73c 2AILwLMuW3N8YKi4iri7+C+l7hCbWwA81yxQbVIZWx1bnOohN3PSKPAle4hO/L3X 19z4U3/4kq/r8T3YfS3wC39UX6MpI1VkfBhvF8Kr+qULo9t+Lra9l75ZI1L1BkEX obdrkLGEbv0jVoc6b3lhGiFLpTHusUOp80/huAADI4ZG8c1vPO5+WeCh70CtEG80 W2tlgefHN4HP0c/h8J3QCR/fGdx/KVTWd6Ggh6gySs3unhz4sF8kA+jcBAyYZfvY vyeZ13rcgL41Q772JnbndtDAghTCRmeuiVdqsYlCvG3+raFt0l3nqWeIGHhK6ySW b5Gd+LBmsrWQvrBDLid83bF1IhlyOdNFfv5T3jQeaOnAJMcijgWsnWin7UpzGJC/ l+GWfuOjvrTsaxz82bIwsqycTJvwfqPCq/8qEUJjxKpvjxEGZWz4YN2hgkX4qOD9 8osFtkyn7AeWuNlEt2G4AuWkwTcOJte9Et1qvAsm7C2qrFsS7D1NYQr+XhJqJb8T 7zdtg1gdYmPbvt8HE9oWJqJuE2XN7pQo81AshBHoWGtOcFSz3J+NSRnAERSZPlg5 kvMSdEDUfLzu75l5IqVJ4pL4ZfMfDOXjuPk/FaJlJPw4IBSsj/vK/WIYnoBfnhKm j96Vy09UryEzazWEQ7T9 =dVDg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1802ef.7050...@toell.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Hi! Am 19.01.2012 12:26, schrieb Arno Töll: On 19.01.2012 05:32, Michael Gilbert wrote: Second concern i have here is that (AFAIK) everyone can upload everything to mentors.debian.net. Which would mean we then would/could distribute non-distribiteable material under the debian.org domain. How can this issue be resolved? [..] We're not doing any license checks, although pabs was pushing use of automated license checks. We're aware of that problem, but we're not having any implementation right now. Yet we're deleting packages where we notice they're not distributable (i.e. not even non-free). Yes, that's a post-publishing removal. Hmmm... What about making the orig tarballs only accessible from Debian machines? In theory only sponsors need it, and sponsors have access to these machines. diff.gz/debian.tar.gz could still be accessible to all, so non-DDs could still at least do (limited) reviews. And with a proper get-orig-source rule (or a way on mentors to provide a link to the source tarball?) even full reviews by non-DDs would be possible. Best regards, Alexander -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f180554@schmehl.info
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 19.01.2012 12:58, Alexander Reichle-Schmehl wrote: Hmmm... What about making the orig tarballs only accessible from Debian machines? In theory only sponsors need it, and sponsors have access to these machines. I am not sure if that's the right message to send to people. We want and push anyone, including non-sponsors to review packages. We believe everyone can learn from other people's packaging styles - for good or not. There are quite a lot of people doing reviews and look at packages. Your workaround complicates handling with source packages to non-developers a lot, and even developers can be scared off by that requirement. A substantial problem in our whole approach is to attract Debian Developers to sponsoring again. If we're complicating access to packages, that's sort of counterproductive. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPGBkSAAoJEMcrUe6dgPNtktkQAJgd5tO5/s7SwV2ELK/XvUKm 78OXDbx8i3L7lct90WgDle/YHOceVNhYrd1aEJ8a1hfHwe62/+F7RZHva6qA54KV tSHWhvd3IfilMTkQHxYkXRjs9Am3Atlrwe8hzh1URnB/MvYIPtZdGfzKENU0Aaz+ NfEVujVwj5zdztZ2Xv5zwynumUzKiPeSjCT9J0RSReOc29ZdH62GuY0MgTMzHgL0 SUapmfnNh5QKNENTG5cZsMWkELULd8oi3hpyf3UE/uqXaA7qHQTFSgQRft15KmKD VDJIUWUsRb70+2jLdhdSZsbNgFvO4jDn+g+8cqPvDIY72WGxMrt4ReO4gg+h8uaQ d0VkALe8V7TlkQiCiREDN5tLue8gt5//jMAwvTXafFGFDvpgJwKfOCBDfYD1nkFl InXvX+A2B6MIzALYEaVcmbhqxJx9kENKXh365DXo56vlx0782KWll5WmU+dG+2fa LMl5JFz9QVggQCF6+Ho+epYvXjXuy1Ujj8OZDp7mqrDrZs2dW1bjMfaZ4hp3ckcZ XR73sBVTjf9mbeTECIlytPTsIc4F5m3XmxoQqaUUS9Thg4FHCq1YbMVUBD48RfJ9 6GGzZgJBe+qKRc94M5V1seIf5OTOzqoS8+fUi27e/js77GY+XhfOEmZQEQN77zUs FNMIsWbl0DJVzRoE2Pn8 =xLxH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f181912.8020...@toell.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Hi! Am 19.01.2012 14:22, schrieb Arno Töll: Hmmm... What about making the orig tarballs only accessible from Debian machines? In theory only sponsors need it, and sponsors have access to these machines. I am not sure if that's the right message to send to people. We want and push anyone, including non-sponsors to review packages. We believe everyone can learn from other people's packaging styles - for good or not. There are quite a lot of people doing reviews and look at packages. Your workaround complicates handling with source packages to non-developers a lot, and even developers can be scared off by that requirement. A substantial problem in our whole approach is to attract Debian Developers to sponsoring again. If we're complicating access to packages, that's sort of counterproductive. Well, don't take it wrong: Mentors is a very usefull service, it was a just an idea which might allow you to become mentors.debian.org. As said, I don't think there's a problem distribute .dsc and diff.gz/debian.tar.gz files. (which still allows a limited review.) About the orig tarball... Well, in many cases it's available somewhere else for download already. So maybe mentors could have a Get tarball here entry where sponsorees can place an URL. (No security risk; you can sill verify if the sponsorees and the downloaded tarball match.) And then it's only a minor step to a dget-mentors-Script (or maybe a patch for dget to automatically take a look at the url field, when downloading from mentors). Granted, not a really good solution, but doable. Best regards, Alexander -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f18290d.3070...@schmehl.info
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Tue, Jan 17, 2012 at 10:59:14PM +0100, Ansgar Burchardt wrote: SUMMARY === We plan to ask for the creation of a new pseudo-package debian-mentors or mentors.debian.org [3] (contact: debian-mentors@lists.debian.org) in Debian's bug tracking system (the name is still subject to change). A workflow for handling sponsoring requests is proposed below. It is based on an earlier discussion on the debian-mentors list[1]. This is a really smart, simple and good idea to use the BTS. I sometimes just keep the RFS packages which get no replies marked as unread in mutt for keeping a track on this and try to help people (not that much recently, duties in real life don't give that much time for me), but if this idea gets to be implemented I am sure we'll have a better panorama of the packages that need to be uploaded. On the other hand I found just great the REVIEWING packages section. This is a key for attracting more contributors, because the sponsoring process can be really frustrating sometimes. In addition, the confirmed tag is really nice because it allows others with no upload rights to start doing revisions and that will facilitate (in some cases of course) the work of the ones who have upload rights and will help themselves because they will learn more about the Debian Policy. I know my mail does not contribute in some sense to this proposal, but I just felt the *need* of writing how great I found it. On the other hand, I don't find as a hassle the fact that sponsors have to close the reports manually. DRIVERS === Ansgar Burchardt Jakub Wilk Arno Töll gregor herrmann Congratulations to the $DRIVERS :) Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119151507.ga32...@ihacku.debian.org
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello again, for the record, as we talked in IRC: On 19.01.2012 15:30, Alexander Reichle-Schmehl wrote: Well, don't take it wrong: Mentors is a very usefull service, it was a just an idea which might allow you to become mentors.debian.org. I didn't take it so. I fully appreciate any suggestions which are doable to us. I do also respect Zobel's requirement to make sure, we allow access to distributable packages only which is only fair. As said, I don't think there's a problem distribute .dsc and diff.gz/debian.tar.gz files. (which still allows a limited review.) Discussing the idea, I pointed out, you can still hide non-distributable files in debian.tar.gz if you really wanted to, in times on 3.0/quilt. That pretty much rules out this idea, sadly. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPGD9lAAoJEMcrUe6dgPNtmTgQAIOZmq9qJ5vHRAWn9CirMPu3 9ti0tzBmkVNf9QgMTJBNTyFw9U/ty5XmIUn1kfw45fqV5LE06nbHLrE4NAwD02Tl X7P3lLv0dwgG0cPXUl960K8durHEfMogNIffwf2jNgSvf9yReHG3sOjDZDXgilGu UZfNX4gsLhzX6FzZLkozr7jFBZ+fz/QA8IztPSDYeaBOV520E5OzpNWtRUtK9Ms8 wvBQoHoYHtO5LjEno96XlJeoSKNMm7AuMMZo01Fwm7kP3+PGx81q2U8jgv8LQEBg aN50ZJhO9qxD/mX1qpE++hSzGdgwyWFWAKscMFkcZuPkeY+/r257reu9/VHAC+Fc BwTycahomMdTmhxbiM9VMqzoqRLcIjy6L5tb1E/gyACPQi8QN7qAGJ8/n/eroDUm +xaHN4KMT40IGtqRX0Yz0BxHUQcPAmscOsNrTY3pvdztav2ipCLA+i7hGfvbYe4c 5lzR/j5i90X72yEy9BTq6d6EZIhVI7tbNfEuy69i+SKfEbRvXLtT4hHWGTaCc69S XSp/MiAzNUVb+PdpR32KWHJoLILKdJiXKBjq8Sj/QCv15mh/B3EAD+FS6mAk5+Wp 2Aep5w5kZqSouvO7h0eaAp6Un3081s5AUO+xMbu1J0Nj0KUkNRdd8PccJ/uFvtMT ZPMBu1GbJ5vETW85SC6d =WP2z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f183f65.9060...@toell.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Alexander Reichle-Schmehl alexan...@schmehl.info writes: Am 19.01.2012 12:26, schrieb Arno Töll: On 19.01.2012 05:32, Michael Gilbert wrote: Second concern i have here is that (AFAIK) everyone can upload everything to mentors.debian.net. Which would mean we then would/could distribute non-distribiteable material under the debian.org domain. How can this issue be resolved? [..] We're not doing any license checks, although pabs was pushing use of automated license checks. We're aware of that problem, but we're not having any implementation right now. Yet we're deleting packages where we notice they're not distributable (i.e. not even non-free). Yes, that's a post-publishing removal. Hmmm... What about making the orig tarballs only accessible from Debian machines? In theory only sponsors need it, and sponsors have access to these machines. Possibly stupid idea, but.. what if an ftp-master trainee or someone similar would preview packages uploaded to mentors? [*] I might be mistaken, but the amount of NEW stuff isn't all that huge, and this review would concentrate on distributability alone, so would be fairly fast in most cases. This would introduce a noticable delay to uploaded packages (in the meantime, the package could be made available from .d.o hosts or so, would anyone want to review the package before it leaves mentors-NEW). On the other hand, having done a preliminary license check at the time it was uploaded to mentors, that note could be passed on to ftp-masters once the package hits the real NEW, thus, reducing their work a little. This way, mentors.d.o gets licence review, the work to be done once the package enters NEW gets reduced, the package would be available to DDs before the license check, to everyone else too afterwards - pretty much everyone wins! -- |8] [*]: Search this email's headers for an answer to a question that's bound to be asked. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762g7bqyj.fsf@algernon.balabit
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
* Gergely Nagy alger...@balabit.hu, 2012-01-19, 17:24: I might be mistaken, but the amount of NEW Why only NEW? Checking only NEW packages doesn't buy us more than, say, checking only package with with have r in their name. I know, this is what ftp-folks do. I call this securi^Wdistributability theater. stuff isn't all that huge, and this review would concentrate on distributability alone, so would be fairly fast in most cases. Might be fast, but it's also boooring. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119165845.ga8...@jwilk.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Arno Töll deb...@toell.net writes: On 19.01.2012 15:30, Alexander Reichle-Schmehl wrote: As said, I don't think there's a problem distribute .dsc and diff.gz/debian.tar.gz files. (which still allows a limited review.) Discussing the idea, I pointed out, you can still hide non-distributable files in debian.tar.gz if you really wanted to, in times on 3.0/quilt. That pretty much rules out this idea, sadly. Also, even without worrying about malice, unified diffs include substantial portions of the original code. If the original code is not redistributable, the unified diff of a patch is going to be a derivative work in most cases and also won't be redistributable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vco7effz@windlord.stanford.edu
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Jakub Wilk jw...@debian.org writes: * Gergely Nagy alger...@balabit.hu, 2012-01-19, 17:24: I might be mistaken, but the amount of NEW Why only NEW? Checking only NEW packages doesn't buy us more than, say, checking only package with with have r in their name. I know, this is what ftp-folks do. I call this securi^Wdistributability theater. For the main archive, the NEW check I think is best thought of as a spot check to ensure maintainers are doing their jobs. The real responsibility of not uploading non-redistributable material lies with the Debian project members with upload rights. ftpmaster is just checking for mistakes (at the point at which most mistakes are made). The difference for mentors is that the uploaders are not (yet) Debian project members and are not guaranteed to be trained in our licensing policies, and have not agreed to follow our rules. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4yvefcq@windlord.stanford.edu
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Thu, Jan 19, 2012 at 10:07:01AM -0800, Russ Allbery wrote: Jakub Wilk jw...@debian.org writes: * Gergely Nagy alger...@balabit.hu, 2012-01-19, 17:24: I might be mistaken, but the amount of NEW Why only NEW? Checking only NEW packages doesn't buy us more than, say, checking only package with with have r in their name. I know, this is what ftp-folks do. I call this securi^Wdistributability theater. For the main archive, the NEW check I think is best thought of as a spot check to ensure maintainers are doing their jobs. The real responsibility of not uploading non-redistributable material lies with the Debian project members with upload rights. ftpmaster is just checking for mistakes (at the point at which most mistakes are made). The difference for mentors is that the uploaders are not (yet) Debian project members and are not guaranteed to be trained in our licensing policies, and have not agreed to follow our rules. ...which means that a signed SC DMUP would suffice. To be honest, I don't even see the how mentors being on debian.net instead of debian.org actually does a difference legally. Both domains belong to SPI and are maintained but Debian people -- granted, maintenance is technically different but, standing in front of a judge, I don't think anyone would actually care whether you set a CNAME or asked DSA to do it. Yes, the machine actually holding the data is outside DSA's reach, but then again, it's a DD with his DD hat on who decided to set the CNAME to offer a service for people interested in Debian. IANAL though. And we don't need to discuss the merit of debian.net here. My actual point is in the way shorter half sentence above. Hauke -- .''`. Jan Hauke Rahm j...@debian.org www.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Hi, I'm generally not a big fan to overuse the BTS for stuff it wasn't really designed for. This tends to result in complex processes that are difficult to follow for newcomers. For example, the wnpp bugs are often misformed, or people don't follow the right process. * Integration into UDD bug search[2] [2] http://udd.debian.org/bugs.cgi It might be better to write a separate cgi for that, to add more specific logic. For example, you could easily split the list with: - new packages - new uploads for existing packages - packages already uploaded (RFS that should be closed) - RFS that couldn't be parsed Note that UDD bugs data is only refreshed every ~6 hours (but this might change soon as DSA is looking into replacing the machine with a newer one). Lucas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119182739.ga12...@xanadu.blop.info
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
* Lucas Nussbaum lu...@debian.org, 2012-01-19, 19:27: I'm generally not a big fan to overuse the BTS for stuff it wasn't really designed for. This tends to result in complex processes that are difficult to follow for newcomers. For example, the wnpp bugs are often misformed, or people don't follow the right process. The big difference is that nobody reads the wnpp bug traffic. But debian-mentors (or whatever the pseudo-package will be eventually called) bug traffic will land on this mailing list. Malformed bug titles will be promptly corrected, people don't following the process will be educated. :) * Integration into UDD bug search[2] [2] http://udd.debian.org/bugs.cgi It might be better to write a separate cgi for that, to add more specific logic. For example, you could easily split the list with: - new packages - new uploads for existing packages - packages already uploaded (RFS that should be closed) - RFS that couldn't be parsed Or we could write a bot that would usertag the bugs appropriately. Then you could use normal BTS view rather than UDD. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119190233.ga1...@jwilk.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Thu, Jan 19, 2012 at 1:27 PM, Lucas Nussbaum wrote: Hi, I'm generally not a big fan to overuse the BTS for stuff it wasn't really designed for. This tends to result in complex processes that are difficult to follow for newcomers. That statement actually describes the Debian project as a whole (not just bts-using services/teams). There are extensive processes in Debian for everything, and as such its not going to necessarily be easy for any newcomer. Then again, that may not be such a bad thing as it means that *qualified* newcomers have already demonstrated the fact that they can educate themselves. If that means answering similar questions somewhat regularly, so be it. A simple link to the developers reference often suffices. That's not so hard. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnsl35_ojnh7fn1a4ufb_jx2jcsk22zebsatw+tscx...@mail.gmail.com
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Thu, Jan 19, 2012 at 1:07 PM, Russ Allbery wrote: Jakub Wilk jw...@debian.org writes: * Gergely Nagy alger...@balabit.hu, 2012-01-19, 17:24: I might be mistaken, but the amount of NEW Why only NEW? Checking only NEW packages doesn't buy us more than, say, checking only package with with have r in their name. I know, this is what ftp-folks do. I call this securi^Wdistributability theater. For the main archive, the NEW check I think is best thought of as a spot check to ensure maintainers are doing their jobs. The real responsibility of not uploading non-redistributable material lies with the Debian project members with upload rights. ftpmaster is just checking for mistakes (at the point at which most mistakes are made). The difference for mentors is that the uploaders are not (yet) Debian project members and are not guaranteed to be trained in our licensing policies, and have not agreed to follow our rules. So, I think these concerns can be abated by thinking of mentors more of an alternative NEW queue for newcomers; rather than as an alternative package pool, which it's not (binary packages are not served, and files hosted are not widely distributed since most users wouldn't know what to do with a source package even if they got one). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNcnpW_kNuX=MD=4mo04tzdqcigk+tuym1_c2thdx8...@mail.gmail.com
Re: Making mentors.debian.net a .org (was: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests)
On Thu, Jan 19, 2012 at 6:47 AM, Arno Töll wrote: DSA is the team which makes a DNS CNAME record, or provides a hosting facility. In my interpretation they are not making facts by that. Making mentors.debian.net a .org makes the project official part of Debian, just like any other core team, e.g. ftp-master, security team, release team and so on. That's not something which should be decided without consensus among Debian Developers and, perhaps, a DPL which delegates some people to a mentors task. Thus, I am sending this mail to -devel again. Maybe anyone wants to raise the voice on that matter. I don't think it is possible to gain a consensus of debian developers. There is of course the option of a GR, but those are a nightmare and have unintended consequences. DSA decides what services they host, so we only need to convince them that a mentors machine wouldn't be a burden. Anyway, I think if we can get people behind this, we would want to make it happen quickly, then the mentors.debian.org psuedo-package would be available, and we could straightforwardly implement the bug-based RFP process. That's the plan, but again: tracking sponsor requests as bugs, and integrate mentors.debian.net into Debian are unrelated problems. Any proposal can be implemented without touching the status-quo of the other. They are intimately related as we need a pseudo-package to even begin the bug-based workflow, and that needs to be a .org. So the official domain is required first. The term contributor conveys a much more welcoming message as it says this is the place where I can go to learn about start making contributions to debian, and this is where we can go to help people become contributors. That's the problem. A contributor can have many roles in Debian, it is overbooked just like terms such as DSA and maintainer (albeit zack suggested to come over the latter problem). Like I've said before, this is not about eliminating ambiguity. Every single word in every single language is ambiguous. It's simply unavoidable. It's about choosing the word with the right context for the goals of the service. This should be a place for contributors to come together to collaborate and make their work better before pestering a DD about it; with minimal experienced intervention (mentoring). This is to attempt to help solve the problem that practically no DDs want to be burdened with mentoring. Let's make this about contributors primarily helping themselves. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPdOiDpk71kPfmMOcTTCOQSW0CeRDqKy0x0t=7txdv...@mail.gmail.com
Re: Making mentors.debian.net a .org (was: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests)
I'm putting the l10n-english team in BCC as they *might* want to help us out here but I don't really want to start cross-posting. You'll figure out which list to proceed on, right? On Fri, Jan 20, 2012 at 01:07:02AM -0500, Michael Gilbert wrote: On Thu, Jan 19, 2012 at 6:47 AM, Arno Töll wrote: The term contributor conveys a much more welcoming message as it says this is the place where I can go to learn about start making contributions to debian, and this is where we can go to help people become contributors. That's the problem. A contributor can have many roles in Debian, it is overbooked just like terms such as DSA and maintainer (albeit zack suggested to come over the latter problem). Like I've said before, this is not about eliminating ambiguity. Every single word in every single language is ambiguous. It's simply unavoidable. It's about choosing the word with the right context for the goals of the service. That's the primary goal, yes, absolutely. Though the past shows clearly how un ambiguous terms served us with confusion, may they have been as appropriate as possible (see the DM != DM != DD != maintainer debacle). My point being, we should look for a perfectly describing term, and then make sure it's not used already in a different (or worse: a similar) context. This should be a place for contributors to come together to collaborate and make their work better before pestering a DD about it; with minimal experienced intervention (mentoring). Well, I'm not a native english speaker, though what you're describing doesn't sound like mentoring but rather training. To mentor, as I understand it, is an action someone skilled performs in order to teach or train another person. As you said, the service provided here is for those who still learn, who are being mentored, i.e. it's actually not for mentoring. Now, I'm not sure training is the right term, as it suggests (to me) the service is something like a playground, but I can be mistaken. A native speaker should probably say something here. Hauke -- .''`. Jan Hauke Rahm j...@debian.org www.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Quoting Ansgar Burchardt (ans...@debian.org): SUMMARY === snip As someone who often sponsors packages (mostly related to packaging teams I'm part of, sometimes for l10n-related stuff, sometimes because someone I know just asked me about this and I fee like I have enough knowledge to decide about the package being OK to sponsor), I wholeheartedly welcome this proposal. It is obviously well designed and easy to follow. Maybe someone will find a minor detail to adapt here or there, but I see no reason to block in any way its adoption. Contragulations to everybody involved in the proposal design. That's really great job. signature.asc Description: Digital signature
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
* Eugene V. Lyubimkin jac...@debian.org, 2012-01-18, 12:19: If you changed the package to address concerns, please send a follow-up to the sponsoring request (To: n...@bugs.debian.org) that includes the URL to the source package and the last changelog entries similar to the initial request. What would sponsoree do for the follow-up RFSes, i.e. new version of the package is prepared and a sponsor is wanted again? Re-open the bug or create new one? If the old bug is closed, I think we should require (or at least strongly encourage) creating a new one. My reasons are as follows: 1) One of the reasons we introduced BTS-based workflow is that we want to keep count of packages being (not) sponsored. Reopening existing bugs makes it harder. 2) It's too easy to just throw reopen NN at control@bugs.d.o without providing additional information that you would normally include in a new bug report. 3) Control messages would create (unnecessary in this case) mail traffic on the mailing list. It shall be noted that maintainers of the other pseudo-package that is mainly used for tracking requests (namely release.debian.org) also strongly prefer opening new bugs over reopening old ones. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120118115424.ga2...@jwilk.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 18.01.2012 08:40, Raphael Hertzog wrote: Dear DSA, do you think it's possible to have a CNAME mentors.debian.org pointing to mentors.debian.net? It's currently not hosted on a .d.o machine but AIUI the mentors.debian.net admins are interested to move it to DSA-managed host at some point. as a maintainer of mentors.d.n I can confirm our interest to make mentors an official Debian service at some point. However, we are not in a hurry to do so immediately and I believe that's something which needs consensus among developers before we can seriously consider that. Moreover, we're lacking Debian Developers interested to join our team which is sort of a prerequisite to integrate a team into Debian's organizational structure. We are in a fairly comfortable hardware situation for the time being too, so there is no urgent need for DSA to provide us hardware to host mentors. That said, if DSA feels comfortable to provide us a debian.org CNAME, or wants to host our service, I think nobody from our side will object that. It is indeed unfortunate to eventually have a mentors.debian.org pseudo-package but no such host, which is why we suggested debian-mentors instead. That said, I fully understand Don's argument to prefer URLs over names which could possibly clash with existing packages. Finally I'd like to point out, that the pseudo-package we are suggesting does not at all integrate any workflow based on the mentors.debian.net service (yet). So, any bug tracked in such a package would not be directly related to any particular workflow on Debexpo (i.e. the software). Therefore I would be fine with mentors.debian.org as a CNAME pointing to a static page hosted on the Debian CMS, e.g. say http://www.debian.org/mentors/ for now. That site would only contain a landing page with links to the debian-mentors list (archives) and mentors.debian.net or something similar. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPFr5mAAoJEMcrUe6dgPNty7kP/3zlMhsFbxkSX6oClHtXt0WE rLnUtO8wqPGKLmZoC3+QJxeZnYbz9L03owdEsiD1k7VUKaRvDf2y9Bgk+dDHfH60 HPJrfsBIGEz532QX/Fyk3Xnor16AZ9gHkG+SdFpw+5G4DsZdXHqAyuZG+Z8RYSwk 3ti4KjTxp9neExA5AuqyZiHUAOHPuq/axh5GrQiTRDjefeCenChldh7GB/oHo2Wp QCawYcbPVI3KSvKmPQ+p25/V2ObSXeuPQK77nVQt95FxObd7e64XFmDw98X6Ea5L TGAkob1VBC31+YdUE+hYMV0lhrF5T4gesA4OIc7v6NobOj9yiZ/nc10Sv7GgDHW1 5XJVVQ9aZM/OdPKjk5cBHN6/wbsHyodmWMEkhQRQLe/OAXJfbOvM6ot4Z29ewc09 uRocO45Rd9CgkYiOCR07bheCfnLTDgC9FSlza6mLTyFl9CfWF2lYXOdWAkWHdVUG pqk6M5AhQsguVuCLcD2d9rs+Pd5hSnxr5OS+LykM7U3UzN2fXeOdeNQbEbwFUGkS PFcjqLxB578d9b6QNaTrAuwYn1N+Dd2AoSNpzRlgdT1yjwVsukBQgXVH8SRGZeaO MSFXNE+1wXzkyWEuuG7D+TKC7o6fGGuw3TAqHZ9dfpOe2deCIie+3y1x0otnUSS5 x6HsbNJN12Cp6PwLZvTW =3BPG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f16be66.4050...@toell.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Eugene V. Lyubimkin jac...@debian.org writes: If you changed the package to address concerns, please send a follow-up to the sponsoring request (To: n...@bugs.debian.org) that includes the URL to the source package and the last changelog entries similar to the initial request. What would sponsoree do for the follow-up RFSes, i.e. new version of the package is prepared and a sponsor is wanted again? Re-open the bug or create new one? Once a package has been uploaded, the request should only be reopened when the upload was rejected by the archive later (eg. manual reject from NEW, signature problems, ...). For new releases a new request should be filed instead. If the version number changes before an upload (for example when a new upstream version was released before the package was sponsored), the sponsoree should send a follow-up to the current request and retitle it to include the new version number. My reasoning is that issues should hopefully be addressed once a package has been uploaded and no longer apply to the next request, they only make the bug log longer. In contrast they might still apply when there was no upload. Regards, Ansgar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/s2s62g9xll1@bistromathics.mathi.uni-heidelberg.de
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Tue, Jan 17, 2012 at 10:59:14PM +0100, Ansgar Burchardt wrote: UPLOADING PACKAGES -- After you uploaded a package, please close the bug report by sending a mail to nnn-d...@bugs.debian.org. Do not close RFS bugs in debian/changelog. It is the sponsor who solves the issue, not the supplier of the package or anyhow related to the package itself. Perhaps instead of requiring a manual close, the bug should be closed automatically when the package is accepted? -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Hi, On Wed Jan 18, 2012 at 08:40:34 +0100, Raphael Hertzog wrote: Dear DSA, do you think it's possible to have a CNAME mentors.debian.org pointing to mentors.debian.net? It's currently not hosted on a .d.o machine but AIUI the mentors.debian.net admins are interested to move it to DSA-managed host at some point. First all, DSA will not point a debian.org entry to a machine that is not maintained by DSA (only exception here for historical reasons is alioth). Second concern i have here is that (AFAIK) everyone can upload everything to mentors.debian.net. Which would mean we then would/could distribute non-distribiteable material under the debian.org domain. How can this issue be resolved? The webpage only very vague says: You can upload your package to this server (through special tools like 'dupload' or 'dput') and after a few checks it will be stored in our repository. What are these few checks?! Cheers, Martin -- Martin Zobel-Helas zo...@debian.org | Debian System Administrator Debian GNU/Linux Developer | Debian Listmaster GPG key http://go.debian.net/B11B627B | GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120118142649.gi2...@ftbfs.de
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
* Adam Borowski kilob...@angband.pl, 2012-01-18, 14:15: UPLOADING PACKAGES -- After you uploaded a package, please close the bug report by sending a mail to nnn-d...@bugs.debian.org. Do not close RFS bugs in debian/changelog. It is the sponsor who solves the issue, not the supplier of the package or anyhow related to the package itself. Perhaps instead of requiring a manual close, the bug should be closed automatically when the package is accepted? Thanks for volunteering to implement this feature! ;) Do you imply that the RFS should be kept open while the package is sitting in the NEW queue? I'm not sure if this is what we want. Anyway, I don't think closing RFS bugs manually would be big hassle to sponsors. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120118202746.ga7...@jwilk.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Wed, Jan 18, 2012 at 09:27:46PM +0100, Jakub Wilk wrote: * Adam Borowski kilob...@angband.pl, 2012-01-18, 14:15: UPLOADING PACKAGES -- After you uploaded a package, please close the bug report by sending a mail to nnn-d...@bugs.debian.org. Do not close RFS bugs in debian/changelog. It is the sponsor who solves the issue, not the supplier of the package or anyhow related to the package itself. Perhaps instead of requiring a manual close, the bug should be closed automatically when the package is accepted? Thanks for volunteering to implement this feature! ;) I guess there are folks with a lot more clue about DAK and friends than me. One way to do this would be debian-*-chan...@lists.debian.org → procmail → 123456-d...@bugs.debian.org. Do you imply that the RFS should be kept open while the package is sitting in the NEW queue? I'm not sure if this is what we want. Good point. RFS is supposed to be for a single upload, a reject by a ftpmaster can be considered to be the equivalent of a RC bug -- you need to upload again. So it'd be a matter of closing the RFS bug whenever the upload succeeds, no matter what happens later. Anyway, I don't think closing RFS bugs manually would be big hassle to sponsors. An additional manual step that takes time, is error-prone and brings nothing new: if the upload fails somehow, the sponsor will be the first to get notified. -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Hi, I just wanted to join the growing chorus of supporter for this proposal. I think its wonderful, and that's only partially because I resurrected the discussion a few months ago. On Wed, Jan 18, 2012 at 9:26 AM, Martin Zobel-Helas wrote: Hi, On Wed Jan 18, 2012 at 08:40:34 +0100, Raphael Hertzog wrote: Dear DSA, do you think it's possible to have a CNAME mentors.debian.org pointing to mentors.debian.net? It's currently not hosted on a .d.o machine but AIUI the mentors.debian.net admins are interested to move it to DSA-managed host at some point. First all, DSA will not point a debian.org entry to a machine that is not maintained by DSA (only exception here for historical reasons is alioth). Second concern i have here is that (AFAIK) everyone can upload everything to mentors.debian.net. Which would mean we then would/could distribute non-distribiteable material under the debian.org domain. How can this issue be resolved? The webpage only very vague says: You can upload your package to this server (through special tools like 'dupload' or 'dput') and after a few checks it will be stored in our repository. What are these few checks?! So, given the first statement above, alioth may not be the best example, but its a .org machine that is already subject to this potential problem and it seems to get along just fine. For example, www space could potentially be used to host non-distributable files, and no one is really actively checking for that. I don't recall if new users have to agree to the DMUP when they create their alioth account, but that could be a solution to the problem (on alioth as well as for mentors); perhaps with some additional wording for this type of hypothetical misuse. Note that alioth as a .org machine can even be used as a mentors alternative today: e.g. http://alioth.debian.org/~gilbert-guest/unstable. Also, I would imagine that at some point someone will automate it so that RFP bug closure causes a removal of the mentors package. Thus as bugs are closed out over time, anything non-distributable will just go away. Additionally, give reviews to outright close bugs that they find in such a situation so it goes away more immediately. Ultimately this is a rather hypothetical concern and as such deserves to be treated more on a case-by-case basis; rather assuming there is going to be a lot of abuse leading the discussion toward a strong a priori solution (in this case rejecting officialization of mentors). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=movanzdts1jbrhkn0yz6157hjqkvc85rhxnhzgftzr...@mail.gmail.com
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Wed, Jan 18, 2012 at 7:43 AM, Arno Töll wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 18.01.2012 08:40, Raphael Hertzog wrote: Dear DSA, do you think it's possible to have a CNAME mentors.debian.org pointing to mentors.debian.net? It's currently not hosted on a .d.o machine but AIUI the mentors.debian.net admins are interested to move it to DSA-managed host at some point. as a maintainer of mentors.d.n I can confirm our interest to make mentors an official Debian service at some point. However, we are not in a hurry to do so immediately and I believe that's something which needs consensus among developers before we can seriously consider that. What consensus (and from whom) is required here? If I interpret things correctly, the DSA team [0] is the group that need to make the call. So lets start that discussion with them (well its already started with the CC's). Moreover, we're lacking Debian Developers interested to join our team which is sort of a prerequisite to integrate a team into Debian's organizational structure. I am not a DD quite yet, but I'm finishing the NM process right now, and as soon as I'm done, I will be very happy to join this team. I would hope there are quite a few other existing DDs willing to be officially part of the team as well. Is there a list of the current official members? Perhaps we send a message to -devel looking for additional volunteers? For now, who on this list would want to be a part of the official team? Anyway, I think if we can get people behind this, we would want to make it happen quickly, then the mentors.debian.org psuedo-package would be available, and we could straightforwardly implement the bug-based RFP process. As a small aside on the matter of naming, I would like to again try to suggest a more empowering term like contributors instead of mentors. Going through this officialization process is an opportunity to rethink the message conveyed by the site name (since the domain name is changing anyway). The term contributor conveys a much more welcoming message as it says this is the place where I can go to learn about start making contributions to debian, and this is where we can go to help people become contributors. The mentors term far too heavily sways the discussion toward the needs/demands of the mentor. Anyway, a major danger of bike-shedding here, but words do have significant meaning, and we should put the critical thought in to getting it right. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MOMCb2Zxb3S7hubhXPO5cracGjAs9xxskYKMGNN0Vp=h...@mail.gmail.com
proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
SUMMARY === We plan to ask for the creation of a new pseudo-package debian-mentors or mentors.debian.org [3] (contact: debian-mentors@lists.debian.org) in Debian's bug tracking system (the name is still subject to change). A workflow for handling sponsoring requests is proposed below. It is based on an earlier discussion on the debian-mentors list[1]. The workflow will also be made available on [2]. [1] http://lists.debian.org/s2svcsm447s@bistromathics.mathi.uni-heidelberg.de [2] http://wiki.debian.org/Mentors/BTS [3] mentors.debian.net is not a .org service (yet). We do not intend to push its transition by that right now. RATIONALE = Currently there are three ways to ask for sponsorship of an upload to the Debian archive: uploads can be requested via a packaging team, via private mail to a (known) developer or via public mail to the debian-mentors lists. Sponsorship in teams can work very well, for example in the Debian Perl Group, but some other teams do have a lack of developers. For these people and maintainers of packages that do not fit in any existing team, the only way to ask for sponsorship is often the third route: the debian-mentors lists. However the current procedure is (too often?) disappointing for both sponsorees [1][2], but also for developers who lost any interest in sponsoring packages. Problems with the current handling of debian-mentors requests include in our opinion: * RFS mails are lost in space due to the high volume of requests. Many requests are ignored or never get any feedback. * Comments and prior reviews may be lost or forgotten, or remain unhonoured when the maintainer opens a new RFS thread instead of replying to the last. * Nobody knows answers to questions such as how many packages are out there which are seeking an uploader or what is the status of a particular RFS without looking through mailing list archives.[3] * Duplication of comments on the debian-mentors list and mentors.debian.net. (those should die anyway, or at least be synchronized) We propose to use the BTS to handle sponsoring requests. Both sponsorees and sponsors should already be familiar with its usage and we hope it will improve the sponsoring process for both sides. It will also make it easier to analyse sponsoring (e.g. number of requests without a response). We hope this will make it easier to sponsors to seek requests that still need attention and encourages more developers to sponsor uploads. We also hope to encourage peer-review of packages by other non-developers. Further suggestions on improvements or simply reasons why you do not sponsor uploads or what other problems you have with the current procedure or our proposed workflow are of course welcome. [1] http://lists.debian.org/debian-mentors/2012/01/msg00334.html [2] http://lists.debian.org/debian-devel/2011/05/msg00753.html [3] http://lists.debian.org/debian-mentors/2011/09/msg00126.html PROPOSED WORKFLOW = In general all mails should be sent to the RFS request (n...@bugs.debian.org). Please also Cc the submitter (nnn-submit...@bugs.debian.org). A copy will be sent to the mailing list automatically by the bug tracker. ASKING FOR SPONSORSHIP -- Once a source package has been prepared and made available (for example via [1]), file a new bug report against the debian-mentors pseudo-package: To: sub...@bugs.debian.org Subject: RFS: hello/3.1-4 -- friendly greeter Package: debian-mentors Severity: normal (important for RC bugs, wishlist for new packages) Dear mentors, I am looking for a sponsor for my package hello: dget -x http://mentors.debian.net/debian/pool/main/h/hello/hello_3.1-4.dsc It builds these binary packages: hello - friendly greeter More information about hello can be obtained from http://www.example.com. Changes since the last upload: hello (3.1-4) unstable; urgency=low * Adopt package. (Closes: #123457) * Fix typo in package description. (Closes: #123456) -- J. Maintainer j...@example.com Sat, 10 Dec 2011 22:17:05 +0100 Regards, J. Maintainer Please indicate in the subject if the package fixes RC bugs, is a QA or NMU upload or a new package: Subject: RFS: hello/1.0-1 [NEW] -- friendly greeter Subject: RFS: hello/1.0-3 [QA] -- friendly greeter Subject: RFS: hello/1.0-1.1 [NMU] [RC] -- friendly greeter Subject: RFS: hello/1.0-2 [RC] -- friendly greeter Please keep track of the bug and respond to comments. If the bug was tagged moreinfo or wontfix and you think you have addressed the issues, please remove the respective tag again. If you changed the package to address concerns, please send a follow-up to the sponsoring request (To: n...@bugs.debian.org) that includes the URL to the source package and the last changelog entries similar to the initial request. If there are issues with the upload after the bug was closed, for example when the package was rejected by the
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Le Tue, Jan 17, 2012 at 10:59:14PM +0100, Ansgar Burchardt a écrit : SUMMARY === We plan to ask for the creation of a new pseudo-package debian-mentors or mentors.debian.org [3] (contact: debian-mentors@lists.debian.org) in Debian's bug tracking system (the name is still subject to change). A workflow for handling sponsoring requests is proposed below. It is based on an earlier discussion on the debian-mentors list[1]. The workflow will also be made available on [2]. [1] http://lists.debian.org/s2svcsm447s@bistromathics.mathi.uni-heidelberg.de [2] http://wiki.debian.org/Mentors/BTS [3] mentors.debian.net is not a .org service (yet). We do not intend to push its transition by that right now. Dear Ansgar and everybody, I think that using a bug tracking system is the way to go. I have proposed in the past a worflow for using WNPP bugs, but having a dedicated pseudo-package would definitely be superior. Another point of my proposal was to ask that developers who call for sponsorship try to review at least another package. Please do not hesitate to take the idea of you like it. http://wiki.debian.org/PackageReview Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120117235414.gb26...@merveille.plessy.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Hi, On Tue, 17 Jan 2012, Ansgar Burchardt wrote: We plan to ask for the creation of a new pseudo-package debian-mentors or mentors.debian.org [3] (contact: debian-mentors@lists.debian.org) in Debian's bug tracking system (the name is still subject to change). A workflow for handling sponsoring requests is proposed below. It is based on an earlier discussion on the debian-mentors list[1]. The proposal looks great. And I like that it will allow us to know more, and in an automated way, about the status of a current sponsorship request. That way the PTS can provide more precise information instead of just telling that a package is available on mentors.debian.net. To better fit the naming of pseudo-packages, we ought to pick mentors.debian.org but it would be weird if that DNS entry did not exist. Dear DSA, do you think it's possible to have a CNAME mentors.debian.org pointing to mentors.debian.net? It's currently not hosted on a .d.o machine but AIUI the mentors.debian.net admins are interested to move it to DSA-managed host at some point. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120118074034.gj12...@rivendell.home.ouaza.com
