Re: Tentative summary of the amendments
Uoti Urpala wrote: Does this GR imply that such a decision may not be made without a new GR to override this one? I was originally worried about this too, and it's one reason out of many why I strongly dislike using GRs to decide technical matters. My understanding though, is that this GR would change a TC decision, with the blessing of the TC, such that the GR becomes the new TC decision. So the GR result should be no harder to change than any other TC decision. -- see shy jo signature.asc Description: Digital signature
Re: [Call for seconds] The “no GR, please“ amendement.
Charles Plessy wrote: --- The Debian project asks its members to be considerate when proposing General Resolutions, as the GR process may be disruptive regardless of the outcome of the vote. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. --- Seconded. -- see shy jo signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Luca Falavigna wrote: The Technical Committee decided not to decide about the question of coupling i.e. whether other packages in Debian may depend on a particular init system. The tech committe made a separate ruling on this question, and decided: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. http://bugs.debian.org/746715 So, your proposal actually overrules this decision of the tech committe. IIRC, the TC decided to let their decision on https://bugs.debian.org/727708 be overridden by a simple majority. But not their decision on #746715. So wouldn't this amendment need a 2:1 majority to pass? -- see shy jo signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson wrote: The technical committee decided not to decide about the question of coupling i.e. whether other packages in Debian may depend on a particular init system. What, then was #746715? This resolution is a Position Statement about Issues of the Day (Constitution 4.1.5), triggering the General Resolution override clause in the TC's resolution of the 11th of February. How can you use 4.1.5, which is Issue, supersede and withdraw **nontechnical** policy documents and statements (emphasis mine) for a technical decision like this? Why does this not come under 4.1.4, and so require a 2:1 majority? -- see shy jo signature.asc Description: Digital signature
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Sam Hartman wrote: Joey == Joey Hess jo...@debian.org writes: Joey Why not just make your proposal be something along the lines Joey of reaffirming the technical decision-making process as it Joey currently stands, from the package maintainers, to the policy, Joey to the TC. It could implicitly or explicitly reaffirm both Joey recent TC decisions on init systems. I'd support very strongly something like this, no more than one or two more paragraphs like the above. I consider Charles Plessy's proposal to do this, more or less. (Enough that I don't think another proposal would be worthwhile.) -- see shy jo signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Kurt Roeckx wrote: Either it's a position statement, or we're making position statement (4.1.5), or using the TC's power (4.1.4). In #727708 it says that a position statement will replace this TC resolution. In #746715 there is no such text. So the question is going to be if this options overrides #746715 or not. I didn't look into it yet, so I might be turning 1 or more of the options into overrding the TC and put them under 4.1.4. So if the project makes a position statement about issues of the day, it's not actually making a technical decision, but just a (nonbinding) statement. A statement that the TC has decided will override their (binding) decision. Well, at least I've found yet another reason to perfer to not vote on this GR: It's too darn complicated to understand the procedural hacking that's going on. -- see shy jo, srsly, you could learn what monads are in the time you'll waste making an informed vote on this GR. signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Adam D. Barratt wrote: Note (and this is not splitting hairs) that serious bug is not a direct analogue for release-critical bug. This GR is not amending Debian policy, it's setting a technical requirement at a more fundamental level, which has never been used to set technical requirements in Debian before. So it's not clear, at least to me, that the release team would have the power to make that distinction if this GR passes. Bypassing the policy process, locking Debian into a technical decision which would require another GR to change, etc -- this GR is wading into uncharted waters without much concern for long term results. -- see shy jo signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson wrote: The problem with making it simply not apply to jessie is that there would be a continued opportunity to create `facts on the ground' which make it difficult to disentangle things in jessie + 1. Can you please point to one thing in jessie that is currently entangled in a way that your proposal would prevent happening? -- see shy jo signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson wrote: Joey Hess writes (Re: Re-Proposal - preserve freedom of choice of init systems): Ian Jackson wrote: The problem with making it simply not apply to jessie is that there would be a continued opportunity to create `facts on the ground' which make it difficult to disentangle things in jessie + 1. Can you please point to one thing in jessie that is currently entangled in a way that your proposal would prevent happening? As far as I'm aware the current situation in jessie is fine as far as this GR goes. [..] So if there is no backsliding, this GR will not delay the jessie release at all. But, the resolution of this GR and the start of the freeze cooincide, +-1 week. And after the freeze, the chances of backsliding being allowed, after release team review, are minimal. -- see shy jo signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson wrote: Joey Hess writes (Re: Re-Proposal - preserve freedom of choice of init systems): Ian Jackson wrote: So if there is no backsliding, this GR will not delay the jessie release at all. But, the resolution of this GR and the start of the freeze cooincide, +-1 week. And after the freeze, the chances of backsliding being allowed, after release team review, are minimal. So your objection to the GR is that it is a no-op ? Other people are objecting on the grounds that the sky would fall. The GR is clearly not a no-op post-jessie. But we're supposed to be getting ready to release jessie now. The timing is off. -- see shy jo signature.asc Description: Digital signature
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Lucas Nussbaum wrote: It is now clear that we will have a vote on this issue. I think that we should use this opportunity to clarify the Project's position, and that's not something that would be achieved if Further Discussion were to win. I am therefore bringing forward an alternative proposal, deeply inspired from the Advice: sysvinit compatibility in jessie and multiple init support option of the TC resolution on init system coupling[1], which was originally written by Russ Allbery[2] and was then amended by many participants to the discussion in February 2014. I am very uncomfortable with GRs being used to set technical policy. We have never before has a GR that did so. It can lock us into technical decisions which we then need a whole other GR process to get us out of. And mass voting on technical minutia is no way to run a distribution. Why not just make your proposal be something along the lines of reaffirming the technical decision-making process as it currently stands, from the package maintainers, to the policy, to the TC. It could implicitly or explicitly reaffirm both recent TC decisions on init systems. -- see shy jo signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Adam D. Barratt wrote: Speaking for no-one other than myself, I _am_ very unhappy that given how long the discussion has been rumbling on for, and how much opportunity there has been, that anyone thought that two weeks before the freeze (which has had a fixed date for nearly a year now) was the right time to raise this. +1 million (Seriously considering going on VAC until the release now, however long that will turn out to be.) -- see shy jo signature.asc Description: Digital signature
Re: Comments on the constitution?
Joachim Breitner wrote: How about reversing the action: By default, there is an election, unless a reasonable, well-defined number of DD publicly state that they see no need for a re-election. A variant on this that would not be susceptable to this: I think this works well unless we have the case of a strongly polarizing DPL, with a large number of supporters and possibly more opponents. ... Would perhaps be to have people state that they are only interested in a pro-forma election. If there's a consensus that the current DPL is well respected and should continue, then we could skip strawman candidates, DPL platforms, QA sessions, etc. (If NOTA wins, the consensus was false and we have to try again.) -- see shy jo signature.asc Description: Digital signature
Re: GR: welcome non-packaging contributors as Debian project members
Paul Wise wrote: Stefano you seem to be 5 years too late with this GR, fjp's AM report looks like he was accepted primarily for his work on documentation and translations: http://lists.debian.org/debian-newmaint/2005/02/msg00017.html Not really. From my original advocation of Frans: | Basically, Frans is now one of the relatively few core d-i developers. | I've watched him grow from a smaller contriutor to the project | (originally he was working only on the installation manual), learn all | the details of working with packages and d-i and now he's everywhere, | working on lots of different parts of d-i, from working on | network-console and the s390 port to processing installation reports and | helping users. He's made the whole thing seem impressively effortless, | while at the same time clearly putting a lot of work into the project. | Frans is exactly the kind of person we need more of on this project and | he deserves to be an official member of it. In addition, as cate pointed out, the constitution already allows DAM/FD to accept such people. And it *has* happened. For example, Mattias Wadenstein is a non-packaging DD. He works on CD building and mirroring. Here's his AM report from 2004: http://lists.debian.org/debian-newmaint/2004/09/msg00033.html -- see shy jo signature.asc Description: Digital signature
DM vote (was Re: Debian Project Leader Election 2010 Results)
| 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | If I count right, there are 112 Debian Maintainers not able to be represented in the above. I wonder if conducting a parallel vote of the DMs, for information only, would be worth doing next year? It would be interesting to see a) how many DMs care about being enfranchised enough to vote and b) how closely their preferences match to those of the DDs. Alternatively, if the DM vote were run during the first week of the real (2 week) vote, results could be announced in time for DDs to incorporate the data into their own votes. (One might, for example, give a better vote to a candidate who seems appealing to newcomers -- or to a candidate whose ideas are too refined for newcomers to appreciate. ;-) -- see shy jo, no longer involved in DM stuff signature.asc Description: Digital signature
Re: planet.debian.org is RC buggy (?)
Nico Golde wrote: when it comes to our users. I have no numbers to prove that but I doubt that a lot of users are reading planet (why should they..). Because: j...@gnu:~/tmp/xscreensaver-5.10grep planet.debian.org -r . ./debian/patches/53_XScreenSaver.ad.in.patch:+*textURL: http://planet.debian.org/rss20.xml ./debian/changelog:+ Now use planet.debian.org instead of .net Which is run regularly by 10% of our users. (I do think this is better than the random selection of posts to livejournal.com that the patch disables.) -- see shy jo signature.asc Description: Digital signature
Re: planet.debian.org is RC buggy (?)
Frank Lin PIAT wrote: I consider blogs as non-free, proprietary material (a very few have a proper license, the distribution media s*cks anyway). I didn't notice a license on your email either. But every time I recall licenses of email being discussed, the conclusion has been that it doesn't sufficiently matter, that the implied redistribution and quoting grant is good enough and being more picky about licensing would be counterproductive to good communication. If one cared about licenses of blog posts, one could configure planet.debian.org to use the license data from the feeds it aggregates, perhaps prominently displaying it at the bottom of a post. For an example of a planet that does this, see http://updo.debian.net/ (you'll find (non-free!) licenses on at least the posts from RMS ;) If this were done on planet.debian.org, I expect it might influence some posters to put a license on their blogs. It might be fairly easy to get things to the point that there is social pressure for bloggers on planet debian to do so. Breaks DFSG #1 Breaks DFSG #3 Given how often we need to contact upstreams to clarify/fix license issues, I imagine most of us would not be bothered to need to contact someone in the same project. Just as we would if they had posted it to a mailing list, or to wiki.debian.org. Breaks DFSG #2: No source for stuffs like charts and graphs (HTML is a valid source here). Is this a problem? If you're interested in making it easier to access the source to web sites in a automatable fashion, check out this proto-RFC: http://kitenet.net/~joey/rfc/rel-vcs/ Replying to a blog entry is very difficult. The replies and the original posted aren't available side-by-side. The comments aren't available on Debian planet (a kind of censorship). Actually, some blog even forbid comments! Is this a problem? It suggests to some of us that it only makes sense to use comments for essentially throwaway speech, that we don't mind being under the control of the blog owner; and that anything substantial should instead be posted to our own blogs. -- see shy jo signature.asc Description: Digital signature
Re: planet.debian.org is RC buggy (?)
Joey Hess wrote: Because: j...@gnu:~/tmp/xscreensaver-5.10grep planet.debian.org -r . ./debian/patches/53_XScreenSaver.ad.in.patch:+*textURL: http://planet.debian.org/rss20.xml ./debian/changelog:+ Now use planet.debian.org instead of .net Which is run regularly by 10% of our users. Which, BTW, suggests another interesting way to see how many unique IP addresses 10% of our users constitute.. -- see shy jo signature.asc Description: Digital signature
Re: Standardization, large scale changes, innovations
Wouter Verhelst wrote: A very good example of that is debhelper; nobody ever told anyone to use it, yet most of our packages do, directly or otherwise. Parts of Debian encourage experimentation, innovation, and evolution of better solutions: parts don't. That debian/rules is a flexible, standard interface, and the lack of any obstacles to providing code that hooks into it has allowed many approaches to be tried. Compare adding a new suite like testing. The barriers to innovation there are high, including needing set up a copy of the archive (or being one of the few trusted to work on the real one), but also one has to overcome collective innertia and convince everyone they should care about the new suite. I don't know if Debian has become more resistent to innovation. Could be that the easy areas are increasingly tapped out. The exciting potential of dpkg source v3 to me is that it potentially opens an area that had stifled most innopvation, by allowing subtypes of the source format to be developed. But this area is still relatively closed to innovation; dpkg's maintainers still need to sign off on new formats, and the v3 source handling in dak is AIUI unneccessarily limited/hardcoded to only supporting certian subtypes. -- see shy jo -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100325195143.ga4...@kitenet.net
Re: Question for all candidates: Care of Core infrastructure
Marc Haber wrote: - dpkg still uses normal console prompting for dpkg-conffile handling, while debconf has been mandatory for regular packages for years now. Dpkg has more active development now than it has for much of the past fifteen years. And they've even talked some about implementing debconf conffile prompting and fixing other much worse dpkg/debconf integration points. That's fairly minor compared to developing saner source package formats, really. One could complain that debconf itself is not being as well maintained as it might be. One of its two maintainers avoided having anything to do with Debian for a full year recently. Especially the transition to using cdebconf has been stalled far too long, on some bugs that are documented and should be a straightforward matter of coding to fix. - The concept of all services are immediately started after configuration and deleting all stop/start links will cause the package's defaults to be re-established on the next package update is meeting a lot of resistance in the user base lately. Many people use this as explanation why Debian is totally out of the question in a professional environment for them. Is there some reason that these professional environments cannot deploy a 2 line policy-rc.d? Perhaps someone should make a no-auto-start-daemon package that contains it? I have seen a lot of users run into the update-rc.d link issue, but never seen any perceive it as anything more than a minor gotcha that you learn the workaround for. -- see shy jo signature.asc Description: Digital signature
Re: Results for Project membership procedures
aj wrote: Joey Hess Hmm, I have the ballot (3341) that I sent in on Dec 14th right here. I have logs indicating it got to master[1] half an hour before deadline. I see I got an ACK for the other ballot, sent at the same time, but not for this one. Anyway, it's always interesting to see your vote analysis. Managing to make this vote actually mean something is quit an accomplishment. -- see shy jo [1] Dec 14 23:24:34 wren postfix/smtp[10681]: 1216131437A: to=gr_members...@vote.debian.org, relay=master.debian.org[70.103.162.29]:25, delay=6.7, delays=2.3/0.02/3.5/0.79, dsn=2.0.0, status=sent (250 OK id=1LC50U-0004Tc-EZ) signature.asc Description: Digital signature
Re: Final call for votes for the debian project leader election 2008
Adeodato Simó wrote: I, too, think that the quoted sentence above from Manoj is just plain inappropriate in a message sent with the Secreatary hat on. I personally, don't belive in this hat concept that seems to have infested the project. When I write a mail, *I* am writing the mail, it doesn't matter in what capacity I am doing so. I also don't wear hats[1]. I hopefully won't post more to this thread, though I'd be curious to know if other people think the above is just fine to say on d-d-a, or just don't care at all, or else. I like to see people being themselves on d-d-a, and not some simalacrum of a role that they're pretending has ursurped their personality. -- see shy jo [1] Unless I'm about to die of sunstroke in Mexico. (Thank you for saving me, Phil.) signature.asc Description: Digital signature
Re: Final call for votes for the debian project leader election 2008
Luk Claes wrote: Everything that is sent as [EMAIL PROTECTED] is seen as official posts from the project just like things sent from [EMAIL PROTECTED] only in different capacities... Some DPLs have found it useful to use the DPL email alias to lend more importance to what they're saying, or avoid using it to avoid lending importance to what they're saying. Others have happily carried out DPL activities using their personal weblog. In either case it's still the person who's leading the project speaking, and if they feel expressing their personal opinions is a good way to lead the project, good for them. If we wanted the project secretary to be a small perl script, one could be written. I prefer Manoj. I guess I also should send some personal opinions about some packages (or maybe even maintainers) in the Bits from the Release Team... That would probably be helpful in some cases. -- see shy jo signature.asc Description: Digital signature
Re: Technical committee resolution
Ian Jackson wrote: That's a nice idea but if a problem with the TC is that the decisions are too poor, reducing the number of people who review those decisions seems like a bad idea. One thing that I'm feeling is that if a technical decision comes down to a vote by a committe, there's often *no* good choice. Making a choice is often what's important. The best example of this is the amd64 naming issue, there were some technically bad choices to steer away from, but it mostly came down to an arbitrary decision needing to be made. -- see shy jo signature.asc Description: Digital signature
Re: Technical committee resolution
Don Armstrong wrote: On Sat, 29 Mar 2008, Joey Hess wrote: Well, just to pick an example, if the TC had chosen you to deal with the wordpress-in-stable issue, and you had personally decided it needed to be in stable, and had done whatever work was initially needed to get it into stable with security support, you'd still be responsible for its security now, and the several security holes it has now would be a problem that you'd be aware of, and at least be worrying about if nothing else. The package in question, as problematic as it is, has an active maintainer who claimed that he would do exactly this. According to the list of open bugs that I can see, the security issues that are currently affecting the stable version are supposedly minor. [If they're not, someone who knows more about the CVEs in question that I do should file more bugs and/or adjust severities appropriately.] By bringing an issue to the tech ctte, both sides of the issue have to give up some control, and thus reposibility. So in this case it's not just wordpresses's maintenance, but also the security support work that the security team would notmally handle (ie, writing DSAs and pushing out fixes) that the tech ctte delegate would be responsible for. FWIW, at least these security holes seem pretty bad: CVE-2007-3543, CVE-2007-3544 remote upload and execution of php code CVE-2007-4154 7 varieties of SQL injection CVE-2008-0196 directory traversal via .., and arbitrary file modification CVE-2007-1599, CVE-2007-3639 redirect authenticated users to other sites and obtain potentially sensative information -- see shy jo signature.asc Description: Digital signature
Re: Technical committee resolution
Ian Jackson wrote: So these two don't seem necessarily to indicate that the decisions were wrong, just that they were ignored. There has indeed been a problem with TC decisions being ignored. The TC is the decision-maker of last resort. So if such an issue is brought to the TC, a decision is made, and that decision is ignored, the TC has in a sense failed. Either it's made a technically bad decision, or it's taken on an issue it should never have ruled on (since someone else was able to make the actual final decision), or it's made a decision that while perhaps good in an ideal world, did not survive contact with the real one. All of these are in a sense wrong decisions, and I see some of each in the examples I listed. It is right that we should think about the quality of the TC's decisions. We should have a mechanism that causes us to review a decision, even after it is too late to change. One of the problems with having a committee who votes on an issue is that often no-one in the committee actually assumes responsibility for the issue. Which is why TC decisions can easily be ignored, and why there's not much review of decisions. I've talked about not liking committees.. I'd rather have a pool of people, and when there's an situation where the normal decision making processes fail, have one person be selected from the pool and be given the responsibily to make the decision, and see it though. That includes implementing it (or finding help to do so), following up on it, and generally being responsible for it just like a developer is responsible for a package. Note that the constitution already has provisions for something like this, but we don't use it for technical decisions much, except in the cases of teams like the release team that take over responsibility for a whole class of decisions. The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the ^ Technical Committee. The TC members seem to be a good pool of people to choose from. I respect everyone on it individually and would be happier bringing an issue to the TC if I knew it meant any one of them would have to take responsibilty for it, rather than all of them (eventually) voting on it. I haven't really considered a fair way to select a person from the pool. It would be nice if the process was not completly random and favored individuals' strengths, but at the same time it shouldn't be predictable who will be assigned before an issue is brought, as that would encourage gaming the system. Perhaps the overall TC's job would be to choose which of its members to assign the issue to. I suspect that such a pool of developers would be much less fun/more work to serve on than the current TC, and would probably have a naturally higher turnover. I think it would also be more satisfying, and might attract valuable people who don't see the current TC as a good use of their time. -- see shy jo signature.asc Description: Digital signature
Re: Technical committee resolution
Clint Adams wrote: No, I would argue that a portion of its membership is trying to rush and make decisions far too quickly. I've never been directly involved in an issue being brought to the TC, but every time I've seen it considered, or considered doing it myself, the glacial speed of the TC has been a major factor in it not being used. Unless you don't want to see the TC be used, its slowness does not seem to be a good thing. Generally issues that were not brought to the TC because its too unwieldly and slow have been decided by arbitrary fiat[1], or left unresolved, or something similarly not ideal. -- see shy jo [1] Hi, I'm Joey Hess and I decided that Debian's default desktop is gnome. How was I able to make this decision? DamnifIknow. signature.asc Description: Digital signature
Re: Technical committee resolution
Manoj Srivastava wrote: This does somewhat resonate. But the experiment where we decided to hand over an issue to one member who took ownership of the issue did not seem to have resulted in a very different outcome -- perhaps because we ultimately did come back to a vote. Which issue was that? Which is why TC decisions can easily be ignored, and why there's not much review of decisions. I don;t understand why taking responsibility for decisions results in higher reviews. I have taken decisions as secretary, and as policy honcho before russ came on board, and I do not recall more of a review. Well, just to pick an example, if the TC had chosen you to deal with the wordpress-in-stable issue, and you had personally decided it needed to be in stable, and had done whatever work was initially needed to get it into stable with security support, you'd still be responsible for its security now, and the several security holes it has now would be a problem that you'd be aware of, and at least be worrying about if nothing else. Or perhaps you might have made a different decision, such as getting the newer, security-supported version into stable rather than the old one, to cut down on the work you'd need to do later. So less a review and more a continuing awareness of the conseqences of the decisions, since you have to deal with them personally as they unfold. (BTW, another thing I like is that responsible for the security of wordpress in etch is a much smaller peice of power/resonsibility than responsible for deciding whether to override the security team.) I suspect that such a pool of developers would be much less fun/more work to serve on than the current TC, and would probably have a naturally higher turnover. I think it would also be more satisfying, and might attract valuable people who don't see the current TC as a good use of their time. For the record, I'd be willing to try this suggestion out on the ctte. Well I'm happy at least one person doesn't think it's a lame-brained idea or too much to ask. I wasn't sure how it would be recieved. -- see shy jo signature.asc Description: Digital signature
Re: Technical committee resolution
Manoj Srivastava wrote: On Fri, 28 Mar 2008 21:37:29 -0400, Joey Hess [EMAIL PROTECTED] said: Hi, I'm Joey Hess and I decided that Debian's default desktop is gnome. How was I able to make this decision? DamnifIknow. As RMS would say on emacs-dev; a decision like this should be made by polling the suers (not a vote -- polling them for opinions _and_ reasons. The TC would have been equally wrong body to make this decision. And yet if the d-i team / debian-cd team / developers at large had a contentious fight about this, the TC would be the ones stuck with the final decision. (FWIW, I obviously did listen to users to a certian extent when making this decision, and since I reluctantly own the issue, I continue to have to listen to users as well as try to keep up with things like kde 4, to make sure that we're still doing *a* (not *the*) right thing. This includes reading all posts on debian-user, scanning forums.debian.net, reading installation reports, etc. Bleh..) -- see shy jo signature.asc Description: Digital signature
Re: Technical committee resolution
Ian Jackson wrote: The causes seem to include: Isn't the main cause that the Technical Committee is well, a committee? (Recall the old saying about many heads and no brain.) That seems to be the core reason for all the problems you listed. I think we could fix these by * Increasing the size of the committee to provide more available energy and effort If the problem is that it's a committe, that won't work. -- see shy jo signature.asc Description: Digital signature
Re: Technical committee resolution
Ian Jackson wrote: The main symptom of the TC's brokenness is that it is not making decisions, or not making them fast enough. Agreed. I haven't heard anyone suggest that the TC is actually making wrong decisions. Well.. #104101: The TCs resolution that kernel sould have VESA fb compiled in was ignored by its maintainer, who instead waited for it to be fixed upstream so it could be built as a module. #164591: The TC decided that md5sum /dev/null should not be annotated with -. This must have been the wrong decision, since it was reversed in the TC's ruling on #341839 #413926: The TC decided wordpress should be shipped in etch, despite the security team's desire to not support it. The security team's tracker now lists 11 open security holes for the version in etch; the team has so far managed one DSA that closed 4 other holes. -- see shy jo signature.asc Description: Digital signature
Re: Constitutional amendment: reduce the length of DPL election process
Anthony Towns wrote: Reducing the DPL election period from 17% of the year to 11% seems like a win to me. YMMV. Well, you could get to 5.5% then by only electing the DPL once every 2 years. -- see shy jo signature.asc Description: Digital signature
Re: Constitutional amendment: reduce the length of DPL election process
Wouter Verhelst wrote: While we're at it, I've long felt that a one-year DPL term is just too short (because a DPL needs to spend a few months to get worked in, and can't do all that much when the next election is about to turn up for fear of being accused to be campaigning, often leaving only slightly over half a year or so of time for real work to be done). If more people feel like it, I'll draft up an amendment that turns it into a two-year term, or so. I'd probably second that, but I'd really appreciate hearing from past and present DPLs, as well as DPL candidates, to decide how to vote on it. PS, probably too obvious to mention, but such an amendment needs to only take effect at the next election cycle. -- see shy jo signature.asc Description: Digital signature
Re: On the Debian Maintainers GR
Christoph Berg wrote: Particularly I don't like the fact that the initial policy for an individual to be included in the keyring does not include any check of any technical or non-technical skills besides having a gpg key and be able to tick 3 checkboxes. Being on the keyring is intentially a lightweight process. The technical skills check is that they have to already be listed as a Maintainer of a package in the archive before they can upload as a Debian Maintainer. -- see shy jo signature.asc Description: Digital signature
Re: Debian Maintainers GR Proposal
Anthony Towns wrote: 1) A new keyring will be created, called the Debian maintainers keyring. It will be initially maintained in alioth subversion using the jetring tool, with commit priveleges initially assigned to: FWIW, I'm uncomfortable with the idea of a GR that specifies what tools (jetring, svn) should be used. It should be left up to the discretion of the people doing the work. If either jetring or svn turns out to be fundamentally broken by design :-) , we don't want a GR to be required to throw them away and choose something better. Which begs the question of what to do about this: * the Jetring developers (Joey Hess, Anthony Towns, Christoph Berg) Basically, I think this comes down to the set of people who have worked on jetring being the people who are interested in making this work as well as possible on the technical side, and if we're part of the team it's due to that broader commitment -- a commitment that others could also make without necessarily being the person who happened to write jetring initially. * the individual has not annually reconfirmed their interest How do you anticipate this working? Would having made an upload within the past 12 months be an implicit reconfirmation of interest? Looks good otherwise. -- see shy jo signature.asc Description: Digital signature
Re: Debian Maintainers GR Proposal
Raphael Hertzog wrote: That's precisely why it's written initially twice in that sentence. initially is ambiguous. Also, I don't want a precident of voting on what tools developers must use. We already have enough bad GR precidents. :-P -- see shy jo signature.asc Description: Digital signature
Re: Debian Maintainers GR Proposal
Anthony Towns wrote: Err, it doesn't seem ambiguous to me: it'll start this way and may change later... If you'd like to suggest other wording, you're welcome to... If it's unambiguous, then the specification of what tools to use is pointless, since it can change at any time, and so again, I am not comfortable with a GR that micromanages how I do my work. -- see shy jo signature.asc Description: Digital signature
Re: Debian Maintainers GR Proposal
Florian Weimer wrote: * Anthony Towns: 5) The intial policy for the use of the Debian Maintainer keyring with the Debian archive will be to accept uploads signed by a key in that keyring provided: * none of the uploaded packages are NEW * the Maintainer: field of the uploaded .changes file matches the key used (ie, maintainers may not sponsor uploads) * none of the packages are being taken over from other source packages * the most recent version of the package uploaded to unstable or experimental lists the uploader in the Maintainer: or Uploaders: fields (ie, cannot NMU or hijack packages) * the usual checks applied to uploads from Debian developers pass I suppose their should be checks for unchanged Provides: and Replaces: lines, too. (Not sure about Enhances:.) There are an infinite number of ways to divert or break files from another package. AFAICS, the checks in the abovequoted portion of aj's proposal are not meant to address such things (that's covered by the bit about DMs being malicious or generally bad). -- see shy jo signature.asc Description: Digital signature
Re: Debian Maintainers GR Proposal
Joey Schulze wrote: The NM process after all is meant to help new maintainers become skilled maintainers of packages. If we want to get them maintain packages without going through NM we should not create a new stage but drop or restructure the NM process. IMHO The same argument could be applied to sponsoring of packages, so I don't find it convincing.. When somebody becomes a DM without going through the NM process and thus has no skills on packaging besides those required for the very package they started with and now wants to package $cool_kde_application which requires $not_so_cool_kde_libraries they also need to package how are they supposed to do so? DMs are not allowed to upload new packages, so they have to find a sponsor to review their work on the new package and upload it. If the DM does not know enough to make a good package, the sponsor should catch this. Or are DMs only allowed to maintain the packages they started with as long as they haven't become more complex so that they can't exceed their packaging skills? Basically yes, and of course, we tend to grow our skills as the packages we maintain grow. Or start clearly sucking and motivate someone else to step up and work on it. -- see shy jo signature.asc Description: Digital signature
Re: Question for Gustavo and Sam: bringing back the fun
Aigars Mahinovs wrote: Flamewars are good if the discussions are based on facts. Lately most flamewars in Debian were on opinions, not on facts. I think it would be useful if we only used the term flamewar for threads that contain actual flaming. The current alternate usage of flamewar for any thread that's annoyingly long to read tends to confuse the issue and perversely promote both sorts of threads: People actively engaged in flaming may think oh, I'm helping the project with another useful flamewar, and people making threads annoyingly long to read may think oh, I'm being cool by being a flame warrior. -- see shy jo signature.asc Description: Digital signature
Re: First call for vote on immediate vote under section 4.2.2
Debian Oroject Secretary wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 2808c3bb-6d17-49b6-98c8-c6a0a24bc686 [ ] Choice 1: The DPL's withdrawal of the delegation remains on hold pending a vote [ ] Choice 2: The DPL's withdrawal of the delegation stands until a vote - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- I'd like to note that since this vote does not offer a you're all insane and wasting my time crossposting this to debian-devel-announce, I won't be voting on it. -- see shy jo signature.asc Description: Digital signature
Re: Proposal - Defer discussion about SC and firmware until after the Etch release
MJ Ray wrote: Which brings me to a related point: some participants in this discussion have been poor at mentioning vital roles they hold, or making it clear what hat(s) they are wearing. Sorry to break it to people, but 'see shy jo' is not that famous yet that it makes everyone remember 'ah, debian-installer'. If you don't understand from what position I'm making a statement that starts with from the d-i side then feel free to ask for a clarification. But I don't wear hats. -- see shy jo signature.asc Description: Digital signature
Re: kernel firmwares: GR proposal
Thomas Bushnell BSG wrote: Right. And the problem is that the d-i team seems to say to themselves, as long as we never do the work, we can badger the rest of Debian into sacrificing the Project's principles, and the work will never be necessary. Um, no. a) I told people at DebConf that I estimated the work would take 6 months. b) Splitting the stuff out of the kernel is a precondition for the work. It's hard to implement something when the specifics of what it needs to deal with are unknown. c) The only thing separating the d-i team from you (generously), is their time, knowledge, and inclination to work on d-i. You don't get to accuse volenteers of this kind of thing when you're not stepping up to do any work yourself. It's a good way to stop having volenteers. The solution requires a little stick to go with the carrot: I'm sorry, but the fact that you dithered for eighteen months does not mean the Project must now sacrifice its principles so that you can dither some more. Your characterisation of six months of intensive development as dithering is absurd. I'll note that I consider this mail a personal attack on both myself and many people I respect, and leave it at that. -- see shy jo signature.asc Description: Digital signature
Re: Proposal - Amendment - allow hardware support from non-free into the debian system
MJ Ray wrote: 3. as a special exception to help users who have vital hardware without free software drivers yet, the Debian system and official CD images may include hardware-support packages from the admin section of the non-free archive area which conform to all Debian Free Software Guidelines except guideline 2 (Source Code), or an archive section/area with equivalent requirements. This is seriously flawed: - It ignores all other installation media supported by debian (floppies, netboot, hd-media, dvd, etc). - It says that certian packages from non-free are part of the Debian system, which is a self-contradicting statement. - It has this strange thing about only stuff from the non-free admin section, which is just totally weird. If we drop the useless sections for debtags, or divide a section, or decide to put stuff in some other section, it magically becomes not a part of Debian? - It talks about non-free _drivers_, which have not been a topic of any debate. No one has suggested including non-free kernel drivers on Debian installation media or supporting them in the installer, and I am confident it will never happen, for many reasons. -- see shy jo signature.asc Description: Digital signature
Re: Proposal - Amendment - allow hardware support from non-free into the debian system
MJ Ray wrote: Apart from maybe possibly getting the wrong section, I think all of those so-called 'serious flaws' are based on misreading the proposal. It certianly seems to be based on us having different defintions of terms including the Debian system and drivers. AIUI, I would word your proposal something like this: 3. as a special exception to help users who have vital hardware without free firmware, the Debian installation media images may include selected firmware from non-free archive, which conforms to all Debian Free Software Guidelines except guideline 2 (Source Code). -- see shy jo signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Joey Hess wrote: 1. The archive did not support a non-free section for udebs until today. Done. 2. libd-i and anna do not support multiple udeb sources, but can only pull from one at a time; noone has yet fixed this mrvn pointed out that true multiple source support isn't needed for this (though it would be very nice for other things). Actually, at least net-retriever already supports multiple suites. 3. The Debian kernel does not currently have non-free firmware separated into different packages. 4. Numerous installation cases become much more complex assuming the above is all implemented. Examples: -- see shy jo signature.asc Description: Digital signature
Re: Amendment: special exception for firmware because of technical limitations
Aurelien Jarno wrote: Not also that I found sad that the DPL try to kill this GR with his latest mail to debian-announce. The problem is known for a long time. How does posting straw polls of our users and developers to d-d-a manage to look to you like an attempt to stop this GR? If he wanted to help, it should have been done that before, not a 3 months before the announced date of the release. And also not while proposals are beeing discussed. He just want to be awarded because he found a solution to the problem. I wish that I had your mind-reading capabilities. No, strike that, your world seems worse with it then mine without it. -- see shy jo signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Anthony Towns wrote: If it makes sense, what are the major difficulties/inconveniences/whatever that were found in having this happen for etch, that will need to be addressed to achieve an etch+1 release that's both useful and convenient for both people who need/want non-free things, and those who want a completely free system? From the d-i side, the major difficulties are: 1. The archive did not support a non-free section for udebs until today. 2. libd-i and anna do not support multiple udeb sources, but can only pull from one at a time; noone has yet fixed this 3. The Debian kernel does not currently have non-free firmware separated into different packages. 4. Numerous installation cases become much more complex assuming the above is all implemented. Examples: a. netboot install where the NIC needs non-free firmware. Possible solutions include: i. Ship a non-free installation image, either extra-debian (as is done for the nslu2), or in non-free. With the problems that: * Such an image will automatically become the image most users use to install, since it's more likely to work. (Example: the nslu2 install image) * So the free image won't be used or tested much. * So we've doubled our work and QA for no actual benefit. ii. Ship only a single free image, with some procedure (ie, cat firmware.cpio initramfs) that users can run to make it include the non-free firmware. * This limits the users who can use it to users competant to assemble it on their own. iii. Require that the user feed the machine some media with the firmware. * Assumes that the drivers for the media don't need non-free firmware. * Assumes that the machine supports removable media. * Removes most of the benefit of netbooting in the first place. b. CD install where the CD, disk, NIC, etc need non-free firmware. Possible approaches include: i. Provide some way for the user to remaster the CD. * Too hard for most users. * If the CD drive itself needs non-free firmware they will need to modify the initrd too, which gets into the really hard territory. ii. Allow some way for the user to add a new session to the CD containing the non-free firmware. * No idea how this could work, but it does prove that drunken late night discussions at DebConf are good for something. * Wouldn't address any firmware that needs to go in the initrd, ie, CD driver firmware. iii. Require additional media (floppy, usb key) or network. * Assumes that the drivers for the that don't need non-free firmware and that the machine supports floppy, usb or network. . Ship a separate non-free CD. * Which then becomes the one everyone uses because it works, as with the non-free netboot image above. * Does bad things to our CD/DVD disk space requirements. Also, in the case of a CD that needs non-free firmware, we have to provide the installer with a way to get not just udebs for the firmware, but debs for it, for the installed system. This complicates all of the above approaches significantly. c. CD or network, etc install where the disk drive needs non-free firmware. If we have 1, 2, and 3 done, this isn't a large issue, but yet another complexifying case. d. Install _from_ hard disk (internal or USB), where the disk needs non-free firmware. This is probably the easiest installation media for a user to modify to add non-free firmware, so it may be amoung the easier cases to handle. 5. Implementing anything in 5 is a lot of work. Implementing it all will be pretty atrocious. My guess is still 6 months of solid work to implent a credible subset of 5, just like it has been all along. 6. We have no clear idea as to which of these possibilities is feasable or the right way to go. 7. People seem to find it much more rewarding to work on fixing bugs in d-i and adding spiffy new features like hard drive encryption and GUI installers than on firmware splitting. And more power to them.. (The work done for the nslu2 provides a small counterpoint to this.) It's worth noting that all of the above also applies to including non-free kernel modules in the installer, although AFAIK we don't have many if any of those in a form suitable for d-i in the archive. -- see shy jo signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Joey Hess wrote: . Ship a separate non-free CD. iv 5. Implementing anything in 5 is a lot of work. Implementing it all 4 will be pretty atrocious. My guess is still 6 months of solid work to implent a credible subset of 5, just like it has been all along. 4 -- see shy jo, suprised some days he didn't fail kindergarten signature.asc Description: Digital signature
Re: Vote analysis
Anthony Towns wrote: So, by the looks of things, we get the same result with either American-style voting (only the first ranked candidate counts) Actually, by American-style voting, several of the candidates would have needed to band together to geta bigger share of the votes, with the ones perceived less likely to win not apprearing on the ballot at all, except possibly as veeps. However, these parties would make sure to try to appeal to as many people as possible, so they'd be very similar underneath. So we might have had a ballot like this: Andreas (with Bill as veep, and Steve losing in the primaries, and shadowy figures backing) Jeroen (with Ted as veep, and AJ losing in the primaries, and shadowy figures backing) Ari Votes would be cast by editing /media/floppy/i-want-to-vote on gluck, with no file locking, revision control, or GPG keys (but with, possibly, a LD_PRELOADED /lib/diebold.so causing some writes not to happen). Of course, only users in groups 18+ can vote. And votes would be counted by a shell one-liner that Manoj developes on the fly before each vote. Although sometimes the tech committee would step in and require that he add arbitrary grep -v's to it and run it again. So due to Ted's suprising unpopularity, I expect Andreas would have won that vote. Although some people would think that it's all Ari's fault that Jeroen wasn't elected. But hey, instead of this graphvis nonsense, we would have a nice map with big blocky red and blue bits on it, to nicely indicate how utterly divided the project was on the vote. And Andreas would have lots of money to spread around to his loyal supporters. So everything would be ok. -- see shy jo, congrats on your win btw signature.asc Description: Digital signature
Re: Question for Bill Allombert: the menu mess
Ted Walther wrote: If menu is a legacy program written by someone else It would be documented in debian/changelog. menu (0.0) unstable; urgency=low * initial release -- joost witteveen [EMAIL PROTECTED] Tue, 5 Nov 1996 22:42:09 +0100 Said changelog also documents pretty well how it grew fairly orginically from simple variable substitutions to a nearly(?) turing complete language. -- see shy jo signature.asc Description: Digital signature
Re: Questions to candidate Anthony Towns
Anthony Towns wrote: (a) branching the archive or doing other necessary changes to ensure netinst CDs etc work reliably Netinsts are relatively robust (though can be broken), businesscard, netboot, and floppy would really benefit from that. (b) security.d.o support against the last preview release, so that users can upgrade from CD/DVD and only have minimal daily downloads Right.. At the moment we don't even include the secure-testing repo in sources.list. (c) having it be an equally important part of the project to stable point releases, including a mail to -announce and similar Nod. Another thing we don't do right now is keep the DVDs and larger CDs static as released, they continue being updated each week. I presume that means that they were broken a week or two ago when stuff was switching over to the current d-i? Probably broken several times before that. We have kept a full copy occaisionally in the past, it's just a matter of doing it (and disk space). -- see shy jo signature.asc Description: Digital signature
Re: Reflections about the questions for the candidates
Enrico Zini wrote: I just went back to the mail archive of that time and stopped reading after a while because of anger rising: lots of good efforts have been done, and the instant reaction to those was in various case absolutely disappointing. It's all stuff you can't put in a report: you just have to swallow, be patient, keep insisting, try new things, this is going to be a long-term one. Would it be possible to illistrate this with a few examples? X: but that isn't fair, we HAVE been doing things! Y: how do you argue that, without disclosing A, B and C? X: sucks. Y: sucks. So why is everything that the DPL is involved in so secretive that they cannot disclose it to the project? It seems that we have a DPL election period where all the candidates try to be very open about where they want to take the project, followed by a DPL term where everything happens in private. Why can the DPL only effectively lead in private? Isn't there a big disconnect there? Anyone else not like this at all? So we waited until we had something big to show. And that's were we found out that when something big happens, even if the DPL has been putting lots of efforts in talking people into making it happen, they never happen in the name of the DPL. They would if it were clear that the DPL had led the project to this happening, in public[1], surely? -- see shy jo [1] Which can after all, include debian-private. signature.asc Description: Digital signature
Re: Questions to candidate Anthony Towns
(Please treat this question as if it were asked on debian-devel not here.) Anthony Towns wrote: I do think it would be interesting for the project to embrace the d-i beta releases and the testing-security support and turn those into regular mini-releases, without many of the standards we expect of stable, but in a form that's still useful. That's been a goal of mine for several years. What more do you feel we should do on those beta releases to reach that? Note that they already include a full set of CDs/DVDs that are tested to work approximatly as well[1] as stable releases. One thing we don't do is branch and freeze the archive, but the consequences of that seem smaller than might be expected. Another thing we don't do right now is keep the DVDs and larger CDs static as released, they continue being updated each week. Another thing we omit is a set of release notes and an upgrade guide from past releases. As far as the testing security stuff, there is always room for improvement but the number/severity of holes fixed in unstable but not testing is generally swamped by both the number not fixed anywhere and by the number (but not generally severity) of those not fixed in stable. So is it just a matter of terminology, perception, and polish; or do you see other major areas where we should improve? -- see shy jo [1] Or arguably better; unlike the first set of stable CDs ours have always worked. :-P signature.asc Description: Digital signature
Re: GR Proposal: GFDL statement
I'm confused. Where does it say that we have to go through the GR process to issue a position statement for something the project has already decided on? -- see shy jo signature.asc Description: Digital signature
Re: Alternate proposal for Declassification of debian-private archives
Manoj Srivastava wrote: a) The post contained sensitive material. In this case, if a reasonable case has been made for the material being sensitive, and one that the declassification teams accepted, then the material should be redacted from the post, and every post it has been quoted in. If it is sensitive in one post, it is sensitive in another. I'd kind of expect that to be done anyway under AJ's proposal. After all, AJ's proposal says that the author of a post can request for it not to be published, and for example by contributing the quoted material above and below, you are a part author of this post that I am writing now. b) I do not want to be associated with the post in question In other words, if this showed up in google it may hurt my future job prospects post ;-). In this case, the post can be published, just every identifying bit about the author needs be redacted from this post and the quotes. Successfully doing this could be quite hard, perhaps much harder than it first appears. I've seen some interesting reserch in these areas that indicates that it's much harder than would be expected to post anonymously, and that elements such as style, time of day, etc can be very effective in tracing an anonymised post back to its author. I don't have URLs for the studies handy but I could dig them up. For more a more personal take on it, note that I am reasonably sure that I can identify any text of more than a few words that you've written in the past 10 years or so in Debian -- I know you, I know the identifying characteristics of your text and even some of your common typo forms. It's quite possible you have the same ability to identify text I have written. This makes obfuscation difficult. If I were part of the declassification team (and yes, I do plan to volenteer to be on it), I would consider this obfuscation to be too challanging to do, and would have to treat requests to do it as requests to not publish the post and derivatives. Which makes your proposal have an identical result as AJ's. -- see shy jo signature.asc Description: Digital signature
Re: Alternate proposal for Declassification of debian-private archives
Here are the urls I didn't find for my other post: http://vitanuova.loyalty.org/nb/nb.cgi/view/vitanuova/2005/03/13/0 http://www.usenix.org/publications/library/proceedings/sec2000/full_papers/rao/rao.pdf http://vitanuova.loyalty.org/NewsBruiser-2.6.1/nb.cgi/view/vitanuova/2005/04/06/0 http://en.wikipedia.org/wiki/Stylometry http://www.sciencenews.org/articles/20031220/bob8.asp -- see shy jo signature.asc Description: Digital signature
Re: GR Proposal 2: Declassification of -private
Daniel Ruoso wrote: I change my position as it seems that's needed to take it to the vote. I consider the whole proposal more important than the differences between them Me too, but I suspect Manoj will be happy with Aj's new proposal, so I will limit myself to seconding it. -- see shy jo signature.asc Description: Digital signature
Re: GR Proposal: Declassification of -private
Anthony Towns wrote: Comments, suggestions and seconds appreciated. I'm very happy to second this proposal, since it saves me the bother of finishing the rough draft of the same thing I've been sitting on for a year, and is much more thought out to boot. Clearly an idea whose time has come. :-) -- see shy jo signature.asc Description: Digital signature
Re: Question to candidates that signed the Vancouver plan as candidate DPL
Bill Allombert wrote: The Vancouver plan has several mention of the security team which lead to believe it was accomodated to address the concern of this team. However [EMAIL PROTECTED] shows that the security team was not consulted and the most active security officer does not endorse the plan, and has no problem suporting 20 architectures security-wise. Er, let's quote every mention of security in Steve's mail: [EMAIL PROTECTED]:~wget -q -O - http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html | grep -i security | sed 's/^/# /' | re-add-some-missing context | manual-annotations 3 /dev/joey/brain # update[1], deploying the testing-security queues has been held up # queues for testing-security. This week, Andreas Barth and Ryan Murray # to handle the addition of testing-security queues. Once this happens, # the testing-security configuration should itself be completed for all # architectures in quick succession, with the result that testing-security All of the above refers only to the testing-security queue for sarge. AFAIK the only involvment of the security team with that queue is that they require said queue to exist at release time so they can easily support 20 architectures. Anyway, no mentions of the security team yet. # The reality is that keeping eleven # architectures in a releasable state has been a major source of work for # the release team, the d-i team, and the kernel team over the past year; # not to mention the time spent by the DSA/buildd admins and the security # team. First mention of the security team. It's a bit strange that it mentions testing being a source of work for the security team, who after all do security for stable, but it could well be referring to any of these activities: - coordination with buildd admins and RMs about the upcoming release, buildd setup for testing-security, etc - contacting maintainers to get package fixes in unstable - coordinating security releases with unstable getting fixed to (to some degree; most recent DSAs have included a note about the fix in unstable as well as testing) It's not clear to me how much of this has to do with the number of architectures though. Another possibility might be that it's referring to the testing security team. We have indeed (and as expected) seen that autobuild issues tend to make it hard to get security fixes into testing in a timely manner[1]. So perhaps this refers to that team. Or some combination of the two teams. Yet another possibility of course is that the four words and the security team were added to the draft for whatever reason and escaped the notice of everyone who reviewed the document because we didn't expect it to be subject to this kind of rather useless deconstruction. # They will be released with sarge, with all that # implies (including security support until sarge is archived), but they Nothing new here, only relevance to the security team is that it's that team's mission to provide said support to Debian releases. # - the Security Team must be willing to provide long-term support for # the architecture Second and final mention of the security team. Gives them some veto power over release architectures. Doesn't seem to me to imply that they were consulted and asked for this power; instead it seems like a fairly common sense requirement similar to the requirement that a release architecture must have a working, tested installer. After all, if the security team can't support a stable release, Debian should not be calling it stable. I'm left with just the one mention of the security team that seems to imply they've had to do a lot of work keeping the eleven arches in sarge in a relesable state, and that mention seems a fairly shakey foundation to base an assumption that the document was crafted to appear to include[2] concerns of the security team and that DPL candidates who signed it were somehow lax in not checking this.. Did you sign on the assumption it has been reviewed by the security team, or did you know they had not been consulted ? Did you make some investigations ? Ftp-master and release team are well within their right to issue their proposed plan without consulting others team. However, you signed in your quality of DPL-candidate and the DPL role is to get advice from relevant parties before endorsing a plan. I'd be happy to see the DPL candidates answer these questions, but the assumption behind them seems to be on shakey ground from my reading of the document. -- see shy jo [1] See any of my periodic posts to debian-release about sarge security status. [2] Which is a rather sly insinuation that I'd hate to have to think was the main reason for Bill's mail. signature.asc Description: Digital signature
question for the candidates
This is the question I tend to ask every time, with a twist.. I see many of good ideas for ways to improve the project in several of your platforms. If you are not elected DPL, which of those ideas do you still expect to be able to work on? How will you be able to do it without the power of being DPL? In the past, IIRC, some DPL candidates have answered that they can't work on any of their platform planks without being DPL. For what it's worth, I find that answer unsatisfying, since I'd hope that any potential DPL who is serious about solving a problem they see in Debian would find ways to work on it even if not elected, and I think the approaches they would use in that situation say a great deal about how they'll lead the project if they are elected. A side twist for Branden and Andreas: If you're not elected but the other skud member is, how will this impact your ability to work on the items in your platform? Which items do you think would suffer from you not being the chairman of the skud team? Which items would you still be able to work on regardless, and why? -- see shy jo signature.asc Description: Digital signature
Re: Exclusion, was: Clarification about krooger's platform
MJ Ray wrote: The debian-installer developers are working on probably the single biggest improvement to debian access for years, making it easier to install, but some languages that were in the old installer are not in the new one and the list has been closed for the next release with very little warning or announcement. There were multiple announcemnts and as much time as possible before closing the set of supported languages for sarge d-i. We have complete translations into 38 languages (vs 22 for boot-floppies) and so far the only additional languages we've gotten translators for and had to defer until after sarge are Malagasy, Vietnamese, Serbian, Hindi, Northern Sami, Irish, Macedonian, Tagalog, Estonian, Belarusian, and Punjabi (Gumurkhi). The only language that has been dropped that was available in the boot floppies is Esperanto. I suspect that is not a significant exclusion; wikipedia puts the number of native speakers of Esperanto as a first language at 200 to 2000. I think all the lost languages are simply because there were no d-i developers who use that language in touch with their user group, rather than any wrong-doing on d-i developers' part. After all, it's time-consuming to communicate in someone else's language and they're busy already. It's actually rather stunning the amount of work that Christian Perrier and other language coordinaters have done to find translators and work with them. So, there's far more obvious exclusion produced by lack of language support than by using a wrong example gender in English. Doubful. IIRC, Christian estimates that roughly 65% of the world's population is able to use d-i in a language they know. -- see shy jo signature.asc Description: Digital signature
Re: -= PROPOSAL =- Release sarge with amd64
Sven Luther wrote: I personally trust the ftp-masters, and believe they are working for the best of the project, but it is hard when one has questions only they can answer or act to solve, to wait apparently forever in the dark. And in some cases, it is even harmfull for the project, as it delays other work that relies on it. As a proof of that, consider the special treatment the .udebs get with regard to the NEW queue processing. Yes, the fact that the ftp-masters have given one of the major things blocking sarge release priority has surely been detrimental to the project. It would have been soo much better if they'd added a few more editors or something. -- see shy jo signature.asc Description: Digital signature
Re: DRAFT amendment to Release sarge with amd64: Freeze architecture support for sarge
Steinar H. Gunderson wrote: IMHO having a GR for this is wrong -- what goes into a release is the business of the Release Manager. However, as there is already a proposal on this, there should also be a counter-proposal for those who disagree. I understand what you're trying to do, but I think that ignoring the illegitimate proposal is a better course of action. -- see shy jo signature.asc Description: Digital signature
Re: -= PROPOSAL =- Release sarge with amd64
Josselin Mouette wrote: I'm looking for seconds for this proposal, and I hope this can be discussed quickly so that it doesn't delay the release for too long. I won't even consider this proposal until you or someone else explains to me why we should use the voting system to decide an issue like this. What part of the constitution even lets a general resolution be made on a topic like this one? Why do it this way, and how could it posibly be useful to the project? If recent experience has shown us anything, it's that votes HURT Debian. Please don't take us further down this path. -- see shy jo signature.asc Description: Digital signature
Re: -= PROPOSAL =- Release sarge with amd64
Eduard Bloch wrote: Seconded. Since in the last thread initiated by me I asked for a similar action (read: an answer) and nothing happened, I think this is a clear answer from FTP masters, saying: WE ARE TO LAZY TO WORK AND TO LEET TO COMMUNICATE WITH SECOND-CLASS DDs. WE WANNA BE REMOVED FROM OUR POSITIONS. That is the only remainding interpretation of their silent response. Maybe a better GR would be one removing the ftpmasters from their position then. This would at least avoid trying to use a GR to make a technical decision, and it seems to be the position you're really seconding anyway. If that's the intent, why not be open about it? -- see shy jo signature.asc Description: Digital signature
Re: -= PROPOSAL =- Release sarge with amd64
Frank Pennycook wrote: Surely it is not so much a technical issue as a policy issue? Since different opinions are being expressed, then in a democracy it would seem valid to decide it by voting. We don't vote to decide Debian policy, where different opinions are expressed regularly, we don't vote on which bugs of a package should be fixed first, be that package debhelper or ftp.debian.org, and we shouldn't vote on technical matters here either. | 1. that the next Debian GNU/Linux release, codenamed sarge, will |include the amd64 architecture, based on the work currently hosted |at http://debian-amd64.alioth.debian.org/ ; This is a technical decision; that the amd64 port is ready, necessary, more important that other pending ports, and that that particular implementation of it is the one we want in Debian. It's also a decision about what will constitute sarge, which is, again, a technical decision, much as was the decision about which installer to use with sarge. | 2. that non-compliance of that amd64 distribution with the Linux |Standard Base specification for IA32 will not be considered a |release-critical bug; This is also a technical decision, just as if we'd decided that amd64 port would not need to use FHS directory locations, or that its shell would not be a POSIX shell. | 3. that we will include it immediately in the sid distribution and |auto-building infrastructure, and take all appropriate steps so |that inclusion won't delay the release of sarge any further. And those steps would indeed require various technical changes to the mirroring system, and probably much else. I can understand that these questions are controversial. I don't quite understand why the suggestion to vote on it is controversial. Go back and take a look at every GR this project has ever voted on, from the logo on, and the quality of the results, vs. decisions made by other means. Voting does not have a good history in this project of getting things done, or even of reaching a decision that most developers are happy with by the first vote. -- see shy jo signature.asc Description: Digital signature
Re: -= PROPOSAL =- Release sarge with amd64
Antti-Juhani Kaijanaho wrote: On Tue, 13 Jul 2004 19:03:31 -0400, Joey Hess [EMAIL PROTECTED] wrote: Maybe a better GR would be one removing the ftpmasters from their position then. This would at least avoid trying to use a GR to make a technical decision, and it seems to be the position you're really seconding anyway. If that's the intent, why not be open about it? I hope nobody considers this seriously unless there are viable candidates to replace the current ftpmasters. I can tell from experience: that job is not for the faint of heart. Actually, I think it's one possible outcome of the current proposal, if it becomes a GR and is passed. After all, when you start dictating to volenteers what jobs to do and how, you risk losing those volenteers. -- see shy jo signature.asc Description: Digital signature
Re: Amendment to the Constitution: Add a new foundation document
Manoj Srivastava [EMAIL PROTECTED]Organization:srivasta@debian.org wrote: There is precedence for this gap in ratifying a foundation and implementing the dictats of that document; as Joey Hess reminded me: I think that this document needs some serious editing before it is suitable as any official statement from the Debian project, let alone a foundation document. In particular, note the use of me above; I noticed other minor problems while reading it but do not have time for a thurough edit. I prefer not to have my name in any foundation document of the Debian project, as it could have unforseen consequences later. when we first accepted the Social Contract and the DFSG, there was an interval before we came into compliance (indeed, it is arguable if we were ever completely in compliance -- see above about it being an on going process). Indeed, there was a release of a minor version just days after the DFSG was accepted, which by no means complied. We also did not yank out older releases, or drop support for them immediately (as shown by the minor release). And given that precident, I really have a hard time understanding why this most recent change has been made into such a big deal. I think it says unfortunate things about some of the directions Debian has gone in the intervening years. Nevertheless, I suppose this document is as good a way to deal with it as any, or at least good enough to be an option on the ballot. With this document, we, the Debian Project, do so affirm this. We affirm that while we are working towards a change in the long term goals and identity of the project, or any change in a foundation document, the needs of the users shall not be catered to during the transition period. shall not? Surely you mean shall. -- see shy jo signature.asc Description: Digital signature
Re: Amendment to the Constitution: Add a new foundation document
Manoj Srivastava [EMAIL PROTECTED]Organization:srivasta@debian.org wrote: There is precedence for this gap in ratifying a foundation and implementing the dictats of that document; as Joey Hess reminded me: I think that this document needs some serious editing before it is suitable as any official statement from the Debian project, let alone a foundation document. In particular, note the use of me above; I noticed other minor problems while reading it but do not have time for a thurough edit. I prefer not to have my name in any foundation document of the Debian project, as it could have unforseen consequences later. when we first accepted the Social Contract and the DFSG, there was an interval before we came into compliance (indeed, it is arguable if we were ever completely in compliance -- see above about it being an on going process). Indeed, there was a release of a minor version just days after the DFSG was accepted, which by no means complied. We also did not yank out older releases, or drop support for them immediately (as shown by the minor release). And given that precident, I really have a hard time understanding why this most recent change has been made into such a big deal. I think it says unfortunate things about some of the directions Debian has gone in the intervening years. Nevertheless, I suppose this document is as good a way to deal with it as any, or at least good enough to be an option on the ballot. With this document, we, the Debian Project, do so affirm this. We affirm that while we are working towards a change in the long term goals and identity of the project, or any change in a foundation document, the needs of the users shall not be catered to during the transition period. shall not? Surely you mean shall. -- see shy jo signature.asc Description: Digital signature
Re: Amendment [RFD: Deferment of GR Changes from GR 2004-003]
Roland Stigge wrote: Since the sarge release is near, I fully understand the reasoning that leads to a deferral of the 2004.003 GR. But considering that the official roadmap of the next Debian release is already deferred by nearly 5 months now and considering the RC bug count and the d-i state, chances are that we can't make it in another 4 months. What d-i state is that? The state that we'll release this month with support for 10 architectures? d-i is still on the last posted schedule. -- see shy jo signature.asc Description: Digital signature
Re: Amendment [RFD: Deferment of GR Changes from GR 2004-003]
Roland Stigge wrote: Since the sarge release is near, I fully understand the reasoning that leads to a deferral of the 2004.003 GR. But considering that the official roadmap of the next Debian release is already deferred by nearly 5 months now and considering the RC bug count and the d-i state, chances are that we can't make it in another 4 months. What d-i state is that? The state that we'll release this month with support for 10 architectures? d-i is still on the last posted schedule. -- see shy jo signature.asc Description: Digital signature
Re: drop or keep non-free - from users viewpoint
Markus wrote: Now how the situation looks from a user viewpoint. I think for the most user non-free is part of the Debian OS. Let me explain why: Ask in normal Debian or GNU/Linux forums how does a normal Debian OS source.list looks. The main answer will be: deb ftp:... main contrib non-free Non-free removal or no, this is not true as of sarge. -- see shy jo signature.asc Description: Digital signature
Re: drop or keep non-free - from users viewpoint
Markus wrote: Now how the situation looks from a user viewpoint. I think for the most user non-free is part of the Debian OS. Let me explain why: Ask in normal Debian or GNU/Linux forums how does a normal Debian OS source.list looks. The main answer will be: deb ftp:... main contrib non-free Non-free removal or no, this is not true as of sarge. -- see shy jo signature.asc Description: Digital signature
Re: Revoking non-free less violently
Andrew Suffield wrote: One thing that we do learn from popularity-contest is that popularity-contest doesn't work. The sample size is too small. That's why we've made popularity-contest be installed by default for sarge. Of course the user still has to choose whether or not to turn it on. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Revoking non-free less violently
Andrew Suffield wrote: One thing that we do learn from popularity-contest is that popularity-contest doesn't work. The sample size is too small. That's why we've made popularity-contest be installed by default for sarge. Of course the user still has to choose whether or not to turn it on. -- see shy jo
English (was Re: High Rate of ballot rejections this year)
Manoj Srivastava wrote: Here is how I undesrtanfd the Shall/Will distinction: Shall is used to express the simple future for first person I and we, as in Shall we meet by the river? Will would be used in the simple future for all other persons. Using will in the first person would express determination on the part of the speaker, as in We will finish this project by tonight, by golly! Using shall in second and third persons would indicate some kind of promise about the subject, as in This shall be revealed to you in good time. There are three views on the shall/will distinction: 1. What distinction? Pretty common for modern English speakers, I think. 2. 1913 Webster warns that shall and will are often confounded by inaccurate speakers and writers 3. Merriam-Webster unabridged has this to say: From the reams of pronouncements written about the distinction between shall and will--dating back as far as the 17th century--it is clear that the rules laid down have never very accurately reflected actual usage. The nationalistic statements of 18th and 19th century British grammarians, who commonly cited the misuses of the Irish, the Scots, and occasionally the Americans, suggest that the traditional rules may have come closest to the usage of southern England. Some modern commentators believe that English usage is still the closest to the traditionally prescribed norms. Most modern commentators allow that will is more common in nearly all uses. Anyway, feel free to use shall, it's probably no more incorrect than my use of yall. -- see shy jo pgp0.pgp Description: PGP signature
English (was Re: High Rate of ballot rejections this year)
Manoj Srivastava wrote: Here is how I undesrtanfd the Shall/Will distinction: Shall is used to express the simple future for first person I and we, as in Shall we meet by the river? Will would be used in the simple future for all other persons. Using will in the first person would express determination on the part of the speaker, as in We will finish this project by tonight, by golly! Using shall in second and third persons would indicate some kind of promise about the subject, as in This shall be revealed to you in good time. There are three views on the shall/will distinction: 1. What distinction? Pretty common for modern English speakers, I think. 2. 1913 Webster warns that shall and will are often confounded by inaccurate speakers and writers 3. Merriam-Webster unabridged has this to say: From the reams of pronouncements written about the distinction between shall and will--dating back as far as the 17th century--it is clear that the rules laid down have never very accurately reflected actual usage. The nationalistic statements of 18th and 19th century British grammarians, who commonly cited the misuses of the Irish, the Scots, and occasionally the Americans, suggest that the traditional rules may have come closest to the usage of southern England. Some modern commentators believe that English usage is still the closest to the traditionally prescribed norms. Most modern commentators allow that will is more common in nearly all uses. Anyway, feel free to use shall, it's probably no more incorrect than my use of yall. -- see shy jo pgpHdLRIBzBBM.pgp Description: PGP signature
Re: General Resolution draft against spam.
A. This has no business being a general resolution, and would be an abuse of that process, IMHO[1]. B. If by some fluke all or any substantial number of these proposals came to pass, whether by GR ot any other means, I would no longer find Debian to be the type of project which I could use as a user, nor contribute to as a developer. I would leave. C. Glad to see many others agree, and hope you've dropped this completly. -- see shy jo [1] If it's not, that's a bug in the constitution. Any quibblers who would like to play constitutional lawyer, please don't list-reply. msg01823/pgp0.pgp Description: PGP signature
Re: General Resolution draft against spam.
A. This has no business being a general resolution, and would be an abuse of that process, IMHO[1]. B. If by some fluke all or any substantial number of these proposals came to pass, whether by GR ot any other means, I would no longer find Debian to be the type of project which I could use as a user, nor contribute to as a developer. I would leave. C. Glad to see many others agree, and hope you've dropped this completly. -- see shy jo [1] If it's not, that's a bug in the constitution. Any quibblers who would like to play constitutional lawyer, please don't list-reply. pgpKsNnAh8uXG.pgp Description: PGP signature
Re: [nomination] here we go...
Ben Collins wrote: Let's get the ball rolling with nominations...I, of course, am running again this year. I'm very sorry to hear that Wichert is not running for a third term, since he is a worthy candidate for DPL (as he has proven over the last 2+ years). Hopefully we'll see some new blood step forth for nominations in this election. Someone check my calculations -- Wiggy entered his second term on March 17th last year. The consitution says the new DPL should enter office one year later, with nominations beginning 9 weeks before that and lasting 3 weeks, then campaigning for 3 weeks, then voting for 3 weeks. So the next DPL should enter office on March 17th; voting should begin on February 25th, campaigning begins on February 4th, and the nomination period began on the 14th. More or less. -- see shy jo
Re: [nomination] here we go...
Raul Miller wrote: Oops, you're right -- I was thinking that last year was 1999. Actually, I seem to have been thinking this year was 2000 when I came up with these dates, so I think most of the dates in the paragraph below are off by one. :-) So the next DPL should enter office on March 17th; voting should begin on February 25th, campaigning begins on February 4th, and the nomination period began on the 14th. More or less. -- see shy jo
Re: Non-Constitutional Voting Procedure
Seth Arnold wrote: But, somehow, I don't think Debian putting itself in a position to ship without a graphical SSL web browser is a good idea. Currently, netscape is the only one I have seen that supports SSL. Konquerer works fine. So, while I love free software, I don't think killing non-free is a good idea. Not until we can ship a free graphical ssl web browser. Time to find a new objection, this one is dead. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-Constitutional Voting Procedure
Seth Arnold wrote: But, somehow, I don't think Debian putting itself in a position to ship without a graphical SSL web browser is a good idea. Currently, netscape is the only one I have seen that supports SSL. Konquerer works fine. So, while I love free software, I don't think killing non-free is a good idea. Not until we can ship a free graphical ssl web browser. Time to find a new objection, this one is dead. -- see shy jo
Re: Non-Constitutional Voting Procedure
John Galt wrote: However, I find konqueror (in kdebase) quite able already. It does everything I've needed netscape to do, including ssl, cookie management, java and javascript, and good page layout. What was the version number of that in Potato again? Um, the contents of potato are beside the point. I was simply letting people know a reaosnable replacement for netscape exists since netscape keeps coming up in discussions on this point as one of the key items in non-free that has no free replacement. Pardon me, but you have obviously mistaken me for someone who gives a damn. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-Constitutional Voting Procedure
Joseph Carter wrote: Without regard to constitutionality, I believe there are technical reasons why non-free should remain a little while longer. Netscape is the biggest of them at the moment since currently Mozilla is not ready to replace it. However, I find konqueror (in kdebase) quite able already. It does everything I've needed netscape to do, including ssl, cookie management, java and javascript, and good page layout. It feels great to purge netscape. -- see shy jo
Re: Non-Constitutional Voting Procedure
John Galt wrote: However, I find konqueror (in kdebase) quite able already. It does everything I've needed netscape to do, including ssl, cookie management, java and javascript, and good page layout. What was the version number of that in Potato again? Um, the contents of potato are beside the point. I was simply letting people know a reaosnable replacement for netscape exists since netscape keeps coming up in discussions on this point as one of the key items in non-free that has no free replacement. Pardon me, but you have obviously mistaken me for someone who gives a damn. -- see shy jo
Re: CFV: Non-free archive removal
Manoj Srivastava wrote: Joey == Joey Hess [EMAIL PROTECTED] writes: Joey So we issue DFSG v2, a new document that just happens to include the Joey text of DFSG v1 verbatim, except for oner paragraph. I think that is what should be done in any case, if this GR passes. We leave the DFSG around (since other people and projects have defined themselves around the DFSG, and they may not wish to change). (historical reasons also present themselves). If the GR passes, the project can choose to adopt DFSG-2 (-3, -4, ...) as we wish. Makes sense to me. Except, I think I mispoke and the GR doesn't actually touch the DFSG at all, just other parts of the Social Contract. -- see shy jo
Re: CFV: Non-free archive removal
Craig Sanders wrote: the facts do support what i say. the debian constitution states what documents may be created or modified by vote, yet fails to mention that either the social contract or the DFSG may be so modified. what this means is that you can't call for a vote to change either of those two documents without first getting the constitution amended to allow it. I don't follow your reasoning. In the first paragraph, you seem to be implying that the Social contract is not a document, since simply stating documents may be modified isn't good enough. Then in the second paragraph, you refer to it as a document. -- see shy jo
Re: CFV: Non-free archive removal
Adam Heath wrote: Issue, but doesn't say a thing about modifying preexisting documents and statements. So we issue DFSG v2, a new document that just happens to include the text of DFSG v1 verbatim, except for oner paragraph. This is the same as the old Who does Debian Admin answer to? thread. It seems more like the I don't want this to happen, so I will be a rules lawyer thread to me. -- see shy jo, who doesn't like the GR, but dislikes apptempts to prevent it by rules-lawyering even less.
Re: An ammendment (Re: Formal CFV: General Resolution to Abolish Non-Free)
I second this amendment. Anthony Towns wrote: On Wed, Jun 07, 2000 at 11:03:33PM -0500, John Goerzen wrote: DEBIAN GENERAL RESOLUTION Proposed by: John Goerzen [EMAIL PROTECTED] I wish to propose an ammendment to the proposed resolution as follows. The text of the resolution should be replaced with a call for the developers to resolve that: --- 1) the Debian project continues to acknowledge the utility of providing non-free software for it users. 2) the Debian project also acknowledges that some developers may be unwilling or unable to explicitly work on non-free software, and holds that this is not and should not be detrimental to their work on the Debian GNU/Linux distribution, or their contribution to the Debian project. 3) the Debian project considers equating the importance of the contrib and non-free areas described in the Social Contract with the official Debian GNU/Linux distribution inappropriate. 4) noting that the Debian project already distributes various other collections of unofficial packages, the project endorses a move to specifically collect the various other add-on components such as experimental, orphaned, non-free and contrib and to clearly separate these from the main collection. --- The intention of this ammendment is to provide a means for developers to offer their support of the existing social contract while acknowledging that the current situation does indeed give somewhat too much credibility. This is obviously something of a compromise position, and as such it is intended to be a resolution that can be agreed to even without agreeing that it's the better possibility of those offered. While the implied technical changes in item (4) should not have any significant negative consequences, they may be implemented in a way that will provide some significant benefits: tying orphaned and experimental to a particular release may make some software more accessible to users who do not wish to run unstable; and setting up infrastructure for various add-on components may make it more convenient to host staging areas that don't quite conform to policy: in order to make Gnome packages consistent, or to make IPv6 packages usable, or even to distribute Debianised KDE source. I imagine this ammendment would be best as a separate option on the ballot to the original proposal, and as such it will require five seconds. Respectfully submitted, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG encrypted mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark -- see shy jo pgpiDjagTLMKh.pgp Description: PGP signature
Re: Leadership Debates
Jason Gunthorpe wrote: Once again, I'd like to see a Leadership Debate this year on IRC between the 4 candidates. Rob Levin from Linux Care has graciously indicated that he would like to moderate and I will coordinate a time and the format. I'm hoping to do this sometime after LWE, in 1 week I think. Good idea! 2) The live debate will consist of several pre-decided questions that the candidates can debate - they may also touch on these questions in #1 [does anyone have a suggestion for the exact format this will take?] I'd also like it if people can start thinking about some hard questions that are worth the leadership candidates debating. If we can't find any then perhaps just ditch #2. What specifically do you plan to do to cause new-maintainer to reopen _soon_? What should be done in the long-term to prevent this type of problem from reocurring? -- see shy jo
Re: New maintainer proposal, re-announce
Dale Scheetz wrote: The project secretary has already said that he has seen no proposal, properly submitted, that anyone can act upon, according to our constitution. Until a proposal has been properly made to debian-vote, there can be no proper action for a developer to take. Who ever said we were going to vote on this? Wichet is delegating his athority to the new-maintainer team, I don't see why a project-wide vote is called for to reorganize that group. After all, we want this resolved *soon*, not months from now after a worthless vote. -- see shy jo
Re: Moving contrib and non-free of master.debian.org
Hamish Moffatt wrote: [contrib] You can't modify everything it does. How so? -- see shy jo
Re: Moving contrib and non-free of master.debian.org
Will Lowe wrote: On Mon, 21 Jun 1999, Wichert Akkerman - Debian project leader wrote: 1) create nonfree.debian.org domain I thinks that's even not clear enough, because the debian.org part makes it somehow official again. Personally, I would prefer unofficial.debian.org. But that, in itself, is a contradiction. How about not.debian.org? -- see shy jo
Re: Moving contrib and non-free of master.debian.org
The ballot will contain the options: 1) create nonfree.debian.org domain I would like to amend this to make it say non-free.debian.org. That is consitent with non-us.debian.org and with the current section name, non-free. -- see shy jo
Re: Moving contrib and non-free of master.debian.org
Jason Gunthorpe wrote: -- Debian shall not use it's machines or resources to distribute software that fails the DFSG. Debian will not accept any packages that fail the DFSG or support and projects producing non-DSFG complient software. Debian web pages and miscellaneous other software will refrain from indexing or otherwise referencing non-DFSG software. -- I feel this statement is in direct opposition to those parts of the social contract that say our first priority is our users. -- see shy jo
Re: Moving contrib and non-free of master.debian.org
Chris Lawrence wrote: (IMHO this proposal is a amendment to the Social Contract; it should be clearly marked as such. I also note that our beloved Constitution Which proposal? Wichert's or Jason's? Jason's is indeed a mod of the social contract. Wichert's is a mere technical change. -- see shy jo
