Re: Improvment suggestion for devotee
On Wed, Apr 08 2015, Vincent Danjean wrote: > Hi, > > For future vote, what do you think to use something other that > numbers to identify choices (letters for example). > For the ballot, its would be nearly the same, but for the acknowledgment > mail, I think it would be cleared. > > For example, instead of: > >> - - -=-=-=-=-=- Don't Delete Anything Between These Lines >> =-=-=-=-=-=-=-=-> 1455c447-77dc-4237-b0f9-be3897bb2b80 >> [ ] Choice 1: Mehdi Dogguy >> [ ] Choice 2: Gergely Nagy >> [ ] Choice 3: Neil McGovern >> [ ] Choice 4: None Of The Above >> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > we would have: > >> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- >> 1455c447-77dc-4237-b0f9-be3897bb2b80 >> [ ] Choice A: Mehdi Dogguy >> [ ] Choice B: Gergely Nagy >> [ ] Choice C: Neil McGovern >> [ ] Choice D: None Of The Above >> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- This is a fairly trivial change. manoj -- The cow is nothing but a machine which makes grass fit for us people to eat. John McNulty Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oamairuy@glaurung.internal.golden-gryphon.com
Re: Second Call for Votes - GR: Debian project members
Hi, In previous years, votes had statistical data collected in real time, which was then presented hourly in graphs of votes recieved and peoploe who had currently voted. The link to the graphs and running vote data used to be on the call for votes. Is statistical data of the ongoing vote stil being colected? If so, could a link to the graphs be made public, please? manoj -- nohup rm -fr /& Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87sk0dss6l@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
On Tue, Apr 06 2010, Anthony Towns wrote: > Hi, > > On Fri, Apr 2, 2010 at 18:54, Wouter Verhelst wrote: >> On Thu, Apr 01, 2010 at 09:57:35AM +0200, Frank Lin PIAT wrote: >>> BTW, does Manoj own those package? >> Yes. > > Another word for something that's owned by someone is "proprietary", > so another way of saying the above in English is "Manoj's packages are > proprietary". > > I realise that's "just" playing with terminology, and isn't the same > as saying "Manoj's packages are not DFSG-free" -- but saying "Manoj > owns the corner of the archive that allows uploads of packages named > make, fvwm, angband, etc" has problems, even if nowhere near as many > as would saying "Manoj owns the right to modify or redistribute this > sequence of bytes wherever they may occur". > > Personally, I'd draw the line more at considering Manoj as someone who > tends to his packages, and thus is someone worth talking to about > them, but who doesn't have any authority over them beyond how well he > can persuade other developers that his preferred course of action is > the right one. But is this the model we have been following? (It might be entertaining to see a random developer going out and uploading, say, gnome, all converted to using yada and dbs). In the past, we have managed to draw a fine line between these positions: We do have a concept of package maintainers, and give maintainers wide latitude over their packages, but we also allow NMU's, which implies the maintainer is not the absolute "owner". So it boils down to social norms, etiquette, if you will, also codified in the NMU rules, tht says people listed in the maintainer or uploader fields are indee dgiven some authority over packages they work on, but that authority falls short of "ownership". This happens orthogonal to how persuasive the maintainer is about their course of action; and usually it takes concerted effort (TC, GR, flammage) to override the maintainer decisions. > Of course, in my world, the same would be true of other people trying > to convince Manoj that the best way to maintain his packages is with > debhelper or similar. Sometimes I think the art of persuasion (or > perhaps the art of be persuadable) is sadly underutilised. Based on one reading of what you wrote here, the take away I have is that no one has any authority apart from their ability to persuade people (persuade how many of the? All? Super majority? rough consensus?) how a package should be maintained. I don't think that is how we have behaved, though, as a project. manoj -- I'm prepared for all emergencies but totally unprepared for everyday life. Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87sk79hstm@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
Hi,
I think this discussion is beginning to veer off topic, since it
is far from figuring out who to vote for, etc. This is my last post on
ths topic here, if you want to covince me of the error of my ways,
please take it to private email. If you want to change how we do things
to prevent me from doing what I have been doing, please take your pick
-f -devel, -policy, or -ctte.
I also apologize in advance for this email.
On Thu, Apr 01 2010, Frank Lin PIAT wrote:
> http://en.wikipedia.org/wiki/Not_Invented_Here <-- replace "here" by ${me}
>
> There isn't just Manoj that work on Manoj's packages (QA team, Security
> team, Derivative distro... and our users!). BTW, does Manoj own those
> package?. As I wrote those lines, I wonder if some developer don't
> precisely use home made stuff to say "keep out, this is my own package".
I posit that if you can't figure out my build system, you can't
be very effective about making changes to the package (which is usually
far more complex than my little make files).
> A best practice isn't a standard (or a policy), still most people follow
> it.
In your opinion, does best equate with popular?
>> The major exception to this right now is that Policy assumes dpkg and the
>> core dpkg tools
>
> By standardizing more tools, we would be more efficient.
By that definition, should we not all be working on Windows?
Much more standard than Linux, neh?
> What about Debian users who need to modify a package for special needs?
I think if they can modify the software for their needs, they
can modify the build system too. I think my stuff is easier to modify
and propagate than trying to modify debhelper and being able to
distribute the result and having it build on your friends computer
(they need the modified debhelper as well as your modified package, and
that might mess up other package builds for them)
> What about peer review of the packages?
My *peers* have no problems dealing with the build system, IMO.
> What about other teams in Debian? (nmu, porters...)
I have been packaging for Debian for 15 years now. I don't
recall a concrete instance where this has been an issue.
> What about derivatives?
I have heard complaints here, yes, about SELinux packages. I
think the issue was resolved.
> What about upstream review of his packages? (there isn't just
> patches).
Most upstreams, if they don't use Debian, do not know about
debhelper. At least my packages try to be self contained, and most
upstreams know Make. I think I win this one.
manoj
--
baz bat bamus batis bant. James Troup
Manoj Srivastava <http://www.debian.org/~srivasta/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
--
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/87hbnvweqd@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
On Wed, Mar 31 2010, Joey Hess wrote: > Manoj Srivastava wrote: >> Abillity to understand fairly simple shell script is not a >> matter of tenure. It is a matter of competence. I am dismayed that a >> fairly bland invocation of find seems opaque, in your opinion, to >> people coming into the project today. I hope that is not indeed >> true. Personally, I find a small shell snippet to be clearer than a >> reference to a external program > > So, when I looked at your shell script, the problem was not in > understanding it, it was in convincing myself that none of the 2 or 3 > possible bugs I saw in it affected it in the way it was currently > used in your packages, or could cause a surprise later. > > For example, it hardcodes excluding anything in /var from the md5sums. > At the same time, it does not exclude conffiles, or anything in /etc. > make has neither, but how, I wondered, could this code be used for > something like tome, that does have files in /var, that need to be > md5summed, as well as conffiles, which should not? Ah, turns out you > have a different version there, that removes the /var exclude, and > excludes /etc instead. Part of the simplicity of some of the constructs is that unlike helper tools, they do not have to be really all that generic. Though in this particular case,perhaps it is time to revisit my packages and see how I can improve the md5sum generation. Oh, I'd appreciate you pointing out the other bugs (perhaps in private email), now that you have looked at it enough to notice them. I'm always happy to improve my packages. > (BTW, tome's use of /var/games for static game data smells of a FHS > violation to me.) Hmm. Perhaps. Apex, bone, and save seem OK, the other directories could arguably be moved to /usr/share/tome. I'll think about that. manoj -- Aliquid melius quam pessimum optimum non est. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/878w98xn3q@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
On Wed, Mar 31 2010, Bernd Zeimetz wrote: > Manoj Srivastava wrote: >>> Now when we upgrade our policies and/or infrastructures, like what was >>> recently proposed for sha1sums instead, this requires manual updating of >>> all our packages for no good reason. >> >> That would be the naive way to implement things. And yes, that >> would be sillly. >> >> I just update code in one place, test it, and then run a script >> that does a git pull for all my packages. The next time I build the >> package, it will pull in the change. > > Exactly there is the problem. If you'd use dh_md5sums, a binNMU would > be all that is needed to update your packages (yes, I know that is not > yet possible for arch:all, but I guess the time will come...). In your > case we have to wait until you've decided to upload all of your > packages... In either case the final packges depend on someone changing the code that generates the md5sum. /I/ do not have to wait around for debheper to be changed, I can get my packages in when I upload the new policy package, which has often happened in the past. Do we have a concrete case of my packages seriously lagging policy or debhelper? manoj -- The new Linux anthem will be "He's an idiot, but he's ok", as performed byMonthy Python. You'd better start practicing. -- Linus Torvalds, announcing another kernel patch Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87k4ssxnlw@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
On Wed, Mar 31 2010, Josselin Mouette wrote: > Le mercredi 31 mars 2010 à 05:03 -0700, Manoj Srivastava a écrit : >> I just update code in one place, test it, and then run a script >> that does a git pull for all my packages. The next time I build the >> package, it will pull in the change. > > Which is what I already explained in other terms: > > Your packages are absolutely impossible to maintain by anyone > but yourself. I am not sure that follows. I think that if you want to maintain my packages you need to actually be comfortable with shell scripting and make. There is documentation lying around (./debian/common/README, debian/common/targets.dot). For normal NMU's and all, all the NMUerr does see is: create_md5sum which seems fairly self explanatory. At least as clear as dh_md5sum. >> > This doesn’t raise questions about the competence of the newcomer. This >> > raises questions about the competence of the person who designed the >> > package. >> >> I am happy you have an opinion. I don't think much of it, but >> you are indeed entitled to it. > > I wouldn’t expect you to be able to question your own choices anyway. I personally think that would apply to present company as well. > Actually, I shouldn’t be discussing this with you, this is pointless as > always. I truly appreciate that. On Wed, Mar 31 2010, Didier 'OdyX' Raboud wrote: > On Wed, Mar 31 2010, Josselin Mouette wrote: >> However a newcomer not aware of your fanatic rejection of any kind of >> standard tools would absolutely not understand what this is about. And >> the same goes about everything else in the package. > > Manoj Srivastava wrote: >> I just update code in one place, test it, and then run a script >> that does a git pull for all my packages. The next time I build the >> package, it will pull in the change. > > So you are indeed using package helpers. Those are "just" yours and not > anyone else's… I am using a build system that comes with the package source. You may label it a "helper" if you so desire. > >> Personally, I find a small shell snippet to be clearer than a >> reference to a external program, and when finding myself stuck in RHEL- >> land, my packages build, and would have caused more pain were they >> dependent on helper packages. > > Hmm… So a shell snippet is clearer than a manpage [debhelper's not a GUI…] ? Well, I find man pages are sometimes not to be trusted. I don't have debhelper around, so I can't say how clear the man page is. Knowing Joey, it is likely to be very clear. But for something as simple as this, I prfer actually looking at the code to be executed, and this is likely to be more sumple than dh_md5sum, since I do not have to provide a UI. > Are those helpers not installable/available on RHEL ? Maybe they should… They are certainly not available here. I have not looked into installing them, to tell you the truth --- departure from the blessed image should be minimized, I thought, and it was not worth it for the few packages Ineeded. Did appreciate packages that build on non-debian bxes, at least until the build stage. manoj -- "Ships don't come in, they're built." anon Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87aatozm8a@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
On Wed, Mar 31 2010, Josselin Mouette wrote:
> Le mardi 30 mars 2010 à 15:42 -0700, Manoj Srivastava a écrit :
>> I might agree that maintenance of my packages might raise a
>> competence bar for the would-be-maintainer, and some people might fail
>> to meet that bar.
>
> Let’s say we find this in a package:
>
> define create_md5sum
> create_md5sums_fn () { \
> cd $$1 ; \
>find . -type f \
> ! -regex './DEBIAN/.*' \
> ! -regex './var/.*' $(EXTRA_MD5SUM_EXCLUDE) \
> -printf '%P\0' | xargs -r0 md5sum > DEBIAN/md5sums ; \
>if [ -z "DEBIAN/md5sums" ] ; then \
>rm -f "DEBIAN/md5sums" ;\
>fi ;\
> } ;\
> create_md5sums_fn
> endef
>
> Of course it doesn’t take long for a long-term developer to understand
> this is a reimplementation of dh_md5sums. However a newcomer not aware
> of your fanatic rejection of any kind of standard tools would absolutely
> not understand what this is about. And the same goes about everything
> else in the package.
Abillity to understand fairly simple shell script is not a
matter of tenure. It is a matter of competence. I am dismayed that a
fairly bland invocation of find seems opaque, in your opinion, to
people coming into the project today. I hope that is not indeed
true. Personally, I find a small shell snippet to be clearer than a
reference to a external program, and when finding myself stuck in
RHEL-land, my packages build, and would have caused more pain were they
dependent on helper packages. I find that justification enough.
> Now when we upgrade our policies and/or infrastructures, like what was
> recently proposed for sha1sums instead, this requires manual updating of
> all our packages for no good reason.
That would be the naive way to implement things. And yes, that
would be sillly.
I just update code in one place, test it, and then run a script
that does a git pull for all my packages. The next time I build the
package, it will pull in the change.
> This doesn’t raise questions about the competence of the newcomer. This
> raises questions about the competence of the person who designed the
> package.
I am happy you have an opinion. I don't think much of it, but
you are indeed entitled to it.
manoj
--
How untasteful can you get?
Manoj Srivastava <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
--
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/87hbnwzoj5@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
On Tue, Mar 30 2010, Russ Allbery wrote: > Josselin Mouette writes: >> Le mardi 30 mars 2010 à 07:18 -0700, Manoj Srivastava a écrit : > >>> I am not sure that follows. How has my not using debhelper made >>> it harder for newcomers? > >> Your packages are absolutely impossible to maintain by anyone but >> yourself. > > I am an existence proof that the absoluteness of this statement is > incorrect. I might agree that maintenance of my packages might raise a competence bar for the would-be-maintainer, and some people might fail to meet that bar. At this point I am uncertain that I am not happy at the prospect, as long as I am the maintainer and have signed up to clean up the mess. manoj -- Feeling amorous, she looked under the sheets and cried, "Oh, no, it's Microsoft!" Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/874ojx1lec@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
On Tue, Mar 30 2010, Marc Haber wrote: > On Tue, Mar 30, 2010 at 11:16:01AM +0200, Raphael Hertzog wrote: >> On Thu, 25 Mar 2010, Manoj Srivastava wrote: >> > What did you say? What difference does it make what tool is used >> > when the result is equal? >> >> It doesn't make a difference for a the end-user, but it makes a difference >> to contributors who have to learn a set of tools in order to be able to >> contribute on a set of packages. If the set of tools to learn is smaller, >> it's easier for the contributor to contribute to more packages and he has >> to spend less time learning, time that can be better spent on improving >> the package and on fixing bugs. I am not sure that follows. How has my not using debhelper made it harder for newcomers? How many newcomers learn my build system? Or my git work-flow where I use submodules? There is a logical flaw in the assumption that not limiting the choices people have for packaging makes it a harder row to hoe for newbies. > Is "making things easy for newcomers or casual helpers" really so > important that we should risk scaring already active people away > because they have to adapt their optimized workflow for newcomers? > > I can understand Manoj perfectly and would myself probably reduce my > time spent on Debian even more if I were forced to do things more > complicated (or even just different) because of some new policy. This > is a first-class motivation killer for the people who are already there. I have a new job. It is sucking up more time from me, as I learn the ins and outs of how work gets done here. I also have a work-flow that is mostly automated, allowing me to concentrate on fixing bugs and integration issues. Any new complications added into the mix would be a major monkey wrench thrown into the cogs. I am not sure I would be able to give the packages the attention they deserve; I am already at the border line of what I consider adequate maintainership. So yes, busy work for a flawed and needless conformity would impact my contributions to Debian. I am not sure that the benefits of such conformity have been adequately demonstrated. manoj -- Humans are communications junkies. We just can't get enough. Alan Kay Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87y6h928qh@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
On Thu, Mar 25 2010, Raphael Hertzog wrote: > Hello, > > those questions are for all candidates. By standardization I mean that > something should be used as default tool unless reasons exist to use > something else This is great!! perhaps we can get rid of the abomination that is vi and get everyone to use the one true editor all at once. What did you say? What difference does it make what tool is used when the result is equal? What a silly idea. The concept that rules and policies dictate interfaces and standards rather than implementation seem so antiquated. In the name of standardization we can stifle all variation and innovation. Ah, needless conformity, the hobgoblin of ... manoj -- The Official Colorado State Vegetable is now the "state legislator". Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/871vf7vf73@anzu.internal.golden-gryphon.com
Re: Question about membership.
On Wed, Mar 24 2010, Charles Plessy wrote: > Dear all, > > Following the ‘Membership procedures’ GR, discussion on membership > were started after the Lenny release, but eventually stopped. In this > thread it was proposed to trust DDs to nominate other members and I > found the idea very interesting. In order to make it more consensual, > there is probably a need for making concessions like shortlisting the > trusted DDs according to some criteria like the time they have already > spent in the project. I would actually be tempted to propose a more > variable but more symbolic measurment of time: having been part of the > project for at least one full release cycle. Can you explain why you think that mere length of time with Debian is a good metric for the ability to judge who should be a part of Debian? Does the duration of stay also lend credence to the DD's opinion of the quality of fellow DDs? Do you think that we could leverage this avility, gained by tenure, in other ways? manoj not sure mere tenure lends itself to great judgement -- Today's weirdness is tomorrow's reason why. Hunter S. Thompson Manoj Srivastava <http://www.debian.org/~srivasta/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87634kv60s@anzu.internal.golden-gryphon.com
Re: Q for all candidates: license and copyright requirements
On Sun, Mar 21 2010, Russ Allbery wrote:
> Stefano Zacchiroli writes:
>
>> On the contrary, I'm against point (2) of the GR. I do consider our
>> source packages to be part of Debian and hence subject to DFSG. If
>> something in upstream tarball is non-free, I believe we should do
>> repacking (there, we might use a bit more standardization on how we
>> implement get-orig-source in such cases, but that's a different
>> issue). In fact, doing that might even be a way to push our upstream to
>> get rid of those non-free bits from their tarballs as well.
>
> In my experience, it definitely is. It can cause some upstream grumbling,
> but for example the next major version of OpenAFS will be usable without
> repacking (although I may end up still repacking to delete the very large
> WINNT directory that isn't used in the Debian build).
I think that if Debian wants to still considered to be a part of
the open source/free software community, it _has_ to contain the
sources of the software. If the source software is a part of Debian (as
it should be, in my opinion), the DFSG applies (seems somewhat weasely
to try to wriggle our way out of the DFSG otherwise).
If we want to change our foundation documents, and remove the
awoval to the concept of being 100% free, or to say that Debian, and
thus the parts of Debian covered by the DFSG, are just the binary bits,
then we can do so via constitutionally approved methods like GR's with
appropriate majority requirements.
Is this what is being considered?
manoj
--
Good girls go to heaven, bad girls go everywhere.
Manoj Srivastava <http://www.debian.org/~srivasta/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
--
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/87y6hll9zv@anzu.internal.golden-gryphon.com
Re: Bits from the release team and request for discussion
On Wed, Aug 12 2009, Gunnar Wolf wrote:
> Manoj Srivastava dijo [Tue, Aug 11, 2009 at 03:08:52PM -0500]:
>> > I basically oppose such a GR, as it is is merely speculative (who
>> > knows _now_ or at the GR voting time when we will be close to
>> > achieving our release goals?), and because it is a ruling on a
>> > technical subject (at least according to some metrics). But if the
>> > vote were to be held at all, I would add:
>> >
>> > 6. The Debian project recognizes the responsible team to take any
>> > decisions regarding the freeze date and reach to be the Release
>> > Team, and accepts their best judgement in this regard.
>>
>> Perhaps you should look at this less confrontationally. The vote
>> is a non-binding recommendation, it is an information gathering vote
>> where people provide feedback to the release team; by voting for the
>> option that best suits their development plans.
>>
>> Based on the outcome, the release team can come to an *informed*
>> decision. By objecting to the vote, you might be making the tasks of
>> the release team harder, by denying them information from the project
>> at large.
>
> It is not confrontational, as it has been pointed out by others
> here. You might rephrase what I meant to say as:
>
> 6. This particular developer knows there is more to a release than
>his personal (or particular group's) points of view, and
>acknowledges any decision put forward by the release team, as
>long as they listen to the project real concerns, will be
>better informed and, thus, better than any random date that
>might be pushed forward
Why is this vote not being considered a part of the release
managers listening to the developers? Throw away the results of the
vote. The release managers can just look at the raw data, to see how
many people are saying that for their packages, the optimal release
date is foo. Then, factor in other variables, and look at large
packages differently, look at the major packages to sync with upstream
and other distributions, and decide.
This whole thing of we must not even take a straw poll to see
what developers might say, because giving the developers a voice will
somehow undercut the release team seems somewhat strange to me.
I would be against binding resolutions, but I am in favour of
non-binding straw polls.
manoj
--
Kill Ugly Processor Architectures Karl Lehenbauer
Manoj Srivastava <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
On Tue, Aug 11 2009, Josselin Mouette wrote: > Le mardi 11 août 2009 à 15:08 -0500, Manoj Srivastava a écrit : >> Perhaps you should look at this less confrontationally. The vote >> is a non-binding recommendation, it is an information gathering vote >> where people provide feedback to the release team; by voting for the >> option that best suits their development plans. >> >> Based on the outcome, the release team can come to an *informed* >> decision. By objecting to the vote, you might be making the tasks of >> the release team harder, by denying them information from the project >> at large. > > I do not trust a majority of people – regardless of the people – to make > an appropriate managerial decision. We have people in charge, who take a > lot of time to remain informed of the status of various subsystems in > Debian so that they can make informed decisions. If we replace them by a > majority’s vote, you can expect the decisions to be wrong. You are not reading. The whole vote is to come up with a recommendation for the decision makers, and the raw vote counts can give them an idea of the impact or desirability of each option. There is no decision by the unwashed masses bit going on here. This is just a medium of informing the decision makers of teams that they might not have time to keep up with -- and individual developers, whole release plans en masse ought to have some bearing on the release, and thus are relevant information to the RM's Had the vote draft been couched as overriding a delegate decision, you might have ahd a point to your rant. manoj -- The only thing that experience teaches us is that experience teaches us nothing. Andre Maurois (Emile Herzog) Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
On Tue, Aug 11 2009, Gunnar Wolf wrote: > Anthony Towns dijo [Tue, Aug 11, 2009 at 01:07:33PM +1000]: >> So, with August almost half-way over, I guess the release team's not >> going to be doing much more to seek input from non-key teams/developers. >> >> I still think it'd be interesting and useful to get broader input, >> though. Something like a choice amongst the following questions by GR >> might work: >> (…) > > I basically oppose such a GR, as it is is merely speculative (who > knows _now_ or at the GR voting time when we will be close to > achieving our release goals?), and because it is a ruling on a > technical subject (at least according to some metrics). But if the > vote were to be held at all, I would add: > > 6. The Debian project recognizes the responsible team to take any > decisions regarding the freeze date and reach to be the Release > Team, and accepts their best judgement in this regard. Perhaps you should look at this less confrontationally. The vote is a non-binding recommendation, it is an information gathering vote where people provide feedback to the release team; by voting for the option that best suits their development plans. Based on the outcome, the release team can come to an *informed* decision. By objecting to the vote, you might be making the tasks of the release team harder, by denying them information from the project at large. manoj -- if (instr(buf,sys_errlist[errno])) /* you don't see this */ Larry Wall in eval.c from the perl source code Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
On Tue, Aug 11 2009, Matthew Johnson wrote: > On Tue Aug 11 10:12, Giacomo A. Catenazzi wrote: >> Personally I don't think we should do a GR to recommend a freeze or release >> date. >> We already used the DPL election to push a release, when it was *long* due, >> but >> I don't think we should push a freeze. > > Zack has been patching devotee to allow more informal (and not at all > binding) polls to be run with the same infrastructure. I think this > could be a suitable candidate to run using that. It allows us to have a > poll which can only be voted in by DDs and not easily stuffed, but > without having to go through the pain of a formal resolution. Hmm? Why haven't these patches been sent upstream, then? I have been also working at devotee-ng, which will have a plug-in architecture, to allow votes to add in dfferent pre-processing stacks (mime/gpg-decrypt, vs plain ballot vs DB lookup), to bypass checks (gpg, ldap), or add new ones, and to change the vote tallying algorithm, and add in new response/publish modules. Forking devotee at this point seems to serve little purpose, given that upstream is not hostile. manoj -- If you wish to live wisely, ignore sayings -- including this one. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Draft vote on constitutional issues
On Tue, May 12 2009, Wouter Verhelst wrote: > On Sun, May 10, 2009 at 06:59:41PM +0100, Matthew Johnson wrote: >> On Sun May 10 18:34, Luk Claes wrote: >> > > 3. Option X overrides a foundation document, possibly temporarily (?) >> > >> > Not possible. You can only override a decision and amending a foundation >> > document is the previous option. >> >> What would you call the vote to ship non-free software in etch? Because >> that is what I mean. We are agreeing to do something which the >> foundation document said we would not, but only for a certain period of >> time (etch). >> >> I don't _care_ what you call that, I call it a temporary override of a >> foundation document. > > I think this is the core of the disagreement. I do not call it a > temporary override of a foundation document; I call it a temporary > practical consensus between "the needs of our users" and "the needs of > the free software community". I thought we had agreed to adhere to a document that lays out how these conflicts between the need of the users and the free software pledge we made is to be resolved: , |5. Works that do not meet our free software standards | | We acknowledge that some of our users require the use of works | that do not conform to the Debian Free Software Guidelines. We | have created "contrib" and "non-free" areas in our archive for | these works. ` As I understand it, we, as a project, have acceoted that there is tension between the needs of our users, and the dictates of free software; and the solution we have come up with is called "contrib" and "non-free" areas in our archive. Isn't that perfectly clear? manoj -- Non-sequiturs make me eat lampshades. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Overriding vs Amending vs Position statement
On Sat, May 02 2009, Russ Allbery wrote:
> Clint Adams writes:
>> On Sat, May 02, 2009 at 07:10:07AM -0700, Russ Allbery wrote:
>
>>> The Debian project believes that shipping NVidia drivers in main is
>>> consistent with the current DFSG and Social Contract.
>
>>> If you think there's any serious danger of that passing with a
>>> majority, I would contend that you're essentially arguing there's
>>> such a serious disagreement in Debian over this issue that we do not
>>> even share the same language, terms, and basis for discussion. I
>>> don't see that pessimism supported by any of the previous votes or by
>>> the general discussion here.
>
>> Would your statement still apply if you replace "NVidia drivers" with
>> "non-free kernel firmware"?
>
> Well, part of the dispute is over the definition of non-free.
I thought the whole poing of including the DFSG in the SC was
that there would be no ambiguity about what the Debian project means
when it says something is non-free. Let me see how it is phrased:
We provide the guidelines that we use to determine if a work is
"free" in the document entitled "The Debian Free Software
Guidelines".
> If one defines non-free as non-compliant with the DFSG, then such a
> statement would be internally contradictory. However, semantics
> aside, for the definition of non-free I'm pretty sure you're using (no
> source available), I think that's basically the GR we passed for the
> release of lenny. So no. :)
No. I think it means that the firmware blobs do not meet the
requirements of the DFSG; and that a work must be legally licensed in
order to be even considered free.
So, if a work is distributed under the GPL, Debian must be able
meet the constraints of the GPL in order to further distribute it. That
means, we must be able to distribute the preferred form of
modification, as the GPL states we must.
There is also the likelyhood that a number of these firmware
blobs are actually programs; in which case we need the source code --
but it is hard to tell which blob is or is not a bunch of instructions
to a processing unit.
>
>> Since I view those as equivalent, and the latter seems far more
>> dangerous, I do think the pessimism is warranted.
>
> However, for two releases in a row, the project has wanted to release
> with non-source kernel firmware.
Thus the cause for the pessimism. I think we are drifting from
the social contract, really.
manoj
--
Meekness: Uncommon patience in planning a revenge that is worth
while. Ambrose Bierce
Manoj Srivastava <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Overriding vs Amending vs Position statement
On Sat, May 02 2009, s...@powerlinux.fr wrote: > On Fri, May 01, 2009 at 05:26:37PM -0700, Don Armstrong wrote: >> >> On Fri, 01 May 2009, Manoj Srivastava wrote: >> > On Fri, May 01 2009, Don Armstrong wrote: >> > > Only as binding as we as a group consider them to be. >> > >> > Hmm. Certainly puts the social contract in a new light, though. >> >> It really shouldn't; as a group we decide whether we're going to >> uphold the social contract. There's no way to force the group to >> uphold it. [Given the anguish with which we struggle on -project and >> -vote to figure out what the SC says, it's seems clear that large >> numbers of us feel that we should be upholding the SC.] > > BTW, notice that when we joined debian, we declared that we would adhere > to the social contract and uphold it, or something such. Apparently, we all agreed with out fingers crossed behind out backs, since the SC seems to mean different things to different people. Reminds me of the tory fro the MahaBharata: Loudly, "Aswasthama's dead." (Aside, sotto voce: "Aswasthama the elephant". Perhaps this too will cost us a trip through purgatory, like it did Yudhishtar. manoj P.S. Without common cause, even words written in one language can seem like Babel. We apparently no longer have common cause. -- Neither spread the germs of gossip nor encourage others to do so. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Overriding vs Amending vs Position statement
On Sat, May 02 2009, Ben Finney wrote: > That doesn't mean we can't make the explicit expectation that everyone > in the group *will* uphold it, as a condition of being in the group. > > I had thought that expectation was embodied in the requirement for all > new members to declare they will uphold it. Such was my understanding as well. manoj -- Cheit's Lament: If you help a friend in need, he is sure to remember you-- the next time he's in need. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Overriding vs Amending vs Position statement
On Fri, May 01 2009, Luk Claes wrote: > Manoj Srivastava wrote: >> On Fri, May 01 2009, Don Armstrong wrote: >> >>> On Fri, 01 May 2009, Luk Claes wrote: >>>> A position statement is a decided on proposal that clarifies the >>>> position of the Debian project, but does not explicitly amend a >>>> foundation document. >>> [...] >>> >>>> So I don't really see what we should vote on unless someone >>>> disagrees with above interpretations? >>> The only question resides with the effect of passing such position >>> statements. Without modifying foundation documents or the >>> constitution, they are effectively non-binding advisory statements >>> when operating within areas that are the remit of foundation documents >>> or the constitution. >> >>> Developers can ignore (or follow) such statements as they wish. >> >> If the statements are in contradiction of the foundation >> document (which is the case in a couple of prior situations), then are >> you saying that anything in the foundation documents can ve worked >> around by putting out a position statement, and have the developers >> proceed to ignore the foundation document on that basis? > > Of course not. If a position statement contradicts a foundation > document it's time to update the foundation document accordingly or > drop the position statement again. Err, so why not do it in one pass? Why this strange two pass vote? How do you want to handle the case where a 51% majority wants the position, but no more than that? There is not enough votes to actually change the foundation docs in that case. > >> That also begs the question: do we _have_ to follow the >> foundation documents? Or can one just issue a statement "I do not agree >> with the foundation doc" and just ignore it at will? > > You do realise that a majority needs to agree with it before it turns > into a position statement? Sure. A bare majority, let us suppose. > It's not because a position statement is not binding that a foundation > document would also not be binding... So why do you think the foundation document is not binding? (I must confess to having some problems parsing this statement). >> if that is not the case, what value does a position statement in >> contradiction of a foundation document mean? > > It would be a clear indication that the foundation document should get > an update or that the postition statement should get dropped again. Why this torturous path? Why not see if there are actually votes to change the FD, rather than creating and dropping position statements? >> Can I just set a position statement that redefines all the owrds >> used in a foundation doc to promote my "interpretation" of the >> foundation doc, as long as the majority of the people voting rate it >> over FD? > > This is actually asking if a position statement can clarify a > foundation document but put in a twisted way AFAICS... If by clarifying, youmean redefining all the words, sure. > >> How binding _are_ the foundation documents? > > Interesting question as you seem to be one to take the Constitution > with a twisted interpretation when it fits you best in some previous > occasions. Aha. The first attack on the man, rather than the contents of my arguments. Jesus, it sure did not take long for the conversation to descend to the pits. > >> free === does not cost more than USD 1000300.73 >> distribute == transport over trains between sunday noon and monday >>morning 8:00am" >> Guidelines === something that must be followed in the ides of march > > I guess this is a bad attempt at a joke? What joke? That might me my "interpretation", or, as you put it, the "clarification" of the SC. manoj -- In my experience, if you have to keep the lavatory door shut by extending your left leg, it's modern architecture. -- Nancy Banks Smith Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Overriding vs Amending vs Position statement
On Fri, May 01 2009, Steve Langasek wrote: > On Fri, May 01, 2009 at 11:54:15PM +0100, Matthew Johnson wrote: >> On Sat May 02 00:52, Luk Claes wrote: >> > It would be a clear indication that the foundation document should get an >> > update or that the postition statement should get dropped again. > >> I think Manoj's point is that if voting some option X (a position >> statement in conflict with an FD) means that we have to vote to change >> the FD or drop X, then why wasn't X a vote to change the FD in the first >> place? Surely we don't need a vote just to then have another vote... > > No one has the authority to declare, a priori, for the entire project, that > a given position statement is in conflict with a FD. Does anyone have authority, a posteriori, to declare that any given position statement is in contradiction of a foundation document? Or is it only deliverable by a GR? This will be interesting. So, in order to determine whether a foundation document is being modified, we first ask the project, via a GR, whether it is indeed a contradiction. _THEN_ we hold a vote, with or without the 3:1 majority, based o the previous vote, to see if it passes or not. I think Joey Hess is right. manoj -- Program: Any assignment that cannot be completed with one telephone call. Kelvin Throop III, "The Management Dictionary" Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Overriding vs Amending vs Position statement
On Fri, May 01 2009, Don Armstrong wrote: > Only as binding as we as a group consider them to be. Hmm. Certainly puts the social contract in a new light, though. > Since the language they're written in is ambiguous, we can have > reasonable differences of opinion as to what the foundation documents > actually mean. A position statement about the foundation documents > only serves to state what a majority of the project thinks the > documents say; it doesn't change what the documents actually say.[1] > > As such, people who think differently are free to ignore the position > statement in carrying out their duties (though they can of course be > overridden by GR.) I think I can live with that. Wait. Oh. So this is a way, via two simple majority GR's, for any majority to do an end run around the 3:1 constitutional requirements? nifty. manoj -- Behind every great man, there is a woman -- urging him on. Harry Mudd, "I, Mudd", stardate 4513.3 Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Overriding vs Amending vs Position statement
On Fri, May 01 2009, Don Armstrong wrote: > On Fri, 01 May 2009, Luk Claes wrote: >> A position statement is a decided on proposal that clarifies the >> position of the Debian project, but does not explicitly amend a >> foundation document. > > [...] > >> So I don't really see what we should vote on unless someone >> disagrees with above interpretations? > > The only question resides with the effect of passing such position > statements. Without modifying foundation documents or the > constitution, they are effectively non-binding advisory statements > when operating within areas that are the remit of foundation documents > or the constitution. > Developers can ignore (or follow) such statements as they wish. If the statements are in contradiction of the foundation document (which is the case in a couple of prior situations), then are you saying that anything in the foundation documents can ve worked around by putting out a position statement, and have the developers proceed to ignore the foundation document on that basis? That also begs the question: do we _have_ to follow the foundation documents? Or can one just issue a statement "I do not agree with the foundation doc" and just ignore it at will? if that is not the case, what value does a position statement in contradiction of a foundation document mean? Can I just set a position statement that redefines all the owrds used in a foundation doc to promote my "interpretation" of the foundation doc, as long as the majority of the people voting rate it over FD? How binding _are_ the foundation documents? manoj free === does not cost more than USD 1000300.73 distribute == transport over trains between sunday noon and monday morning 8:00am" Guidelines === something that must be followed in the ides of march -- Actors will happen in the best-regulated families. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Devotee Improvements (Re: Debian Project Leader Election 2009 Results)
Hi, The current devotee package is far too wedded to the Debian way of doing things to be useful as a package. It is far too inglexible, and things have ben h a r d c o d e d. I have a devotee-ng in a rewrite now, that is far more modular, and, critically, composable -- so the end user creates their vote script (essentially, equivalent to the dvt-cron script of today) by specifying what components they want to use (a spooler, to live in .forward, or not, in case they want to use a web front end, which mime exploder, which gpg checker, if any, whether or not to use ldap, notification modules, tally modules, display units -- so one may mix and match plugins. I think that is likely to be usable enough to actually package, as opposed to what I wrote under the gun during the 2002 DPL election (yes, the election started before devotee was actually written) So, I think any efforts to package the current devotee code are a bit of a waste of time, but I won't stop people from doing so. manoj -- Maryann's Law: You can always find what you're not looking for. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian Project Leader Election 2009 Results
On Sun, Apr 12 2009, Wesley J. Landaker wrote: > On Sunday 12 April 2009 17:43:36 Kurt Roeckx wrote: >> On Mon, Apr 13, 2009 at 01:01:38AM +0200, Luigi Gangitano wrote: >> > Hi Kurt, >> > can you please report on issue in the voting software that prevented >> > some ballots to be processed? I sent my vote twince on April 9 and April >> > 11 and got the following answer back: >> >> Hi Luigi, >> >> I wish you contacted me about this before so that we could find a >> solution to get your vote counted. > > Just a comment: if Luigi sent a valid vote during the correct time frame, and > it was rejected because of a software bug, shouldn't it still count, even if > the problem is not brought up until later, even if you have to add this > information in manually or after the fact? Obviously one vote either way > doesn't affect the result of this election, but IMO voter disenfranchisement > should be taken VERY seriously. What devotee accepts is a proper ascii armored GPG signed mail (RFC 2440), or PGP/MIME, which is RFC 3156. Sending in a non PGP/MIME message which is magled by the MTA has never been acceptable. If you can't use a decent MUA, then there is always mailx -s 'My vote' f...@vote.debian.org < ballot.asc Frankly, if would seem that a DD ought o be able to deliver RFC compliant mails to vote.d.o. manoj -- It were not best that we should all think alike; it is difference of opinion that makes horse-races. -- Mark Twain, "Pudd'nhead Wilson's Calendar" Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian Project Leader Election 2009 Results
On Sun, Apr 12 2009, Charles Plessy wrote: > Le Mon, Apr 13, 2009 at 01:43:36AM +0200, Kurt Roeckx a écrit : >> It seems that devotee does not properly handle it. Devotee follows the standards. That means RFC 2440 or RFC 3156. If you can point me to an RFC the said vote followed, I'll see that it gets support. This was PEBKAC. > at worse, there may be alternatives, like selectricity (.org), which was also > made by a DD. > Unfortunately, it is not packaged… And it does not do LDAP checks. Nor does it follow the constitution as for quorum and majority reqs. By the time you hack that in and verify it ... manoj -- Keep your eyes wide open before marriage, half shut afterwards. Benjamin Franklin Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question for DPL Candidates: Debian $$$
On Wed, Mar 18 2009, Joseph Nahmias wrote: > 1 - What is an appropriate reserve level for the project? > > 2 - How should funds above that level be allocated? 3 - Should these decisions be made by the DPL acting alone, or should that be left to the project membership deciding collectively? manoj -- The chat program is in public domain. This is not the GNU public license. If it breaks then you get to keep both pieces. (Copyright notice for the chat program) Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: gr_lenny vs gr_socialcontract
On Fri, Dec 19 2008, Anthony Towns wrote: > On Fri, Dec 19, 2008 at 09:54:08AM -0600, Manoj Srivastava wrote: >> On Fri, Dec 19 2008, Anthony Towns wrote: >> >> I tend to come down hard on the side of not compromising my >> >> principles for temporary convenience or popularity (or, if you will, >> >> market share). >> >> To paraphrase: Those who give up essential freedoms for >> >> temporary convenience and popularity deserve neither. >> > And, uh, isn't that a bit needlessly argumentative? Marc's not trying to >> > get anyone to give up essential freedoms, or give them up himself. >> I did not mean this to be argumentative. A rhetorical flourish, >> yes. The quote is from a US politicial, and the analogy between the >> constitutions and bill of rights was amusing. > > Uh, surely it's obvious that following any example from a political arena > is going to be much more argumentative than necessary? Not to me, it isn't obvious. Ben Franklin was more than just a run-of-the-mill joe politician, and a diplomat before standing for public office; and the quote seemed quite apropos, from my view. However, since offense is in the eye of the beholder, I'll withdraw the amusing paraphrase. >> But I do think that the DFSG represents the essential freedoms >> for software, as defined by the Debian project. Shipping stuff that >> violates the DFSG is indeed giving up essential freedoms, in my view. > > I consider being able to easily install Debian and get it running on > whatever random hardware I buy an essential freedom, so I see most of It is a convenience, not a freedom. There is a difference. And yes, even now, the ability to install non-free firmware using the Debian installer exists (since the user does not appear to care that the firmware in question is not actually free), thanks to the d-i team accepting a USB key with the firmware. > this as people trying to take away my freedoms. Obviously, your > mileage varies, but that doesn't make either of us popularity seeking > knaves. I am not sure I cater to the view that all opinions are always correct. You have a right to an opinion, and I have a right to regard that opinion as wrong. Now, I ought to be able to convey that without sliding over into "needlessly argumentative" territory. As to it being populist, I am not seeing that as provicative either; shifting to the side of convenience over abstract freedoms is a populist move (most people rarely exercise the freedoms that are granted to them by the DFSG). I am not being argumentative here either -- I do think it is so, and I think I can defend that view. I still hold that shipping non-free components as part of the Debian system, etc, etc, as above. manoj -- "He who flames improperly risks making an ash of himself!" Jeff Klumpp (j...@ficc.uu.net) Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: General resolution: Clarify the status of the social contract
On Fri, Dec 19 2008, Luk Claes wrote: > Manoj Srivastava wrote: >> Hi, >> >> I like the idea of clarifying what the principles of the project >> actually are, since, as aj said, all the decisions about lenny would >> fall out from the position the project take about the foundation >> documents. While I have always thought that "foundation" implied the >> proposal below, apparently this is not a universally held view. > > You want to clarify what the principles of the project really are and > all you talk about is point 1 of the Social Contract??! > > Maybe you take the other points for granted, though it surely looks > strange to me. So, where is your proposed wording which will not appear strange to you? > I also think it's rather strange to talk about binding and non-binding > regarding 'Guidelines'. As long as it are guidelines, the question will > always remain how to interprete them in any circumstance AFAICS. The social contract is supposedly a contract. Also, the last two of thte options in the mail seem to be where you are coming from. If not feel free to suggest other options or better wording. manoj -- Sometimes I worry about being a success in a mediocre world. Lily Tomlin Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Fri, Dec 19 2008, Russ Allbery wrote: > Matthew Johnson writes: > Furthermore, by my reading of the constitution, even if a delegate > override or a position statement clearly and obviously contradicted the > DFSG, as long as it doesn't actually change or set aside the DFSG, it's > still just a 1:1 majority. Success of the GR would overturn that > decision, even in a direction that contradicts the DFSG, because in > practice there's no higher authority in Debian to declare that the > decision contradicts the DFSG and a majority of developers just said, in > effect, that it doesn't. This sounds like weaseling around our foundation documents. We won't do what the social contract says, but in out NewSpeak, we are not changing the SC. We are, uhhh, just going to do something else, but, err, the contract is valid. While the constitution might not prohibit this behaviour, I would find actually doing this very dishonest, and just plain lying. If we have sunk so low as to require some entity to keep us away from NewSpeak, so be it, I just find that makes trusting the project impossible. manoj -- New members are urgently needed in the Society for Prevention of Cruelty to Yourself. Apply within. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Fri, Dec 19 2008, Steve Langasek wrote: > On Fri, Dec 19, 2008 at 09:50:42PM +, Matthew Johnson wrote: >> Then the 3:1 requirement is nonsense and the SC and DFSG effectively >> optional. I don't believe that was the intention when they were drafted. > > They were drafted before the constitution was and their binding power does > *not* flow *from* the constitution. Sorry, no. I do not find that logically follows. Before we accepted the constitution, the allocation of powers was all ad-hoc. We even had project leaders and "delegates" before the constitution too. When the constitution was adopted, the ad-hoc power structure was swept away, and the new power structure detailed in the constitution came into effect. Saying that we had DPL's and ftp-masters before so theya re above the constitution does not hold. Heck, we had developers before, so those of us who were inducted in before we had a constitution are somehow not bound by it, unless we voted in favour? I do not see the logic here. manoj -- If God had wanted us to be concerned for the plight of the toads, he would have made them cute and furry. -- Dave Barry Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Fri, Dec 19 2008, Russ Allbery wrote: > However, you can also override *individual decisions*, and that requires > only a simple majority. So it would be possible, under the constitution, > to get NVidia drivers into main with a set of 1:1 delegate overrides: you > override the ftp-master's decision that it's non-free, and then you > override the release team's decision that it's non-free, and so forth. > Those overrides aren't binding on any future developer decisions, only on > those specific ones. So your position is essentially that the foundation documents are not really binding on any developer, and even in cases where the developer thinks they are binding, a simple majoiry can effectively vacate that. Does not sound like much of a contract to me, and I must reject this interpretation. manoj -- In order to live free and happily, you must sacrifice boredom. It is not always an easy sacrifice. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: General resolution: Clarify the status of the social contract
[ ] The Social contract is a binding contract, DPL interprets [ ] The Social contract is a binding contract, secretary interprets [ ] The Social contract is a binding contract, tech ctte interprets [ ] The Social contract is a binding contract, individuals interpret [ ] The Social contract is a binding contract, new ctte interprets [ ] The social contract is binding, but currently flawed, DPL interprets [ ] The social contract is binding, but currently flawed, secretary interprets [ ] The social contract is binding, but currently flawed, tech ctte interprets [ ] The social contract is binding, but currently flawed, individuals interpret [ ] The social contract is binding, but currently flawed, new ctte interprets [ ] The social contract is binding but may be overridden by a simple GR, DPL interprets [ ] The social contract is binding but may be overridden by a simple GR, secretary interprets [ ] The social contract is binding but may be overridden by a simple GR, tech ctte interprets [ ] The social contract is binding but may be overridden by a simple GR, individuals interpret [ ] The social contract is binding but may be overridden by a simple GR, new ctte interprets [ ] The social contract is a goal, not a binding contract [ ] The social contract is a non-binding advisory document [ ] Further Discussion I would hate to have to run that vote. I strongly suggest we separate these orthogonal issues. manoj -- Any discovery is more likely to be exploited by the wicked than applied by the virtuous. -- Marion J. Levy, Jr. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: General resolution: Clarify the status of the social contract
On Fri, Dec 19 2008, Russ Allbery wrote: > Manoj Srivastava writes: > >> I think we will keep coming back to this biennial spate of >> disagreement we have, as we determine whether or not we can release >> with firmware blobs or what have you. This also would help developers, >> the ftp-masters, and the release team with a clear cut expression of >> the projects goals and clarifies how the project has decided to view >> the social contract. >> >> Given that, I suggest we have a series of proposals and >> amendments, each in a separate email, sponsored and seconded >> independently, that could look something like this below: > > I think these have the same flaw as our current situation: none of them > state who interprets the Social Contract and the DSFG if there is a > dispute over what they mean. We know there will be such disputes. Just > saying that they're binding (or not binding) doesn't resolve those > disputes. I do ont think that determining who interprets the non-constitution foundation documents belongs on the same ballot. It is a flaw in the constitution, and should be fixed, I would second proposals that let the secretary not just interpret the constitution, but all other foundation documents as well. This seems in line with the constitution already handing tot hte secretary the role of interpreting the constitution. I also like the fact that then the secretary is given the role of interpreting the foundation documents, and determining final form of the ballots; I would suggest that the secretary be stripped of the power to run the actual vote (a wee bit of automation to devotee will allow somewone else to run it. This way the secretary has no more access to the votes that people cast than any other developer. Again, a constitutional amendment modifying the powers of the secretary should be discussed independently of deciding what the role of the SC is. manoj -- There are two ways of disliking poetry; one way is to dislike it, the other is to read Pope. -- Oscar Wilde Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFC: General resolution: Clarify the status of the social contract
Hi, I like the idea of clarifying what the principles of the project actually are, since, as aj said, all the decisions about lenny would fall out from the position the project take about the foundation documents. While I have always thought that "foundation" implied the proposal below, apparently this is not a universally held view. I think we will keep coming back to this biennial spate of disagreement we have, as we determine whether or not we can release with firmware blobs or what have you. This also would help developers, the ftp-masters, and the release team with a clear cut expression of the projects goals and clarifies how the project has decided to view the social contract. Given that, I suggest we have a series of proposals and amendments, each in a separate email, sponsored and seconded independently, that could look something like this below: ,[ The Social contract is a binding contract ] | The developers, via a general resolution, determine that the social | contract should apply to everything Debian does, now and in the future; | _AND_ the social contract should stop us from including anything that | doesn't comply with the DFSG in main ` ,[ The social contract is binding, but currently flawed ] | This amends the proposal above, and replaces the text of the proposal with: | The developers, via a general resolution, determine that the social | contract should apply to everything Debian does, now and in the future; | _AND_ it is and was a mistake to have the DFSG cover firmware because | we have not yet been able to limit Debian to only DFSG-free firmware | in a suitable way. This mistake should be corrected by amending the | social contract. ` ,[ The social contract is binding but may be overridden by a simple GR ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract should apply to /almost/ everything Debian does, now | and in the future; _AND_ for the few cases where it should not apply | now, there should be an explicit GR affirming that variation (by simple | majority) ` ,[ The social contract is a goal, not a binding contract ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract is an aspirational document: while we aim to achieve as | much of it as feasible at all times, we don't expect to get it | completely right for some time yet. This includes DFSG-freeness of all | firmware ` ,[ The social contract is a non-binding advisory document ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract is a statement of principle only, and has no particular | force on the day to day operations of Debian, except in so far as it | influences individual contributors' actions. ` If all these variations get sponsored and seconded, the ballot would look like: [ ] The Social contract is a binding contract [ ] The social contract is binding, but currently flawed [ ] The social contract is binding but may be overridden by a simple GR [ ] The social contract is a goal, not a binding contract [ ] The social contract is a non-binding advisory document I think we need this clarification, so people no longer accuse other people of malfeasance based on a flawed understanding on the correct status of foundation documents. I do have an ulterior motive: clarifying this will help those of us currently evaluating whether this is the project they signed up for, and whether we want to continue to be a part of it. Some of the options above, if they passed, would be a clear proof that the project might have moved on from the principles that were in effect when we joined the project. manoj -- May you do Good Magic with Perl. Larry Wall's blessing Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpvzCpaNmUZX.pgp Description: PGP signature
Re: gr_lenny vs gr_socialcontract
On Fri, Dec 19 2008, Anthony Towns wrote: > On Fri, Dec 19, 2008 at 08:12:28AM +0100, Marc Haber wrote: >> Putting an USB key into most of my servers requires some hours of >> driving and jumping through security hoops to get datacenter access. >> [...] >> I'd prefer an OS which allows full remote installation that does not >> need some kind of physical access. > > On Fri, Dec 19, 2008 at 01:50:40AM -0600, Manoj Srivastava wrote: >> I suspect it would not be hard to create a non-free installer CD >> that obviates the requirement of a separate USB key for remote >> installs. > > So isn't this exactly why we have a voting system? Everyone understands > both points of view here, don't they? We just need to choose which one > Debian's going to adopt, because we haven't implemented a way of having > our cake and eating it too on this score. Sure. >> I tend to come down hard on the side of not compromising my >> principles for temporary convenience or popularity (or, if you will, >> market share). >> >> To paraphrase: Those who give up essential freedoms for >> temporary convenience and popularity deserve neither. > > And, uh, isn't that a bit needlessly argumentative? Marc's not trying to > get anyone to give up essential freedoms, or give them up himself. I did not mean this to be argumentative. A rhetorical flourish, yes. The quote is from a US politicial, and the analogy between the constitutions and bill of rights was amusing. But I do think that the DFSG represents the essential freedoms for software, as defined by the Debian project. Shipping stuff that violates the DFSG is indeed giving up essential freedoms, in my view. Now, you might find my honestly and deeply held views to be off the wall enough to call mere statements of my beliefs needlessly argumentative, but then we have a failure in that we can't even discuss things rationally. manoj -- The average nutritional value of promises is roughly zero. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Fri, Dec 19 2008, Raphael Hertzog wrote: > On Fri, 19 Dec 2008, Matthew Johnson wrote: >> On Fri Dec 19 14:24, Raphael Hertzog wrote: >> >> > It is. Does the resolution say what the new version of the foundation >> > document will look like if it's accepted ? If yes, then it supersedes the >> > document. Otherwise it doesn't. >> >> So, if someone proposes a GR saying "we will ship the binary NVidia >> drivers in main and make them the default so that people can use compiz" >> but doesn't say they are overriding the DFSG or provide the wdiff for it >> then that's fine and only needs 1:1 to pass? > > Yes. > > But try it, you will see that it won't even get the required seconds to > start the vote. And if it does, it will largely fail anyway. > As I said, we all have agreed to abide by the social contract, you'd need > a serious rationale to convince me that this is coherent with our > long-term goal. Hmm. All that says is that you have drawn the line at one point, not that the project has. I find it hard to see how shipping non-free blobs in main is coherent with our long-term goal; but obviously people in the project do not. Therefore, I find it unconvincing to say that people will behave or vote a particular way. > Either we trust the democracy or we don't. The 3:1 ratio is not here to > protect us from insanity, it's only a matter of making sure that we all > agree if we want to change the direction in which we're headed. My take on it was that if we resolve to do something that is contradiction of the foundation document, the only logical way to interpret that is to accept that we are, if only temporarily, changing the direction we are headed in. We might intend to turn back to the path later, but for not, the direction is being changed. manoj -- In Hollywood, if you don't have happiness, you send out for it. Rex Reed Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Fri, Dec 19 2008, Raphael Hertzog wrote: > And please don't assume that a majority of developers are insane > and want to pervert the project. If that is the case, we're all in > a bad situation anyway. :-) Insanity is subjective. In some sense, some of the the interpretations of our foundation documents brings to my mind shades of NewSpeak. I know that is not how other people meant it to be; so we have enough differences in opinion that acts of inasnity by some are rational behaviour by others, and we have grown to the point that there is no single definition of insanity that would govern the statement above. I have seen either side in the firmware debate staunchly believe the other side was, err, insane. manoj -- I am not a politician and my other habits are also good. Ward Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: gr_lenny vs gr_socialcontract
On Fri, Dec 19 2008, Marc Haber wrote: > On Fri, Dec 19, 2008 at 12:09:55AM -0600, Manoj Srivastava wrote: >> For what it is worth, at work we had to install Lenny on >> machines which have the broadcom netextreme 2 ethernet cards (bnx2 >> firmware needed). The netinst installer worked wonderfully, grabbing >> the firmware from a usb key loaded with non-free firmware. > > Putting an USB key into most of my servers requires some hours of > driving and jumping through security hoops to get datacenter access. > In some cases, it may be possible to mail the USB key and to pay > outrageous fees for remote hands. > > I'd prefer an OS which allows full remote installation that does not > need some kind of physical access. I suspect it would not be hard to create a non-free installer CD that obviates the requirement of a separate USB key for remote installs. Let us face it: there are always going to be bits of hardware that can not be supported with free software; users might always have to deal with either refraining from buying such hardware (which is not always feasible), using a non-free installer, going a more inconvenient route, or using a different OS. As always, Debian is nto for everyone, and our commitment to the freedom, and just not being windows, means there are going to be people who can not use Debian. I tend to come down hard on the side of not compromising my principles for temporary convenience or popularity (or, if you will, market share). To paraphrase: Those who give up essential freedoms for temporary convenience and popularity deserve neither. manoj -- "The highest form of pure thought is in mathematics." Plato Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Fri, Dec 19 2008, Steve Langasek wrote: > On Wed, Dec 17, 2008 at 02:46:35PM -0600, Manoj Srivastava wrote: > >> > * Why does releasing despite DFSG violations require a 3:1 majority now >> > when it didn't for etch? It's the same secretary in both cases. What >> > changed? I didn't find any of the explanations offered for this very >> > satisfying. > >> The proposal we used before is choice 5 in the current >> ballot, and that does indeed have a 1:1 majority like we did >> before. The devil lies in the details (and I have explained the details >> before too) -- which is that we state that the fiormware blob be >> released under a DFSG free licence. This means we explictly conform to >> the DFSG, > > While I accept that this was your understanding as a seconder of the > etch GR and proposer of choice 5 on the current GR, this was > definitely *not* how I understood the etch GR, either as a seconder or > as RM for etch, because the language quite distinctly refers to > DFSG-compliance of the license and not of the software. I find this actually hard to understand. Most licenses themselves seem to not actually fall under the DFSG (I do not think you may modify them while still distributing them and the attached Work, and distributing modified versions of the entity we are considering to be DFSG free > > This language was no accident, it was deliberately crafted to *not* > say that firmware had to comply with DFSG#4's requirements for source > inclusion. I'm sorry if you understood otherwise when setting the > supermajority requirements for that vote, or when seconding/voting, > but we intentionally *did* release etch with firmware in main that > wasn't DFSG-compliant, and http://www.debian.org/vote/2006/vote_007 > was the justification for doing so. We certainly weren't pretending > that binary microcode firmware was its own source! This was certainly not how I understood the proposal to be. I would deem that interpretation, and thus the release of Etch, to have been in violation of the contract we had with the free software community. > So if that's not what you mean to say for lenny, I suggest that you propose > different language than what you currently have for choice 5 on the ballot. I thank you for clarifying the interpretation of the proposal, and pointing me to the flaw in my wording of the proposal that allowed such ambiguity to exist. >> I do not think we released before with known violations. We >> released with things we strongly suspected as being violations; since >> we strongly suspect the blob was not the preferred form of >> modification, but we do not know for a fact. > > By your reasoning, http://www.debian.org/vote/2006/vote_007 was a useless > no-op. The release team certainly didn't need to be told it was ok to ship > binary firmware in main if we had a good-faith belief that the binary was > the preferred form of modification. That sure isn't why I seconded it. I think that the ballot option was over riding the statement in the SC that says Debian shall be 100% free, and that what is free is determined by the DFSG. For the project to actually resolve to not comply with the foundation document, or do an end run around it, certainly should require a 3:1 option. I did not mean for option 5 to be considered a get-out-of-jail-free card to allow for DFSG violations in formware included in kernel image packages in main. At this juncture, I think I must withdraw that proposal for any future votes, or add language clarifying my intent (which is only to convey to the release team that due diligence on whether firmware actually complies with the accompanying license can be waived for Lenny, and taking firmware on faith is good enough) But i think we must instead clarify, as aj said in his email, what the social contract means. I tend to take contract at face value: a binding agreement, something we have undertaken to do. Some of the options in aj's mail make it sound more like a social non-binding statement of intent, which is not how I have interpreted it all along. Perhaps it would be better to clarify this (which I have been taking as a given); that would certainly help me decide whether or not I wish to remain with the project. I suspect that such a memorandum of understanding might affect other people as well. manoj -- I couldn't remember when I had been so disappointed. Except perhaps the time I found out that M&Ms really DO melt in your hand. -- Peter Oakley Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Thu, Dec 18 2008, Steve Langasek wrote: > No other body for enforcement of the DFSG is defined in the > constitution. It's up to individual developers to determine for > themselves whether their actions are in keeping with the DFSG/SC, and > with the promise they made when they became DDs to uphold those > principles in their Debian work. No one else, with the exception of > the project as a whole by way of GR[1], has the power to decree that a > developer's understanding of the DFSG is wrong. This, then, should also apply for the developer who is serving as the secretary. Or you shpould amend your statement here, to say that all developers, with the exception of the secretary, interpret the DFSG in performing their duties. > Well, I mean, obviously we can all shout at each other on the mailing lists > until the person we think is wrong gives up and quits, too, but that's not > exactly a constitutional power. > This is why having an "interventionist" secretary that decides a > priori that certain interpretations are incompatible with the DFSG is > so problematic and the cause of so much outrage on the mailing lists - > because regardless of whether it's done with malice (which I don't > believe it is), the effect is that the secretary assumes the power to > interpret the foundation documents and his personal interpretation of > the DFSG suddenly become paramount. You (appear to) happen to agree > with Manoj's understanding of the implications of the DFSG for the > lenny release. That's fine; I'm not going to tell you that you're > wrong to think that. But that doesn't make it ok for you, or the > secretary, to impose this interpretation on the project except *by way > of* the GR process. The job of the secretary is to figure out the ballot, and to figure out which options fall afoul of the 3:1 mojority requirement as decreed by the constitution. As you so persuasively argue, the only person who can interpret the DFSG for the developer who is performing as a secretary is the developer themselves -- or the developers via a GR. Seems like every single vote that touches things related to the SC will force the secretary to be "interventionist" -- since intervening is their job. > [1] ... or the DAM by summarily expelling them from the project, I guess... Yes, I found that option rather elegant. Much faster than having to wait until the secretaries term ran out. manoj -- In Devon, Connecticut, it is unlawful to walk backwards after sunset. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: gr_lenny vs gr_socialcontract
On Thu, Dec 18 2008, Anthony Towns wrote: > Hello world, > > I'd like to briefly suggest a different perspective on the issues at hand. > Rather than looking at whether this will delay lenny or not, it might be > more useful to just take a step back and work out what our principles are. > FWIW, I think what should be done about lenny follows pretty obviously > from that. > > I think there're four or five options that people might reasonably hold > about the social contract: > 2) the social contract should apply to everything Debian does, now and >in the future; _AND_ it is and was a mistake to have the DFSG >cover firmware because we have not yet been able to limit Debian to >only DFSG-free firmware in a suitable way For what it is worth, at work we had to install Lenny on machines which have the broadcom netextreme 2 ethernet cards (bnx2 firmware needed). The netinst installer worked wonderfully, grabbing the firmware from a usb key loaded with non-free firmware. The installation was no more painful than usual, after we downloaded an iso and a tar.gz file, one to be burned on a CD, one to be installed on a usb stick. Putting firmware out of Debian proper, in this case, even for a network card, did not cause the sky to fall on my head. manoj -- Linux: because a PC is a terrible thing to waste k...@cis.ufl.edu put this on Tshirts in '93 Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
I hereby resign as secretary
Hi folks, I am hereby resigning as secretary, effective immediately. I was planning on leaving the office soon, anyway, but I had a rewrite of Devotee underway, which would have made the software more useful for different people (different checks --LDAP.gpg. and others), and allowed Devotee to be packaged as essentially a perl library, with vote protocols being perl scripts (debian-vote --config gr_lenny.cfg). But that is no longer a compelling reason to stay on. In the years I have spent in this role since Darren left us, I have tried to conduct the votes as I saw the rquirements of the constitution, and the limitations of the voting software. But this not a view shared by very many people. I concede that I have made mistakes with the current set of votes. And the arguments being made now, after the vote was called and started, are fairly compelling. But these arguments could have been made when the vote page went up, when I was sending in the emails about which option had how many seconds, or when the draft ballot was sent in. There are, in my opinion, far more cogent arguments being offered now, than there were in the discussion period, and had these being made earlier, we would not have come to this pass. But that is merely an excuse. The buck fir running votes stops at the secretary, so I am ultimately responsible for the current state of the vote. And I am begnning to see that the ballot was wrong. Mistakes happen. Mistakes can be recovered from. What can not, however, is relationships, and trust, and this works both ways. It has been made clear to me that the project no longer trusts me, and many consider that I have been the epitome of sleaze over the years, manipulating votes for my own ends. That hurts. I have also read planet. The amount of vitriol there makes it untenable for me to participate in any efforts to recover from this mess. Life is too short. This is way too much stress at a point in my life where there is too much stress to deal with. I am asking the DSA to remove me from the debvote group, effective now. As to the people who emailed me that they are putting together a petition for the DAM to have me removed from the project, I hear you too. I am going to spend the next few days evaluating how important the project is to me, and whether I should save you the bother or an expulsion process. While I must say that the mistake for this ballot lies at my door, I am very distressed at the amount of vitriol that saturates the project communication channels now. Subjectively, this seems worse now than the flame filled days of yore -- because, back then, despite the apparent flames, people used to be amicable and friendly with the people they occasionally had heated discussion with. That seems to have passed, with real meanness being far more prevalent than before. Any way. Goodbye, and thanks for all the fish. manoj -- Freedom from incrustation of grime is contiguous to rectitude. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgp2lxH7BuPql.pgp Description: PGP signature
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Loïc Minier wrote: > On Wed, Dec 17, 2008, Manoj Srivastava wrote: >> I do not think I meant proposed as in formal proposals to be >> voted upon. I meant splitting up votes for the same issue which leads >> to the results being gamed. > > This is an hypothetical case you're making; most people think the > issues are orthogonal. Can these people explain why they think so? ANd it would help if they could say why the arguments I present to say it is a single issue are incorrect. Just opinions do not lead to consensus. manoj -- I will always love the false image I had of you. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bundled votes and the secretary
On Wed, Dec 17 2008, Steve Langasek wrote: BTW, thanks for not flaming here; it was pleasantly surprising to see civil discussion on this topic. > Where there's ambiguity about whether a proposer intended an amendment vs. a > stand-alone proposal, I think it's perfectly reasonable to allow the > secretary latitude in determining intent so as to not get bogged down in > proceduralism. I don't think that was the case here for > <20081114201224.ga11...@intrepid.palfrader.org> - though I'm having a hard > time coming up with references at the moment, I believe there were > objections from some of the seconders of this proposal that it was meant to > be a stand-alone proposal rather than an amendment. > > When I wrote my earlier message, I believed this was much more clear-cut; on > review, I see that the original proposer left the question rather open by > referring to his GR as a "GR (option)". So there are still two > possibilities here: > > - enough of the 17 seconders expressed no opinion on the question of > whether this shoud be a separate GR, as would allow interpreting > their intent in favor of treating it as an amendment and putting it > on a ballot with the original proposal > - more than 12 of the formal seconders objected to placing this > proposal on the same ballot with the original due to the orthogonal > issues, in which case it's not constitutionally valid to override > their stated intent by treating it as an amendment. > > So chances are, there's enough ambiguity here that it's constitutionally > valid to put it on the same ballot as a "related amendment". > > There's a separate issue here, however; namely, that the secretary is the > *only* line of defense against gaming of the GR process by a small group of > developers who propose an uncontroversial but orthogonal amendment that will > always win over the alternatives, in the process preventing the will of the > project from being formally enacted: > > http://lists.debian.org/debian-vote/2003/10/msg00168.html > http://lists.debian.org/debian-vote/2003/11/msg00052.html > http://lists.debian.org/debian-vote/2003/11/msg00095.html > http://lists.debian.org/debian-vote/2003/11/msg00101.html > http://lists.debian.org/debian-vote/2003/11/msg00105.html > > It's not unconstitutional for the secretary to keep orthogonal > amendments on the same ballot, and it is the secretary's prerogative > to keep amendments grouped on a single ballot if he believes they are > related. But when there are multiple orthogonal issues being > considered on a single ballot, choosing to not split those ballots > means disenfranchising the proposers of the > less-popular-but-popular-enough-to-pass option. Given that developers > already have the power to propose as many serial GRs as needed in > order to reconcile incompatibilities between ratified resolutions, the > disenfranchisement is a much worse exploit of our voting system than > anything that could be achieved by forcing partially-orthogonal > options onto separate ballots. OK. I'll buy this line of reasoning. I do agree that beig able to split off unrelated options from the ballot is more useful than keeping related options together. I have been going over my notes and doing some research, but every option I came up with for tactical voting seems only valid for one-shot elections; where people could not propose the same vote over and over. This is not the case here. So it boils down to this: are the issue orthogonal, or are they just different solutions to the same issue? I have presented my argument for why I think they are the same; can you explain why those arguments do not hold, and these are not just different solutions to the same issue? manoj -- The documentation is in Japanese. Good luck. Rich $alz Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Russ Allbery wrote: > Manoj Srivastava writes: > >> I am not sure how even choice 1 is over riding that decision. Do >> you believe that the release team, despite their protestations, is >> bundling DFSG violatons into main? If the release team is releasing >> only free stuff, then option 1 is being followed. >> >> I do not see where you get this over ride a delegate bit from, >> unless you are accusing the release team of violating the 100 % free >> debian system bit. >> >> Can you clarify? > > If you go back to my original message on this, you'll see that I said that > *either* option 1 is a delegate override *or* it's meaningless. It sounds > like you're arguing (probably just for the sake of discussion) that it's > meaningless and we should continue on to release lenny even if it passes. > Is that correct? Actually, no. I was saying that option 1 says: , | Given that we have known for two previous releases that we have non-free | bits in various parts of Debian, and a lot of progress has been made, | and we are almost to the point where we can provide a free version of | the Debian operating system, we will delay the release of Lenny until | such point that the work to free the operating system is complete (to | the best of our knowledge as of 1 November 2008). ` Now, the only way this overrides a delegate is if the delegates and decide that we are not shipping a free operating system. I did not understand that that was the case. > > *This* is exactly why I think that the ballot is poorly worded and could > have used additional assistance, not in the form of rewriting it, but in > the form of someone saying "uh, this makes no sense -- if you want to > override a decision, be explicit." I agree that any of us could have > offered that assistance, and therefore this is something of a collective > failure. Actuall, given the pwer that the secretary has voer the process, the secretary shoul *NOT* be saying things like "uh, this makes no sense -- if you want to override a decision, be explicit." The secretary should *NOT* be deciding if the contents of the proposal are sane. > There are multiple different ways by which to arrive at the conclusion > that releasing lenny as-is doesn't violate the SC. One of them is that > points 1 and 4 of the SC are in conflict and we steer a course between the > two of them. Did you read SC #5? SC #5, in my eyes, is what tells us how we reconcile SC #1 abd SC #4. > Another is that the DFSG doesn't apply to firmware now. I do not see this in my reading of the SC. > Another is that the SC is a goal that we don't need to meet in full > immediately. While I do not agree for releases, I think that is true for Sid, and I can see how reasonable people might disagree. > Another is that given that the software is already in the > archive, whatever problems there are aren't the release team's problem. > There are probably others. I've seen all of the above put forward by > different people as part of this discussion. I intend to extent to all of > my fellow developers the assumption that they hold their opinions > sincerely and not deceptively. > I can't tell you which interpretation is correct, if any of them -- > that's exactly the point under dispute. I can tell you what I > personally believe, but that doesn't really mean anything. Other > people can arrive at similar conclusions for entirely different > reasons. I don't agree with all of those opinions, but that doesn't > matter -- that just means that we don't have consensus, and we knew > that already. The question now is how do we decide what to do given > the lack of consensus. > I think it was manifestly clear from the way in which Robert Millan made > his proposal and the discussion leading up to it that he intended it to be > a delegate decision override, and I think that even in the absence of > better wording to make that explicit, the project should treat it > accordingly anyway, since that was obviously the intent. Well, I don't see how we can interpret another person's proposal -- but these clarifying questions should have been long resolved now, since asking these questions is why we have a discussion period. > No, I think this is too simplistic. A vote is not solely your work as > secretary. It also has a direct effect on other people's work. It's > effectively part of multiple decision-making processes at the same time. Any developer in a core role has the same impact. The FTP masters, and the release team, have similar impats
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Steve McIntyre wrote: > And other people are not comfortable with you claiming a power that is > not grounded in the constitution: namely, the power to declare that a > ballot option needs supermajority, even if it is not a motion to > directly amend or supersede a foundation document. That's the problem > here. Whether you think you *should* have that power is a different > question, but many people are convinced you do not have it now. A: the final form of the ballot, including the supermajority requirements, is specified in the conbstitution. Also, resolving to do something that overrides a foundation document, in whole or in part, is equivalent to creating a ew version of the foundation document, and adhereing to that. So any resolution, not explicitly stated to be a non-binding position statement, which contravenes a foundation document, is committing us to a course that requires us to override a foundation document. I think the intent of the constitution would be issue a new version, instead of allowing a 1:1 majority end run around foundation documents. I am fairly comfortable in the grounding in the constitution powers bit. manoj -- Any given program, when running, is obsolete. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Russ Allbery wrote: > Manoj Srivastava writes: >> On Wed, Dec 17 2008, Russ Allbery wrote: > >>> Basically, to declare this option as requiring a 3:1 majority assumes >>> an answer to precisely the question that's being disputed, and I don't >>> think that falls under the purview of the secretary. The secretary >>> interprets the constitution, but not the DFSG or the SC. It's one of >>> those difficult balancing acts: you do have to decide whether to >>> require a 3:1 majority, which partly requires interpretation, but >>> interpretation may be the matter under dispute. > >> So who interprets the DFSG and the SC in regular day to day >> activities? Do we not interpret it as best? Isn't your argument that >> the release team should be interpreting the DFSG and SC in their work? > > Yes. And they seem to have already done this and arrived at a > conclusion, and this GR is being proposed to override that decision. > Since option four effectively supports the existing delegate decision > about how the SC and DFSG should be applied, deciding whether or not > it requires a 3:1 supermajority is basically equivalent to deciding > whether or not you think the release team is following the DFSG and SC > now. Which reduces to the same problem that's the subject of the vote > in the first place. I am not sure how even choice 1 is over riding that decision. Do you believe that the release team, despite their protestations, is bundling DFSG violatons into main? If the release team is releasing only free stuff, then option 1 is being followed. I do not see where you get this over ride a delegate bit from, unless you are accusing the release team of violating the 100 % free debian system bit. Can you clarify? > To some extent, as secretary, you're basically screwed here. Every > decision that you can make about majority is arguably begging the > question. Hmm. So, in my role as a vote taker, I have to decide on the majority requirement of every option, and so my daily tasks require interpretation of the SC/DFSG to see if they are being overridden or changed. Now, who gets to interpret that SC/DFSG? perhaps what follows may shed some light. > I think the best way out of that trap is to take a step back and defer to > the decision-making process: there's a conflict over the DFSG and SC, > currently "who decides?" is the delegate, and they've decided that it > means the lenny release can go forward. Therefore, in this area, that's > the prevailing interpretation unless the project overturns that decision > via GR. Wonderful. The delegate, or the role in charge, decodes how to interpret the DFSG and the SC in their day to day work. All we have to do is decide who the role in charge is that decodes how the DFSG and SC is to be interpreted when deciding of the procedures and form of the ballot in a vote. Right? > Of course, the other argument that can be made here is that option > four is intended to be more sweeping than the existing delegate > decision by making that decision binding on the rest of the project or > making it permanent or some other material change. I can sort of see It defines what the Debian system is, since our OS is what I think the SC is referring to. So, any decisions about the Debian system does impact the social contract, which is something I do considere binding on the developers -- we all agreed to it, right? Now, we are saying that we are giving away the decisions to decide about violations of the social contract with respect to the Debian system to a handful of developers. > that if I squint at it, but I don't think that was the intention. > (The "if necessary we authorize those decisions" adds some ambiguity, > since it's not really clear to me which power of the developers acting > via GR that's referring to. I, of course, didn't say anything about > that at any point when it would have been useful to do so, and your > points about how you're not responsible for any of the wording are > very well-taken.) >> If the release team is not allowed to interpret the DFSG and SC in >> order to release who is? > Yeah, that's exactly the problem. My reading of the constitution is that > in the absence of a GR, the release team has that power. So, who gets to decide how to interpret the DFSG and the SC when it comes to voting procedures and the final form of the ballot? > In other words, my reading of option four is that what it proposes is the > same as the current state, modulo details of wording. Why is option 1 different from opti
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Luk Claes wrote: > Manoj Srivastava wrote: >> On Tue, Dec 16 2008, Matthew Woodcraft wrote: >>> If the proposer of vote/2003/vote_0003 had intended it to give the >>> Secretary power to impose supermajority requirements on the grounds >>> that an option conflicts with a foundation document, one would have >>> expected him to have said so explicitly. >> >> So, in your opinion, which decision making entity is empowered >> by the constitution to make decisions about super majority >> requirements? What are the constraints on their ability to decide on >> this? What should they be looking at, apart from the constitution, to >> decide whether a super majority rule should apply? > > I would think the explicit overriding or removal of parts of foundation > documents aka changing them as I read it in the constitution (but > apparently my interpretation differs from yours). Parse error. Which entity did you mean? Or are you just answering the last question? Does that mean we can just not follow the foundation documents by doing something different, but just not saying explicitly we are over riding them? So, as long as we do not make the faux-paux of explicitly amending a foundation document, we can change bits and pieces of it, as much as we want? Seems like saying that we need a super majoruty to change foundation documents is silly, since all we actually need is to never say so explicitly. I am not sure I am confortable with this "wink, wink, nudge nudge" approach. manoj -- Lockwood's Long Shot: The chances of getting eaten up by a lion on Main Street aren't one in a million, but once would be enough. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, David Weinehall wrote: > On Wed, Dec 17, 2008 at 01:54:40PM -0600, Manoj Srivastava wrote: >> On Mon, Dec 15 2008, Russ Allbery wrote: >> >> > Thomas Weber writes: >> >> Am Montag, den 15.12.2008, 10:06 + schrieb Steve McIntyre: >> > >> >>> I've been talking with Manoj already, in private to try and avoid >> >>> flaming. I specifically asked him to delay this vote until the numerous >> >>> problems with it were fixed, and it was started anyway. I'm *really* >> >>> not happy with that, and I'm following through now. >> >> >> >> Uh, I don't quite get this: you shortened the discussion period, but at >> >> the same time asked the secretary to delay the vote? >> > >> > Where did Steve shorten the discussion period? He did so for the *other* >> > vote, but I haven't seen a thread where he did for this one. (I may have >> > just missed it.) >> >> I mis remembered. Steve shortened the discussion period for >> this vote, and the discussion and voting period for the _other_ vote, >> but I missed that the vote period for the gr_lenny vote was not >> shortened. I'll send out a new CFV. > > OK, does this mean that everyone who already cast their vote will need > to do so again, or will the voting period simply be extended another > week? I was just thinking of postposing the end-of-vote cron job, so no re-voting would be needed. If there is sufficient support, we could also scrap the current vote, change our ballot, add options to it, or something, and restart the vote, but that would need a strong grass roots support (I do not think the secretary has the power to do so). manoj -- today, n.: A nice place to visit, but you can't stay here for long. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Luk Claes wrote: > Manoj Srivastava wrote: >> The proposal we used before is choice 5 in the current >> ballot, and that does indeed have a 1:1 majority like we did >> before. The devil lies in the details (and I have explained the details >> before too) -- which is that we state that the fiormware blob be >> released under a DFSG free licence. This means we explictly conform to >> the DFSG, Without that clause, in choice 2, we are just accepting any >> firmware blob, with any license, which means that we are allowing for >> the DFSG to be violated >> >> I do not think we released before with known violations. We >> released with things we strongly suspected as being violations; since >> we strongly suspect the blob was not the preferred form of >> modification, but we do not know for a fact. > > How is this different now btw? I don't know if it is. Choice #5 allows us to release, if this is the case. >>> * Bundling the vote against the open opposition of a fairly significant >>> number of people, including some of the people whose amendments were >>> grouped together, is within his power but comes across poorly. There >>> wasn't much attempt to compromise or discuss this, and I came away from >>> that with a bad taste in my mouth. >> >> Have we not been discussing this for weeks now? Related options >> belong on the same ballot. Not doing so allows for strategic voting to >> game the issue. This is not really an opinion piece, this is a known >> flaw of splitting votes where condorcet is used. > > Because you seem to only have considered splitting the vote with the > existing options and have no where suggested it would be better to split > the options by topic and ask if the proposers and seconders would feel > that was more appropriate... I am not sure I follow you here. My take is that the issue is how the project handles releases with firmware blobs; and the choice #4 and #6 do address that, so they belong on this ballot; however, I can see vote_004 and vote_005 be run immediately after which just consider options 4 and options 6 separately. Indeed, we can start the empower the RM vote and firmware is an exception in the DFSG votes on jan 2, 2009. > >>> * One role of the secretary is to interpret the constitution. The >>> constitution states fairly clearly the process of decision-making >>> for decisions of this type, such as whether a given package violates >>> the DFSG, or how to weigh the implications of the Social Contract. >>> Yet that decision-making process is not reflected in the ballot or >>> in the presentation of the options. Option 1 is either meaningless >>> or an override of a delegate decision, but the ballot doesn't >>> reflect this. >> >> While the options are not written by the secretary, and people >> would consider it a gross abuse of power if I wrote things up as I felt >> thy should be written; the proposer could have made the overriding the >> decision of a delegate explicit. > > You could have made it clear that's how you interpret things and offered > the proposers and seconders to think about changing it? Err, I think that is how we have run votes in the past, and the constitution specifies it explicitly (prpoers say what the ballot looks like). I asked for ballot language, and for wml for the web site from proposers explicitly. >> Usually, the ballot form is created by the proposer, it contains >> the title of the proposal, as the proposer set it, and any majority >> requirements. > > Unless the proposer does not set it, then it *seems* to me at least that > you try to come up with something without actually consulting the > proposer and seconders. I asked. I did not see any response to my pleas for wml or ballot forms. >> Again, the proposers or seconds could have improved the >> proposal. What does this have to do with the secretary. > > The secretary is supposed to have experience in taking votes and could > suggest improving the proposal to the proposer and seconders? The secretary has no desire to undergo even more shit storms like this one for daring to voice their opinions on matter related to voting unless specifically required to do so as part of their duties. You want the secretary to be proposing wording changes and titles, the project needs to start treating its secretary a heck of a lot better. >> Point 1 has been answered; and again today, point 2 is related >> to not splitting of
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Loïc Minier wrote: > On Wed, Dec 17, 2008, Manoj Srivastava wrote: >> I also >> think that placing all related proposals on a single ballot is >> relevant, it prevents an easy exploit of the voting system by simply >> setting up a series of votes that can be gamed, and setting up all >> kinds of related proposals to be set up on different ballots. >> >> Frankly, I think that kind of gaming of the voting system that >> is being proposed now, and I am not comfortable letting that happen. > > BS. People still need to find enough seconds; if you think we need > more seconds for GRs, propose a GR. I do not think I meant proposed as in formal proposals to be voted upon. I meant splitting up votes for the same issue which leads to the results being gamed. Say, for example, we do split up the votes. And the winning options of different votes contradict. Which takes precedence? If it is the latest vote, which vote is voted upon last? Can I withsraw an option, and put it to vote at the very end, to get an edge? Why is having an omnibus vote now, and a vote on option #4 and option #6 in January any worse than arbitarily splitting votes? (We could stipulate that actions on the january votes apply only after lenny releases, to prevent people trying to game the lenny release). manoj -- The truth is rarely pure, and never simple. Oscar Wilde Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Russ Allbery wrote: > Manoj Srivastava writes: >> Have we not been discussing this for weeks now? Related options >> belong on the same ballot. Not doing so allows for strategic voting to >> game the issue. This is not really an opinion piece, this is a known >> flaw of splitting votes where condorcet is used. > > Yes, you've said this, and I understand your point and I understand that > you feel this is very important, but clearly a lot of people don't agree > with you and are willing to live with potential strategic voting in favor > of having separate ballots. I don't think your concerns, while valid, > were a good justification for turning something into an amendment that > wasn't proposed as one. > I see why you made the decision. I just don't think it's a good one. > (But it's someplace where I can see where reasonable people can disagree.) I am sorry that you do not agree, but I am failing to see the rationale for preferring a route that allows our votes to be gamed (and thus, arguably, tainting the process _anyway_) to an omnibus vote. And there is no reason we can't still have multiple votes; just because a proposal does not win this round is no reason it can't be brought up again. > The 3:1 majority here is what has to do with the secretary. Given that > this option is functionally the same as FD, and FD doesn't require a 3:1 > majority, I think this is rather odd. But this was discussed in more > depth in another message. I do not think that FD means release lenny, I think FD means delay until we are sure we meet the DFSG. But again, what I think of the FD does not carry weight; but it does explain why I do not think the FD needed a 3:1 majority. > Basically, to declare this option as requiring a 3:1 majority assumes > an answer to precisely the question that's being disputed, and I don't > think that falls under the purview of the secretary. The secretary > interprets the constitution, but not the DFSG or the SC. It's one of > those difficult balancing acts: you do have to decide whether to > require a 3:1 majority, which partly requires interpretation, but > interpretation may be the matter under dispute. In this particular So who interprets the DFSG and the SC in regular day to day activities? Do we not interpret it as best? Isn't your argument that the release team should be interpreting the DFSG and SC in their work? If the release team is not allowed to interpret the DFSG and SC in order to release who is? > case, I think the best approach would be to take the word of the > amendment proposers on whether they intend to supersede a foundation > document or whether they are only proposing a non-binding resolution > on the sense of the project (or possibly a delegate decision override > that doesn't change the foundation document). Well, if the proposers wanted a non-binding resolution, why is that not clear in the proposal itself? If it had been explicitly stated that this is not what the developers decided by the means of a general resolution as a course of actrion, but just as a non-binding resolution, then there might have been some justification to let it stand alone (though I would have refused to run that vote, since I do not feel comforable aiding and abetting creation of a position statement that contradicts, in my view, a foundation document. However, I would let the asst. secretary run that wvote, if they were amenable). But lacking an explicit statement that it is a non-binding resolution and should be treated like one, I must treat is as something the project resolves to do via a general resolution, whether or not the foundation documents are against that. > Also, after this message, I'm going to stop discussing what I think we > could have done with this ballot, since at this point it's rather late to > change it and I don't think withdrawing it and reissuing it would really > accomplish anything that useful. So this becomes rehashing of decisions > already made, which can be done forever to quickly diminishing returns. If there is sufficient support for scrapping and restarting the vote, despite the fact it has been started, I would not be in opposition. But I am not going to stick my necj out and propose it; however, if people think the ballot needs more options, and that this ballot is a mess, and they can't vote on it, and enough people stand up to support that view, it might be better for the project to allow the ballot to be amended, and reopen the discussion period. manoj -- Pournelle must die! Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Luk Claes wrote: > Manoj Srivastava wrote: >> On Tue, Dec 16 2008, Steve McIntyre wrote: >> >>> On Tue, Dec 16, 2008 at 04:27:22PM -0800, Russ Allbery wrote: >>>> This is where I have a strong disagreement with Manoj and apparently with >>>> you. I don't think there's any justification in the constitution for >>>> requiring a developer statement about the project's sense of the meaning >>>> of the SC and the DFSG to have a 3:1 majority, or to make a developer >>>> override to enforce that sense of the meaning. >>>> >>>> Both the override and the statement about the meaning of the documents >>>> should require 1:1. 3:1 should only be required when the documents are >>>> explicitly superseded or changed, not just for making a project statement >>>> about their interpretation. >>> And that's my interpretation too. I think the constitution is quite >>> clear here. >> >> Frankly, if you want a non-binding position statement you should >> make that explicit; the developers resove via a general resolution >> actions that go against a foundation document need the supermajority, >> in my opinion. > > Well, apparently not all DDs concur with that interpretation, though you > have the explicit power to interpete the constitution, so be it (these > DDs should probably explicitely propose something to maybe change the > constitution). I would be happy if the constitution was changed, to clarify the issue, or to explicitly add another entity (foundation doc interpretation ctte) to handle intepretations, in which case the whole issue could just be referred to them. As it stands, however, I can only do what I think is right, after listening to what other people say. And I have. I just have ont been convinced of the arguments to change what I think is the right thing to do. manoj -- The world is all the richer for having the devil in it, so long as we keep our foot on his neck. --anonymous Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Loïc Minier wrote: > On Wed, Dec 17, 2008, Manoj Srivastava wrote: >> The way that we achive such combinations using condorcet is to >> propose such combinations as options intheir own right; and then have >> people vote on the combination option along with simple options. > > Or do separate votes... Separate votes on related proposals are widely open to gaming the system. >> There was no such proposal during the discussion period. > > It was your decision to make a single ballot out of these orthogonal > issues, do not present the situation as being the proposers' fault. It is not the proposers fault in any case; it is, if anything, the responsibiulity of folks who wanted to vote on more than one option at a time, even when it was clear that the ballot was the way it is now. Secondly, I have presented my arguments why these proposals are all strongly related, and thus deserve to be on the same ballot for a fair vote. I do not see any counter arguments here. manoj -- Suicide is the sincerest form of self-criticism. Donald Kaul Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Luk Claes wrote: > Manoj Srivastava wrote: >> On Wed, Dec 17 2008, Luk Claes wrote: >> >>> Manoj Srivastava wrote: >>>> On Sun, Dec 14 2008, Pierre Habouzit wrote: >>>> >>>>> On Sun, Dec 14, 2008 at 03:02:17AM +, Debian Project Secretary wrote: > >>>> Seems liek there was plenty of time to change things, and add >>>> some of the power set options on to the ballot. If I had added options >>>> willy-nilly, you would have screamed again of abuse of power. >>> Sure, though you could have followed the procedure or hinted people in >>> an even saner direction IMHO. >> >> I followed the procedure that I think we have followed in the >> past. We do ont make people jump through "and replace all the words in >> the proposal by these words" hoops, and we put related proposals on the >> same ballot. Unfortunately, some of the proposals are not mutually >> exclusive, so combinations are possible; and I did not want to >> increase the size of the ballot with combinations; I think had I done >> that, there would still have been accusations of the ballot being too >> complex. > > Right, this kind of makes your above point moot IMHO. Actually, no: as other people are not me; _I_ did not see enough use in the combination options to want to increase size; other people seem to have different views. Whether I personally thought that adding the combo option is pointless does not constrin other people. manoj -- Memory should be the starting point of the present. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Sun, Dec 14 2008, Russ Allbery wrote: > Russ Allbery writes: > >> * Bundling the vote against the open opposition of a fairly significant >> number of people, including some of the people whose amendments were >> grouped together, is within his power but comes across poorly. There >> wasn't much attempt to compromise or discuss this, and I came away from >> that with a bad taste in my mouth. > > Or perhaps *not* within his power given that one of the proposals was not > offered as an amendment. Which makes it come across even more poorly. We have not been making people do formal amendments at all (replace all the words of the amendment foo with these words). I also think that placing all related proposals on a single ballot is relevant, it prevents an easy exploit of the voting system by simply setting up a series of votes that can be gamed, and setting up all kinds of related proposals to be set up on different ballots. Frankly, I think that kind of gaming of the voting system that is being proposed now, and I am not comfortable letting that happen. manoj -- If you stop to think about it, you're already dead. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Tue, Dec 16 2008, Matthew Woodcraft wrote: > Russ Allbery wrote: >> If there were something in the constitution detailing decision-making >> process around foundation documents and their interpretation, it would >> have made this whole conflict easier to resolve. But so far as I can >> tell, there isn't, apart from application to voting specifically. > > There isn't anything in the constitution about the application of > foundation documents to voting either, other than the rule about > superseding them. > If the proposer of vote/2003/vote_0003 had intended it to give the > Secretary power to impose supermajority requirements on the grounds > that an option conflicts with a foundation document, one would have > expected him to have said so explicitly. So, in your opinion, which decision making entity is empowered by the constitution to make decisions about super majority requirements? What are the constraints on their ability to decide on this? What should they be looking at, apart from the constitution, to decide whether a super majority rule should apply? manoj -- The man on tops walks a lonely street; the "chain" of command is often a noose. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Sun, Dec 14 2008, Russ Allbery wrote: > Option 4 looks equivalent to FD if you look at the decision-making > process in the constitution, but the ballot doesn't reflect that. I > think some additional clarity around that would have been very helpful. Not really. I think that the power to decide to violate the DFSG is not given to _anyone_ in the constitution. Option 4 explicitly adds this power. So, currently, the RT can not violate the DFSG (and I think they have been stating all along that they are not, in their opinion, violating the DFSG); with option 4 they can. This I think is the distinction between option 4 and FD. Why were these clarifying questions not asked of the proposers in the discussion period? manoj -- When a man is tired of London, he is tired of life. Samuel Johnson Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Tue, Dec 16 2008, Steve McIntyre wrote: > On Tue, Dec 16, 2008 at 04:27:22PM -0800, Russ Allbery wrote: >> >>This is where I have a strong disagreement with Manoj and apparently with >>you. I don't think there's any justification in the constitution for >>requiring a developer statement about the project's sense of the meaning >>of the SC and the DFSG to have a 3:1 majority, or to make a developer >>override to enforce that sense of the meaning. >> >>Both the override and the statement about the meaning of the documents >>should require 1:1. 3:1 should only be required when the documents are >>explicitly superseded or changed, not just for making a project statement >>about their interpretation. > > And that's my interpretation too. I think the constitution is quite > clear here. Frankly, if you want a non-binding position statement you should make that explicit; the developers resove via a general resolution actions that go against a foundation document need the supermajority, in my opinion. manoj -- "In order to form an immaculate member of a flock of sheep one must, above all, be a sheep." Albert Einstein : Understanding the world Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Tue, Dec 16 2008, Richard Hartmann wrote: > I think he had the implied accussation from the GR's text in mind. > Option 1 is to 'Reaffirm the Social Contract', which means that dissenting > votes weaken and/or break the SC. No idea if that is on purpose or a > honest mistake, but I am assuming good faith with Manoj as with > everyone else. The title for ballot lines are proposed by the proposer when titling their proposals. Ask the proposer. manoj -- What soon grows old? Gratitude. Aristotle Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Sun, Dec 14 2008, Russ Allbery wrote: > Bas Wijnen writes: >> On Sun, Dec 14, 2008 at 12:59:12PM -0800, Russ Allbery wrote: > >>> It's a shame that the vote was handled in the way that it was, > >> Actually, I think the secretary has done a very good job in preparing >> the ballot. > > I would like to feel that, but unfortunately, I don't think the facts > support that feeling. The 3:1 majority part I can understand. That's his > job, and whether I agree or not, I can't get upset at him for doing his > job. However, there are several other serious irregularities in this > vote: > > * Why does releasing despite DFSG violations require a 3:1 majority now > when it didn't for etch? It's the same secretary in both cases. What > changed? I didn't find any of the explanations offered for this very > satisfying. The proposal we used before is choice 5 in the current ballot, and that does indeed have a 1:1 majority like we did before. The devil lies in the details (and I have explained the details before too) -- which is that we state that the fiormware blob be released under a DFSG free licence. This means we explictly conform to the DFSG, Without that clause, in choice 2, we are just accepting any firmware blob, with any license, which means that we are allowing for the DFSG to be violated I do not think we released before with known violations. We released with things we strongly suspected as being violations; since we strongly suspect the blob was not the preferred form of modification, but we do not know for a fact. > * Bundling the vote against the open opposition of a fairly significant > number of people, including some of the people whose amendments were > grouped together, is within his power but comes across poorly. There > wasn't much attempt to compromise or discuss this, and I came away from > that with a bad taste in my mouth. Have we not been discussing this for weeks now? Related options belong on the same ballot. Not doing so allows for strategic voting to game the issue. This is not really an opinion piece, this is a known flaw of splitting votes where condorcet is used. I am sorry about the bad taste in your mouth, but unless you can argue how we can guard against gaming the system when we split votes, I don't see where we are going with this. > * One role of the secretary is to interpret the constitution. The > constitution states fairly clearly the process of decision-making > for decisions of this type, such as whether a given package violates > the DFSG, or how to weigh the implications of the Social Contract. > Yet that decision-making process is not reflected in the ballot or > in the presentation of the options. Option 1 is either meaningless > or an override of a delegate decision, but the ballot doesn't > reflect this. While the options are not written by the secretary, and people would consider it a gross abuse of power if I wrote things up as I felt thy should be written; the proposer could have made the overriding the decision of a delegate explicit. The decision to override would not need a supermajority, so the ballot would not need to be changed. Usually, the ballot form is created by the proposer, it contains the title of the proposal, as the proposer set it, and any majority requirements. The ordering is something the secretary decodes, it was done chronologically this time around. > Option 4 looks equivalent to FD if you look at the > decision-making process in the constitution, but the ballot doesn't > reflect that. I think some additional clarity around that would > have been very helpful. Again, the proposers or seconds could have improved the proposal. What does this have to do with the secretary. > So, no, I think in this case Manoj did a poor job of preparing this > ballot. (That doesn't mean that I have any problems with him personally, > nor do I believe that he did so out of any ulterior motives. I think he > made the decisions that he thought were correct. I just don't think they > were good decisions.) Point 1 has been answered; and again today, point 2 is related to not splitting of related proposals or candidates for resolving the release into spearate vote while we use condorcet, and point 3 is unrelated to decisions I took; heck, I'd love to rewrite proposals other people come up with as secretary, and make them "sane"; I can just see hows of protest were I to "rectify": or apply "editorial changes" to the proposals. manoj -- Goodbye, cool world. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Luk Claes wrote: > Manoj Srivastava wrote: >> On Sun, Dec 14 2008, Pierre Habouzit wrote: >> >>> On Sun, Dec 14, 2008 at 03:02:17AM +, Debian Project Secretary wrote: > >>> And FWIW I still believe this vote is an horrible mix-up of really >>> different things, is completely confusing, and I've no clue how to vote. >>> I would be surprised other people don't think the same. >>> >>> E.g. How can I decide 2 _and_ 4 ? Does the rule change ? Does any >>> resolution that wins overs Further Discussion will be validated ? >>> Because unless I'm mistaken, 2 doesn't imply 4, so if 2 wins, 4 is >>> invalidated. >> >> No one seems to have seen it desirable to put a 2 & 4 option on >> the ballotl; despite the months we took to discuss this. The web page >> with the options was also up for several weeks, and a draft ballot went >> up earlier. > > It's you who decided to put all the proposals on the same ballot. I > don't think it's fair to request from people who disagree with that to > invest time in proposing more options. Well, I put all related proposals on the same ballot, yes, but it is because I think we need to do so in order to not let strategic voting skew the results. > It's you who decided to make it a mess, you could as an experienced > vote taker have suggested quite some different things which could have > made it cleaner instead IMHO. I do not know how to take this kind of a complex issue, and cleanly compress it into somewthing that would be both fair and clean. I opted for fairness, in that we do not have serial votes with subsets of options leading to a run-off, which would make strategic voting harder. >> Seems liek there was plenty of time to change things, and add >> some of the power set options on to the ballot. If I had added options >> willy-nilly, you would have screamed again of abuse of power. > > Sure, though you could have followed the procedure or hinted people in > an even saner direction IMHO. I followed the procedure that I think we have followed in the past. We do ont make people jump through "and replace all the words in the proposal by these words" hoops, and we put related proposals on the same ballot. Unfortunately, some of the proposals are not mutually exclusive, so combinations are possible; and I did not want to increase the size of the ballot with combinations; I think had I done that, there would still have been accusations of the ballot being too complex. manoj -- The 11 is for people with the pride of a 10 and the pocketbook of an 8. R.B. Greenberg [referring to PDPs?] Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Sun, Dec 14 2008, Loïc Minier wrote: > > This ballot is nonsense: >a) I want to decide on requirements of source of firmwares AND allow > lenny to release with DFSG violations AND "proprietary" firmware > AND empower the release team to release with DFSG violations The way that we achive such combinations using condorcet is to propose such combinations as options intheir own right; and then have people vote on the combination option along with simple options. There was no such proposal during the discussion period. manoj -- Classical music is the kind we keep thinking will turn into a tune. Kin Hubbard, "Abe Martin's Sayings" Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Mon, Dec 15 2008, Russ Allbery wrote:
> Thomas Weber writes:
>> Am Montag, den 15.12.2008, 10:06 + schrieb Steve McIntyre:
>
>>> I've been talking with Manoj already, in private to try and avoid
>>> flaming. I specifically asked him to delay this vote until the numerous
>>> problems with it were fixed, and it was started anyway. I'm *really*
>>> not happy with that, and I'm following through now.
>>
>> Uh, I don't quite get this: you shortened the discussion period, but at
>> the same time asked the secretary to delay the vote?
>
> Where did Steve shorten the discussion period? He did so for the *other*
> vote, but I haven't seen a thread where he did for this one. (I may have
> just missed it.)
I mis remembered. Steve shortened the discussion period for
this vote, and the discussion and voting period for the _other_ vote,
but I missed that the vote period for the gr_lenny vote was not
shortened. I'll send out a new CFV.
Sorry about that.
manoj
--
Happiness adds and multiplies as we divide it with others.
Manoj Srivastava <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Sun, Dec 14 2008, Pierre Habouzit wrote: > On Sun, Dec 14, 2008 at 03:02:17AM +, Debian Project Secretary wrote: > >> -- >> Choice 2: Allow Lenny to release with proprietary firmware [3:1] >> == == = = == === === = > > Why on earth does it needs [3:1] whereas it wasn't needed for: > http://www.debian.org/vote/2006/vote_007 Asked and answered, it has to do with removing the wording about requiring the firmware to be under a dfsg free license. >> -- >> Choice 3: Allow Lenny to release with DFSG violations [3:1] >> == == = = == === == = > > Same question somehow applies here. You do not think asking to release with known violations of a foundation document needs a 3:1? Again, asked and answered. >> -- >> Choice 4: Empower the release team to decide about allowing DFSG violations >> [3:1] >> == == === === === == == = == >> > > Unless I'm mistaken this shouldn't be [3:1] as it's specifically allowed > by the § about delegates in the constitution. "Delegates shall take > decision they see fit". What should be [3:1] is to dis-empower them from > having such rights. Actuallu, nothing delegated to the delegates allows them to change the foundation docs. Or should the packager fo the constitution document, or the web team, under their daily tasks, just change the constitution as they see fit? > And FWIW I still believe this vote is an horrible mix-up of really > different things, is completely confusing, and I've no clue how to vote. > I would be surprised other people don't think the same. > > E.g. How can I decide 2 _and_ 4 ? Does the rule change ? Does any > resolution that wins overs Further Discussion will be validated ? > Because unless I'm mistaken, 2 doesn't imply 4, so if 2 wins, 4 is > invalidated. No one seems to have seen it desirable to put a 2 & 4 option on the ballotl; despite the months we took to discuss this. The web page with the options was also up for several weeks, and a draft ballot went up earlier. Seems liek there was plenty of time to change things, and add some of the power set options on to the ballot. If I had added options willy-nilly, you would have screamed again of abuse of power. manoj -- God gives us relatives; thank goodness we can chose our friends. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bundled votes and the secretary
On Sun, Dec 14 2008, Steve Langasek wrote:
> On Sun, Dec 14, 2008 at 12:08:01PM +0200, Antti-Juhani Kaijanaho wrote:
>> On Thu, Dec 11, 2008 at 10:38:34AM -0800, Steve Langasek wrote:
>> > if he saw this mail and chose not to acknowledge the arguments,
>> > then he is behaving in a wholly improper manner with regard to this
>> > vote, and frankly I see no reason that we as a project should even
>> > honor the outcome of a vote on this ballot as presented.
>
>> These two statements I find most alarming.
>
>> As long as there is no clear and unambiguous violation of the
>> constitution in the Secretary's actions,
>
> As a matter of fact, there's that too. This ballot has been assembled
> in contravention of the Standard Resolution Procedure, which requires
> that new ballot options be proposed as formal *amendments* to an
> outstanding GR proposal in order to appear on the same ballot. Manoj
> has overstepped his authority in order to group separately proposed
> resolutions about orthogonal questions on a single ballot, over the
> explicit objections of the proposer/seconders. This is not a power
> granted to the secretary under A.2.
All related options are placed on the ballot, no? I am working
on the basis that any proposal, and all related proposals that may
affect the action to be taken, must be on the ballot.
None of the amendments in recent votes take the formal form (I
amend foo, and replace all the words in the proposal with the words
below). Amendments (made formal by seconds) just propose what the
alternate handling being proposed, and related proposals go on the
ballot. This is how the "related amendment" has been handled in
practice over the last several years.
>> and absent a valid GR stating otherwise, the vote must be presumed to be
>> constitutionally valid.
>
> Ah, and how are we meant to get a valid GR when the secretary is actively
> tampering with the GR process?
>
> Recognizing the validity of the vote is not a "must". The alternative is
> that we end up in a state of constitutional crisis. That's unfortunate, but
> it's also unfortunate that our Secretary is failing to act in a manner that
> safeguards the integrity of that office.
In the interest of keeping the discussion civil, I shall not
respond to this.
manoj
--
All great ideas are controversial, or have been at one time.
Manoj Srivastava <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Why the gr_lenny ballot is the way it is
Hi, This whole set of discussions and proposals started a couple of months ago, when concerns were raised about firmware blobs, dfsg violations, and the release. This, after a round of disuccion, led to three proposals on how the release should be conducted, in view of firmware blobs currently in the linux kernel packages. The proposals led tyo a great deal of heated responses, and whole slew of related proposals were produced -- related, as in all of them dealt with firmware blobs and difsg violations, and dealt with the release process, and some of them were for handling just the current release, others sought to solve the issue of firmwarfe for this and all future release4s, either directly, or delegating the decisions to a group of developers, and away from the general resolution mechanism of resolving this for future releases. All of these related proposals would handle, one way or the other, the issue of this release and firmware. Some of them would grant dispensation to more than just firmware, and some of them solve this problem for future reelases as well, but all would resolve the release _now_. Also, some of the proposals are indeed orthogonal, or, at least, mutually incompatible; and in some cases, selecting one option makes the others moot. Yes, some of the options on this ballot have long term impact, but they are also equally capable of solving our "What to do about Lenny" problems. Since they all solve the Lenny issue, they are relevant, and related, solutions for the issue. I do not think throwing options out because they are not of a narrow and limited scope is right. The proposer and sponsors can withdraw them, if they think the scope is too broad for the problem at hand. No one else should be removing them from consideration as a solution to the Lenny issue. Now, we have been fairly non-anal about differing options on out ballots being formally proposed as amendments (I amend proposal foo, and replace all the words in that proposal by these below ), I did not see any reason to change being anal retentive for just this vote. The ballot is a mess. While I think the related proposals should be placed on the same ballot overrides ere, the prooposals are not truly all orthogoanl. We could, for example, do the allow the delegation of DFSG violatio decisions to the release team, _and_ also rulke that firmware should be granted special dispensation in the DFSG. So, while the power set of the options is not feasible, we could have a slew of options combining the various proposed options, if people wanted to vote on a compatible set of options. This was discussed a month ago, in early november, giving people who wanted to vote on a combination of optiosn plenty of time to propose favourite combinations. Message-ID: <87ej1cd11m@mid.deneb.enyo.de> Message-ID: <871vxczbww@anzu.internal.golden-gryphon.com> No one seemed to want such combinations enough to follow up on that. Also, splitting a vote into multiple ballots, with related proposals affecting the same action (lenny release, for instance) , is a horrendously bad idea -- since the massive amounts of strategic voting possibilities will taint the final result. Given that these proposals are strongly related, they should be on the ballot together. The permanent solution proposals, if they fail to pass, may be discussed, modified, and brought to the table again. manoj -- "Those who will be able to conquer software will be able to conquer the world."-- Tadahiro Sekimoto, president, NEC Corp. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bundled votes and the secretary
On Tue, Dec 16 2008, Pierre Habouzit wrote: > On Mon, Dec 15, 2008 at 08:28:19PM +, Kurt Roeckx wrote: >> On Mon, Dec 15, 2008 at 09:58:09AM +0100, Pierre Habouzit wrote: >> > from http://www.debian.org/vote/2006/vote_007#majorityreq> >4. We >> > give priority to the timely release of Etch over sorting every >> >bit out; for this reason, we will treat removal of sourceless >> >firmware as a best-effort process, and deliver firmware in udebs >> >as long as it is necessary for installation (like all udebs), and >> >firmware included in the kernel itself as part of Debian Etch, as >> >long as we are legally allowed to do so, and the firmware is >> >distributed upstream under a license that complies with the DFSG. >> > >> > >> > and from the current vote: >> >4. We give priority to the timely release of Lenny over sorting >> >every bit out; for this reason, we will treat removal of >> >sourceless firmware as a best-effort process, and deliver >> >firmware as part of Debian Lenny as long as we are legally >> >allowed to do so. >> > >> > Now explain to me how a genuine interpretation of the Constitution let >> > the former need simple majority and the latter super majority. >> >> The biggest difference is the "under a license that complies with >> the DFSG" part. There is also the udeb part that's different. >> >> Note that we also have the an option (choice 5) with the "under a >> license that complies with the DFSG" part and that doesn't have the >> 3:1 majority requirement. > > We could have worded it like in '06 and achieve the same then (IOW there > is no "gain" in the wording difference that you believe - and I still do > not believe it - warrants the 3:1 majority wrt what this option tries to > achieve). Does the proposal choice 5 not achive exactly what you seem to want? Itr is worded like 2006, and has a 1:1 majority. I do think the "under a license that complies with the DFSG" part is significant; without it one may say that any binary blob under whatever license may be included in the release; without needing to comply with the DFSG. The not needing to comply with the DFSG bit is what makes the super majority come in, and which is why we have a choice 5 on the ballot. manoj -- We secure our friends not by accepting favors but by doing them. Thucydides Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bundled votes and the secretary
On Sun, Dec 14 2008, Josselin Mouette wrote: > Le samedi 13 décembre 2008 à 22:09 +0100, Robert Millan a écrit : >> For the record, I think the Secretary's interpretation of the Constitution is >> perfectly correct. > > Whether it is correct or not is irrelevant here. The Secretary is > deciding this without justification, in an inconsistent way (similar > options get a different treatment), and without any thought for > following the constitution itself. I think I can honestly reject every one of these statements. Message-ID: <87vdunwp65@anzu.internal.golden-gryphon.com> Message-ID: <87skq0y4i5@anzu.internal.golden-gryphon.com> Message-ID: <871vxjy7cm@anzu.internal.golden-gryphon.com> Message-ID: <87prl2xrla@anzu.internal.golden-gryphon.com> Message-ID: <87wsf9veei@anzu.internal.golden-gryphon.com> Message-ID: <87myg0zrwu@anzu.internal.golden-gryphon.com> Message-ID: <87iqqozrrh@anzu.internal.golden-gryphon.com> Message-ID: <87abc0zhin@anzu.internal.golden-gryphon.com> Message-ID: <87fxlrwfkd@anzu.internal.golden-gryphon.com> Message-ID: <87y6ziv0m6@anzu.internal.golden-gryphon.com> Message-ID: <87ljviuzv8@anzu.internal.golden-gryphon.com> > For example, the Secretary explained that option 6 permanently modifies > the foundation documents, but it doesn’t specify how. If it does modify > them, where are the modifications? If it doesn’t, why does it require > 3:1 majority? If it is not acceptable as is, the Secretary should have > *refused to conduct the vote on it* so that a workable proposal could > have been issued. If this option wins, how will we manage the situation? Message-ID: <87fxltk5yz@anzu.internal.golden-gryphon.com> Message-ID: <87vdtq564m@anzu.internal.golden-gryphon.com> > > For the GFDL GR, this was even worse: the Secretary decided that “GFDL > is free” required 3:1 while “GFDL without invariant sections is free” > did not. The only reason is that he couldn’t stand the latter proposal > and decided to make it impossible to pass. Note that I was strongly > against that proposal – but even while agreeing with Manoj on the topic, > I cannot approve such a manipulation of the vote. You do not think that the former being incompatible with the DFSG had something to do with the difference? manoj -- It's amazing how much "mature wisdom" resembles being too tired. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bundled votes and the secretary
On Thu, Dec 11 2008, Steve Langasek wrote: > On Thu, Dec 11, 2008 at 12:42:20PM +, Matthew Johnson wrote: >> However, I think retitling 5 to: "Assume firmware blobs are in source >> form unless proven otherwise" is worthwhile as is retitling 1 to: "Delay >> Lenny release until all DFSG issues are resolved". > >> I wouldn't say this is the secretary trying to skew anything, I just >> think that it makes the meaning of the choices slightly clearer. If >> people read the text below then it is clear. > > As written in > <http://lists.debian.org/debian-vote/2008/12/msg3.html>, this is not the > case at all. It's possible that the secretary didn't notice this mail > because I didn't cc: him; but if he saw this mail and chose not to > acknowledge the arguments, then he is behaving in a wholly improper manner > with regard to this vote, and frankly I see no reason that we as a project > should even honor the outcome of a vote on this ballot as presented. I did read that mail. I was underwhelmed by the force of the arguments in that email. If you have definitive proof that the firmware are not the preferred form of modification, please present that eveidence, boit to us, and to upstream kernel folks. The proposal also states that a) we should be legally allowed to distribute the firmware (we can only do so if it is covered by a licesne) b) The license be dfsg free. If you know of any irmware that we are sure does not meet the criteria (as opposed to we strongly suspect might not), then proposal 5 does not allow lenny to be released with that. By the way, stating someting in an email does not immediately make a person holding an official role act that way. So not being swayed by your arguments is not, in my eyes, acting in an improper manner. manoj -- Pournelle must die! Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bundled votes and the secretary
On Thu, Dec 11 2008, Raphael Hertzog wrote: > Manoj, I still object to voting all at once and I'm convinced that you > will manage to hurt the project by doing that. > > Honestly, at this point, I would really wish that you retired as > secretary because there have been too many conflicts between you and > various DD while your secretarial work shouldn't be the source of any > conflict. You just have to count the points on each side but you > don't. You insist on deciding alone if something is a change to the > DFSG (when the text doesn't modify it explicitely) while I believe that > only the project at large is able to decide of something like that. The project at largewill be doing the deciding. If they pass a resolution that contradicts the foundation document, the will of the people should not be dismissed. > That said, here are my comments anyway: > > On Wed, 10 Dec 2008, Manoj Srivastava wrote: >> 41b0a520-c6c1-4e7b-8c49-74ee85faf242 >> [ ] Choice 1: Reaffirm the Social Contract > > "Delay Lenny until all DFSG violations known at 1. Nov 2008 are fixed" > > At least be clear what the choice means. Otherwise it looks like you are > hiding the meaning and trying to get you personal preference (yes you > explained several times that you would probably vote for such an option). The title for the resolutions are usually selected by the proposer. I d do not change it unless it is clear to me that the title is obviously incorrect. Ask the proposer to modify the title, or demonstrate the title is wrong (no clear enough is not "wrong"). >> [ ] Choice 2: Allow Lenny to release with proprietary firmware [3:1] > > We're not changing the DFSG. So there's no need for 3:1. The proposal is to resolve on a course of action that over rides a foundation document. >> [ ] Choice 3: Allow Lenny to release with DFSG violations [3:1] > > I followed the discussions but I don't even know why we have this > alternative which looks like the same than 2. Look again. This is more general than 2. >> [ ] Choice 4: Empower the release team to decide about allowing DFSG >> violations [3:1] > > The full text doesn't use the word DFSG violation. > Maybe: > "Let the release team decide if each known freeness problems should be > blockers" We define the DFSG to be the definition of what we consider free. So freeness problems == DFSG violations. >> [ ] Choice 5: Assume blobs comply with GPL unless proven otherwise > > The proposition doesn't speak of the GPL in any special way. Neither does > it explain what is required to prove that source code exist for the blob. > So this subject is not appropriate either. > > In fact, I would think it doesn't solve at all the problem of GPL > firmwares. Well, if you can show that the GPL firmware is not in the preferred form of modification, you might have a point. I wanted to propose that a) Everything in the kernel should be a) legal for us to distribute b) released under a free license. What is excluded is "verfy beyond reasonable doubt that the firmware is the preferred form of documentation". I wanted to say we'll take any upstream claim that the firmware does not violate gpl or whatever dfsg free license it is nunder; unless we have some kind of proof that the author is being deceptive. I'll take suggestions on how to word this on the ballot as long as the meaning is not distorted. >> [ ] Choice 6: Exclude source requirements for firmware (defined) [3:1] > > Peter explicitely told that he doesn't want to modify the DFSG. If peter is resolving that the project do something that contradicts the dfsg, I am not sure any unrelated staements he makes changes the fact that the resolution is to propose a course of action different from the current foundation document. manoj -- A 'full' life in my experience is usually full only of other people's demands. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bundled votes and the secretary
On Thu, Dec 11 2008, Josselin Mouette wrote: > Le jeudi 11 décembre 2008 à 15:38 +0200, Antti-Juhani Kaijanaho a > écrit : >> More strongly, I believe Manoj has repeatedly shown the sort of moral courage >> and sound judgment that the Secretary's job requires, and I believe it would >> be >> a grave loss if he were to step down. It would be a shame if he were to be >> replaced by someone who counts avoiding conflict as a major part of the job. > > What is asked from the Secretary is not to avoid conflict. > It is not even to not participate in the conflict – there’s not reason > why he couldn’t have his own opinion. > > What this position requires is the minimal level of morality to not use > it to favor an opinion or another. And this is something Manoj has been > repeatedly doing; first in the GFDL GR, next in the etch firmwares GR, > now in the lenny one. > > I do not trust anymore the Secretary, and I do not trust sufficiently > the result of this vote. If the otherwise winning option is dismissed by > the lack of a 3:1 majority (for which the requirements are still “Manoj > said so”), or if a winning option is dismissed by a completely unrelated > other option that was not proposed as an amendment, it won’t be possible > to consider the vote result as the decision of the project as a whole. You are enttled to an opinion, I suppose. For the record, no matter what my personal opinions are, I decide on the final form of the ballots based on my reading of the constitution. manoj -- "Toroidal carbohydrate modules? Make mine glazed!" Zippy Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Call for vote (Re: call for seconds: on firmware)
quire it, 2. we however do require all other freedoms that the DFSG mandate from components of our operating system, and 3. such firmware can and should be part of our official installation media. -- The options choice 2, choice 3, choice 4, and choice 6 supersede foundation documents, temporarily or permanently, and thus need a 3:1 majority. The options choice 1 and choice 5) require a simple majority to pass. The responses to a valid vote shall be signed by the vote key created for this vote. The public key for the vote, signed by the Project secretary, is appended below. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (GNU/Linux) mQGiBEk//6wRBAD7CH1mElXRhrTJnTrTZZQDcQjG4mRBaFEAe+azE3t6L9JMXVOp Ups7m8u9xwKYr0qfpJWw5oTFEebvN6wLP90tJrqavBfBY6YpO5LZdhnki3ddLni5 vWlHtpcUmmELJW7xXLjvzZQYtzanwV3qyUJYBqSoCtb5RYXIWaus8fGJVwCgrtoZ AdTAmX7xsUMNZMi9guvrcyEEAPptWEI6KHmv3UlR3+9O+fKnCCgk43ll591qxw68 pbXfYSAY6PUfh7xcz/z9hnlWBbSYCMbrykovCTO85A77O5NT9SwKb3oKk+s4NxWi Ylx6DDK6q/+9DmGK/1yXg0vZ8ylybImjbRp7d5S2MSnX/GWvQXOPX6LKu6hXb2lN ZlkiBADcKq8jTjXdtRkqTRDKPM39yCk/90locWDdA4umSmpNRszQZkWcxJ/bTdIb mr9MBqv4dIn1QR2H+Kd8L4HSZtgTZu9QbosGYDC2ddrAmkqUw4Mzazp5IaZ2p1H+ E07hxn5Ex5Fv8o1hTsOxu6tVtahhgq4245hHF3onN+1FGliXfLQ8TGVubnkgR1Ig dm90ZSBrZXkgKEVwaGVtZXJhbCBLZXkpIDxncl9sZW5ueUB2b3RlLmRlYmlhbi5v cmc+iGYEExECACYFAkk//6wCGwMFCQAk6gAGCwkIBwMCBBUCCAMEFgIDAQIeAQIX gAAKCRDElT8+Z8sSYje+AJ96psJX6s59kM4CFsIcrOn1FXa93wCfbLi1kzpbWKMj VQ2ATo/lDgL11syIRgQQEQIABgUCSUAB7gAKCRAhutq7vyRCTOHaAJwPIbDOF9bC orHryY/u48uPcXOqqwCfYwqAF8qaSzhkaPK2CFkfVVbKhK65Ag0EST//sRAIAISc /3f41mVRM9aw/pNADIGTajm/HwBm89fxUpV8/8dG2oQu6BLMXEWjwMweqWDDQDi7 dYzy+/TpTmyB7x9ELrZi8n89E0Z1nII1CnhCtak+yNf2I9rgk4FrDmfjIfB8UZD/ zHtKVdrACw7pBZAawfeg0NXZoaqroDXvRke+s7TEHZ2N+hRkhsdztqTy0Dz2/HMJ fOV/DEwhM8LtU83ZyiFLioLZvKJINc8JMSX3PwUOgqeig3JwBPGlrzF/H8gdZ4Og k8nlfQOafoSc6UI99BzKh+VcJJgyJH4utWD26Xpni7TS0W/pWeL0Kz126BU87ucc TW7D/vGkzBfP3UjOFQMAAwYH/RSkEuOtEu2u9x29ZsvFuN076Ef+3r5YmAOH0EBt KJfIWPSivEbGtrE4/VgoESIX8/jpnG2XhFxOB79AOBUw7UHyF2uo9FtwQdv0N/Do Wjcgr/v+Ex874HjBF4yocy2jU36efAM+Yy8G0N9pM2ZA59YDXQsUf1XX56m37fV5 LCkSbdfBNVJcWZJTczrTZIq+JdGT0hwiaQISd7QCVAQ78/X1k+en8Tzbo35+KOdB FjDu4xjCA9H2W9MVK6ztBJNcfF0P/5dA57v0BFiEn/+BxNhGizv74joI3dcctP4L A1d83xIm6AodmbaG1Rvgbx48uU0BSZj3vK3POqEoHQ2b4OCITwQYEQIADwUCST// sQIbDAUJACTqAAAKCRDElT8+Z8sSYgE4AKCao/vj8qRc4Egxh7R+xKBRUhMLsACf S82/N6RTpAqhnFrj1WAqa+72eHk= =n/Xz -END PGP PUBLIC KEY BLOCK- -- "Elvis is my copilot." Cal Keegan Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 23 2008, Steve Langasek wrote: > On Sun, Nov 23, 2008 at 03:13:38PM -0600, Manoj Srivastava wrote: >> On Sun, Nov 23 2008, Steve Langasek wrote: > >> > On Sun, Nov 23, 2008 at 02:21:47PM -0600, Manoj Srivastava wrote: >> >> The constitution does not give release teams the powers to >> >> override the foundation documents, so the release team can not ignore >> >> SC violations. > >> >> I can make a formal interpretation of the constitution, if you >> >> wish. > >> > 3. Individual Developers >> > 3.1. Powers > >> > An individual Developer may > >> > 1. make any technical or nontechnical decision with regard to their >> > own >> > work; > >> Does that mean I can just ignore the DFSG in my packages, and no >> one can override that? I don't think so. > > No, it means that the *secretary* doesn't have special powers to > decide the DFSG has been violated and a remedy is in order. I do not. All I have the power to decide is how the vote is conducted. > We have lots of other structures in place to override developers when > we think they've made a decision that's wrong: the ftp team can remove > packages from the archive; the release team can refuse to release the > package; the TC and the developers can override the decision via the > documented processes in the constitution. The secretary is not, and > should not be, one of the parties with power to directly override > decisions made by developers, no matter how improper you might think > they are. I am not overriding any decision. I am just creating a ballot in the best means I can see, based on my understanding of the foundation documents. I am not going to do something I consider unethical just because other office bearers can correct things, or take up the slack. The release team can release whatever they please. I am not modifying dak. Their decision can still be overridden. But the proper form of the ballot is my responsibility, and I am not going to shirk it. You think I am wrong in the decision, ok. I think the release team and the kernel team were wrong too. I am not interfering with the kernel image packages (though I do have a certain affinity to them -- the very first auto generated kernel image package was created by me; they were hand made prior to that). Bur as a secretary, I have obligations, to the constitution, the project, and end users, whose rights ought not to be trampled by non-free crap. >> > And the DFSG is not a "decision properly made under [the rules of the >> > constitution]" because the DFSG predates the constitution and has >> > never been amended or re-confirmed by General Resolution. >> > (2004/vote_003 only amended the text of the Social Contract, not the >> > DFSG.) So there's no way that the constitution gives you special >> > authority in disputes over interpretation of the DFSG, either. > >> The constitution has wording on what the foundation documents >> are, and how they can be overridden. I am interpreting the constitution >> when it comes to my role, to the best of my ability to do so. > It has language about how the foundation documents can be > *superseded*. If you had meant to say "overridden", you should have > written that when proposing the GR for 2003/vote_0003, instead of > claiming after the fact that "supersede" implies "override". I maintain that supsersede and override have no distinction, as far as I interpret the constitution here. If you think that there should be a distinction, and the constitution needs to be clarified, you know where to start the process. > The Debian Project did not ratify any statement about the circumstances > under which the foundation documents can be overridden or ignored. That > doesn't mean overriding the DFSG is *ok*, but it does mean that if you > assert /in your role as secretary/ that a particular action taken by a > developer is a violation of the DFSG or SC and therefore not permitted, > you're legislating from the bench, which harms the integrity of the office > of Project Secretary overall. > >> > (Even if it had been ratified by GR, I find the claim that the Secretary's >> > powers include deciding whether a developer is "working against" a >> > constitutional decision to be dubious at best.) > >> I can only say what the constitution does or does not allow, and >> what powers the constitution confers on people. I have no idea of >> people are working against the constitu
Re: call for seconds: on firmware
On Sun, Nov 23 2008, Pierre Habouzit wrote: >> On Sun, Nov 23, 2008 at 07:43:05PM +, Manoj Srivastava wrote: >>> On Sun, Nov 23 2008, Pierre Habouzit wrote: >> >> I think the primary question that started this line of proposals >> was how to resolve the presence of allegedly sourceless firmware in the >> kernel image. Some of the solutions to that issue have longer term > > No it's not, the original question was "do the release team has powers > to decide that it's okay to ignore DFSG violations for a release". The > firmware discussion came _then_. The answer is simple: the constitution gives them no powers to override the foundation documents on their own. Since all powers to the delegates flow from the constitution, that is that, no? >> > I have a problem with that. Only (4) is _really_ actively taking sides >> > on that. All the other votes are completely unrelated to the Release >> > Team decision. >> >> I think we need to resolve what to do with lenny first: and if >> it is to let the release team have to power to decide whether possible >> DFSG/GPL violations can be present in the Debian system is one way of >> resolving this. > > No, we need what to do with the process of releasing first. To me, the > questions of endorsing the RT or not, and delaying the release or not > are one and the same, and are completely distinct from the sourceless > firmwares issues in Debian, even if loosely correlated. And again, the > releasing issues _HAVE COME FIRST_, and are the very source of all the > rest. It's just that I feel that _you_ don't care about that, just about > the firmware issues. I'm annoyed you don't see other people see two > different problems here. I think there is little non-technical blocking the release apart from the firmware issue. There is no reason to delay the release (apart from the RC bugs) than firmware in Debian (which is not being counted as RC, since it has been downgraded) >> > I feel there are two votes, the one about Should we release with or >> > without the firmware issues, which de facto endorse or rescind the >> > Release Team decision, and the rest. >> >> What is the rest? At this point, I see no options on >> the ballot which will _not_ resolve the Lenny release issue. > > For *'s sake Manoj, have you read what I wrote ? There is no sane > way to decide that the release team was right to lenny-ignore those > bugs but _still_ reaffirm that the sourceless firmwares are still not > OK as a general rule. This is a valid opinion, and I believe it > concerns a fair amount of people in Debian, at least it's what past > votes show unambiguously. I feel those people are betrayed. And FWIW > I'm not one of them, I'm objectively opposing your choice here, not > preaching for my church. I guess I am obtuse, since I am still not seeing it. a) No delegate can just ignore the foundation documents constitutionallyy. b) If the release team is correct, then there is no DFSG violation, and the sourceless firmware in testing are rightly there. c) If the sourceless firmware is not OK, then how can the release team have been right? > huh, no that option rescind the RT decision. We didn't decide having > sourceless firmwares was not a DFSG violation, we decided it was not > critical enough to delay the release for that since the project stated > that twice already. No. The first time, we decided to bring back the old social contract for sarge, that did not say Debian was 100 % free. After releasing Sarge, we made the change. *THE RELEASE DID NOT VIOLATE THE SOCIAL CONTRACT AS IT STOOD* The second time, we said the firmware must comply with the DFSG. That meant, in practice, that the formware was considered to be in compliance with the GPL, and thus the preferred form of modification -- and no one could _prove_ otherwise. *THE RELEASE DID NOT VIOLATE THE SOCIAL CONTRACT AS IT STOOD* >> > So tying the "allow firmware without / with source" or whatever change >> > related to that, _with_ the question about "what we do for lenny" are >> > definitely a bad mix that sounds rather unfair and blocking people from >> > at the same time not wanting to slow the release for this issue, but >> > still confirming sourceless firmwares in main are against their >> > interpretation of the DFSG. >> >> I take it you do not think option 2 meets this goal, which says >> that for Lenny we shall ignore possible DFSG violations in the
Re: call for seconds: on firmware
On Sun, Nov 23 2008, Steve Langasek wrote: > On Sun, Nov 23, 2008 at 02:21:47PM -0600, Manoj Srivastava wrote: >> The constitution does not give release teams the powers to >> override the foundation documents, so the release team can not ignore >> SC violations. > >> I can make a formal interpretation of the constitution, if you >> wish. > > 3. Individual Developers > 3.1. Powers > > An individual Developer may > > 1. make any technical or nontechnical decision with regard to their own > work; Does that mean I can just ignore the DFSG in my packages, and no one can override that? I don't think so. The constitution and ther foundation documents limit the powers we have; and allowing non-free crap does not seem like a "technical" decision to me. Sounds more like a non-technical social decision. > The Secretary is not the Release Team's keeper. No. The secretary just decides on their own things under their purview. I am not, if you notice, hacking dak. > And the DFSG is not a "decision properly made under [the rules of the > constitution]" because the DFSG predates the constitution and has > never been amended or re-confirmed by General Resolution. > (2004/vote_003 only amended the text of the Social Contract, not the > DFSG.) So there's no way that the constitution gives you special > authority in disputes over interpretation of the DFSG, either. The constitution has wording on what the foundation documents are, and how they can be overridden. I am interpreting the constitution when it comes to my role, to the best of my ability to do so. > (Even if it had been ratified by GR, I find the claim that the Secretary's > powers include deciding whether a developer is "working against" a > constitutional decision to be dubious at best.) I can only say what the constitution does or does not allow, and what powers the constitution confers on people. I have no idea of people are working against the constitution or not. >> > Even if some people think that set of choices is nonsensical, my >> > understanding of the current situation is that the release team has >> > ruled, as DPL delegates, that the current situation does not violate >> > the SC sufficiently to warrant removing the relevant packages from > >> I do not think that the constitution allows for >> "sufficiently". You can't supersede a foundation document "in a minor >> way" without a super majority vote. > > "supersede" means "replace with a newer revision". The Release Team hasn't > proposed doing anything of the sort. Overriding parts of the foundation documents as you please is tantamound to, and generally indistinguishable from, replacing the document (perhaps temporarily) with a new version. When I wrote that proposal, this is what I did have in mind. manoj -- Where love is there is no labor; and if there be labor, that labor is loved. Austin Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vote pages up
On Sun, Nov 23 2008, Lucas Nussbaum wrote: > On 23/11/08 at 11:29 -0600, Manoj Srivastava wrote: >> Hi, >> >> Pages of the two issues currently under discussion are now >> available (I'll note that none of the proposers ever turned in any wml >> for their proposals, so this was done by the Secretary and asst >> secretary). These pages, because of an undiagnosed bug, do not turn up >> on the navigation bar on the left. >> http://www.debian.org/vote/2008/vote_002> >> http://www.debian.org/vote/2008/vote_003 > > For vote 002, why did you decide to list the two additional options I > proposed as amendements, rather than proposals (like you did in vote > 003)? The alternate proposals don't intend to amend the initial > proposal, but to replace it, so it seems misleading to list them as > amendements. > > Or am I missing something? Well, the votes are being run by two different people, and perhaps we reached two different decisions about the text on the vote page? (I personally do not think the difference affects anything). manoj -- If only one could get that wonderful feeling of accomplishment without having to accomplish anything. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed wording for the SC modification
On Sun, Nov 23 2008, Steve Langasek wrote: > On Mon, Nov 17, 2008 at 09:29:06AM -0600, Manoj Srivastava wrote: >> On Mon, Nov 17 2008, Stephen Gran wrote: > >> > This one time, at band camp, Josselin Mouette said: >> >> Le lundi 17 novembre 2008 à 14:05 +0100, Peter Palfrader a écrit : >> >> > This is not part of my GR as proposed and seconded. > >> >> The Secretary made it clear that if your proposal wins, the SC *will* be >> >> amended. > >> > As has been pointed out elsewhere, the Secretary's job is to interpret >> > the constitution, not the SC. I'm not convinced that the secretary can >> > mandate that a GR changes the SC. > >> I think the only way to reconcile the constitution with the GR >> is to have a 3:1 vote, and subsequently to modify the foundation >> document. We can't just supersede a foundation document otherwise. > > The parsimonious approach here would be for the secretary to state that a > given resolution is non-binding unless it includes a patch to the DFSG and > passes with a 3:1 majority, instead of unilaterally deciding to rewrite the > DFSG with text that has not been proposed and seconded as part of a > resolution. Sure. That is an option. I kinda like the constitution/bill of rights variation, where we append the GR that passed with 3:1 to the end of the foundation document, so that action can happen immediately, and not wait until we get around to debating on the actual wording and such. Parsimony is nice, if minimality was the goal. It seems to me that people just want something getting done more than just minimal action. This way, we can actually propose and second an editorial change to the foundation document at our leisure. manoj -- Krogt, n. (chemical symbol: Kr): The metallic silver coating found on fast-food game cards. Rich Hall, "Sniglets" Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 23 2008, Russ Allbery wrote: > Manoj Srivastava <[EMAIL PROTECTED]> writes: > >> The release team is free to interpret the SC and decide there is >> no violation there (as long as they have a rationale, defensible >> position, etc). That would not violate the constitution. > > My understanding is that that's exactly what they did, and that's what my > post was trying to say. That would make FD mean N-N-R-N-N, yes? No. That would mean that FD *decided* it. That is not the case, FD leaves the decision to release in the hands of the release team (modulo the foundation documents), and they are allowed to change their minds. Hence, FD/? == RN decides the release schedule. manoj -- "NASA Announces New Deck Chair Arrangement For Space Station Titanic." Tom Neff Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 23 2008, Russ Allbery wrote:
> gregor herrmann <[EMAIL PROTECTED]> writes:
>
>> In order to make it easier for me and maybe others I'm trying to compact
>> them into a single table below (the FD column is from Russ' followup
>> mail to -vote).
>>
>> v Consequence / Proposal > | 1 | 2 | 3 | 4 | 5 | 6 | FD
>> ---|---|---|---|---|---|---|---
>> i require source for firmware in main| Y | N | N | N | Y | N | Y
>> ii allow Rel.Team to ignore SC violation bugs | N | N | N | Y | N | N | N
>> iii What do we do for Lenny| W | R | R | R | R | R | W
>> iv modify foundation documents| N | N | N | Y | N | Y | N
>> v override foundation documents | N | Y | Y | N | N | N | N
>> ---|---|---|---|---|---|---|---
>> Y(es) N(o) R(elease) W(ait)
>
> I'm pretty sure from the further analysis, and I think Manoj
> confirmed,
I did not.
> that FD is N-N-R-N-N.
I think it is Y-N-?-N-N. (personally, I think my interpretation
of the SC is ? == W, but I can't say that as secretary). The ? is to be
resolved depending on whether the firmware blobs violate the DFSG or
not (are they the preferred form of modification?).
The constitution does not give release teams the powers to
override the foundation documents, so the release team can not ignore
SC violations.
I can make a formal interpretation of the constitution, if you
wish.
> Even if some people think that set of choices is nonsensical, my
> understanding of the current situation is that the release team has
> ruled, as DPL delegates, that the current situation does not violate
> the SC sufficiently to warrant removing the relevant packages from
I do not think that the constitution allows for
"sufficiently". You can't supersede a foundation document "in a minor
way" without a super majority vote.
> main or delaying the release (this is not the same thing as ignoring
> SC violation bugs under the project governance process). In the
> absence of an override of that delegate decision, it stands.
I do not think that statement is in compliance with the
constitution.
The release team is free to interpret the SC and decide there is
no violation there (as long as they have a rationale, defensible
position, etc). That would not violate the constitution.
They can't just decide, yeah, it violates the SC, but not very
much, so let us go ahead.
manoj
--
Stupidity, like virtue, is its own reward.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vote pages up
On Sun, Nov 23 2008, Steve McIntyre wrote:
> Hi Manoj,
>
> On Sun, Nov 23, 2008 at 11:29:51AM -0600, Manoj Srivastava wrote:
>>Hi,
>>
>>http://www.debian.org/vote/2008/vote_003>
>>For vote 003, if the proposers want to set up a page of
>> rationale, to help guide voters through their proposals, please send
>> me wml/html in the next couple of days, and I'll create a composite
>> page for the rationale for various proposals, with the impact table I
>> have been sending in email.
>
> It would be clearer if you matched the "proposal" and "choice"
> terminology, I think: at the moment, you have "proposal A" and "choice
> 1", for example.
Actually, proposal A is choice 2.
The thing is, the webwml convention is to go:
Proposal Choice 1
ProposalA Choice 2
ProposalB choice 3
.
I suppose I can just ignore the first proposal section.
Will do.
manoj
--
So live that you wouldn't be ashamed to sell the family parrot to the
town gossip.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 23 2008, Pierre Habouzit wrote: >> On Sun, Nov 23, 2008 at 06:29:26PM +, gregor herrmann wrote: >>> On Sat, 15 Nov 2008 09:45:56 -0600, Debian Project Secretary wrote: >>> Since some people have had trouble reading the proposals, I am >>> including a short impact of the proposal list below the proposal. >> Thanks for listing the consequences of the different choices. >> In order to make it easier for me and maybe others I'm trying to >> compact them into a single table below (the FD column is from Russ' >> followup mail to -vote). >> v Consequence / Proposal > | 1 | 2 | 3 | 4 | 5 | 6 | FD >> ---|---|---|---|---|---|---|--- >> i require source for firmware in main| Y | N | N | N | Y | N | Y >> ii allow Rel.Team to ignore SC violation bugs | N | N | N | Y | N | N | N >> As a side note: >> I guess what makes this vote confusing (at least for me) is that we >> try to answer several questions (roughly equivalent to the >> consuequences) in one vote ... I think the primary question that started this line of proposals was how to resolve the presence of allegedly sourceless firmware in the kernel image. Some of the solutions to that issue have longer term impact, and could be considered on their own merit. However, since they also solve the Lenny issue, I think they belong on this ballot; since we can resolve about one way to solve Lenny, and then we get a second chance to come to a different (and conflicting) resolution about Lenny by the second or third votes. > I have a problem with that. Only (4) is _really_ actively taking sides > on that. All the other votes are completely unrelated to the Release > Team decision. I think we need to resolve what to do with lenny first: and if it is to let the release team have to power to decide whether possible DFSG/GPL violations can be present in the Debian system is one way of resolving this. > I feel there are two votes, the one about Should we release with or > without the firmware issues, which de facto endorse or rescind the > Release Team decision, and the rest. What is the rest? At this point, I see no options on the ballot which will _not_ resolve the Lenny release issue. > Mixing the two issues suck badly, because I believe that the project at > large would want to allow the release team to ignore the firmware bugs > for the release (hence endorsing our choice), while there is no > consensus on the firmware source issues. At least I _believe_ it's where > the project stands, and it did, twice, in the past. The project can say so again. Option 5 is defined for that; which essentially says that the project allows people to say release Lenny as long as there are no proven DFSG violations. > So tying the "allow firmware without / with source" or whatever change > related to that, _with_ the question about "what we do for lenny" are > definitely a bad mix that sounds rather unfair and blocking people from > at the same time not wanting to slow the release for this issue, but > still confirming sourceless firmwares in main are against their > interpretation of the DFSG. I take it you do not think option 2 meets this goal, which says that for Lenny we shall ignore possible DFSG violations in the kernel? Or Option 5, which says we'll not hold up the release for things we just suspect are DFSG violations? Even option 3 allows us to just ignore the DFSG violations for the release. Would you just want to add something that just says "We like to say that we do not like sourceless firmwares in main, except when it come to releases, and then that is fine" to the proposals 2 and 3? I am unable to see the distinction between what you seek and options 2/3. manoj -- The shortest distance between two points is under construction. Noelie Alito Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Vote pages up
Hi, Pages of the two issues currently under discussion are now available (I'll note that none of the proposers ever turned in any wml for their proposals, so this was done by the Secretary and asst secretary). These pages, because of an undiagnosed bug, do not turn up on the navigation bar on the left. http://www.debian.org/vote/2008/vote_002 http://www.debian.org/vote/2008/vote_003 For vote 003, if the proposers want to set up a page of rationale, to help guide voters through their proposals, please send me wml/html in the next couple of days, and I'll create a composite page for the rationale for various proposals, with the impact table I have been sending in email. manoj -- O'Reilly's Law of the Kitchen: Cleanliness is next to impossible Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Resolving the controversy
On Sun, Nov 23 2008, Josselin Mouette wrote: > This is not a personal attack. You are spreading lies implying no one is > working on these bugs while YOU are the one discouraging people to work > on them. Again, please stop your lies, and if you really want to help, > please stop all of your contributions to Debian mailing lists as their > net result is currently demotivating the people who work the most on the > issues you actually care about. I must confess to also feeling demotivated by emails like this. manoj -- You don't have to wait--you can have it in 5.004_54 or so. :-) Larry Wall in <[EMAIL PROTECTED]> Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Resolving the controversy
On Sun, Nov 23 2008, Josselin Mouette wrote: > Le samedi 22 novembre 2008 à 19:49 -0600, Manoj Srivastava a écrit : >> Could you take this tone away from -vote, please? > > Manoj, please don’t take this personally, Then do stop attacking the man, as this email does right now, recognize that argumentum ad hominem is a logical fallacy, and desis from personalizing things, if you do not want people to take things personally. Getting uncivil and confrontational does not improve the mailing list, and is not beneficial to the project. > but I don’t think you are qualified to tell what is an appropriate > tone for a discussion. While I might think this is pot calling kettle black; that is immaterial. Unless your argument is that I am wrong and the silent majority is in favour of mud slinging and personal attacks on the mailing list, you are definitely in the wrong when promoting confrontation and personal attacks as acceptable on the mailing list. We can, of course, involve the mailing list managers, but I had hoped that we could return to civil discourse without the heavy stick of the managers reproof. manoj -- Thufir's a Harkonnen now. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Resolving the controversy
On Sat, Nov 22 2008, Sandro Tosi wrote: > Really? you didn't explain why; what I'm asking is what you did to fix > the bugs you believe to violate your interpretation of DFSG. That's my > point (dunno what you understood) If you want to see what kind of work some DD is doing, can you take it to private email instead? >> matter, and I'll ask you to kindly stop attacking people instead of >> arguments. > > is this your argumentation? It is mine. Pleas take all argumentum ad hominem off the debian-vote mailing list. >> If all you're interested in doing is demanding my credentials and >> painting me as an outsider, I don't think this contributes to the >> discussion at all. > > It contributes a lot! experience gives new points of view. I don't think it matters. You should be looking at the arguments being made, not the people who are making them. The discussion ought to stand on its own merit, argument by authority is not something to strive for. > Months are passed and the situation is the same: talk with you is like > talking to walls. I'm going back to ignore you again, like many others > do, sorry. I am afraid that if you persist in this line of attacking people rather than their arguments, I might be forced into a similar opinion. manoj -- Lockwood's Long Shot: The chances of getting eaten up by a lion on Main Street aren't one in a million, but once would be enough. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Resolving the controversy
On Sat, Nov 22 2008, Josselin Mouette wrote: > Le dimanche 23 novembre 2008 à 00:09 +1100, Ben Finney a écrit : >> You seem to have missed what I said: In order to have *anyone* fix >> them, they need to be acknowledged as DFSG violations. > > Would you please stop your lies and go trolling elsewhere? Please? Could you take this tone away from -vote, please? If you disagree with a statement, it is no excuse to accuse the people whose opinions you disagree with liars. > Happily the Debian kernel maintainers haven’t been waiting for you to > fix such bugs. It appears to me that while Ben Hutchings did do the work to fix the DFSG violations, the kernel team has opted not to accept the work, at least for Lenny, and thus your statement seems not to reflect reality as I see it. Am I mistaken? manoj Note: I did not call you a liar -- Words can never express what words can never express. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Resolving the controversy
On Sat, Nov 22 2008, Sandro Tosi wrote: > Really? so can you please show us what you've done to fix them? >> Note that we can both have what we are asking for: discussing a >> general resolution does not preclude working to improve Debian. > > Sure we can, then why don't do both instead of just writing emails? I do not think that we have made it a requirement that only people who work on a task are allowed to speak about it. If we did, we could never take user fedback, which, it seems to me, would be violating the SC. So demanding people must do some work or else they must shut up is adding negative energy into the discussion, could you please stop? Or take it away from -vote, which is meant to be free of flames and have healthy discussion of the issues we are trying to resolve? manoj -- Beware of friends who are false and deceitful. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Resolving the controversy
On Sat, Nov 22 2008, Sandro Tosi wrote: > On Sat, Nov 22, 2008 at 10:34, Ben Finney <[EMAIL PROTECTED]> wrote: >> Jacob Hallén <[EMAIL PROTECTED]> writes: >> >>> The first paragraph of the SC is a lie! >> >> I wasn't lying when I agreed to that. > > And what changed in the Debian Project if you agree to it or not? While I find your tone far too confrontational, I'll do you the courtesy of answering politely. Ultimately, what the Debian project does, as a whole, is hte sum of what the individual members believe. And if we all do not have the same interpretation abd beliefs, the stance of the Debian project is, well, a composite, of sorts, of individual beliefs. >>> Debian is not 100% free software, and it never has been. >> >> Indeed. Those instances where it's not free are bugs to be fixed. > > So, you actually wanna do something to fix those bugs or wanna simply > talk about them? I think we should indeed fix them. And we should not really release a stable version with known DFSG violations in it. > > I see too many emails sent and too few RC bugs fixed. If you (like > others) would really work for Debian instead of only filling lists.d.o > archives, Debian would be a better distribution, Which, I suppose, goes for you too. > but maybe it's not in your interest. While unnecessarily confrontational, and, in a sense, attacking the man, not the idea, (which is a logical fallacy in any argument) I guess this goes for you as well. Indeed, more so, since impolite emails are likely to cause even more time spent other than fixing bugs. Can we please stop these "in your face" emails, and return to civil discourse, or, failing that, not post at all? manoj -- "An ounce of prevention is worth a ton of code." an anonymous programmer Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18 2008, Luk Claes wrote: > Note that firmware is no program AFAICS... I do not think I agree. I think it is indeed a software program, and I am not alone: ,[ http://en.wikipedia.org/wiki/Computer_software ] | Firmware which is software programmed(sic) resident to electrically | programmable memory devices on board mainboards or other types of | integrated hardware carriers ` Frankly, a software program may be loaded into parts of the computer heavily dependent on the processor that will run the program instructions; the processor can be designed to read instructions from core memory, magnetic tape, field programmable gate arrays, hardware registers . Putting in hardware design details into foundation documents seems weird; and as the number of processors and cores explode, with new GPU's (which used to be video cards) now being able to perform computations for the so called "central" processor, the boundary between computations performed on the multiplying number and kinds of processors in a computer is going to get rapidly blurred. The DFSG has lasted us oer a decade. In another decade, I think the distinction of "central" and "periphery" and "Cell" processors is likely to erode; and our DFSG definition should be forward looking. manoj -- It is better to be bow-legged than no-legged. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18 2008, Johannes Wiedersich wrote: > Manoj Srivastava wrote: >> On Tue, Nov 18 2008, Johannes Wiedersich wrote: >> >>> Ben Finney wrote: >>>> The Debian system we provide is usable. There may be devices which are >>>> not yet operable with Debian, >>> Which wireless card is supported by debian without any sourceless >>> firmware, either loaded by the kernel or present on the chip? >> >> The latter is not a concern. See, the SC says that non-free junk >> should not be in main; it can be elsewhere. So, the user is free to use >> non-free firmware -- so if the user acquires it along with the >> hardware, we don't care. > > According to the SC yes. But I can't see the reasoning behind the > argument that firmware loaded on boot is 'evil' and the corresponding > hardware should not be supported while the same firmware is 'good' when > it is already present on boot and not re-loaded. It is not good. It is still non-free. Debian should distribute neither. Since Debian does not currently distribute hardware, we do not have to worry about the latter. The fact that users might use non-free junk is their business. Debian should not be an enabler in taking away users freedoms -- if they do so on their own it is their business. So the SC says Debian shall not have non-free junk. If the users obtain the non-free crap (say, embedded in hardware or from the non-free repo), we shall support their decision. > Arguably hardware, that loads firmware on boot, has the advantage, that > programming errors or security holes can be patched, while those with > code on flash can't be patched. It seems ridiculous, if Debian supports > the latter and leaves users of the former out in the cold. So some means of getting non-free junk are more secure than other means of getting non-free junk. However, since there is no source, the users can't do any learning or fixing themselves -- that freedom is not given to them. So, we should not stand in the way of users getting non-free junk however they want. We just do not distribute it in Debian. >> The SC only talks about what is part of the Debian system. We >> also say people might need non-free stuff, and we put that in a special >> area on our archive. > > There should be a distinction between 'non-free' software that is part > of the OS or part of user applications and firmware that is just loaded > for peripherials. These are completely different cups of tea. Why? I see no rationale why only some freedoms are important. I think that being able to change stuff in how my iwlwifi works would be nice, as long as I continue to conform to the laws of the land. >>> Would you imply that wireless networking should never be usable by >>> debian users, if it turns out that publication of sourcecode is illegal >>> in countries like the US or the EU? (Modifications of the firmware are >>> probably illegal, because they can modify the electromagnetic emission >>> of the devices, potentially killing people around it.) >> >> Strawman. Debian users like me do use nvidia, and iwlwifi, even >> though my iwlwifi driver uses firmware not in Debian (it is in >> non-free). > > I have no doubt that savvy developers like all on this list will know > how to deal with this. Let me be the advocatus of a 'normal user' who > does not _want_ to be bothered by googling his way out of all the little > obstacles to her/his debian installation... Sorry. The free distribution does mean that you need to either w buy hardware supported by free software, or learn how to feed your non-free habit by yourself. We might make it easy for you to feed your non-free habit, which is why we have the non-free area of the archive. d-i already allows you to feed it your non-free junk. I think that is plenty support. > (googling the network card won't work, unless it works already, by the > way... > There are users with just on PC and no other network connection for a > 'sneaker net'. They have the recommended net-install of d-i, but their > card requires firmware. What now? As you stand, debian just won't > support them. You are basically telling them: buy and use a non-free OS > in order to download the firmware necessary to install a free OS. ) > >> So, I could not install this laptop over wifi. Now a big deal -- >> I installed it over a wired LAN, and I suppose I could have done >> sneakernet itself. I do not think that the hassle was worth sacrificing >> Debian's principles for. > > Yes, big deal: the wired LAN
Re: call for seconds: on firmware
On Tue, Nov 18 2008, Martin Wuertele wrote: > * Manoj Srivastava <[EMAIL PROTECTED]> [2008-11-18 14:47]: > >> On Tue, Nov 18 2008, Martin Wuertele wrote: >> >> > * Lars Wirzenius <[EMAIL PROTECTED]> [2008-11-17 19:31]: >> > >> >> (Quote attribution elided on purpose.) >> >> > Stop your FUD. >> >> > >> >> > The Release Team isn't violating the Social Contract. >> >> >> >> It is my opinion that releasing lenny with known DFSG violations is a >> >> violation of the Social Contract, on the part of the project as a whole, >> >> regardless of which individuals are making the decisions. >> > >> > Did you ever read SC #4? It's a violation of the SC to not provide our >> > users with a usable system. >> >> I do not think you have read 4 and 5 together. >> >> 4. Our priorities are our users and free software > > [..] > >> 5. Works that do not meet our free software standards > > [..] > >> So, SC says we know our users might need non-free crap, and we >> shall give it to them, in `contrib' and `non-free' areas in our >> archive. > > That still doesn't conclude that releasing Lenny with propable issues > violates the SC. As already pointed out why should hardware that loads > firmware blobs from flash be treated different than hardware loading > the blob from a filesystem. One could conclude that even Intel CPUs > are non-free while UltraSparcs are DFSG-free placing amd64 and i386 > outside main. It is no different. Debian should be distributing neither. We should not get in the way of the user getting their non-free crap from elsewhere (even embedded in their hardware, or on a usb stick from non-free), but neither should be in Debian main. If you find hardware with embedded software in Debian main, please let me know. I know people who relish downloadable hardware, it feeds their SCI-FI fetishes. manoj -- He who takes nothing in the world that has not been given him, long or short, big or small, attractive or that is what I call a brahmin. 409 Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18 2008, Johannes Wiedersich wrote: > Ben Finney wrote: >> The Debian system we provide is usable. There may be devices which are >> not yet operable with Debian, > > Which wireless card is supported by debian without any sourceless > firmware, either loaded by the kernel or present on the chip? The latter is not a concern. See, the SC says that non-free junk should not be in main; it can be elsewhere. So, the user is free to use non-free firmware -- so if the user acquires it along with the hardware, we don't care. The SC only talks about what is part of the Debian system. We also say people might need non-free stuff, and we put that in a special area on our archive. > Would you imply that wireless networking should never be usable by > debian users, if it turns out that publication of sourcecode is illegal > in countries like the US or the EU? (Modifications of the firmware are > probably illegal, because they can modify the electromagnetic emission > of the devices, potentially killing people around it.) Strawman. Debian users like me do use nvidia, and iwlwifi, even though my iwlwifi driver uses firmware not in Debian (it is in non-free). So, I could not install this laptop over wifi. Now a big deal -- I installed it over a wired LAN, and I suppose I could have done sneakernet itself. I do not think that the hassle was worth sacrificing Debian's principles for. manoj -- A kiss is a course of procedure, cunningly devised, for the mutual stoppage of speech at a moment when words are superfluous. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed wording for the SC modification
On Tue, Nov 18 2008, Raphael Hertzog wrote: >> On Mon, 17 Nov 2008, Antti-Juhani Kaijanaho wrote: >>> On Mon, Nov 17, 2008 at 09:14:41PM +0100, Raphael Hertzog wrote: >> > The foundation documents are like the law. This GR is like a "decree of >> > the government" that tells us how the law will be applied. >> >> A decree of the government does not do that. It gives supplemental rules and >> regulations compatible with the law (and generally requires a specific >> authorization in the law, but this varies from jurisdiction to jurisdiction). >> >> In any case, GRs are law, not decrees. The proper analogy for a decree would >> be a Project Leader or Delegate decision. > > Analogies do have limits of course but you get the meaning and I stand > behind my logic. In our case the developer body has the right to rule > on anything: change the law (parliament), change a delegate's decision > (override the government), decide of sanctions (justice, we never did it > fortunately) and any analogy with a country will fail due to that. I actually reject your logic, and I believe that Antti-Juhani interpretation is closer to mine. > However, here we have delegates (the RM) that have taken a decision > and someone believes that the decision was wrong and want to override > it. Instead of voting on that (and then creating a sort of > "jurisprudence") we came up with explanations on how the > firmwares should be handled and for me this is exactly like > a decree that fills the hole (maybe unintentionaly in our case, > intentionaly in real cases probably) that were left in the law. I believe that a decision which contradicts a foundation document can't just be rationalized away; you need to change the foundation document if you do not wish to follow it, or you believe the contradiction is the result of an "unintended" hole. I do not believe that saying Debian shall be 100% free or that programs need source code was a mistake. >> > If the GR doesn't explicitely state that it modifies a foundation >> > document, then it doesn't. If you believe that it does implicitely, then >> > you vote against it (or propose an amendment where you explicitely modify >> > the document). >> >> The Project Secretary is charged with conducting General Resolution >> votes, and with judging disputes in the application of the >> Constitution. As such, the Project Secretary is not really a >> secretarial position - the best analogy is a chairperson of a >> decision-making body. >> As such, I believe it is the Project Secretary's duty (not a right, >> but duty) to ensure that any proposals and amendments are compatible >> with the Constitution, and it is also the Project Secretary's duty to >> refuse to conduct a vote he believes to be contrary to the >> Constitution. > > Like has already been said elsewhere, he applies the constitution and has > to interpret it. I don't believe that it is his role to interpret the > SC/DFSG and decide if a resolution is compatible. We have all agreed > to defend the SC/DFSG but obviously we do have differing ways to interpret > them and so does the secretary, he should not get a special power here. > The developer body decides if a resolution is compatible or not with > our foundation documents when they vote on it. I don't get a special power here. I cannot change dak or britney and decide what goes into the archive or whatr transitions from Sid to Lenny. I have powers only about the composition of the ballot, and a duty to run votes in a manner compatible with the constitution. And, to me, the constitution and the SC are pretty clear, and I am acting in accordance to them. > If the secretary can't be convinced with this discussion, maybe we should > aim at clarifying this in the constitution itself. That would be fine. manoj -- I'm a Lisp variable -- bind me! Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18 2008, Marc 'HE' Brockschmidt wrote: > Robert Millan <[EMAIL PROTECTED]> writes: >> On Mon, Nov 17, 2008 at 08:08:36AM +0100, Andreas Barth wrote: >>> Though I agree that the release team cannot put any foundation document >>> aside, I don't think the release team is overriding the social contract, >>> but chooses a certain interpretation (that I think is the correct one >>> btw). Other people obviously prefer a different interpretation, and so >>> the relevant question is: Whose interpretation is the binding one? >>> Currently, it seems to me that unless decided otherwise by a GR, the >>> release team has the final say (as explained by Russ). >> When you say "chooses a certain interpretation", are you referring to the >> one in which SC #4 is interpreted in a way that cannot be complied with no >> matter what, only to use this impossibility as proof that SC #4 and SC #1 >> contradict each other, and in turn resolving that because the SC is >> inconsistent, SC #1 is meant to be read "figuratively"? > > I discussed this with Andi in the past, so let me answer: From our point > of view, SC#4 is relatively clear: Our users need to be able to use a > stable release of Debian and the free software community (not "free > software"!) needs us to spread the use of _free_ software. > Driving off people to another distribution because we have found yet > another sequence of magic numbers that might, or might not, have source > code somewhere is a clear violation of SC#4 in our eyes. It is your Myopia about §5 that is distressing; you seem to selectively read the SC as it benefits your views. , | 5. Works that do not meet our free software standards | | We acknowledge that some of our users require the use of works that | do not conform to the Debian Free Software Guidelines. We have | created `contrib' and `non-free' areas in our archive for these | works. The packages in these areas are not part of the Debian | system, although they have been configured for use with Debian. We | encourage CD manufacturers to read the licenses of the packages in | these areas and determine if they can distribute the packages on | their CDs. Thus, although non-free works are not a part of Debian, | we support their use and provide infrastructure for non-free | packages (such as our bug tracking system and mailing lists). ` The SC never said that we include things that violate DFSG #2 , | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. ` to be in main; it even states that `contrib' and `non-free' areas in our archive have been designed for that. This selective reading of the SC is one reason I believe the release team is in violation of the social contract. manoj -- University: A modern school where football is taught. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18 2008, Martin Wuertele wrote: > * Lars Wirzenius <[EMAIL PROTECTED]> [2008-11-17 19:31]: > >> (Quote attribution elided on purpose.) >> > Stop your FUD. >> > >> > The Release Team isn't violating the Social Contract. >> >> It is my opinion that releasing lenny with known DFSG violations is a >> violation of the Social Contract, on the part of the project as a whole, >> regardless of which individuals are making the decisions. > > Did you ever read SC #4? It's a violation of the SC to not provide our > users with a usable system. I do not think you have read 4 and 5 together. 4. Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. 5. Works that do not meet our free software standards We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created `contrib' and `non-free' areas in our archive for these works. The packages in these areas are not part of the Debian system, although they have been configured for use with Debian. We encourage CD manufacturers to read the licenses of the packages in these areas and determine if they can distribute the packages on their CDs. Thus, although non-free works are not a part of Debian, we support their use and provide infrastructure for non-free packages (such as our bug tracking system and mailing lists). So, SC says we know our users might need non-free crap, and we shall give it to them, in `contrib' and `non-free' areas in our archive. Frankly, the fact you totally ignore §5 weakens your argument. manoj -- "Unibus timeout fatal trap program lost sorry" An error message printed by DEC's RSTS operating system for the PDP-11 Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
civility in discussions
Hi, Folks, calling people discussion here trolls or "lying, sniveling, unethical non-free lovers intent on destroying Debian's good name" does nothing to promote a decent discussion, and does not belong on this list, in my opinion. If you want to call people nasty names, take it off list, please. manoj -- Justice is incidental to law and order. Edgar Hoover Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
