Re: Upstream metadata to help our users contribute back to projects we redistribute.
On Thu, Jul 25, 2019 at 3:34 PM Jelmer Vernooij wrote: > > > On 25 July 2019 15:17:13 GMT+01:00, Felipe Sateler > wrote: > >On Thu, 25 Jul 2019 17:27:51 +0900, Charles Plessy wrote: > > > >> Hello everybody, > > > >Hello Charles, > > > >> > >> (posted on -project because of the context, but answers probably > >belong > >> to -devel, where I am not subscribed...) > >> > >> there is an intersting discussion going on about Git and the > >preferred > >> form for modification of the programs we redistribute. > >> > >> Indeed, as of today would be hard to say « just run “apt-get source > >> ” and voilà, you can hack and contribute back upstream > >». > >> > >> There has been now and in the past (for instance when discussing the > >> proposed format “3.0 (Git)” for dpkg) some important points raised > >> explaining the challenge of redistributing the upstream VCS instead > >of a > >> flat file archive. > >> > >> This is why some packges are shipping metadata indicating where to > >find > >> the upstream sources, send upstream bugs, or even where to dontate > >> money, in order to help our users contribute back to the developement > >of > >> the software that Debian is made of. > > > >Are there tools that are actively using this information? > >Unfortunately, > >the links you quote below do not provide much information about where > >this information is used (other than bibref table in UDD). > > > >On the other side of the coin, are there any tools that help generate > >this metadata? For example, github-hosted projects can have their Bug- > >Database, Bug-Submit, Changelog, Repository, Repository-Browse > >automatically derived. > > lintian-brush (https://packages.debian.org/intuan-brush) can update > debian/upstream/metadata from various kinds of upstream-bundled files like > dist.ini, META.json, doap (used by GNOME) or setup.py. > > Thanks, this tool looks very useful, and not only for upstream/metadata. -- Saludos, Felipe Sateler
Re: Upstream metadata to help our users contribute back to projects we redistribute.
On Thu, 25 Jul 2019 16:26:02 +0200, Xavier wrote: > Hi, > > pkg-js-tools embeds a tool that generates debian/upstream/metadata for > Github repositories (github-missing-upstream). Thanks, this is useful. It's named github-debian-upstream though ;) > > dpt from pkg-perl-tools uses this file to link locally upstream repo in > "git remote" This sounds cool too. Sounds more useful than for just perl packages. -- Saludos, Felipe Sateler
Re: Upstream metadata to help our users contribute back to projects we redistribute.
On Thu, 25 Jul 2019 17:27:51 +0900, Charles Plessy wrote: > Hello everybody, Hello Charles, > > (posted on -project because of the context, but answers probably belong > to -devel, where I am not subscribed...) > > there is an intersting discussion going on about Git and the preferred > form for modification of the programs we redistribute. > > Indeed, as of today would be hard to say « just run “apt-get source > ” and voilà, you can hack and contribute back upstream ». > > There has been now and in the past (for instance when discussing the > proposed format “3.0 (Git)” for dpkg) some important points raised > explaining the challenge of redistributing the upstream VCS instead of a > flat file archive. > > This is why some packges are shipping metadata indicating where to find > the upstream sources, send upstream bugs, or even where to dontate > money, in order to help our users contribute back to the developement of > the software that Debian is made of. Are there tools that are actively using this information? Unfortunately, the links you quote below do not provide much information about where this information is used (other than bibref table in UDD). On the other side of the coin, are there any tools that help generate this metadata? For example, github-hosted projects can have their Bug- Database, Bug-Submit, Changelog, Repository, Repository-Browse automatically derived. -- Saludos, Felipe Sateler
Re: Problems with NM Front Desk
On 06/07/10 10:09, Patrick Schoenfeld wrote: some stuff about Manuel not being ready for DD status AFAICT, none of this justifies silently removing someone from the NM database. -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
Re: Problems with NM Front Desk
On 06/07/10 15:11, Raphael Hertzog wrote: On Tue, 06 Jul 2010, Felipe Sateler wrote: On 06/07/10 10:09, Patrick Schoenfeld wrote: some stuff about Manuel not being ready for DD status AFAICT, none of this justifies silently removing someone from the NM database. I can't speak for the NM team, but if he was asked to go through DM first (and that's what I understood), I could understand that his NM application got removed for now. The part I find strange is the silentness of the removal, not the removal itself. Don't attribute it to malice. I didn't. I can be a honest mistake (like forgetting to mail the applicant indicating the removal, or millions of others). I'm just stating that silent removal does not seem justifiable. And the NM team has not yet spoken about that point. -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
Re: On terminology
On 05/07/10 20:25, Russ Allbery wrote: and not all Debian Maintainers are maintainers That last one is new to me. What's the point of becoming a Debian Maintainer if not to maintain one or more packages in Debian? So that they can upload a Debian package. They may have no intention to become the maintainer. I see a real layer of additional distinction from people who upload packages to people who are maintainers. The latter is a role with a set of responsibilities that people pick up consciously and that comes with a committment. Many Debian Maintainers do take on that role, but it's not a necessary component to becoming a Debian Maintainer or exercising the one additional capability that a DM has. Hmm, I don't follow. To be a DM, you need to have someone advocate you on the grounds of your work as a package maintainer. It seems to me that you don't consider people who are only listed as Uploaders as package maintainers. I suspect a fair bunch of DMs will not appear on any package as maintainer, but only as Uploaders of packages maintained within a team. I myself never had a package with DMUA set for which I was the Maintainer: of the package. -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
Re: New contact address for the wanna-build team, and other bits
Adeodato Simó wrote: Regarding requests for give-backs, etc., this is the new state of things: * Packages-arch-specific: still bug against ‘buildd.debian.org’ * Bin-NMUs: still debian-rele...@lists.debian.org * Chroot problems, package priority issues: still arch@buildd.debian.org * Give-backs and dep-waits: debian-wb-t...@lists.debian.org (including requests for experimental, but please mark them as such) What is the difference between give backs and BinNMUs? A give back is a request to build again because the first failure was not the package's fault, but rather the buildd? I can't seem to find anything on google. An explanation of all this terminology (including dep-wait) would be appreciated (hopefully in a document explaining why and when would any be needed and how to ask for them). -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: General resolution: Clarify the status of the social contract
Manoj Srivastava wrote: I like the idea of clarifying what the principles of the project actually are, since, as aj said, all the decisions about lenny would fall out from the position the project take about the foundation documents. While I have always thought that foundation implied the proposal below, apparently this is not a universally held view. I think we will keep coming back to this biennial spate of disagreement we have, as we determine whether or not we can release with firmware blobs or what have you. This also would help developers, the ftp-masters, and the release team with a clear cut expression of the projects goals and clarifies how the project has decided to view the social contract. I think that your set of proposals is only part of this particular issue. Part of the issue is also how does the Social Contract apply to stable v testing/unstable. Does the SC apply more strictly to stable? If yes, this should be documented in the constitution or the SC itself. If not, then the whole problem that started this is moot. IOW, are DFSG-freeness allowed as bugs in testing/unstable but not in stable, or are all suites equal in that if one of them can contain non-free bits then it is up to the release team to consider such bugs as not delayers of the release. Something along the lines of: ,[ The Social contract applies more strictly to stable releases ] | The developers, via a general resolution, determine that the social | contract should stop us from including anything that doesn't comply | with the DFSG in main AND violations of the DFSG present in | the testing suite prevent the release of the next stable version. ` ,[ The social contract applies equally to all suites, violations | are considered bugs ] | This amends the proposal above, and replaces the text of the proposal with: | The developers, via a general resolution, determine that the social | contract should stop us from including anything that doesn't comply with | the DFSG in main AND violations of the DFSG present in the testing or | unstable suites do not necessarily prevent the release of | the next stable version, since they were already present in Debian. ` ,[ The social contract applies equally to all suites, violations | are considered unacceptable ] | This amends the proposal above, and replaces the text of the proposal with: | The developers, via a general resolution, determine that the social | contract must stop us from including anything that doesn't comply with the | DFSG in main AND violations of the DFSG found in any suite are cause | for removal of the offending code inmediately. ` If option 1 wins, then the lenny release gets delayed, and a new GR making a formal amendment to clarify this in the SC should be done. If option 2 wins, there should be a GR defining the process for determining wether a bug delays or not the release (release team, GR, whatever). If option 3 wins, Debian (including old releases) would become uninstallable for an unknown timeframe until all DFSG violations are solved. I do realize that this options are very related to your proposed GR, but I don't really know how to solve that. Perhaps a wording that didn't shamelessly copy your GR would help. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Developer Status
Stefano Zacchiroli wrote: On Sun, Oct 26, 2008 at 04:24:24PM -0300, Felipe Sateler wrote: The Debian Contributor class is a class of people that the Debian project doesn't give any tool/resource to do their work. Which is untrue: - you can dig in this thread and you will find members of DSA stating that DC can be given shell access to project machines if they need it - examples of well respected porters which nowadays are nothing for Debian (in term of how we recognize them, not in term of how useful they are for us!) can be given access to buildds / port machines - as per my proposal in a separate thread they can be given @debian.org mail addresses None of which were in the original proposal/announcement. These kind of stuff would indeed make it much better (although I still have my doubts on the design, which is why I haven't proposed any similar fixes). - on the same lines, they can be given commit access rights to the repository of some of our infrastructure (e.g., the PTS, whose committers nowadays need to be DDs, for no evident reason) That is a separate problem that just happens to be possibly solved by this. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Stefano Zacchiroli wrote: On Sat, Oct 25, 2008 at 04:56:36PM -0300, Felipe Sateler wrote: My name is on the Maintainer field of 2 packages in main, and I think we can consider the Maintainer fields as a list of contributors (evidently, not all of them). I haven't (formally) agreed to any document, my key is not signed by anyone in the project, I haven't been advocated by anyone and certainly have not answered any set of predefined questions. Why should the bar for non-developing contributors should be different than mine (ie, they have to do more than just the work they are contributing)? Nobody is saying that to contribute in general you will need something more than at present. For example, nobody is proposing to get rid of sponsors (which are now, and will be also in the future, to sponsor anybody's work), or to inhibit people submit patches to the BTS (they are contributors too!). Still (part of) the proposal is to introduce a particular class of contributors which is also able to vote on choices of the Debian project (elections and GR). In the initial proposal that class happens to be called Debian Contributors, but that's just a matter of naming, and you can argue that it is an inappropriate one. The Debian Contributor class is a class of people that can't do anything. Debian Members can vote. I think that the Debian Contributor class (which in the end is a mere ACK that their work is appreciated) should have a particularly low bar. Perhaps one advocation or two. Still, I hope you see the reason for adding some checks before letting people to vote upon choices which are bounding for the Debian project. After all sponsored uploads and patches are subject to review, why voting rights shouldn't? And note that the bar would basically be ID+PP, which boils down to checking that you have an identity and that you share the ideals of the Debian project. Of course. I have to note that I'm arguing against parts of the proposal that I think aren't OK, not the whole thing. I think that the general idea of the proposal is good, but it is not correctly implemented. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Yves-Alexis Perez wrote: On Sun, Oct 26, 2008 at 12:30:02PM -0300, Felipe Sateler wrote: The Debian Contributor class is a class of people that can't do anything. Sure, it really sounds good… I'm not sure what you wanted to say with that, but I'll clarify my statement. The Debian Contributor class is a class of people that the Debian project doesn't give any tool/resource to do their work. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Bas Wijnen wrote: On Thu, Oct 23, 2008 at 05:40:32PM -0300, Felipe Sateler wrote: Basically, they need to pass the ID check, agree to the Social Contract/DFSG and have successfully answered a set of questions similar to the ones used in the current first PP step, to keep doing the same thing they have been doing all this time. No. Current Debian Maintainers also need an ID check, agree to SC/DFSG/DMUP and be advocated. The only thing that is added (and that was made clear by Joerg), is that they need to answer a very limited set of questions. I am talking about the DNDCs here. DNDCs have no priviledge whatsoever besides getting included in a list. Yes, and possibly getting a @contributor.debian.org e-mail, appearantly. So what does Debian want to do? We want to show those people we appreciate their work, and we want them to be able to tell others that they do work for Debian. We also want this to be worth something, so we shouldn't add just anyone to the list, but only people who agree with our philosophy. In order to be able to say anything, we need e-mail most of the time, and in order to identify someone as the person I'm talking about, we need a signed key. So the ID check is going to stay. For the philosophy thing, we need agreement with our foundational documents (which isn't any problem, of course). The need to be advocated seems reasonable to me as well, to maintain the status of that list. So there's only answering the questions, and I think that was only the case for DDC, not DNDC. My name is on the Maintainer field of 2 packages in main, and I think we can consider the Maintainer fields as a list of contributors (evidently, not all of them). I haven't (formally) agreed to any document, my key is not signed by anyone in the project, I haven't been advocated by anyone and certainly have not answered any set of predefined questions. Why should the bar for non-developing contributors should be different than mine (ie, they have to do more than just the work they are contributing)? Becoming a Debian Maintainer is supposed to be a light-weight version of the New Maintainer process. It's not a I'll skip the New Maintainer process entirely-version. If the current Debian Maintainer process is failing for some reason, please elaborate. If it's not, then I don't see why adding more checks is useful. I don't think it's failing, but I also don't see where the more checks would be. You're talking about the very limited TS questions? Jörg made it clear that this wouldn't be much trouble, and that people should be able to finish the checks in a very short time. You may be right that there's no reason for them, and in that case it would be better to remove them. But it's also not a big issue IMO. Maybe. But then, big issues are IME created usually by small incremental issues. I think the burden of proof is on the proposer's side, not the other way around. But I think that for general upload rights the bar is way lower. As I said in another message, 1 year is enough to do a lot of work, but spending half of that year waiting is not useful, I think. If a person needs to learn about Debian packaging at the start of the year, then I don't think it's reasonable to expect much work on more than a few packages, at least in the first 6 months. And for a few packages, there's no need to get full upload rights. Just becoming a DC is enough for that, and that needs no waiting. Only if this person applies for DC status at the start of said year, which may or may not be what people are actually doing: my first package was uploaded in 2006 and I still haven't applied for DD or DM. Others may do it differently. You seem to want to rush total outsiders into the most priviledged positions of the project. Why would that be a good thing? What is the problem of letting people work 6 months with slightly fewer rights? I don't want to rush people into privileged positions. I object arbitrary limits, specially when I think the limit will miss many important cases. I don't see the many cases you are talking about. One effect of this proposal is that people should apply for DC when they are getting started. If people don't do that, but instead are active but not in any keyring, then 6 months is a long time to wait before being able to apply for DM. Apparently I was thinking mostly in the latter case than the former. I consider it nonsense to apply for official status while doing my first contributions to a project. I don't usually go to a project and say hey, I want to contribute, please give me (restricted) access to your VCS. I think it would also cause more work for the people administering the Dx queues, which I hear are already overworked. It could be good to allow skipping of the delay for one month per advocate, which means you need to get seven advocations (one to start, plus one for each month) to start
Re: Developer Status
Joerg Jaspert wrote: On 11547 March 1977, Felipe Sateler wrote: While, strictly speaking, this increases the barrier to get DM compared to the current implementation of DM, we do not think it is an unreasonable or too high level. Anyone who is able to get a package put together in a lintian clean way will be able to get DM without much effort or time used. So this basically requires DMs to do the (somewhat reduced) PP and TS questions, and I don't see the real reason for this. The idea behind DMs is to maintain a package one knows how to maintain. The only reason I can see here is that DDs are not being trusted in their advocations, which is a far worse problem that won't get solved by this. As written above, the actual amount of checks DM have to do is left to the NM Committee and can be adjusted as needed. This does IMO not contradict DM, but it enhances the value of it in the long term. Right now you can be DM, but have to pass the full NM before you can get DD. In future you get DM (and yes, you have a tiny amount of more work to do for this), be it for a few months and then you can get DD relatively easy by just doing the last few steps needed. Ie. once you are a DM you are already about half through NM. What you are doing is moving the work from one side to the other (pre-DD to pre-DM). Given that the idea of DMs was to reduce the barrier of entry, it kind of defeats the purpose. Those two classes are the initial set in which every NM will end up. After six months as DC or DM one might chose to become a Debian Member or Debian Developer. This - ensures that the interest in Debian isn't short-term. Why do people keep thinking this is a good thing? Because short term involvement usually creates more work than it helps, IME? I would like some numbers to back this claim. Also, what is short term? I would find one year to be sufficient to do a great amount of good work, but then a 6-month process is too much bureaucracy. - enables them to learn more about the workings in Debian and generally helps them for the next step. They should be doing this on their own, and not force an arbitrary limit on them. What if they did this before applying for DD/DME/DM/DC status? Then it will be a no-brainer to pass the rest in this process. That is not the point. Why do I have to wait 6 months to learn more when I already did that? Unfortunately a large number of people trying to join Debian did not do that before applying, as past has shown us. I really don't see why NM should be a mentoring process. Instead of asking NMs to do stuff during the process, I think it would be much better to ask them to show what they have already done. This way you get less work for the AM/whatever and force NMs to do their homework before applying and not while. This all smells like a whole lot of bureocracy for no gain to me. I do see the gain for everyone that wants to join and also for those non-technical people that do help to make Debian better. Not everything in Debian is about packaging alone, even if some people (not attacking you, thats a general some) love to think there is nothing besides packages. We do want translators, we do want documentation writers, they all help to make Debian even more the Universal OS by opening it up to those not speaking english. Or those that aren't the most clueful ones in technical things and just want to use a great OS to get their daily work done. Yes, the most important part in Debian is about packaging, without this there won't be a place for translators/documentation writers, but that doesn't mean we should ignore or deny their existance. I do want translators, documentation writers, etc to be recognized for their work. I also want them to have the tools to do their work. The DMe thing would only accomplish adding your name to a list, since it gives you no tool/privilege to do your work better/easier. I want them to do, eg, i18n campaigns like Christian Perrier does. For that they require technical skills, that is true. But then every contributor to any software project has to learn a few things before they can be effective (eg, learn about patching or the VCS in use). -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Felipe Sateler wrote: I do want translators, documentation writers, etc to be recognized for their work. I also want them to have the tools to do their work. The DMe thing would ^^^ That should be DC. only accomplish adding your name to a list, since it gives you no tool/privilege to do your work better/easier. I want them to do, eg, i18n campaigns like Christian Perrier does. For that they require technical skills, that is true. But then every contributor to any software project has to learn a few things before they can be effective (eg, learn about patching or the VCS in use). -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Bas Wijnen wrote: On Wed, Oct 22, 2008 at 11:29:53PM -0300, Felipe Sateler wrote: Debian Contributor -- Basically, they need to pass the ID check, agree to the Social Contract/DFSG and have successfully answered a set of questions similar to the ones used in the current first PP step, to keep doing the same thing they have been doing all this time. No. Current Debian Maintainers also need an ID check, agree to SC/DFSG/DMUP and be advocated. The only thing that is added (and that was made clear by Joerg), is that they need to answer a very limited set of questions. I am talking about the DNDCs here. DNDCs have no priviledge whatsoever besides getting included in a list. So this basically requires Debian Maintainers to do the (somewhat reduced) PP and TS questions, and I don't see the real reason for this. The idea behind Debian Maintainers is to maintain a package one knows how to maintain. Those people are getting upload rights to the archive. Don't you think it's reasonable that the project wants people to show that they won't mess things up before giving such a priviledge to them? Becoming a Debian Maintainer is supposed to be a light-weight version of the New Maintainer process. It's not a I'll skip the New Maintainer process entirely-version. If the current Debian Maintainer process is failing for some reason, please elaborate. If it's not, then I don't see why adding more checks is useful. The only reason I can see here is that DDs are not being trusted in their advocations, which is a far worse problem that won't get solved by this. We have over 1000 members. That's way too much to use the if you have 1 invitation, you're in-system. Looking at the recent flamewar, I'm pretty sure almost every DM has at least one other DM whose advocation they don't trust. So I don't think one advocation is not enough is a problem at all. It's just a result of having many members. Don't forget that this is a quick thing. People who don't care enough to answer some quick questions (or show in some other way that they can handle the responsibility) aren't interested enough to get the priveledge we're talking about, IMO. Hmm, I see the point. However, remember that the current Debian Maintainer thing is intended for maintainership of few packages. As the original Debian Maintainer process was intended (someone gets a package sponsored, works with the sponsor for a few releases, and then the sponsor is confident the sponsoree won't screw up so flags the DM-Upload-Allowed: yes), I do think 1 invitation, you're in should work. If it is not working this way, then perhaps it doesn't. But I haven't heard anyone say that yet. - ensures that the interest in Debian isn't short-term. Why do people keep thinking this is a good thing? If people only have short-term interest, that's not a bad thing in itself. But in this case we're talking about giving them long-term priviledges (upload any package; vote; become DPL, that sort of thing). We want members of our project to have a long-term interest, don't you agree? Partially, depending on the definition of long-term. I do agree that voting and becoming DPL or other delegation should require long-term interest. But I think that for general upload rights the bar is way lower. As I said in another message, 1 year is enough to do a lot of work, but spending half of that year waiting is not useful, I think. - enables them to learn more about the workings in Debian and generally helps them for the next step. They should be doing this on their own, and not force an arbitrary limit on them. What if they did this before applying for DC/DM status? In the proposal, there is no help during these 6 months. So basically, if people want to do this on their own, the project will ask them to say so before doing that (in the proposal). Saying so means applying for DC status. Applying for DM is not possible before those 6 months are over. You seem to want to rush total outsiders into the most priviledged positions of the project. Why would that be a good thing? What is the problem of letting people work 6 months with slightly fewer rights? I don't want to rush people into privileged positions. I object arbitrary limits, specially when I think the limit will miss many important cases. While you might not intend that, it still does. DDMs would be DNDMs + general upload rights, which is clearly a DNDM DDM relationship. ... You say there is no first or second class, but DDMs would drop down to DNDMs. Of course there technically is a full and almost full rights membership. What I think he means to say, is that DNDMs should not be looked down upon, and that they do get everything they need from the project. That's why I said you might not intend that. If they are effectively almost-DDM, there is a large room for looking down. Personally, I think a DNDM should have
Re: Developer Status
Joerg Jaspert wrote: Now let us describe the way the account status is meant to be handled in future. This mail has mixed future and present tense. Have these changes already been implemented, or are planned? A new user can start out in two ways depending on their personal preference. The first is the non-technical way: Debian Contributor -- A DC is someone that has a strong relation with Debian through the work they are doing for/around Debian. Possible examples are translators and documentation writers. DC have to pass the ID check, agree to the Social Contract/DFSG and have successfully answered a set of questions[DCDMQ] similar to the ones used in the current first PP step.[TEMPL] Basically, they need to pass the ID check, agree to the Social Contract/DFSG and have successfully answered a set of questions similar to the ones used in the current first PP step, to keep doing the same thing they have been doing all this time. The second way is the technical one: Debian Maintainer - A DM has the same strong relation with Debian a DC has, but additionally wants to maintain a limited set of packages without the help of a sponsor. A DM has to pass the same checks a DC has and very few questions from the TS part[DCDMQ]. A (very) small TS basically, the most important TS questions for them. They are allowed to upload their own (source) package. The allowed list of (source) packages to upload can be edited by any member of the NM committee[NMC], who will do a package check before they add new packages to the DM's list. In contrast to current DM this is based on source packages and allows uploads of new binary components, which have to pass NEW, too. While, strictly speaking, this increases the barrier to get DM compared to the current implementation of DM, we do not think it is an unreasonable or too high level. Anyone who is able to get a package put together in a lintian clean way will be able to get DM without much effort or time used. So this basically requires DMs to do the (somewhat reduced) PP and TS questions, and I don't see the real reason for this. The idea behind DMs is to maintain a package one knows how to maintain. The only reason I can see here is that DDs are not being trusted in their advocations, which is a far worse problem that won't get solved by this. Those two classes are the initial set in which every NM will end up. After six months as DC or DM one might chose to become a Debian Member or Debian Developer. This - ensures that the interest in Debian isn't short-term. Why do people keep thinking this is a good thing? - enables them to learn more about the workings in Debian and generally helps them for the next step. They should be doing this on their own, and not force an arbitrary limit on them. What if they did this _before_ applying for DD/DME/DM/DC status? - leaves everyone the option to stay DC or DM, if they do not want/need more rights. After the 6 months time in Debian Contributor/Maintainer are passed, applicants can apply to get Debian Developer status. There are now 2 different classes of DD status available, one with and one without upload rights. To not add confusion we selected to name them Debian member (no upload rights) and Debian Developer (upload rights). Both are project members, i.e. with voting and all other constitutional rights, the term classes does not indicate any kind of first or second level membership. While you might not intend that, it still does. DDs would be DMEs + general upload rights, which is clearly a DME DD relationship. Changes to existing Debian Developers - No changes are done to existing Debian Developers, until they ask for it. If you want to drop down to DME, no matter if you want to keep a few packages maintained like a DM does, drop the NM-Committee a mail. You say there is no firs or second class, but DDs would drop _down_ to DMEs. This all smells like a whole lot of bureocracy for no gain to me. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: Update #1 [RFC: Introducing Debian Enhancement Proposals (DEPs)]]
Sven Luther wrote: What about having a centralized email address where to send original proposals, and which forward the proposal to the appropriate list, after having incremented the proposal number ? This is already what we do for bug reports, so it should not cause a major problem to the DDs, no ? Which raises the question if this is possible/reasonable to implement directly on debbugs. A new pseudo package dep, which then a script extracts information from (much like wnpp). -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: Update #1 [RFC: Introducing Debian Enhancement Proposals (DEPs)]]
Forwarding a message from Sven Luther On Thursday 17 January 2008 13:33:36 Sven Luther wrote: On Thu, Jan 17, 2008 at 12:53:35PM -0300, Felipe Sateler wrote: Sven Luther wrote: What about having a centralized email address where to send original proposals, and which forward the proposal to the appropriate list, after having incremented the proposal number ? This is already what we do for bug reports, so it should not cause a major problem to the DDs, no ? Which raises the question if this is possible/reasonable to implement directly on debbugs. A new pseudo package dep, which then a script extracts information from (much like wnpp). The problem with this, is that the debbugs, is that it doesn't allocate nice consecutive small numbers as we probably want for this proposal. Maybe a second debbugs instance, or a multiple addresspaace debbugs would do ? -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
