From sundaram at fedoraproject.org Wed Oct 1 13:21:21 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 01 Oct 2008 18:51:21 +0530
Subject: PackageKit Codeina replacement and Fluendo
In-Reply-To: <78323d480809301551i48112608laa461f792f2c86b1@mail.gmail.com>
References: <78323d480809301551i48112608laa461f792f2c86b1@mail.gmail.com>
Message-ID: <48E37951.7070409@fedoraproject.org>
Mani A wrote:
> "Paul W. Frields" wrote
>> It may not be, but they will have the exact same chance as any other
>> third party to offer software through a repository. The bits in
>> Fedora will not send users anywhere, including there, preferentially.
>
> That is fine, but many newbie users will feel better if they are
> asked to use an Internet Search Engine for 'a suitable phrase',... if
> they really want to make use of such files. The default messages used
> in many applications has a wrong psychological impact (on newbies).
Asking users to suggest specific terms will likely lead to "contributory
infringement" charges.
Rahul
From poelstra at redhat.com Thu Oct 2 03:54:37 2008
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 01 Oct 2008 20:54:37 -0700
Subject: Fedora Board Recap 2008-SEP-30
Message-ID: <48E445FD.2050300@redhat.com>
https://fedoraproject.org/wiki/Board/Meetings/2008-09-30
== Roll Call ==
Attendees: John Poelstra, Jesse Keating, Karsten Wade, Bill Nottingham,
Matt Domsch, Chris Tyler, Seth Vidal, Paul Frields, Spot Callaway, Jef
Spaleta
Regrets: Harald Hoyer
== Followup to Previous Business ==
=== Codecs (2008-09-16) ===
* https://fedoraproject.org/wiki/Features/GStreamer_dependencies_in_RPM
* https://bugzilla.redhat.com/show_bug.cgi?id=438225
* Seth Vidal is going to meet with Richard Hughes to make sure a EULA
associated with a specific package or codec works correctly with
PackageKit and associated packages
* '''UPDATE 2008-09-23'''
** RESOLUTIONS
*# Fedora will '''only''' handle packages with EULAs through
PackageKit
*# Fedora does not foresee ever having packages in the official Fedora
repos that contain EULAs
** Remaining questions for follow-up:
*# What is the regular work flow for codecs in F10 when someone goes to
play a media file with a gstreamer enabled player?
*# What will be the default behavior for a default installation?
*# Can we confirm that we are no longer prompting for any specific vendor?
** Spot to track down answers to the remaining questions
* '''UPDATE 2008-09-30''' from Spot
** In a default, fresh F10 install, if you go to play an mp3 file with a
gstreamer enabled player, it will pop-up a helper
** On a default F10 system there will be nothing in the pop-up
** If you have an applicable third party yum repository configured, it
will find the packages that provide the missing codecs and install them.
** Codeina will NOT be installed by default and should be removed from
the Fedora 10 repository and obsoleted and blocked.
** There are no hooks to any third party vendors at this time.
** '''ACTIONS'''
*# Spot will talk with PackageKit upstream about finding a way to
included Fedora specific information which links to a Fedora wiki page
on Fedora's stance on third party codecs
*# Spot will work with package maintainer(s) to resolve the items noted
above related to codeina
=== Trademark Update (2008-09-16) ===
* Board wants to maintain a good hold on how the primary Fedora
trademark is used while provides lots of latitude for secondary mark
* Process of legal review continues and appears to be moving forward
favorably
* trademark guidelines draft has recently been updated and can be found
here: https://fedoraproject.org/wiki/User:Pfrields/NewTrademarkGuidelines
* '''UPDATE 2008-09-23'''
** Paul Frields has a meeting with with Red Hat legal this week
* '''UPDATE 2008-09-30'''
** Met with Legal this week
** Looking for a way to include language that accommodates appliance
operating systems (AOS) and qualified ISV applications
** Very close to having a finalized policy--review if you haven't done
so lately
*** https://fedoraproject.org/wiki/User:Pfrields/New_trademark_guidelines
** Working with community to come up with a term related to the
secondary trademark
*** Leaning towards using the term ''Fedora Remix''
** The secondary trademark will be a text based trademark
*** Requested Fedora artwork team help with stylizing the text
*** Working to clarify licensing of the image containing the
''wordmark'' design
== New Business ==
* fedora-advisory-board thread about multiple elections at the same time
**
https://www.redhat.com/archives/fedora-advisory-board/2008-September/msg00080.html
* The board thinks that having concurrent Fedora elections is a great
idea and supports it
* Have a "Fedora General Election" of sorts
* Could the marketing group help raise visibility within Fedora?
** Need a clear call to action
** Is there a way to collect questions and responses from the community
and candidates?
* '''ACTIONS'''
** Jef to take discussion to fedora-marketing-list brainstorming about
what could happen around vetting issues, debates, etc.
== Next Meeting ==
* Date: 2008-10-07
* Time: 18:00 UTC
* Location: irc.freenode.net
** Public channel to ask questions: #fedora-board-public
** Moderated channel for board answers: #fedora-board-meetings
** Board to only join moderated channel so as to focus discussion there
From jbwillia at math.vt.edu Mon Oct 6 19:42:43 2008
From: jbwillia at math.vt.edu (ben)
Date: Mon, 06 Oct 2008 15:42:43 -0400
Subject: New Fedora 9 Re-spins
Message-ID: <48EA6A33.704@math.vt.edu>
The Fedora Unity Project is proud to announce the release of new ISO
Re-Spins of Fedora 9.
These Re-Spin ISOs are based on the officially released Fedora 8
installation media and include all updates released as of October 4th, 2008.
The ISO images are available for i386, x86_64 architectures via Jigdo
and Torrent starting Tuesday October 7th, 2008.
Go to http://spins.fedoraunity.org/spins to get the bits!
DVD Media Only
Due to known problems in comps, this is a DVD Only Re-spin. The CD
version would have required all 6 to 7 discs to install.
Full Installation Problems if Language Support Groups Selected
Selecting some language groups will cause file conflict errors, such as
reported and explained in #465715
Thanks to
We would like to give a special thanks to the following for testing this
Re-Spin:
- Harley-D Dana Hoffman Jr
- zcat Jason Farrell
- vwbusguy- Scott Williams
- Southern_Gentleman Ben Williams
- kanarip Jeroen van Meeuwen
- baard1973 Stefan Hartsuiker
- troubi_51 Corentin Perard
Testing Results
A full test matrix can be found at our Test Matrix
A full list of bugs, packages and changelogs that have been updated in
this Re-Spin can be reviewed on
http://spins.fedoraunity.org/changelogs/20081004/
Previous Re-Spin (20080718) will expire
Due to limited resources, this spin will immediately obsolete 20080718,
which will be deleted from our mirrors in the next few days.
Fedora Unity has taken up the Re-Spin task to provide the community with
the chance to install Fedora with recent updates already included.
These updates might otherwise comprise more than 2.05GiB of downloads
for a full install.
This is a community project, for and by the community. You can
contribute to the community by joining our test process.
Go to http://spins.fedoraunity.org/spins to get the bits!
Assistance Needed
If you are interested in helping with the testing or mirroring efforts,
please contact the Fedora Unity team.
Contact information is available at http://fedoraunity.org/
or the #fedora-unity channel on the
Freenode IRC Network (irc.freenode.net).
To report bugs in the Re-Spins please use http://bugs.fedoraunity.org/
--
Ben Williams
Window-Linux Specialist
Mathematics Department-Virginia Tech
561E McBryde Hall
540 231-2739
From poelstra at redhat.com Wed Oct 8 02:03:09 2008
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 07 Oct 2008 19:03:09 -0700
Subject: Fedora Board Meeting Recap 2008-10-07
Message-ID: <48EC14DD.9010408@redhat.com>
Recap and full IRC transcript found here:
https://fedoraproject.org/wiki/Board/Meetings/2008-10-07
Please make corrections and clarifications to the wiki page.
== Codecs ==
* followup:
https://fedoraproject.org/wiki/Board/Meetings/2008-09-30#Codecs_.282008-09-16.29
* ACTIONS:
** spot - create the English page
** quaid (and/or spot) - assign a page name under fp.o and file a Trac
ticket at https://fedorahosted.org/fedora-infrastructure
** spot - give page to hughsie for PK inclusion
== Trademark Update ==
* followup:
https://fedoraproject.org/wiki/Board/Meetings/2008-09-30#Trademark_Update_.282008-09-16.29
* Paul had several discussions with RH's attorney responsible for TM issues
* Spot and Paul have a conference call with him and outside counsel
tomorrow afternoon.
* Counsel has seen They have seen the draft marks produced by Artwork
** https://fedoraproject.org/wiki/User:Pfrields/Secondary_trademark_design
* Spot and Paul will be hashing out the last of the issues with them,
including licensing for the secondary mark.
* It would be '''really''' helpful if the mark was freely licensed, i.e.
redistributable '''and''' modifiable
== Board Q&A ==
* Handling of respins and source
* See more details in IRC log
== IRC Transcript ==
From luis at tieguy.org Wed Oct 8 11:40:47 2008
From: luis at tieguy.org (Luis Villa)
Date: Wed, 8 Oct 2008 07:40:47 -0400
Subject: election software
Message-ID: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
Hey, all-
recently saw this: http://nigelj.livejournal.com/10507.html Can't
comment directly because I don't have an LJ account.
Elections are fairly serious, important business- much less so in a
community where elected representatives are the deciders of last
resort instead of first resort, but still. So I'd strongly recommend
using someone else's code that has been tested and reviewed for
security and correctness rather than writing your own. Two open
options are:
http://www.heliosvoting.org/
http://selectricity.org/
I realize Fedora has some unusual needs, and I appreciate the effort
Nigel has put in on this, but Fedora should strongly consider not
reinventing this particular wheel. Focus on the deliberative part of
what Nigel is working on (question tool, etc.) and leave the voting
part to those who have already worked on the problem extensively.
Luis
From stickster at gmail.com Wed Oct 8 12:21:44 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 08 Oct 2008 12:21:44 +0000
Subject: election software
In-Reply-To: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
Message-ID: <1223468504.3457.36.camel@localhost.localdomain>
On Wed, 2008-10-08 at 07:40 -0400, Luis Villa wrote:
> Hey, all-
>
> recently saw this: http://nigelj.livejournal.com/10507.html Can't
> comment directly because I don't have an LJ account.
>
> Elections are fairly serious, important business- much less so in a
> community where elected representatives are the deciders of last
> resort instead of first resort, but still. So I'd strongly recommend
> using someone else's code that has been tested and reviewed for
> security and correctness rather than writing your own. Two open
> options are:
>
> http://www.heliosvoting.org/
^^^
Anyone know what's the purpose of the Google API stuff in this code?
(Not necessarily a question just for Luis, but for anyone knowledgeable
looking at the code.)
> http://selectricity.org/
^^^
I looked around for a bit and couldn't find the source code for the
webapp part, but this is based on http://rubyvote.rubyforge.org/ ,
correct?
> I realize Fedora has some unusual needs, and I appreciate the effort
> Nigel has put in on this, but Fedora should strongly consider not
> reinventing this particular wheel. Focus on the deliberative part of
> what Nigel is working on (question tool, etc.) and leave the voting
> part to those who have already worked on the problem extensively.
--
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From luis at tieguy.org Wed Oct 8 13:14:20 2008
From: luis at tieguy.org (Luis Villa)
Date: Wed, 8 Oct 2008 09:14:20 -0400
Subject: election software
In-Reply-To: <1223468504.3457.36.camel@localhost.localdomain>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
<1223468504.3457.36.camel@localhost.localdomain>
Message-ID: <2cb10c440810080614m21ac7e1ar8bd5551e4ade0bff@mail.gmail.com>
On Wed, Oct 8, 2008 at 8:21 AM, Paul W. Frields wrote:
> On Wed, 2008-10-08 at 07:40 -0400, Luis Villa wrote:
>> Hey, all-
>>
>> recently saw this: http://nigelj.livejournal.com/10507.html Can't
>> comment directly because I don't have an LJ account.
>>
>> Elections are fairly serious, important business- much less so in a
>> community where elected representatives are the deciders of last
>> resort instead of first resort, but still. So I'd strongly recommend
>> using someone else's code that has been tested and reviewed for
>> security and correctness rather than writing your own. Two open
>> options are:
>>
>> http://www.heliosvoting.org/
> ^^^
> Anyone know what's the purpose of the Google API stuff in this code?
> (Not necessarily a question just for Luis, but for anyone knowledgeable
> looking at the code.)
Author cc'd. Ben?
>> http://selectricity.org/
> ^^^
> I looked around for a bit and couldn't find the source code for the
> webapp part, but this is based on http://rubyvote.rubyforge.org/ ,
> correct?
I'm told by the author that an updated source release of rubyvote is
due 'very soon', but I really don't know about the web frontend part-
I'd been under the impression it was also in the rubyvote source repo,
but I may be incorrect.
Luis
From a.badger at gmail.com Wed Oct 8 15:18:02 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 08 Oct 2008 08:18:02 -0700
Subject: election software
In-Reply-To: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
Message-ID: <48ECCF2A.4040507@gmail.com>
Luis Villa wrote:
> Hey, all-
>
> recently saw this: http://nigelj.livejournal.com/10507.html Can't
> comment directly because I don't have an LJ account.
>
> Elections are fairly serious, important business- much less so in a
> community where elected representatives are the deciders of last
> resort instead of first resort, but still. So I'd strongly recommend
> using someone else's code that has been tested and reviewed for
> security and correctness rather than writing your own. Two open
> options are:
>
> http://www.heliosvoting.org/
For those who are interested, the source code is here:
http://github.com/benadida/helios/tree/master
It makes some bad choices as an open source project but nothing that's
not fixable. (Keeping local copies of third-party upstream sources
jumps out at me immediately. Keeping partial local copies of third
party modules and mixing those together and with the developer's own
code makes me shiver).
This is written in python with cherrypy as its object dispatcher. But
it also makes use of django utility functions (django's local copy of
python-simplejson :-( It looks like the Google App Engine code is
required at the moment but it's being ported to work with a plain
postgresql backend. I don't see signs of an ORM being used although the
code is being ported to a home-built db abstraction layer based on the
Google App Engine.
I don't see very much information in the app's data model for limiting
who can vote. I ran into tracebacks creating a new election so I'm not
sure how it works in practice.
The "Java support required for heliosvoting" popup is disconcerting...
Is that a Google App Engine requirement?
> http://selectricity.org/
>
Selectricity has several negatives:
* source code? I think that rubyvote was a base but not the complete
package.
* ruby -- we have very little ruby knowledge internally so we'd be
somewhat high and dry on this one. This is especially bad because at
minimum we'd want to tie into our account system for auth.
> I realize Fedora has some unusual needs, and I appreciate the effort
> Nigel has put in on this, but Fedora should strongly consider not
> reinventing this particular wheel. Focus on the deliberative part of
> what Nigel is working on (question tool, etc.) and leave the voting
> part to those who have already worked on the problem extensively.
>
Judging from commit dates (misleading since heliosvote was worked on
prior to it being released publically) Nigel's been working on the
problem longer than they have :-)
Collaboration is a good thing, though. If Nigel and Ben can get along
and want to work with each other, that would lead to a better voting app
all around. I'm somewhat doubtful that we could have something ready to
use for the post-F10 election cycle no matter what happens, though.
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL:
From luis at tieguy.org Wed Oct 8 15:37:57 2008
From: luis at tieguy.org (Luis Villa)
Date: Wed, 8 Oct 2008 11:37:57 -0400
Subject: election software
In-Reply-To: <48ECCF2A.4040507@gmail.com>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
<48ECCF2A.4040507@gmail.com>
Message-ID: <2cb10c440810080837h1e6231eflf3d4fb0e48ee9c5a@mail.gmail.com>
[ben adida, the author of helios, is a friend of free software; if you
cc him on responses about helios you're likely to get a good response.
responding both to remind people of that and to point out to ben the
questions asked by toshio, below.]
[tangentially, i did not realize the app engine dependency; i would
have been slower to recommend if i'd realized that. still, glad to
hear that there is a pgsql port in the works.]
On Wed, Oct 8, 2008 at 11:18 AM, Toshio Kuratomi wrote:
> Luis Villa wrote:
>> Hey, all-
>>
>> recently saw this: http://nigelj.livejournal.com/10507.html Can't
>> comment directly because I don't have an LJ account.
>>
>> Elections are fairly serious, important business- much less so in a
>> community where elected representatives are the deciders of last
>> resort instead of first resort, but still. So I'd strongly recommend
>> using someone else's code that has been tested and reviewed for
>> security and correctness rather than writing your own. Two open
>> options are:
>>
>> http://www.heliosvoting.org/
>
> For those who are interested, the source code is here:
> http://github.com/benadida/helios/tree/master
>
> It makes some bad choices as an open source project but nothing that's
> not fixable. (Keeping local copies of third-party upstream sources
> jumps out at me immediately. Keeping partial local copies of third
> party modules and mixing those together and with the developer's own
> code makes me shiver).
>
> This is written in python with cherrypy as its object dispatcher. But
> it also makes use of django utility functions (django's local copy of
> python-simplejson :-( It looks like the Google App Engine code is
> required at the moment but it's being ported to work with a plain
> postgresql backend. I don't see signs of an ORM being used although the
> code is being ported to a home-built db abstraction layer based on the
> Google App Engine.
>
> I don't see very much information in the app's data model for limiting
> who can vote. I ran into tracebacks creating a new election so I'm not
> sure how it works in practice.
>
> The "Java support required for heliosvoting" popup is disconcerting...
> Is that a Google App Engine requirement?
luis
From ben at adida.net Wed Oct 8 14:58:57 2008
From: ben at adida.net (Ben Adida)
Date: Wed, 08 Oct 2008 07:58:57 -0700
Subject: election software
In-Reply-To: <2cb10c440810080614m21ac7e1ar8bd5551e4ade0bff@mail.gmail.com>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
<1223468504.3457.36.camel@localhost.localdomain>
<2cb10c440810080614m21ac7e1ar8bd5551e4ade0bff@mail.gmail.com>
Message-ID: <48ECCAB1.4060902@adida.net>
Luis Villa wrote:
>>> http://www.heliosvoting.org/
>> ^^^
>> Anyone know what's the purpose of the Google API stuff in this code?
>> (Not necessarily a question just for Luis, but for anyone knowledgeable
>> looking at the code.)
>
> Author cc'd. Ben?
It's written to the Google App Engine API, so that it can be hosted with
scalability and reliability more or less for free:
http://code.google.com/appengine/
common question: "So I have to trust Google?"
Actually no. That's the point of cryptographically verified voting: you
do NOT trust the host of the election, you verify the results using the
built-in verifier code (which you can run as the standalone Python
script from your home machine.)
Also, the only Google-based login is for the election administrator.
Individual voters do *not* need Google accounts.
That said, if you still want to take on the hosting of the software
independently, I'm working on a PostgreSQL-backed version of the code.
You can actually see the beginnings of that in the source tree.
Happy to answer any additional questions.
-Ben
PS: the Information Card Foundation just used Helios for their board
election, 2-person board with 50 voters, worked without a single voter
complaint.
From ben at adida.net Wed Oct 8 16:20:26 2008
From: ben at adida.net (Ben Adida)
Date: Wed, 08 Oct 2008 09:20:26 -0700
Subject: election software
In-Reply-To: <2cb10c440810080837h1e6231eflf3d4fb0e48ee9c5a@mail.gmail.com>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
<48ECCF2A.4040507@gmail.com>
<2cb10c440810080837h1e6231eflf3d4fb0e48ee9c5a@mail.gmail.com>
Message-ID: <48ECDDCA.2060400@adida.net>
Luis Villa wrote:
> [ben adida, the author of helios, is a friend of free software;
I think I'm more than a friend, actually, I've been a free software
developer on a number of web-related free software projects since 1998 :)
> [tangentially, i did not realize the app engine dependency; i would
> have been slower to recommend if i'd realized that. still, glad to
> hear that there is a pgsql port in the works.]
The app engine is a dependency only insofar as it provides rapid
deployment and scaling. The core of the technology is all free.
Toshio: I see you're going through the code with a fine-tooth comb...
very nice. I look forward to more comments. I think you'll see that most
of your concerns are simply (small) side-effects of the hosted App
Engine setting.
>> It makes some bad choices as an open source project but nothing that's
>> not fixable. (Keeping local copies of third-party upstream sources
>> jumps out at me immediately. Keeping partial local copies of third
>> party modules and mixing those together and with the developer's own
>> code makes me shiver).
The only reason local copies of third-party packages are kept is because
Google App Engine doesn't have them built in, so they have to be present
as part of the source tree. If you have the third-party packages
installed in your Python path, and you're running the pgsql version
(when it's ready), you can rm -rf those third-party packages.
Can you expand on what you mean by "partial" local copies, or by
"mixing"? I'm pretty sure I'm not mixing any code, it's more like
bundling because I can't count on the python path at App Engine.
>> This is written in python with cherrypy as its object dispatcher. But
>> it also makes use of django utility functions (django's local copy of
>> python-simplejson :-(
Also because of Google App Engine, which has django built in but not the
standalone version of simplejson. Thus you see me trying to import
simplejson, and if that fails I try to import the one from django.
Just a couple of lines of code, though, nothing that can't be quickly
fixed once the dependency is gone :)
>>It looks like the Google App Engine code is
>> required at the moment but it's being ported to work with a plain
>> postgresql backend. I don't see signs of an ORM being used although the
>> code is being ported to a home-built db abstraction layer based on the
>> Google App Engine.
I'm very dubious of ORM in general, both in terms of performance and
transparency. I prefer dictionary wrapping of SQL results. The
home-built db abstraction layer is one that I've worked on for years on
many projects, and I've only just recently adapted it to Google App Engine.
Also, the layer is really just a wrapper around DBUtils and psycopg2.
The heavy lifting is done by those existing libraries. My API just
exposes a simpler API especially when it comes to transactions and
connection management.
>> I don't see very much information in the app's data model for limiting
>> who can vote.
Voters have passwords that are auto-generated on the server side. Only
voters that are listed for an election are allowed to vote. Is there
something else you were expecting to see in the data model?
>> I ran into tracebacks creating a new election so I'm not
>> sure how it works in practice.
Where, at www.heliosvoting.org? Or running it on your own? The pgsql
version is not working yet. Do you have the full traceback?
You can report and track the bug at: http://helios.lighthouseapp.com
>> The "Java support required for heliosvoting" popup is disconcerting...
>> Is that a Google App Engine requirement?
This is a key feature of Helios, not a Google App Engine requirement.
Java is used on the client side, in your browser, to perform ballot
encryption before your ballot even leaves your browser. It is also used
to generated zero-knowledge proofs that your ballot was correctly created.
The key idea of Helios is that it implements security and verifiability
features that go far beyond any other voting system. You get to verify
that your vote actually counted, and you get a cryptographic proof of
that result. Again, I want to stress: there is no other web-based voting
system that provides anywhere close to this level of verifiability today.
(If JavaScript had a bignum library, I wouldn't be using Java, of course.)
Happy to answer any other questions, of course.
-Ben
From a.badger at gmail.com Wed Oct 8 17:55:29 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 08 Oct 2008 10:55:29 -0700
Subject: election software
In-Reply-To: <48ECDDCA.2060400@adida.net>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com> <48ECCF2A.4040507@gmail.com> <2cb10c440810080837h1e6231eflf3d4fb0e48ee9c5a@mail.gmail.com>
<48ECDDCA.2060400@adida.net>
Message-ID: <48ECF411.2040909@gmail.com>
Ben Adida wrote:
> Toshio: I see you're going through the code with a fine-tooth comb...
> very nice. I look forward to more comments. I think you'll see that most
> of your concerns are simply (small) side-effects of the hosted App
> Engine setting.
>
>>> It makes some bad choices as an open source project but nothing that's
>>> not fixable. (Keeping local copies of third-party upstream sources
>>> jumps out at me immediately. Keeping partial local copies of third
>>> party modules and mixing those together and with the developer's own
>>> code makes me shiver).
>
> The only reason local copies of third-party packages are kept is because
> Google App Engine doesn't have them built in, so they have to be present
> as part of the source tree. If you have the third-party packages
> installed in your Python path, and you're running the pgsql version
> (when it's ready), you can rm -rf those third-party packages.
>
Cool. The cherrypy inclusion looked clean like this :-)
> Can you expand on what you mean by "partial" local copies, or by
> "mixing"? I'm pretty sure I'm not mixing any code, it's more like
> bundling because I can't count on the python path at App Engine.
>
I'd have to look at the code more, but looking at random files in the
base/* directory didn't give me a good feeling. There were comments at
the top of files like, This code was taken from feedparser under License
XXX. There was other code taken from different projects (github is down
so I can't look at what right now) -- it made that directory look like a
packagers nightmare. If we're not going to use it, I didn't want to
deal with analyzing it :-) If we are, then I (or someone else) will
have to.
>>> This is written in python with cherrypy as its object dispatcher. But
>>> it also makes use of django utility functions (django's local copy of
>>> python-simplejson :-(
>
> Also because of Google App Engine, which has django built in but not the
> standalone version of simplejson. Thus you see me trying to import
> simplejson, and if that fails I try to import the one from django.
>
The code actually does the reverse of that :-) Not a big deal, just
need to switch the failure case (and for Fedora, remove simplejson from
django bz#464885).
> Just a couple of lines of code, though, nothing that can't be quickly
> fixed once the dependency is gone :)
>
>>> It looks like the Google App Engine code is
>>> required at the moment but it's being ported to work with a plain
>>> postgresql backend. I don't see signs of an ORM being used although the
>>> code is being ported to a home-built db abstraction layer based on the
>>> Google App Engine.
>
> I'm very dubious of ORM in general, both in terms of performance and
> transparency. I prefer dictionary wrapping of SQL results. The
> home-built db abstraction layer is one that I've worked on for years on
> many projects, and I've only just recently adapted it to Google App Engine.
>
> Also, the layer is really just a wrapper around DBUtils and psycopg2.
> The heavy lifting is done by those existing libraries. My API just
> exposes a simpler API especially when it comes to transactions and
> connection management.
>
I'm not complaining about it, just noting it. It limits the
database backends that can be used to the ones that the app has been
ported to rather than letting the ORM manage database portability. (I
love postgres but, as mmcgrath tells me frequently, mysql is much easier
to administer which makes him much happier :-)
>>> I don't see very much information in the app's data model for limiting
>>> who can vote.
>
> Voters have passwords that are auto-generated on the server side. Only
> voters that are listed for an election are allowed to vote. Is there
> something else you were expecting to see in the data model?
>
I'm not certain. github is down right now or I could look at the
various files I was looking at before :-)
My basic aim is figuring out how we'd tie the authentication in the app
into our account system.
>>> I ran into tracebacks creating a new election so I'm not
>>> sure how it works in practice.
>
> Where, at www.heliosvoting.org? Or running it on your own? The pgsql
> version is not working yet. Do you have the full traceback?
>
> You can report and track the bug at: http://helios.lighthouseapp.com
>
Yeah, at heliosvoting.org. I first tried to create an election managed
by trustees and got a traceback. Then I tried to create an election
managed by myself and got a traceback. Didn't explore further. Since I
was just evaluating how it stacked up to what we have now, Im afraid I
didn't file a bug report. Sorry.
>>> The "Java support required for heliosvoting" popup is disconcerting...
>>> Is that a Google App Engine requirement?
>
> This is a key feature of Helios, not a Google App Engine requirement.
>
> Java is used on the client side, in your browser, to perform ballot
> encryption before your ballot even leaves your browser. It is also used
> to generated zero-knowledge proofs that your ballot was correctly created.
>
> The key idea of Helios is that it implements security and verifiability
> features that go far beyond any other voting system. You get to verify
> that your vote actually counted, and you get a cryptographic proof of
> that result. Again, I want to stress: there is no other web-based voting
> system that provides anywhere close to this level of verifiability today.
>
> (If JavaScript had a bignum library, I wouldn't be using Java, of course.)
>
Hmm..... there's upsides and downsides to this. We want to have
accessibility for voting if possible so a reliance on java and
javascript is problematic. If there's a json or xmlrpc interface, then
we could code an alternate front-end.
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL:
From mmcgrath at redhat.com Wed Oct 8 18:15:30 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 8 Oct 2008 13:15:30 -0500 (CDT)
Subject: election software
In-Reply-To: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
Message-ID:
On Wed, 8 Oct 2008, Luis Villa wrote:
>
> I realize Fedora has some unusual needs, and I appreciate the effort
> Nigel has put in on this, but Fedora should strongly consider not
> reinventing this particular wheel. Focus on the deliberative part of
> what Nigel is working on (question tool, etc.) and leave the voting
> part to those who have already worked on the problem extensively.
>
I'm not convinced the question tool isn't going to be a waste of Nigel's
time actually. Feature creep aside, we have low participation right now
anyway and by creating this tool we're actually asking _more_ of the few
people who do get involved.
Questions:
Was any cost / benefit analysis done on this?
Aside from one board member's interest in it has anyone expressed this as
an actual need that should be filled?
Was that need from the voters perspective or the running members
perspective?
Are people running for the board getting inundated with questions?
Do we expect the question system to increase voter turnout? How?
-Mike
From ben at adida.net Wed Oct 8 21:55:42 2008
From: ben at adida.net (Ben Adida)
Date: Wed, 08 Oct 2008 14:55:42 -0700
Subject: election software
In-Reply-To: <48ECF411.2040909@gmail.com>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com> <48ECCF2A.4040507@gmail.com> <2cb10c440810080837h1e6231eflf3d4fb0e48ee9c5a@mail.gmail.com>
<48ECDDCA.2060400@adida.net> <48ECF411.2040909@gmail.com>
Message-ID: <48ED2C5E.3040006@adida.net>
Toshio Kuratomi wrote:
> I'd have to look at the code more, but looking at random files in the
> base/* directory didn't give me a good feeling. There were comments at
> the top of files like, This code was taken from feedparser under License
> XXX.
I try to be excessively clear about sources from which I borrow code,
but the only times I bring them in by source is when the project isn't
packaged, when I'm using some starting point but then expanding on it,
or when I need a small piece and can't install the rest because of
native-code dependencies. Here's an exhaustive list:
- HTML sanitizer: code from feedparser, with appropriate copyright
notice from Mark Pilgrim.
- number.py and randpool.py for basic number theory in the Python Crypto
Toolkit. The Python Crypto Toolkit includes native components which
doesn't jive well with Google App Engine.
- oauth.py, taken from the OAuth Python library but hacked a bit because
some parts were not quite right.
- REST.py, taken from public sample code to build simple REST facilities
on top of cherrypy. Not a package to begin with.
> There was other code taken from different projects (github is down
> so I can't look at what right now) -- it made that directory look like a
> packagers nightmare. If we're not going to use it, I didn't want to
> deal with analyzing it :-) If we are, then I (or someone else) will
> have to.
So, of course you should analyze the code to your heart's content.
That said, I just want to point out one important feature: this is a
cryptographically verifiable voting system, which means the results are
presented with a mathematic proof of correctness. So, in fact, the only
part you really *need* to review is the verification program: the
client/, crypto/ directories.
I'm not suggesting you ignore the rest of the code, I'm only trying to
highlight the verifiability of the system.
>> Also because of Google App Engine, which has django built in but not the
>> standalone version of simplejson. Thus you see me trying to import
>> simplejson, and if that fails I try to import the one from django.
>>
> The code actually does the reverse of that :-) Not a big deal, just
> need to switch the failure case (and for Fedora, remove simplejson from
> django bz#464885).
Oops, you are correct about the order. Note that this should go away
when the Google App Engine folks fix their bug (which I've reported to
them), an inconsistency between the platform and the sdk.
> I'm not complaining about it, just noting it. It limits the
> database backends that can be used to the ones that the app has been
> ported to rather than letting the ORM manage database portability. (I
> love postgres but, as mmcgrath tells me frequently, mysql is much easier
> to administer which makes him much happier :-)
Well, I won't get into a DB fight, but... are you trying to package this
for aptitude-style installation? That's great but it might be a bit
premature for that.
Would you consider running the election at heliosvoting.org and using
the Python verification programs (which you can and should audit) to
verify the election? That should make it quite easy for you (and just as
verifiable.)
Of course, installing it yourself is a perfectly fine option (once pgsql
is supported), just a lot more work and not any real additional
verifiability.
> My basic aim is figuring out how we'd tie the authentication in the app
> into our account system.
1) I would recommend not tying this to an existing auth system: just use
election-specific passwords emailed to folks. Simpler and really just as
good since there is a *public* verification phase where everyone can
check that the hash of their vote is on the public bulletin board.
2) If you really want to tie it to your existing auth system, you could
hack the code or use the OAuth-based API where you build a different
front-end that sends votes to the server via REST calls. I'm working
with a large university that wants to do just this, so we'll have sample
code for this approach in a couple of months.
>>>> I ran into tracebacks creating a new election so I'm not
>>>> sure how it works in practice.
>> Where, at www.heliosvoting.org? Or running it on your own? The pgsql
>> version is not working yet. Do you have the full traceback?
>>
>> You can report and track the bug at: http://helios.lighthouseapp.com
>>
> Yeah, at heliosvoting.org. I first tried to create an election managed
> by trustees and got a traceback. Then I tried to create an election
> managed by myself and got a traceback. Didn't explore further. Since I
> was just evaluating how it stacked up to what we have now, Im afraid I
> didn't file a bug report. Sorry.
No problem. Can't reproduce either of these right now, but let me know
when you do reproduce them.
> Hmm..... there's upsides and downsides to this. We want to have
> accessibility for voting if possible so a reliance on java and
> javascript is problematic. If there's a json or xmlrpc interface, then
> we could code an alternate front-end.
Using Java and JavaScript should not preclude accessibility. Java is
only used for bignum computation, never UI. JavaScript is used to glue
HTML and Java together. The HTML should be easily customizable to be
screen-reader friendly or otherwise accessible.
Now, if you're thinking about a lynx interface, that is indeed a
problem, but it's a problem that gets at the heart of the features
offered by Helios: Helios *needs* the browser to be able to do crypto so
the vote can be sealed encrypted before it leaves the browser.
This is definitely a lot more than an HTML form, I know, but it brings
with it a qualitatively much higher level of verifiability.
-Ben
From a.badger at gmail.com Wed Oct 8 23:32:34 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 08 Oct 2008 16:32:34 -0700
Subject: election software
In-Reply-To: <48ED2C5E.3040006@adida.net>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com> <48ECCF2A.4040507@gmail.com> <2cb10c440810080837h1e6231eflf3d4fb0e48ee9c5a@mail.gmail.com> <48ECDDCA.2060400@adida.net>
<48ECF411.2040909@gmail.com> <48ED2C5E.3040006@adida.net>
Message-ID: <48ED4312.7000008@gmail.com>
Ben Adida wrote:
> Toshio Kuratomi wrote:
>> I'd have to look at the code more, but looking at random files in the
>> base/* directory didn't give me a good feeling. There were comments at
>> the top of files like, This code was taken from feedparser under License
>> XXX.
>
> I try to be excessively clear about sources from which I borrow code,
> but the only times I bring them in by source is when the project isn't
> packaged, when I'm using some starting point but then expanding on it,
> or when I need a small piece and can't install the rest because of
> native-code dependencies. Here's an exhaustive list:
>
The problem from a distro packager's point of view is that we
don't know how you stack up against the upstream for the module code.
In almost all cases, we'd rather go with upstream for the code since
they have a larger community than just a single app. That means more
chance of bugs and security issues being detected and fixed upstream
than downstream.
Your list of code includes some files that are simply files from
upstream, some that are legitimately being incorporated into your
codebase, and some that are being taken from upstream and then modified.
This is a nightmare for packagers as they have to analyze, decide if
there's an active upstream for the code, figure out if they should be
using the upstream system library instead of the copy you have, figure
out if there's any extra bugfixes in your version that they need to get
ported to the system library, figuring out if you're using old, buggy
versions of the library when newer ones have security fixes, and so on.
>> There was other code taken from different projects (github is down
>> so I can't look at what right now) -- it made that directory look like a
>> packagers nightmare. If we're not going to use it, I didn't want to
>> deal with analyzing it :-) If we are, then I (or someone else) will
>> have to.
>
> So, of course you should analyze the code to your heart's content.
>
> That said, I just want to point out one important feature: this is a
> cryptographically verifiable voting system, which means the results are
> presented with a mathematic proof of correctness. So, in fact, the only
> part you really *need* to review is the verification program: the
> client/, crypto/ directories.
>
> I'm not suggesting you ignore the rest of the code, I'm only trying to
> highlight the verifiability of the system.
>
So the analysis mentioned here isn't so much analyzing it for security.
It's analyzing it to figure out how we're going to package it, if all
the licenses are compatible, etc. Analyzing the code for use as
Fedora's voting software is a different beast :-)
>> I'm not complaining about it, just noting it. It limits the
>> database backends that can be used to the ones that the app has been
>> ported to rather than letting the ORM manage database portability. (I
>> love postgres but, as mmcgrath tells me frequently, mysql is much easier
>> to administer which makes him much happier :-)
>
> Well, I won't get into a DB fight, but... are you trying to package this
> for aptitude-style installation? That's great but it might be a bit
> premature for that.
>
yes. If we run it in Fedora Infrastructure we need to package it for
Fedora. It's not a 100% hard and fast rule but it's a pretty big thing.
We want to make sure that the software is suitable for Fedora and we
want to make sure that we're sharing the knowledge of what makes our
infrastructure work with the rest of the world.
> Would you consider running the election at heliosvoting.org and using
> the Python verification programs (which you can and should audit) to
> verify the election? That should make it quite easy for you (and just as
> verifiable.)
>
Probably not... but not necessarily no :-) That's probably a board
question and I'm an infrastructure guy instead. (This is a list where
Board Members take in information, though, so they can make their
preference known :-)
> Of course, installing it yourself is a perfectly fine option (once pgsql
> is supported), just a lot more work and not any real additional
> verifiability.
>
Understood.
>> My basic aim is figuring out how we'd tie the authentication in the app
>> into our account system.
>
> 1) I would recommend not tying this to an existing auth system: just use
> election-specific passwords emailed to folks. Simpler and really just as
> good since there is a *public* verification phase where everyone can
> check that the hash of their vote is on the public bulletin board.
>
We probably would want to tie to the existing auth system. Currently we
allow people to join groups while elections are in progress and they get
to vote in those elections. Keeping track of group joining while an
election is in progress and sending out new one-time passwords wouldn't
be the best in this situation. Also, I'm pretty sure that some of our
users won't like the fact that the passwords travel via email. (We could
encrypt with GPG if we have a key on file or something but that's extra
work that when we'd be happier to put the extra work into getting our
authentication working with the app).
> 2) If you really want to tie it to your existing auth system, you could
> hack the code or use the OAuth-based API where you build a different
> front-end that sends votes to the server via REST calls. I'm working
> with a large university that wants to do just this, so we'll have sample
> code for this approach in a couple of months.
>
Are you talking about a different front-end to the account system or a
different front-end to the election server? This is certainly something
we could look into in either case. We need to find some method of
pushing authorization data from our account system to other web
applications and oauth was something we wanted to look into for that.
>>>>> I ran into tracebacks creating a new election so I'm not
>>>>> sure how it works in practice.
>>> Where, at www.heliosvoting.org? Or running it on your own? The pgsql
>>> version is not working yet. Do you have the full traceback?
>>>
>>> You can report and track the bug at: http://helios.lighthouseapp.com
>>>
>> Yeah, at heliosvoting.org. I first tried to create an election managed
>> by trustees and got a traceback. Then I tried to create an election
>> managed by myself and got a traceback. Didn't explore further. Since I
>> was just evaluating how it stacked up to what we have now, Im afraid I
>> didn't file a bug report. Sorry.
>
> No problem. Can't reproduce either of these right now, but let me know
> when you do reproduce them.
>
Something's wrong with java::
BigInt.APPLET.newBigInteger is not a function
http://www.heliosvoting.org/static/bigint.js
Line 21
I have the gcjwebplugin (using IcedTea) installed and enabled. If that
doesn't work we'll have problems as that's what ships with Fedora.
>> Hmm..... there's upsides and downsides to this. We want to have
>> accessibility for voting if possible so a reliance on java and
>> javascript is problematic. If there's a json or xmlrpc interface, then
>> we could code an alternate front-end.
>
> Using Java and JavaScript should not preclude accessibility. Java is
> only used for bignum computation, never UI. JavaScript is used to glue
> HTML and Java together. The HTML should be easily customizable to be
> screen-reader friendly or otherwise accessible.
>
> Now, if you're thinking about a lynx interface, that is indeed a
> problem, but it's a problem that gets at the heart of the features
> offered by Helios: Helios *needs* the browser to be able to do crypto so
> the vote can be sealed encrypted before it leaves the browser.
>
That's what I'm thinking. Now we haven't had complaints yet that
any of the web sites we have are not accessible this way but there's
only one (useful to packagers only) that is not usable in lynx. And it
is a goal of ours to have accessible web apps.
Is a command line front end a possibility? Does your app have a json or
xmlrpc that we could tap into?
In terms of actually using the Helios Voting app for Fedora Elections,
you want to talk with Nigel Jones as he's the coder behind our current
voting app. I'm just raising issues that we'll have to address if we
choose to switch.
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL:
From jkeating at redhat.com Wed Oct 8 23:54:49 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 08 Oct 2008 16:54:49 -0700
Subject: election software
In-Reply-To: <48ED4312.7000008@gmail.com>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
<48ECCF2A.4040507@gmail.com>
<2cb10c440810080837h1e6231eflf3d4fb0e48ee9c5a@mail.gmail.com>
<48ECDDCA.2060400@adida.net> <48ECF411.2040909@gmail.com>
<48ED2C5E.3040006@adida.net> <48ED4312.7000008@gmail.com>
Message-ID: <1223510089.4410.92.camel@luminos.localdomain>
On Wed, 2008-10-08 at 16:32 -0700, Toshio Kuratomi wrote:
> Probably not... but not necessarily no :-) That's probably a board
> question and I'm an infrastructure guy instead. (This is a list where
> Board Members take in information, though, so they can make their
> preference known :-)
My gut reaction is no. We wouldn't want our voting data be handled on a
system outside our control. Our voting data isn't trade secrets, but
it's also not something we're ever going to play fast and loose with.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
From luis at tieguy.org Thu Oct 9 00:02:54 2008
From: luis at tieguy.org (Luis Villa)
Date: Wed, 8 Oct 2008 20:02:54 -0400
Subject: election software
In-Reply-To: <48ED4312.7000008@gmail.com>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
<48ECCF2A.4040507@gmail.com>
<2cb10c440810080837h1e6231eflf3d4fb0e48ee9c5a@mail.gmail.com>
<48ECDDCA.2060400@adida.net> <48ECF411.2040909@gmail.com>
<48ED2C5E.3040006@adida.net> <48ED4312.7000008@gmail.com>
Message-ID: <2cb10c440810081702q2339d7cm292b255d6d055a3c@mail.gmail.com>
On Wed, Oct 8, 2008 at 7:32 PM, Toshio Kuratomi wrote:
> In terms of actually using the Helios Voting app for Fedora Elections,
> you want to talk with Nigel Jones as he's the coder behind our current
> voting app. I'm just raising issues that we'll have to address if we
> choose to switch.
FWIW, I had believed from previous email exchanges that Nigel was
subscribed to f-a-b; if that is incorrect I apologize- I should have
cc'd him earlier, obviously. Nigel, if you aren't subscribed a walk
through the archives is probably in order :)
Luis
From dev at nigelj.com Thu Oct 9 00:40:54 2008
From: dev at nigelj.com (Nigel Jones)
Date: Thu, 09 Oct 2008 13:40:54 +1300
Subject: election software
In-Reply-To: <48ED4312.7000008@gmail.com>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
<48ECCF2A.4040507@gmail.com>
<2cb10c440810080837h1e6231eflf3d4fb0e48ee9c5a@mail.gmail.com>
<48ECDDCA.2060400@adida.net> <48ECF411.2040909@gmail.com>
<48ED2C5E.3040006@adida.net> <48ED4312.7000008@gmail.com>
Message-ID: <1223512854.20046.287.camel@fantail.jnet.net.nz>
On Wed, 2008-10-08 at 16:32 -0700, Toshio Kuratomi wrote:
> > Would you consider running the election at heliosvoting.org and using
> > the Python verification programs (which you can and should audit) to
> > verify the election? That should make it quite easy for you (and just as
> > verifiable.)
> >
> Probably not... but not necessarily no :-) That's probably a board
> question and I'm an infrastructure guy instead. (This is a list where
> Board Members take in information, though, so they can make their
> preference known :-)
This is (in my opinion) not an option for us.
> >> My basic aim is figuring out how we'd tie the authentication in the app
> >> into our account system.
> >
> > 1) I would recommend not tying this to an existing auth system: just use
> > election-specific passwords emailed to folks. Simpler and really just as
> > good since there is a *public* verification phase where everyone can
> > check that the hash of their vote is on the public bulletin board.
> >
> We probably would want to tie to the existing auth system. Currently we
> allow people to join groups while elections are in progress and they get
> to vote in those elections. Keeping track of group joining while an
> election is in progress and sending out new one-time passwords wouldn't
> be the best in this situation. Also, I'm pretty sure that some of our
> users won't like the fact that the passwords travel via email. (We could
> encrypt with GPG if we have a key on file or something but that's extra
> work that when we'd be happier to put the extra work into getting our
> authentication working with the app).
We do have some weird requirements at times for allowing people to vote,
at least with doing everything ourselves we can check on the spot
in-app.
> >> Hmm..... there's upsides and downsides to this. We want to have
> >> accessibility for voting if possible so a reliance on java and
> >> javascript is problematic. If there's a json or xmlrpc interface,
> then
> >> we could code an alternate front-end.
> >
> > Using Java and JavaScript should not preclude accessibility. Java is
> > only used for bignum computation, never UI. JavaScript is used to
> glue
> > HTML and Java together. The HTML should be easily customizable to be
> > screen-reader friendly or otherwise accessible.
> >
> > Now, if you're thinking about a lynx interface, that is indeed a
> > problem, but it's a problem that gets at the heart of the features
> > offered by Helios: Helios *needs* the browser to be able to do
> crypto so
> > the vote can be sealed encrypted before it leaves the browser.
> >
> That's what I'm thinking. Now we haven't had complaints yet
> that
> any of the web sites we have are not accessible this way but there's
> only one (useful to packagers only) that is not usable in lynx. And
> it
> is a goal of ours to have accessible web apps.
>
> Is a command line front end a possibility? Does your app have a json
> or
> xmlrpc that we could tap into?
>
> In terms of actually using the Helios Voting app for Fedora Elections,
> you want to talk with Nigel Jones as he's the coder behind our current
> voting app. I'm just raising issues that we'll have to address if we
> choose to switch.
Why change to something else when what we use now is proven to work? By
developing specifically for Fedora Project we know/knew that:
* It's going to meet any requirements that our groups have
* It's going to integrate with our Infrastructure perfectly
* It was going to counter other issues with the old voting application
In addition, as the elections application doesn't do/never will use any
super-weird code, unless something changes in the TurboGears framework
(which we can adapt to), in the currently deployed state, it could work
for years. As a result, the maintenance requirements are very low.
Now in an earlier point there was something about "reinventing the
wheel" etc, how does nominating candidates in-side the application
'reinvent the wheel', it's a natural 'election' process, in fact it
makes it easier, this is what I'm concentrating on now. Making the
whole process easier for the end user to save them from 15+ minutes of
digging around to work out where everything is/should be.
I think the time spent trying to migrate to a different system would be
a waste, we know that our code works, it gets tested every step of the
way and the few features we need *work*. Yes I'm building in new
features, but the end goal is to make the process better.
- Nigel
--
Nigel Jones
From kwade at redhat.com Thu Oct 9 01:46:56 2008
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 08 Oct 2008 18:46:56 -0700
Subject: election software
In-Reply-To:
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
Message-ID: <1223516816.3452.576.camel@calliope.phig.org>
On Wed, 2008-10-08 at 13:15 -0500, Mike McGrath wrote:
> Was any cost / benefit analysis done on this?
Not to my knowledge.
> Aside from one board member's interest in it has anyone expressed this as
> an actual need that should be filled?
>
> Was that need from the voters perspective or the running members
> perspective?
>
> Are people running for the board getting inundated with questions?
>
> Do we expect the question system to increase voter turnout? How?
Without hunting the archives, there were several discussions around the
last Board election that people wanted a way to ask questions of the
candidates. But I dunno, maybe if you look at it you'll find that it
was three people making all the noise. :D
- Karsten
--
Karsten Wade, Community Gardener
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From ben at adida.net Thu Oct 9 01:15:57 2008
From: ben at adida.net (Ben Adida)
Date: Wed, 08 Oct 2008 18:15:57 -0700
Subject: election software
In-Reply-To: <1223512854.20046.287.camel@fantail.jnet.net.nz>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
<48ECCF2A.4040507@gmail.com>
<2cb10c440810080837h1e6231eflf3d4fb0e48ee9c5a@mail.gmail.com>
<48ECDDCA.2060400@adida.net> <48ECF411.2040909@gmail.com>
<48ED2C5E.3040006@adida.net> <48ED4312.7000008@gmail.com>
<1223512854.20046.287.camel@fantail.jnet.net.nz>
Message-ID: <48ED5B4D.5090803@adida.net>
Nigel Jones wrote:
>> We probably would want to tie to the existing auth system. Currently we
>> allow people to join groups while elections are in progress and they get
>> to vote in those elections. Keeping track of group joining while an
>> election is in progress and sending out new one-time passwords wouldn't
>> be the best in this situation. Also, I'm pretty sure that some of our
>> users won't like the fact that the passwords travel via email. (We could
>> encrypt with GPG if we have a key on file or something but that's extra
>> work that when we'd be happier to put the extra work into getting our
>> authentication working with the app).
> We do have some weird requirements at times for allowing people to vote,
> at least with doing everything ourselves we can check on the spot
> in-app.
It may well be that your specific requirements make Helios a poor
choice. If you need to modify the list of voters while an election is in
progress, that's probably an incompatibility that won't go away: Helios
is meant for secure elections, and modifying the voter list after some
people have already cast a vote is an inherent weakness. A weakness
which Fedora may be completely willing to accept of course, but that
makes Fedora a very special case, so this likely won't be built into Helios.
> Why change to something else when what we use now is proven to work?
I'm pretty sure that your system, like almost every other election
system is only proven to work insofar as you haven't noticed any
errors... but then again how would one notice an error in a system where
voters send in a vote to a black box, and out comes a tally? Even if the
code is free/open-source, voters can't be sure *which* code was actually
used to compute the tally. So the chance that you'd detect an error in
tallying is actually fairly small.
That's what Helios is meant to address, and in that respect, I can't
stress enough how it is radically different than most code you see. It
provides a cryptographic proof of every election result, so an observer
can run *his* code on the public election data to verify that all
captured votes, identified by hash at casting time, were correctly
tallied. All without violating voter secrecy.
If this sounds intriguing and you want to learn more, and if you have
60-90 free minutes (Hah, I know, crazy, but you never know), here's a
presentation I gave at Google on this topic in general:
http://youtube.com/watch?v=ZDnShu5V99s
What this kind of technology means is that you can safely outsource your
election to a third party, and you know the election ran well because
the third party provides a proof of the election.
As Fedora is not in the business of elections, I would recommend
considering this as an option.
But again, if your voting requirements must remain as unique as
described by Toshio, then maybe Helios isn't the right solution.
Regardless, I really appreciate everyone's time considering Helios. I'm
happy to answer any additional questions, of course, and I appreciate
all of the feedback!
-Ben
From stickster at gmail.com Thu Oct 9 14:06:20 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 09 Oct 2008 14:06:20 +0000
Subject: election software
In-Reply-To: <1223516816.3452.576.camel@calliope.phig.org>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
<1223516816.3452.576.camel@calliope.phig.org>
Message-ID: <1223561180.13014.27.camel@localhost.localdomain>
On Wed, 2008-10-08 at 18:46 -0700, Karsten 'quaid' Wade wrote:
> On Wed, 2008-10-08 at 13:15 -0500, Mike McGrath wrote:
>
> > Was any cost / benefit analysis done on this?
>
> Not to my knowledge.
>
> > Aside from one board member's interest in it has anyone expressed this as
> > an actual need that should be filled?
> >
> > Was that need from the voters perspective or the running members
> > perspective?
> >
> > Are people running for the board getting inundated with questions?
> >
> > Do we expect the question system to increase voter turnout? How?
>
> Without hunting the archives, there were several discussions around the
> last Board election that people wanted a way to ask questions of the
> candidates. But I dunno, maybe if you look at it you'll find that it
> was three people making all the noise. :D
To sum it up, and without going back and scouring archives, we received
a number of complaints from community members both inside and outside
Red Hat that elections for FESCo and the Board aren't informed by
understanding where nominees stand on any issues. The complaints were
that voters have no information on which to make informed choice, but
rather vote for whom they recognize, meaning the results will always be
slanted toward people who happen to be getting paid to work on Fedora
all the time.
I remember specifically suggesting in a Board meeting that community
questions could just as easily be picked up on a wiki page and then
answers solicited from the nominees. By suggesting that option I was
hoping that we would not let "scalability" get in the way of
responsiveness to the community. I think scalability is a very good
thing, but we're trying to solve an unquantified problem with an equally
unquantified solution. That's sometimes unavoidable when dealing with
qualitative issues like community satisfaction.
As I recollect that conversation, we agreed that collecting questions on
the wiki was the right way to go in the short term, and that the amount
of community response would determine whether we pursued something more
comprehensive.
--
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From stickster at gmail.com Thu Oct 9 15:54:37 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 09 Oct 2008 15:54:37 +0000
Subject: Fedora Remix mark
Message-ID: <1223567677.13014.57.camel@localhost.localdomain>
https://fedoraproject.org/wiki/User:Pfrields/Secondary_trademark_design
This is the page where I collected your contributions to a design. The
time's come for me to refer the design candidates to the Board for
approval. Thus far, these designs are the ones that seem to be most
well-related to the existing "Fedora" word design and expressive of the
remix idea:
By Nicu and Mo:
https://fedoraproject.org/w/uploads/2/2a/Fedora_secondary_logo_drafts_nicubunu_mizmo_1.png
https://fedoraproject.org/w/uploads/2/2a/Fedora_secondary_logo_drafts_nicubunu_mizmo_1.svg
By Jay and Nicu:
https://fedoraproject.org/w/uploads/6/61/Fedora_secondary_logo_drafts_nicubunu_color.png
https://fedoraproject.org/wiki/Image:Fedora_secondary_logo_drafts_nicubunu_color.svg
Our legal counsel has told us that concentrating on the permissive use
of the mark is more effective than permissive modification of the mark.
Whichever mark is selected, we'll work with Artwork to develop
appropriate treatments that work in various background situations (for
example, black & white). Then I'll develop a page that shows the usage
guidelines for this mark, similar to the one for the Fedora logo.
By the way, the background for the mark, and the existing cutouts in the
design such as the letter shapes in "remix," can be transparent, which
yields some interesting possibilities for downstream remix creators.
--
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From notting at redhat.com Thu Oct 9 17:32:56 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 9 Oct 2008 13:32:56 -0400
Subject: Fedora Remix mark
In-Reply-To: <1223567677.13014.57.camel@localhost.localdomain>
References: <1223567677.13014.57.camel@localhost.localdomain>
Message-ID: <20081009173256.GA24763@nostromo.devel.redhat.com>
Paul W. Frields (stickster at gmail.com) said:
> By Nicu and Mo:
> https://fedoraproject.org/w/uploads/2/2a/Fedora_secondary_logo_drafts_nicubunu_mizmo_1.png
> https://fedoraproject.org/w/uploads/2/2a/Fedora_secondary_logo_drafts_nicubunu_mizmo_1.svg
I like the rounded #13 here. I'm not really sure why the desire to spell
remix with a '1' is prevalent.
Bill
From kwade at redhat.com Thu Oct 9 18:54:30 2008
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Thu, 09 Oct 2008 11:54:30 -0700
Subject: Fedora Remix mark
In-Reply-To: <20081009173256.GA24763@nostromo.devel.redhat.com>
References: <1223567677.13014.57.camel@localhost.localdomain>
<20081009173256.GA24763@nostromo.devel.redhat.com>
Message-ID: <1223578470.5964.26.camel@calliope.phig.org>
On Thu, 2008-10-09 at 13:32 -0400, Bill Nottingham wrote:
> Paul W. Frields (stickster at gmail.com) said:
> > By Nicu and Mo:
> > https://fedoraproject.org/w/uploads/2/2a/Fedora_secondary_logo_drafts_nicubunu_mizmo_1.png
> > https://fedoraproject.org/w/uploads/2/2a/Fedora_secondary_logo_drafts_nicubunu_mizmo_1.svg
>
> I like the rounded #13 here. I'm not really sure why the desire to spell
> remix with a '1' is prevalent.
Recursive visual remix pun, I presumed. When we spin Fedora, we only
use letters of the English alphabet. A Fedora Remix can use other
characters outside of that set, which is why it is not a spin but a
remix.
- Karsten
--
Karsten Wade, Community Gardener
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From stickster at gmail.com Thu Oct 9 21:17:51 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 09 Oct 2008 17:17:51 -0400
Subject: Fedora Remix mark
In-Reply-To: <1223578470.5964.26.camel@calliope.phig.org>
References: <1223567677.13014.57.camel@localhost.localdomain>
<20081009173256.GA24763@nostromo.devel.redhat.com>
<1223578470.5964.26.camel@calliope.phig.org>
Message-ID: <1223587071.26136.54.camel@localhost.localdomain>
On Thu, 2008-10-09 at 11:54 -0700, Karsten 'quaid' Wade wrote:
> On Thu, 2008-10-09 at 13:32 -0400, Bill Nottingham wrote:
> > Paul W. Frields (stickster at gmail.com) said:
> > > By Nicu and Mo:
> > > https://fedoraproject.org/w/uploads/2/2a/Fedora_secondary_logo_drafts_nicubunu_mizmo_1.png
> > > https://fedoraproject.org/w/uploads/2/2a/Fedora_secondary_logo_drafts_nicubunu_mizmo_1.svg
> >
> > I like the rounded #13 here. I'm not really sure why the desire to spell
> > remix with a '1' is prevalent.
>
> Recursive visual remix pun, I presumed. When we spin Fedora, we only
> use letters of the English alphabet. A Fedora Remix can use other
> characters outside of that set, which is why it is not a spin but a
> remix.
I brought up the idea of remixing the characters with the Artwork team,
so you can blame me. ;-) But yeah, I like the "R" styling better
myself.
--
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From stickster at gmail.com Fri Oct 10 02:35:54 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 9 Oct 2008 22:35:54 -0400
Subject: election software
In-Reply-To: <1223561180.13014.27.camel@localhost.localdomain>
References: <2cb10c440810080440x777d0913o46ae82a87649f6f6@mail.gmail.com>
<1223516816.3452.576.camel@calliope.phig.org>
<1223561180.13014.27.camel@localhost.localdomain>
Message-ID: <20081010023554.GB7116@localhost.localdomain>
On Thu, Oct 09, 2008 at 02:06:20PM +0000, Paul W. Frields wrote:
> On Wed, 2008-10-08 at 18:46 -0700, Karsten 'quaid' Wade wrote:
> > On Wed, 2008-10-08 at 13:15 -0500, Mike McGrath wrote:
> >
> > > Was any cost / benefit analysis done on this?
> >
> > Not to my knowledge.
> >
> > > Aside from one board member's interest in it has anyone
> > > expressed this as an actual need that should be filled?
> > >
> > > Was that need from the voters perspective or the running members
> > > perspective?
> > >
> > > Are people running for the board getting inundated with questions?
> > >
> > > Do we expect the question system to increase voter turnout? How?
> >
> > Without hunting the archives, there were several discussions around the
> > last Board election that people wanted a way to ask questions of the
> > candidates. But I dunno, maybe if you look at it you'll find that it
> > was three people making all the noise. :D
>
> To sum it up, and without going back and scouring archives, we received
> a number of complaints from community members both inside and outside
> Red Hat that elections for FESCo and the Board aren't informed by
> understanding where nominees stand on any issues. The complaints were
> that voters have no information on which to make informed choice, but
> rather vote for whom they recognize, meaning the results will always be
> slanted toward people who happen to be getting paid to work on Fedora
> all the time.
>
> I remember specifically suggesting in a Board meeting that community
> questions could just as easily be picked up on a wiki page and then
> answers solicited from the nominees. By suggesting that option I was
> hoping that we would not let "scalability" get in the way of
> responsiveness to the community. I think scalability is a very good
> thing, but we're trying to solve an unquantified problem with an equally
> unquantified solution. That's sometimes unavoidable when dealing with
> qualitative issues like community satisfaction.
>
> As I recollect that conversation, we agreed that collecting questions on
> the wiki was the right way to go in the short term, and that the amount
> of community response would determine whether we pursued something more
> comprehensive.
Sorry to reply to myself. The Board has been discussing this during
the day and seems to agree that switching election systems right now
makes little sense. We can easily revisit the issue but we should
have a better understanding of the problem we're trying to solve
before doing so.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From jkeating at redhat.com Wed Oct 15 19:02:44 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 15 Oct 2008 12:02:44 -0700
Subject: Fedora Remix mark
In-Reply-To: <1223567677.13014.57.camel@localhost.localdomain>
References: <1223567677.13014.57.camel@localhost.localdomain>
Message-ID: <1224097365.4122.48.camel@luminos.localdomain>
On Thu, 2008-10-09 at 15:54 +0000, Paul W. Frields wrote:
> This is the page where I collected your contributions to a design. The
> time's come for me to refer the design candidates to the Board for
> approval.
Yay art opinions!
So, I strongly dislike what is done to the R of Remix in "13". Maybe my
eyes suck, but it just looks like something went wrong when drawing the
R.
Overall I think I prefer the rounded 9, although I can't tell much
difference between it and all the choices from Jay and Nicu, except for
the (mis)spelling of "remix", and well, COLORS!
I'd prefer something like 9, with remix spelled correctly, and as many
color options as possible.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
From kwade at redhat.com Wed Oct 15 19:19:45 2008
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 15 Oct 2008 12:19:45 -0700
Subject: Fedora Remix mark
In-Reply-To: <1224097365.4122.48.camel@luminos.localdomain>
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
Message-ID: <1224098385.28571.192.camel@calliope.phig.org>
On Wed, 2008-10-15 at 12:02 -0700, Jesse Keating wrote:
> On Thu, 2008-10-09 at 15:54 +0000, Paul W. Frields wrote:
> > This is the page where I collected your contributions to a design. The
> > time's come for me to refer the design candidates to the Board for
> > approval.
>
> Yay art opinions!
>
> So, I strongly dislike what is done to the R of Remix in "13". Maybe my
> eyes suck, but it just looks like something went wrong when drawing the
> R.
+1
I find it distracting.
> Overall I think I prefer the rounded 9, although I can't tell much
> difference between it and all the choices from Jay and Nicu, except for
> the (mis)spelling of "remix", and well, COLORS!
>
> I'd prefer something like 9, with remix spelled correctly, and as many
> color options as possible.
I'll +0.5 this because I think it's the closest compromise we'll get to.
That is, I *prefer* the intentional misspelling of remix (I think I
slightly prefer the '!' over the '1',) but with Bill and Jesse
(apparently) against it, it might be a bike shed issue not to get in to.
If, however, the 'i' isn't an option, for example Legal really liked the
misspelling, then I'm most in favor of the ones like 9b with COLORS!
- Karsten
--
Karsten Wade, Community Gardener
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From gdk at redhat.com Wed Oct 15 19:40:43 2008
From: gdk at redhat.com (Greg Dekoenigsberg)
Date: Wed, 15 Oct 2008 15:40:43 -0400 (EDT)
Subject: Fedora Remix mark
In-Reply-To: <1224097365.4122.48.camel@luminos.localdomain>
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
Message-ID:
On Wed, 15 Oct 2008, Jesse Keating wrote:
> On Thu, 2008-10-09 at 15:54 +0000, Paul W. Frields wrote:
>> This is the page where I collected your contributions to a design. The
>> time's come for me to refer the design candidates to the Board for
>> approval.
>
> Yay art opinions!
>
> So, I strongly dislike what is done to the R of Remix in "13". Maybe my
> eyes suck, but it just looks like something went wrong when drawing the
> R.
>
> Overall I think I prefer the rounded 9, although I can't tell much
> difference between it and all the choices from Jay and Nicu, except for
> the (mis)spelling of "remix", and well, COLORS!
>
> I'd prefer something like 9, with remix spelled correctly, and as many
> color options as possible.
I don't suppose we could just defer to the Fedora Art team to make a
decision, since we have set them up to be the authoritative voice on
precisely these kinds of matters?
I'd rather see Mo/Nicu/et al making the call than Jesse. Not that I don't
love Jesse. ;)
--g
From stickster at gmail.com Wed Oct 15 19:50:32 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 15 Oct 2008 19:50:32 +0000
Subject: Fedora Remix mark
In-Reply-To:
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
Message-ID: <1224100232.22899.81.camel@victoria-eth.internal.frields.org>
On Wed, 2008-10-15 at 15:40 -0400, Greg Dekoenigsberg wrote:
> On Wed, 15 Oct 2008, Jesse Keating wrote:
>
> > On Thu, 2008-10-09 at 15:54 +0000, Paul W. Frields wrote:
> >> This is the page where I collected your contributions to a design. The
> >> time's come for me to refer the design candidates to the Board for
> >> approval.
> >
> > Yay art opinions!
> >
> > So, I strongly dislike what is done to the R of Remix in "13". Maybe my
> > eyes suck, but it just looks like something went wrong when drawing the
> > R.
> >
> > Overall I think I prefer the rounded 9, although I can't tell much
> > difference between it and all the choices from Jay and Nicu, except for
> > the (mis)spelling of "remix", and well, COLORS!
> >
> > I'd prefer something like 9, with remix spelled correctly, and as many
> > color options as possible.
>
> I don't suppose we could just defer to the Fedora Art team to make a
> decision, since we have set them up to be the authoritative voice on
> precisely these kinds of matters?
>
> I'd rather see Mo/Nicu/et al making the call than Jesse. Not that I don't
> love Jesse. ;)
I'm OK with that call. I think the rounded banner definitely works best
in everyone's opinion as being more thematically related to the font
choices. So Artwork team, what do you say?
--
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From mspevack at redhat.com Wed Oct 15 20:30:36 2008
From: mspevack at redhat.com (Max Spevack)
Date: Wed, 15 Oct 2008 22:30:36 +0200 (CEST)
Subject: Fedora Remix mark
In-Reply-To:
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
Message-ID:
On Wed, 15 Oct 2008, Greg Dekoenigsberg wrote:
> I don't suppose we could just defer to the Fedora Art team to make a
> decision, since we have set them up to be the authoritative voice on
> precisely these kinds of matters?
+1 -- this is how we prevent bikeshedding. Delegate choices to the
appropriate project, with the Fedora Board ensuring overall sanity.
From skvidal at fedoraproject.org Wed Oct 15 20:50:43 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 15 Oct 2008 16:50:43 -0400
Subject: Fedora Remix mark
In-Reply-To:
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
Message-ID: <1224103843.21581.21.camel@rosebud>
On Wed, 2008-10-15 at 15:40 -0400, Greg Dekoenigsberg wrote:
> On Wed, 15 Oct 2008, Jesse Keating wrote:
>
> > On Thu, 2008-10-09 at 15:54 +0000, Paul W. Frields wrote:
> >> This is the page where I collected your contributions to a design. The
> >> time's come for me to refer the design candidates to the Board for
> >> approval.
> >
> > Yay art opinions!
> >
> > So, I strongly dislike what is done to the R of Remix in "13". Maybe my
> > eyes suck, but it just looks like something went wrong when drawing the
> > R.
> >
> > Overall I think I prefer the rounded 9, although I can't tell much
> > difference between it and all the choices from Jay and Nicu, except for
> > the (mis)spelling of "remix", and well, COLORS!
> >
> > I'd prefer something like 9, with remix spelled correctly, and as many
> > color options as possible.
>
> I don't suppose we could just defer to the Fedora Art team to make a
> decision, since we have set them up to be the authoritative voice on
> precisely these kinds of matters?
Yes, agreed.
-sv
From duffy at fedoraproject.org Wed Oct 15 21:16:34 2008
From: duffy at fedoraproject.org (=?ISO-8859-1?Q?M=E1ir=EDn_Duffy?=)
Date: Wed, 15 Oct 2008 17:16:34 -0400
Subject: Fedora Remix mark
In-Reply-To: <1224100232.22899.81.camel@victoria-eth.internal.frields.org>
References: <1223567677.13014.57.camel@localhost.localdomain> <1224097365.4122.48.camel@luminos.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
Message-ID: <48F65DB2.8080209@fedoraproject.org>
Paul W. Frields wrote:
> On Wed, 2008-10-15 at 15:40 -0400, Greg Dekoenigsberg wrote:
>> On Wed, 15 Oct 2008, Jesse Keating wrote:
>>
>>> On Thu, 2008-10-09 at 15:54 +0000, Paul W. Frields wrote:
>>>> This is the page where I collected your contributions to a design. The
>>>> time's come for me to refer the design candidates to the Board for
>>>> approval.
>>> Yay art opinions!
>>>
>>> So, I strongly dislike what is done to the R of Remix in "13". Maybe my
>>> eyes suck, but it just looks like something went wrong when drawing the
>>> R.
>>>
>>> Overall I think I prefer the rounded 9, although I can't tell much
>>> difference between it and all the choices from Jay and Nicu, except for
>>> the (mis)spelling of "remix", and well, COLORS!
>>>
>>> I'd prefer something like 9, with remix spelled correctly, and as many
>>> color options as possible.
>> I don't suppose we could just defer to the Fedora Art team to make a
>> decision, since we have set them up to be the authoritative voice on
>> precisely these kinds of matters?
>>
>> I'd rather see Mo/Nicu/et al making the call than Jesse. Not that I don't
>> love Jesse. ;)
>
> I'm OK with that call. I think the rounded banner definitely works best
> in everyone's opinion as being more thematically related to the font
> choices. So Artwork team, what do you say?
My recommendation is this design, but let's try it with
remix spelled out normally instead of with the !.
https://fedoraproject.org/w/uploads/6/61/Fedora_secondary_logo_drafts_nicubunu_color.png
Do we need to provide a palette of possible colors? Or is it
okay to be open-ended in the usage guidelines for this mark?
Or both? :)
~m
From jkeating at redhat.com Wed Oct 15 22:03:32 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 15 Oct 2008 15:03:32 -0700
Subject: Fedora Remix mark
In-Reply-To:
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
Message-ID: <1224108212.4122.51.camel@luminos.localdomain>
On Wed, 2008-10-15 at 15:40 -0400, Greg Dekoenigsberg wrote:
> I'd rather see Mo/Nicu/et al making the call than Jesse. Not that I
> don't
> love Jesse. ;)
I'm fine with that. More than fine actually.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
From ianweller at gmail.com Wed Oct 15 23:10:04 2008
From: ianweller at gmail.com (Ian Weller)
Date: Wed, 15 Oct 2008 18:10:04 -0500
Subject: Fedora Remix mark
In-Reply-To: <1224100232.22899.81.camel@victoria-eth.internal.frields.org>
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
Message-ID: <20081015231004.GB13790@gmail.com>
On Wed, Oct 15, 2008 at 07:50:32PM +0000, Paul W. Frields wrote:
> So Artwork team, what do you say?
>
I guess I'll put in my USD 0.02. Some of it might not be coherent or
related to the current decisions already made.
Design 13 makes the most sense to me out of all the ones on that page,
but I think that having it white on a blue background makes the logo
itself too cluttered. I'd prefer #13 in the first mizmo-draft.
Using a 1 (one) in place of the I (aye) is a bad idea IMHO -- or even an
exclamation point. The 1 detracts, makes us look more like 13-year-old
"h4x0rs" (funny I'm saying that, hehe) on the web being generally
annoying. The exclamation point distracts even more.
I do like the different color concepts brought up by nicu, but perhaps
they'd be better suited for the text color, going back to my reasoning
for not having a colored background behind "remix". The differing colors
might even have a purpose (classification of different remixes, maybe?) --
but who knows?
And I'm loving the little arrow thing on the 'R'.
--
Ian Weller http://ianweller.org
GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36
"Technology is a word that describes something that doesn't work yet."
~ Douglas Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
From kwade at redhat.com Wed Oct 15 23:53:58 2008
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 15 Oct 2008 16:53:58 -0700
Subject: Fedora Remix mark
In-Reply-To:
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
Message-ID: <1224114838.28571.208.camel@calliope.phig.org>
On Wed, 2008-10-15 at 22:30 +0200, Max Spevack wrote:
> On Wed, 15 Oct 2008, Greg Dekoenigsberg wrote:
>
> > I don't suppose we could just defer to the Fedora Art team to make a
> > decision, since we have set them up to be the authoritative voice on
> > precisely these kinds of matters?
>
> +1 -- this is how we prevent bikeshedding. Delegate choices to the
> appropriate project, with the Fedora Board ensuring overall sanity.
I presumed that choices had already been vetted by Art and what we were
presented with was a stalemate or set of choices that Art wanted a
decision on. If that hasn't happened (yet), then definitely let it.
- Karsten
--
Karsten Wade, Community Gardener
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From stickster at gmail.com Thu Oct 16 11:45:12 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 16 Oct 2008 11:45:12 +0000
Subject: Proposal for Board: Keeping infra open for EOL
In-Reply-To: <1224116401.8840.24.camel@kennedy>
References: <1224116401.8840.24.camel@kennedy>
Message-ID: <1224157512.3335.88.camel@victoria-eth>
On Wed, 2008-10-15 at 20:20 -0400, Brian Pepple wrote:
> Hey Paul,
>
> In today's FESCo meeting we discussed a proposal(1) to keep the
> infrastructure open for EOL branches (which came from the Fedora Legacy
> thread on the devel-list). We felt that the Board needs to also
> weigh-in on this, since it deals with:
>
> 1. Goals of the project
> 2. Use of the 'Fedora' brand (including possibly the trademarks)
> 3. Infrastructure
>
> If the Board could look at this during the next board meeting, it would
> be appreciated.
>
> 1)
> https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EOL
I'm reposting this here to FAB (with Brian's blessing), mostly for the
sake of transparency. The page linked above also has a "Discussion" tab
which has been populated by some of the FESCo members. Let's add this
to the upcoming week's agenda. We needn't rehash the ever-expanding
thread-o'-doom on fedora-devel-list here, but we should consider the
balance between Fedora's stated objectives[1], and the desire to allow
contributors the freedom to pursue new avenues.
= = =
[1] https://fedoraproject.org/wiki/Objectives
--
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From stickster at gmail.com Thu Oct 16 12:38:16 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 16 Oct 2008 12:38:16 +0000
Subject: Fedora Remix mark
In-Reply-To: <48F6EF9A.4010201@nicubunu.ro>
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
<48F65DB2.8080209@fedoraproject.org> <48F6EF9A.4010201@nicubunu.ro>
Message-ID: <1224160697.3335.98.camel@victoria-eth>
On Thu, 2008-10-16 at 10:39 +0300, Nicu Buculei wrote:
> M?ir?n Duffy wrote:
> > My recommendation is this design, but let's try it with
> > remix spelled out normally instead of with the !.
> >
> > https://fedoraproject.org/w/uploads/6/61/Fedora_secondary_logo_drafts_nicubunu_color.png
>
> Added an update:
> https://fedoraproject.org/wiki/Image:Fedora_secondary_logo_drafts_nicubunu_color1.png
>
> > Do we need to provide a palette of possible colors? Or is it
> > okay to be open-ended in the usage guidelines for this mark?
> > Or both? :)
>
> This time I tried a single logo and a swatch for the other colors (used
> Agave to find fitting colors)
Very nice. I'm not sure how Agave picks colors, but I've been impressed
with the results on the rare occasions I've used it!
Once the Artwork team is happy with and approves a logo, there are a
couple more treatments that would be helpful:
* for use on dark backgrounds
* one or two monochromatic versions
Please let me know when as soon as you can when you've approved a logo
-- there's at least one party queued up to use it.
--
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From bkearney at redhat.com Thu Oct 16 12:54:47 2008
From: bkearney at redhat.com (Bryan Kearney)
Date: Thu, 16 Oct 2008 08:54:47 -0400
Subject: Fedora Remix mark
In-Reply-To: <1224160697.3335.98.camel@victoria-eth>
References: <1223567677.13014.57.camel@localhost.localdomain> <1224097365.4122.48.camel@luminos.localdomain> <1224100232.22899.81.camel@victoria-eth.internal.frields.org> <48F65DB2.8080209@fedoraproject.org>
<48F6EF9A.4010201@nicubunu.ro>
<1224160697.3335.98.camel@victoria-eth>
Message-ID: <48F73997.5000306@redhat.com>
Paul W. Frields wrote:
> On Thu, 2008-10-16 at 10:39 +0300, Nicu Buculei wrote:
>> M?ir?n Duffy wrote:
>>> My recommendation is this design, but let's try it with
>>> remix spelled out normally instead of with the !.
>>>
>>> https://fedoraproject.org/w/uploads/6/61/Fedora_secondary_logo_drafts_nicubunu_color.png
>> Added an update:
>> https://fedoraproject.org/wiki/Image:Fedora_secondary_logo_drafts_nicubunu_color1.png
>>
>>> Do we need to provide a palette of possible colors? Or is it
>>> okay to be open-ended in the usage guidelines for this mark?
>>> Or both? :)
>> This time I tried a single logo and a swatch for the other colors (used
>> Agave to find fitting colors)
>
> Very nice. I'm not sure how Agave picks colors, but I've been impressed
> with the results on the rare occasions I've used it!
>
> Once the Artwork team is happy with and approves a logo, there are a
> couple more treatments that would be helpful:
>
> * for use on dark backgrounds
> * one or two monochromatic versions
>
> Please let me know when as soon as you can when you've approved a logo
> -- there's at least one party queued up to use it.
We are working on a Jboss spin, which would be nice to use. Do you have
plans in place for a logos rpm?
-- bk
From sebastian at when.com Thu Oct 16 13:10:50 2008
From: sebastian at when.com (Sebastian Dziallas)
Date: Thu, 16 Oct 2008 15:10:50 +0200
Subject: Requesting Trademark Approval for Sugar Spin
Message-ID: <48F73D5A.5090908@when.com>
Hi everybody,
as you may have noticed, the OLPC SIG has been working on a spin
including the Sugar Desktop Environment. Recently, this spin has been
pushed into the Spin SIG's GIT repository and I felt it was time to
request trademark approval from the board for it.
The kickstart file is located here:
http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=blob;f=fedora-livecd-sugar.ks;
There are some things which should be explained, though.
For example, we're disabling SELinux just temporarily - it will be
enabled again as soon as bug #467118 gets fixed (#466884 has already
been closed). Concerning the choice of the display manager, it should be
mentioned that we chose slim instead of gdm, since it pulls in less
dependencies and should be more light-weight.
Best Regards,
Sebastian Dziallas
From nicu_fedora at nicubunu.ro Thu Oct 16 07:39:06 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Thu, 16 Oct 2008 10:39:06 +0300
Subject: Fedora Remix mark
In-Reply-To: <48F65DB2.8080209@fedoraproject.org>
References: <1223567677.13014.57.camel@localhost.localdomain> <1224097365.4122.48.camel@luminos.localdomain> <1224100232.22899.81.camel@victoria-eth.internal.frields.org>
<48F65DB2.8080209@fedoraproject.org>
Message-ID: <48F6EF9A.4010201@nicubunu.ro>
M?ir?n Duffy wrote:
> My recommendation is this design, but let's try it with
> remix spelled out normally instead of with the !.
>
> https://fedoraproject.org/w/uploads/6/61/Fedora_secondary_logo_drafts_nicubunu_color.png
Added an update:
https://fedoraproject.org/wiki/Image:Fedora_secondary_logo_drafts_nicubunu_color1.png
> Do we need to provide a palette of possible colors? Or is it
> okay to be open-ended in the usage guidelines for this mark?
> Or both? :)
This time I tried a single logo and a swatch for the other colors (used
Agave to find fitting colors)
--
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro
From notting at redhat.com Thu Oct 16 13:43:30 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 16 Oct 2008 09:43:30 -0400
Subject: Requesting Trademark Approval for Sugar Spin
In-Reply-To: <48F73D5A.5090908@when.com>
References: <48F73D5A.5090908@when.com>
Message-ID: <20081016134330.GD20184@nostromo.devel.redhat.com>
Sebastian Dziallas (sebastian at when.com) said:
> Hi everybody,
>
> as you may have noticed, the OLPC SIG has been working on a spin
> including the Sugar Desktop Environment. Recently, this spin has been
> pushed into the Spin SIG's GIT repository and I felt it was time to
> request trademark approval from the board for it.
>
> The kickstart file is located here:
>
> http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=blob;f=fedora-livecd-sugar.ks;
>
> There are some things which should be explained, though.
>
> For example, we're disabling SELinux just temporarily - it will be
> enabled again as soon as bug #467118 gets fixed (#466884 has already
> been closed). Concerning the choice of the display manager, it should be
> mentioned that we chose slim instead of gdm, since it pulls in less
> dependencies and should be more light-weight.
If you're turning off sendmail, why not remove it? Are you using cups
and bluetooth via some other methods? (otherwise they can be removed as well.)
Aside from that, looks sane to me (given the SELinux caveat.)
Bill
From kanarip at kanarip.com Thu Oct 16 14:09:17 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 16 Oct 2008 16:09:17 +0200
Subject: Requesting Trademark Approval for Sugar Spin
In-Reply-To: <20081016134330.GD20184@nostromo.devel.redhat.com>
References: <48F73D5A.5090908@when.com>
<20081016134330.GD20184@nostromo.devel.redhat.com>
Message-ID: <48F74B0D.8090507@kanarip.com>
Bill Nottingham wrote:
> If you're turning off sendmail, why not remove it? Are you using cups
> and bluetooth via some other methods? (otherwise they can be removed as well.)
>
Technical review is done at the Spin SIG technical review stage, maybe
you want to chime in there instead.
Kind regards,
Jeroen van Meeuwen
-kanarip
From tcallawa at redhat.com Thu Oct 16 16:46:03 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 16 Oct 2008 12:46:03 -0400
Subject: Fedora Remix mark
In-Reply-To: <48F73997.5000306@redhat.com>
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
<48F65DB2.8080209@fedoraproject.org> <48F6EF9A.4010201@nicubunu.ro>
<1224160697.3335.98.camel@victoria-eth> <48F73997.5000306@redhat.com>
Message-ID: <1224175563.2529.13.camel@localhost.localdomain>
On Thu, 2008-10-16 at 08:54 -0400, Bryan Kearney wrote:
> We are working on a Jboss spin, which would be nice to use. Do you
> have
> plans in place for a logos rpm?
I'll probably whip up a "fedora-remix-logos" package once we have the
licensing and guidelines set in stone.
~spot
From jspaleta at gmail.com Thu Oct 16 16:54:32 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 16 Oct 2008 08:54:32 -0800
Subject: Fedora Remix mark
In-Reply-To: <1224175563.2529.13.camel@localhost.localdomain>
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
<48F65DB2.8080209@fedoraproject.org> <48F6EF9A.4010201@nicubunu.ro>
<1224160697.3335.98.camel@victoria-eth> <48F73997.5000306@redhat.com>
<1224175563.2529.13.camel@localhost.localdomain>
Message-ID: <604aa7910810160954p4c0268ebk3281dfa5ec35aa55@mail.gmail.com>
On Thu, Oct 16, 2008 at 8:46 AM, Tom spot Callaway
> I'll probably whip up a "fedora-remix-logos" package once we have the
> licensing and guidelines set in stone.
And maybe remix-release and remix-release-notes to match the generic-*
package set we have now?
I guess there will be some sort of discussion on when its okay for the
fedora-remix-logos package to be used instead of the generic-logos
package. Or does the remix mark let us do away with the generic-logos
concept completely?
-jef
From tcallawa at redhat.com Thu Oct 16 17:01:30 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 16 Oct 2008 13:01:30 -0400
Subject: Fedora Remix mark
In-Reply-To: <604aa7910810160954p4c0268ebk3281dfa5ec35aa55@mail.gmail.com>
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
<48F65DB2.8080209@fedoraproject.org> <48F6EF9A.4010201@nicubunu.ro>
<1224160697.3335.98.camel@victoria-eth> <48F73997.5000306@redhat.com>
<1224175563.2529.13.camel@localhost.localdomain>
<604aa7910810160954p4c0268ebk3281dfa5ec35aa55@mail.gmail.com>
Message-ID: <1224176490.2529.18.camel@localhost.localdomain>
On Thu, 2008-10-16 at 08:54 -0800, Jeff Spaleta wrote:
> On Thu, Oct 16, 2008 at 8:46 AM, Tom spot Callaway
> > I'll probably whip up a "fedora-remix-logos" package once we have the
> > licensing and guidelines set in stone.
>
> And maybe remix-release and remix-release-notes to match the generic-*
> package set we have now?
Ehh. I think that using fedora-remix-logos + generic-release is fine.
Most people who are using the Fedora Remix mark will have a custom
-release package anyways.
> I guess there will be some sort of discussion on when its okay for the
> fedora-remix-logos package to be used instead of the generic-logos
> package. Or does the remix mark let us do away with the generic-logos
> concept completely?
No, because there are still use-cases where we do not permit someone to
use the Fedora Remix mark.
~spot
From notting at redhat.com Thu Oct 16 17:09:47 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 16 Oct 2008 13:09:47 -0400
Subject: Fedora Remix mark
In-Reply-To: <1224175563.2529.13.camel@localhost.localdomain>
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
<48F65DB2.8080209@fedoraproject.org> <48F6EF9A.4010201@nicubunu.ro>
<1224160697.3335.98.camel@victoria-eth>
<48F73997.5000306@redhat.com>
<1224175563.2529.13.camel@localhost.localdomain>
Message-ID: <20081016170947.GE23397@nostromo.devel.redhat.com>
Tom spot Callaway (tcallawa at redhat.com) said:
> On Thu, 2008-10-16 at 08:54 -0400, Bryan Kearney wrote:
> > We are working on a Jboss spin, which would be nice to use. Do you
> > have
> > plans in place for a logos rpm?
>
> I'll probably whip up a "fedora-remix-logos" package once we have the
> licensing and guidelines set in stone.
So Art is now going to be responsible for three versions of all
artwork? That may be somewhat onerous (or at least irritating) for
them.
Bill
From tcallawa at redhat.com Thu Oct 16 17:13:55 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 16 Oct 2008 13:13:55 -0400
Subject: Fedora Remix mark
In-Reply-To: <20081016170947.GE23397@nostromo.devel.redhat.com>
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
<48F65DB2.8080209@fedoraproject.org> <48F6EF9A.4010201@nicubunu.ro>
<1224160697.3335.98.camel@victoria-eth> <48F73997.5000306@redhat.com>
<1224175563.2529.13.camel@localhost.localdomain>
<20081016170947.GE23397@nostromo.devel.redhat.com>
Message-ID: <1224177235.2529.20.camel@localhost.localdomain>
On Thu, 2008-10-16 at 13:09 -0400, Bill Nottingham wrote:
> Tom spot Callaway (tcallawa at redhat.com) said:
> > On Thu, 2008-10-16 at 08:54 -0400, Bryan Kearney wrote:
> > > We are working on a Jboss spin, which would be nice to use. Do you
> > > have
> > > plans in place for a logos rpm?
> >
> > I'll probably whip up a "fedora-remix-logos" package once we have the
> > licensing and guidelines set in stone.
>
> So Art is now going to be responsible for three versions of all
> artwork? That may be somewhat onerous (or at least irritating) for
> them.
Uhh, the only thing that would be in "fedora-remix-logos" would be the
approved color variants of the chosen remix logos. We're not really
tripling their work. People can layer the remix logo on top of other
artwork as needed (within the licensing and guidelines, of course).
~spot
From notting at redhat.com Thu Oct 16 17:20:38 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 16 Oct 2008 13:20:38 -0400
Subject: Fedora Remix mark
In-Reply-To: <1224177235.2529.20.camel@localhost.localdomain>
References: <1224097365.4122.48.camel@luminos.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
<48F65DB2.8080209@fedoraproject.org> <48F6EF9A.4010201@nicubunu.ro>
<1224160697.3335.98.camel@victoria-eth>
<48F73997.5000306@redhat.com>
<1224175563.2529.13.camel@localhost.localdomain>
<20081016170947.GE23397@nostromo.devel.redhat.com>
<1224177235.2529.20.camel@localhost.localdomain>
Message-ID: <20081016172038.GG23397@nostromo.devel.redhat.com>
Tom spot Callaway (tcallawa at redhat.com) said:
> > So Art is now going to be responsible for three versions of all
> > artwork? That may be somewhat onerous (or at least irritating) for
> > them.
>
> Uhh, the only thing that would be in "fedora-remix-logos" would be the
> approved color variants of the chosen remix logos. We're not really
> tripling their work. People can layer the remix logo on top of other
> artwork as needed (within the licensing and guidelines, of course).
We already have to duplicate any artwork in fedora-logos that includes
the logotype, etc. for generic-logos; what you're saying is that
fedora-remix-logos would be a separate package, and users of it would
still need generic-logos?
Bill
From tcallawa at redhat.com Thu Oct 16 17:31:29 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 16 Oct 2008 13:31:29 -0400
Subject: Fedora Remix mark
In-Reply-To: <20081016172038.GG23397@nostromo.devel.redhat.com>
References: <1224097365.4122.48.camel@luminos.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
<48F65DB2.8080209@fedoraproject.org> <48F6EF9A.4010201@nicubunu.ro>
<1224160697.3335.98.camel@victoria-eth> <48F73997.5000306@redhat.com>
<1224175563.2529.13.camel@localhost.localdomain>
<20081016170947.GE23397@nostromo.devel.redhat.com>
<1224177235.2529.20.camel@localhost.localdomain>
<20081016172038.GG23397@nostromo.devel.redhat.com>
Message-ID: <1224178289.2529.27.camel@localhost.localdomain>
On Thu, 2008-10-16 at 13:20 -0400, Bill Nottingham wrote:
> Tom spot Callaway (tcallawa at redhat.com) said:
> > > So Art is now going to be responsible for three versions of all
> > > artwork? That may be somewhat onerous (or at least irritating) for
> > > them.
> >
> > Uhh, the only thing that would be in "fedora-remix-logos" would be the
> > approved color variants of the chosen remix logos. We're not really
> > tripling their work. People can layer the remix logo on top of other
> > artwork as needed (within the licensing and guidelines, of course).
>
> We already have to duplicate any artwork in fedora-logos that includes
> the logotype, etc. for generic-logos; what you're saying is that
> fedora-remix-logos would be a separate package, and users of it would
> still need generic-logos?
So, here's how it works:
We're making a Fedora Remix logo. It will come in several, pretty
colors, but it will be the same logo. This logo will not have a
background color, instead, it will have a transparent background. This
logo (in its many color incarnations) will be approved for use in
accordance with the Fedora Secondary Trademark Guidelines.
So, lets say I decide to make a spin of Fedora that is all about
Dinosaurs. I've customized the background, images, and added Dinosaur
specific programs. I've looked through the Fedora Secondary Trademark
Guidelines and confirmed that I am permitted to use the Fedora Remix
logo without having to get any special permission from Fedora. I then
call my spin "Dinosaur Linux: A Fedora Remix". I make custom images for
Dinosaur Linux, upon which I can paste one of the Fedora Remix logos
from the fedora-remix-logos package. I can't use any of the logos in
fedora-logos package because I'm not an approved Fedora spin, but I
could use the generic-logos replacement if I wanted to.
It is possible that someone's spin may not meet the criteria to use the
Fedora Remix mark, so we can't just put these new logos into
generic-logos.
Does that make sense?
~spot
From sundaram at fedoraproject.org Thu Oct 16 18:38:01 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 17 Oct 2008 00:08:01 +0530
Subject: Fedora Remix mark
In-Reply-To: <1224178289.2529.27.camel@localhost.localdomain>
References: <1224097365.4122.48.camel@luminos.localdomain> <1224100232.22899.81.camel@victoria-eth.internal.frields.org> <48F65DB2.8080209@fedoraproject.org>
<48F6EF9A.4010201@nicubunu.ro> <1224160697.3335.98.camel@victoria-eth>
<48F73997.5000306@redhat.com> <1224175563.2529.13.camel@localhost.localdomain> <20081016170947.GE23397@nostromo.devel.redhat.com> <1224177235.2529.20.camel@localhost.localdomain> <20081016172038.GG23397@nostromo.devel.redhat.com>
<1224178289.2529.27.camel@localhost.localdomain>
Message-ID: <48F78A09.50501@fedoraproject.org>
Tom "spot" Callaway wrote:
> It is possible that someone's spin may not meet the criteria to use the
> Fedora Remix mark, so we can't just put these new logos into
> generic-logos.
>
> Does that make sense?
The newly proposed trademark guidelines don't seem to have apprehensions
against granting the remix branding rights to pretty much anyone. So,
what use cases are you thinking of that wouldn't get the remix usage
rights? Can we make it more explicit in the proposed guidelines?
Rahul
From kwade at redhat.com Thu Oct 16 19:10:55 2008
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Thu, 16 Oct 2008 12:10:55 -0700
Subject: Fedora Remix mark
In-Reply-To: <604aa7910810160954p4c0268ebk3281dfa5ec35aa55@mail.gmail.com>
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224097365.4122.48.camel@luminos.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
<48F65DB2.8080209@fedoraproject.org> <48F6EF9A.4010201@nicubunu.ro>
<1224160697.3335.98.camel@victoria-eth> <48F73997.5000306@redhat.com>
<1224175563.2529.13.camel@localhost.localdomain>
<604aa7910810160954p4c0268ebk3281dfa5ec35aa55@mail.gmail.com>
Message-ID: <1224184255.28571.226.camel@calliope.phig.org>
On Thu, 2008-10-16 at 08:54 -0800, Jeff Spaleta wrote:
> On Thu, Oct 16, 2008 at 8:46 AM, Tom spot Callaway
> > I'll probably whip up a "fedora-remix-logos" package once we have the
> > licensing and guidelines set in stone.
>
> And maybe remix-release and remix-release-notes to match the generic-*
> package set we have now?
I don't see us producing a remix-release-notes. fedora-release-notes
_could_ be built to be made generic, as per the generic-logos, but it's
not there.
I'm unclear if it is an imperative that we do make that possible. The
release notes are a snapshot in time of the packages, and are out of
date fairly quickly with package updates. Someone doing a remix and
wanting to base on fedora-release-notes would need to confirm and update
all the content; excise out irrelevant content; etc.
Until someone wants it and is willing to do the work to make it happen,
a {generic,remix}-release-notes is unlikely.
- Karsten
--
Karsten Wade, Community Gardener
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From jspaleta at gmail.com Thu Oct 16 19:20:51 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 16 Oct 2008 11:20:51 -0800
Subject: Fedora Remix mark
In-Reply-To: <1224184255.28571.226.camel@calliope.phig.org>
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
<48F65DB2.8080209@fedoraproject.org> <48F6EF9A.4010201@nicubunu.ro>
<1224160697.3335.98.camel@victoria-eth> <48F73997.5000306@redhat.com>
<1224175563.2529.13.camel@localhost.localdomain>
<604aa7910810160954p4c0268ebk3281dfa5ec35aa55@mail.gmail.com>
<1224184255.28571.226.camel@calliope.phig.org>
Message-ID: <604aa7910810161220w2702f8f6g43f42edc27abe20f@mail.gmail.com>
On Thu, Oct 16, 2008 at 11:10 AM, Karsten 'quaid' Wade
> Until someone wants it and is willing to do the work to make it happen,
> a {generic,remix}-release-notes is unlikely.
yum list "generic*"
generic-logos.noarch 9.99.0-1.fc10 rawhide
generic-release.noarch 9.91-2 rawhide
generic-release-notes.noarch 9.91-2 rawhide
I wasn't talking about packages with actual content. The generic
package family is constructed so that the trademark encumbered fedora
packages are not accidentally pulled in as the only package which
fills a specific dep.. like the system-release or system-release-notes
dep. The exist as stubs to ensure dep closure for spin developers.
-jef
From jspaleta at gmail.com Thu Oct 16 19:20:51 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 16 Oct 2008 11:20:51 -0800
Subject: Fedora Remix mark
In-Reply-To: <1224184255.28571.226.camel@calliope.phig.org>
References: <1223567677.13014.57.camel@localhost.localdomain>
<1224100232.22899.81.camel@victoria-eth.internal.frields.org>
<48F65DB2.8080209@fedoraproject.org> <48F6EF9A.4010201@nicubunu.ro>
<1224160697.3335.98.camel@victoria-eth> <48F73997.5000306@redhat.com>
<1224175563.2529.13.camel@localhost.localdomain>
<604aa7910810160954p4c0268ebk3281dfa5ec35aa55@mail.gmail.com>
<1224184255.28571.226.camel@calliope.phig.org>
Message-ID: <604aa7910810161220w2702f8f6g43f42edc27abe20f@mail.gmail.com>
On Thu, Oct 16, 2008 at 11:10 AM, Karsten 'quaid' Wade
> Until someone wants it and is willing to do the work to make it happen,
> a {generic,remix}-release-notes is unlikely.
yum list "generic*"
generic-logos.noarch 9.99.0-1.fc10 rawhide
generic-release.noarch 9.91-2 rawhide
generic-release-notes.noarch 9.91-2 rawhide
I wasn't talking about packages with actual content. The generic
package family is constructed so that the trademark encumbered fedora
packages are not accidentally pulled in as the only package which
fills a specific dep.. like the system-release or system-release-notes
dep. The exist as stubs to ensure dep closure for spin developers.
-jef
From poelstra at redhat.com Fri Oct 17 02:11:51 2008
From: poelstra at redhat.com (John Poelstra)
Date: Thu, 16 Oct 2008 19:11:51 -0700
Subject: Fedora Board Recap 2008-OCT-14
Message-ID: <48F7F467.5050306@redhat.com>
https://fedoraproject.org/wiki/Board/Meetings/2008-10-14
== Roll Call ==
Attendees: John Poelstra, Paul Frields, Matt Domsch, Bill Nottingham,
Seth Vidal, Jesse Keating, Spot Callaway, Chris Tyler, Harald Hoyer,
Karsten Wade
Regrets: Jef Spaleta
== MinGW (2008-07-15) ==
https://fedoraproject.org/wiki/Board/Meetings/2008-07-15#Mingw
* So far approximately 50 packages
* Release Engineering reports that cost of coming up with separate
infrastructure as previously requested by the board appears to far
outweigh the benefits
**
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-oct-13#MinGW_Repos
* '''RESOLUTION''':
** Board removes its original requirement that the MinGW packages be
separated from the main Fedora repos though may revisit in the future if
issues arise
** Board continues to leave ongoing implementation details to FESCo
== Trademark Update ==
* Guidelines are fully approved by legal counsel
* Paul needs to finish out page describing usage guidelines around the
secondary mark
** Allowed uses of colors and backgrounds
* Spot will add to legal section of Fedora wiki once Paul makes final
changes
* '''ACTION'''
** Everyone should join in voting on fedora-advisory-board at redhat.com
**
http://www.redhat.com/archives/fedora-advisory-board/2008-October/msg00021.html
== Artwork in Fedora ==
* Recent email threads on fedora-desktop-list at redhat.com
* Discussion centered around who is responsible for the "look and feel"
of Fedora
* Look of default icon set of distribution is important because it does
makes a first impression on new users
* Where does Fedora define "Upstream Fedora Artwork" to exist?
* Is Fedora specific art work considered to be working "upstream" or
does such an "upstream" exist?
* The Board is ultimately responsible for the ''look and feel'' of
Fedora but would like it to be clear that it has delegated this
responsibility to the Fedora Art Team
** Historically this was FESCo's responsibility
*** https://www.redhat.com/archives/fedora-art-list/2007-July/msg00154.html
***
https://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070726#Nodoka_Theme
** When FESCo recently re-evaluated its role it retained many of its
previous responsibilities, but did not explicitly retain responsibility
over the ''look and feel'' of Fedora. As a result this responsibility
reverted to the Fedora Board.
*** https://fedoraproject.org/wiki/Board/Meetings/2008-06-09
*** http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080612
* There were no dissenting votes to the following resolution:
* '''RESOLUTION'''
*# FESCo has previously delegated the responsibility to determine the
look and feel of Fedora to the Artwork team, and the Board continues to
support that decision
*# The Artwork team, like any other Fedora team, should work with other
groups to develop consensus on look and feel discussions
*# The Artwork team should formally decide whether or not Echo should be
the default icon set in Fedora 10
From tcallawa at redhat.com Tue Oct 21 20:57:07 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 21 Oct 2008 16:57:07 -0400
Subject: PackageKit "Vendor" URLs
Message-ID: <1224622627.3343.46.camel@localhost.localdomain>
Hi guys,
Here's my first pass at a very simple page to explain to PackageKit
users why something they searched for was not found in Fedora:
https://fedoraproject.org/wiki/PackageKit_Items_Not_Found
Feedback is welcomed. Keep in mind that we cannot make references to
specific 3rd party repositories here.
~spot
From davej at redhat.com Tue Oct 21 21:07:33 2008
From: davej at redhat.com (Dave Jones)
Date: Tue, 21 Oct 2008 17:07:33 -0400
Subject: PackageKit "Vendor" URLs
In-Reply-To: <1224622627.3343.46.camel@localhost.localdomain>
References: <1224622627.3343.46.camel@localhost.localdomain>
Message-ID: <20081021210733.GA15469@redhat.com>
On Tue, Oct 21, 2008 at 04:57:07PM -0400, Tom spot Callaway wrote:
> Hi guys,
>
> Here's my first pass at a very simple page to explain to PackageKit
> users why something they searched for was not found in Fedora:
>
> https://fedoraproject.org/wiki/PackageKit_Items_Not_Found
>
> Feedback is welcomed. Keep in mind that we cannot make references to
> specific 3rd party repositories here.
Wait, packagekit looks for 3rd party drivers now?
When did this happen?
Dave
--
http://www.codemonkey.org.uk
From stickster at gmail.com Tue Oct 21 21:48:16 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Tue, 21 Oct 2008 17:48:16 -0400
Subject: PackageKit "Vendor" URLs
In-Reply-To: <20081021210733.GA15469@redhat.com>
References: <1224622627.3343.46.camel@localhost.localdomain>
<20081021210733.GA15469@redhat.com>
Message-ID: <1224625696.23916.10.camel@localhost.localdomain>
On Tue, 2008-10-21 at 17:07 -0400, Dave Jones wrote:
> On Tue, Oct 21, 2008 at 04:57:07PM -0400, Tom spot Callaway wrote:
> > Hi guys,
> >
> > Here's my first pass at a very simple page to explain to PackageKit
> > users why something they searched for was not found in Fedora:
> >
> > https://fedoraproject.org/wiki/PackageKit_Items_Not_Found
> >
> > Feedback is welcomed. Keep in mind that we cannot make references to
> > specific 3rd party repositories here.
>
> Wait, packagekit looks for 3rd party drivers now?
> When did this happen?
Not on its own. The user must seek out and install third party
repositories to have their contents supported. In other words, the
behavior is better, but the requirements haven't changed.`
--
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From poelstra at redhat.com Wed Oct 22 23:17:57 2008
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 22 Oct 2008 16:17:57 -0700
Subject: Preview Release Planning Meeting
Message-ID: <48FFB4A5.4000401@redhat.com>
Sending this mail out to representatives from each of the key Fedora
teams to have a short meeting on Wednesday, October 29, 2008 at 17:00
UTC (1 PM EDT), to make sure we are all aligned for the F10 Preview
Release scheduled for the following Tuesday, November 4, 2008
Please coordinate within your team if the leader has changed or if
someone is attending in your place. Then please let me know. I plan to
send telephone conference details directly to the following people on
Monday.
Spot Callaway -- Fedora Engineering manager
M?ir?n Duffy -- Art
Dimitris Gelzos -- Translation
Paul Frields -- Fedora Project Leader
Jesse Keating -- Release Engineering
Mike McGrath -- Infrastructure
Bill Nottingham -- Development/FESCo
John Poelstra -- Organizer
Jonathan Roberts -- Marketing
Max Spevack -- Ambassadors
Karsten Wade -- Documentation
Will Woods -- QA
Ricky Zhou -- Websites
I will send another reminder next Monday along with the conferencing
information.
John
From notting at redhat.com Fri Oct 24 18:55:28 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 24 Oct 2008 14:55:28 -0400
Subject: PackageKit "Vendor" URLs
In-Reply-To: <1224622627.3343.46.camel@localhost.localdomain>
References: <1224622627.3343.46.camel@localhost.localdomain>
Message-ID: <20081024185528.GA7203@nostromo.devel.redhat.com>
Tom spot Callaway (tcallawa at redhat.com) said:
> Hi guys,
>
> Here's my first pass at a very simple page to explain to PackageKit
> users why something they searched for was not found in Fedora:
>
> https://fedoraproject.org/wiki/PackageKit_Items_Not_Found
>
> Feedback is welcomed. Keep in mind that we cannot make references to
> specific 3rd party repositories here.
The initial bits are rather repetitive. Not sure it can be avoided.
Under what circumstances is PackageKit looking for *drivers*?
Bill
From notting at redhat.com Fri Oct 24 18:58:38 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 24 Oct 2008 14:58:38 -0400
Subject: PackageKit "Vendor" URLs
In-Reply-To: <20081024185528.GA7203@nostromo.devel.redhat.com>
References: <1224622627.3343.46.camel@localhost.localdomain>
<20081024185528.GA7203@nostromo.devel.redhat.com>
Message-ID: <20081024185838.GB7203@nostromo.devel.redhat.com>
Bill Nottingham (notting at redhat.com) said:
> Tom spot Callaway (tcallawa at redhat.com) said:
> > Hi guys,
> >
> > Here's my first pass at a very simple page to explain to PackageKit
> > users why something they searched for was not found in Fedora:
> >
> > https://fedoraproject.org/wiki/PackageKit_Items_Not_Found
> >
> > Feedback is welcomed. Keep in mind that we cannot make references to
> > specific 3rd party repositories here.
>
> The initial bits are rather repetitive. Not sure it can be avoided.
>
> Under what circumstances is PackageKit looking for *drivers*?
We may want to explain what a 'codec' is, depending on how PackageKit
is phrasing it before you get to this page. For codecs and drivers,
asking for them to be packaged may not be helpful, as:
- for codecs, if it's not there, it's either legal or it doesn't exist
- for drivers, we want them upstream
Bill
From tcallawa at redhat.com Fri Oct 24 19:32:47 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 24 Oct 2008 15:32:47 -0400
Subject: PackageKit "Vendor" URLs
In-Reply-To: <20081024185838.GB7203@nostromo.devel.redhat.com>
References: <1224622627.3343.46.camel@localhost.localdomain>
<20081024185528.GA7203@nostromo.devel.redhat.com>
<20081024185838.GB7203@nostromo.devel.redhat.com>
Message-ID: <1224876767.5166.95.camel@localhost.localdomain>
On Fri, 2008-10-24 at 14:58 -0400, Bill Nottingham wrote:
> Bill Nottingham (notting at redhat.com) said:
> > Tom spot Callaway (tcallawa at redhat.com) said:
> > > Hi guys,
> > >
> > > Here's my first pass at a very simple page to explain to PackageKit
> > > users why something they searched for was not found in Fedora:
> > >
> > > https://fedoraproject.org/wiki/PackageKit_Items_Not_Found
> > >
> > > Feedback is welcomed. Keep in mind that we cannot make references to
> > > specific 3rd party repositories here.
> >
> > The initial bits are rather repetitive. Not sure it can be avoided.
> >
> > Under what circumstances is PackageKit looking for *drivers*?
>
> We may want to explain what a 'codec' is, depending on how PackageKit
> is phrasing it before you get to this page.
Done, thanks.
> For codecs and drivers,
> asking for them to be packaged may not be helpful, as:
>
> - for codecs, if it's not there, it's either legal or it doesn't exist
I'm not sure about that. I don't want to assume we have every known
codec covered.
> - for drivers, we want them upstream
Good point. I've adjusted this section.
~spot
From jspaleta at gmail.com Fri Oct 24 19:40:44 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 24 Oct 2008 11:40:44 -0800
Subject: PackageKit "Vendor" URLs
In-Reply-To: <1224876767.5166.95.camel@localhost.localdomain>
References: <1224622627.3343.46.camel@localhost.localdomain>
<20081024185528.GA7203@nostromo.devel.redhat.com>
<20081024185838.GB7203@nostromo.devel.redhat.com>
<1224876767.5166.95.camel@localhost.localdomain>
Message-ID: <604aa7910810241240m59a44b12h4381e67e92177568@mail.gmail.com>
On Fri, Oct 24, 2008 at 11:32 AM, Tom spot Callaway
> I'm not sure about that. I don't want to assume we have every known
> codec covered.
At some point, legal to include codecs could show up in the gst bad
pool. And only technical quality would keep them from being added to
the good pool.
http://gstreamer.freedesktop.org/modules/gst-plugins-bad.html
"GStreamer Bad Plug-ins is a set of plug-ins that aren't up to par
compared to the rest. They might be close to being good quality, but
they're missing something - be it a good code review, some
documentation, a set of tests, a real live maintainer, or some actual
wide use. "
-jef
From poelstra at redhat.com Sat Oct 25 02:18:09 2008
From: poelstra at redhat.com (John Poelstra)
Date: Fri, 24 Oct 2008 19:18:09 -0700
Subject: Blocker Bug Review Meeting :: Monday @ 14:00 UTC
Message-ID: <490281E1.1090305@redhat.com>
A meeting is being held to review the current blocker bugs in
anticipation of the Final Development Freeze this Tuesday, October 28th.
All teams (thus the cc to f-a-b) in Fedora are welcome to join in and help.
WHEN: Monday, October 27, 2008 @ 14:00 UTC (10 AM EDT) and going as long
as we need to
WHERE: irc.freenode.net #fedora-blocker
Fedora 10 Blocker:
https://bugzilla.redhat.com/showdependencytree.cgi?id=438943&hide_resolved=1
Fedora 10 Preview Blocker:
https://bugzilla.redhat.com/showdependencytree.cgi?id=446449&hide_resolved=1
There still remain approximately 600 rawhide bugs that have not been
triaged for potential blocker status and should be considered as well.
These bugs are here: http://tinyurl.com/6llac8
Other tracker bugs of interest are here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers
John
From dominik at greysector.net Tue Oct 28 08:06:23 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 28 Oct 2008 09:06:23 +0100
Subject: Blocker Bug Review Meeting :: Monday @ 14:00 UTC
In-Reply-To: <490281E1.1090305@redhat.com>
References: <490281E1.1090305@redhat.com>
Message-ID: <20081028080622.GA23949@mokona.greysector.net>
On Saturday, 25 October 2008 at 04:18, John Poelstra wrote:
> A meeting is being held to review the current blocker bugs in
> anticipation of the Final Development Freeze this Tuesday, October 28th.
>
> All teams (thus the cc to f-a-b) in Fedora are welcome to join in and help.
>
> WHEN: Monday, October 27, 2008 @ 14:00 UTC (10 AM EDT) and going as long
> as we need to
This mail arrived only yesterday evening (about 5 hours after the meeting).
According to the headers, it was stuck somewhere on RedHat servers:
Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com
[10.8.4.110])
by hormel.redhat.com (Postfix) with ESMTP id 4A87261A04F;
Mon, 27 Oct 2008 18:12:29 -0400 (EDT)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Received: from int-mx2.corp.redhat.com (nat-pool.util.phx.redhat.com
[10.8.5.200])
by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id
m9P2ICiE029439; Fri, 24 Oct 2008 22:18:12 -0400
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
From jkeating at redhat.com Tue Oct 28 15:09:06 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 28 Oct 2008 08:09:06 -0700
Subject: Blocker Bug Review Meeting :: Monday @ 14:00 UTC
In-Reply-To: <20081028080622.GA23949@mokona.greysector.net>
References: <490281E1.1090305@redhat.com>
<20081028080622.GA23949@mokona.greysector.net>
Message-ID: <1225206546.2157.37.camel@luminos.localdomain>
On Tue, 2008-10-28 at 09:06 +0100, Dominik 'Rathann' Mierzejewski wrote:
>
> This mail arrived only yesterday evening (about 5 hours after the
> meeting).
> According to the headers, it was stuck somewhere on RedHat servers:
> Received: from listman.util.phx.redhat.com
> (listman.util.phx.redhat.com
> [10.8.4.110])
> by hormel.redhat.com (Postfix) with ESMTP id 4A87261A04F;
> Mon, 27 Oct 2008 18:12:29 -0400 (EDT)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think that's partly my fault. It was stuck in a moderator queue that
I didn't see until pretty late.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
From jkeating at redhat.com Tue Oct 28 18:15:05 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 28 Oct 2008 11:15:05 -0700
Subject: Requesting Trademark Approval for Sugar Spin
In-Reply-To: <48F73D5A.5090908@when.com>
References: <48F73D5A.5090908@when.com>
Message-ID: <1225217705.2157.73.camel@luminos.localdomain>
On Thu, 2008-10-16 at 15:10 +0200, Sebastian Dziallas wrote:
> Hi everybody,
>
> as you may have noticed, the OLPC SIG has been working on a spin
> including the Sugar Desktop Environment. Recently, this spin has been
> pushed into the Spin SIG's GIT repository and I felt it was time to
> request trademark approval from the board for it.
>
I'm in approval of this, but I'm curious how it fits into the
ecostructure of OLPC and what the OLPC project itself is putting out for
images.
Is this spin supposed to be used on regular hardware, or just the OLPC
unit?
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
From katzj at redhat.com Tue Oct 28 18:32:51 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 28 Oct 2008 14:32:51 -0400
Subject: Requesting Trademark Approval for Sugar Spin
In-Reply-To: <1225217705.2157.73.camel@luminos.localdomain>
References: <48F73D5A.5090908@when.com>
<1225217705.2157.73.camel@luminos.localdomain>
Message-ID: <1225218771.13184.20.camel@aglarond.local>
On Tue, 2008-10-28 at 11:15 -0700, Jesse Keating wrote:
> On Thu, 2008-10-16 at 15:10 +0200, Sebastian Dziallas wrote:
> > as you may have noticed, the OLPC SIG has been working on a spin
> > including the Sugar Desktop Environment. Recently, this spin has been
> > pushed into the Spin SIG's GIT repository and I felt it was time to
> > request trademark approval from the board for it.
> >
> I'm in approval of this, but I'm curious how it fits into the
> ecostructure of OLPC and what the OLPC project itself is putting out for
> images.
The OLPC project images are jffs2 and intended purely for usage on the
XO (well, or there are also the qemu images I guess).
> Is this spin supposed to be used on regular hardware, or just the OLPC
> unit?
It's a spin of Fedora using Sugar, much like we have spins of Fedora
using XFCE, KDE, GNOME, ... And much like other Fedora spins run on on
the OLPC hardware, this should also.
Jeremy
From matt at domsch.com Tue Oct 28 19:50:20 2008
From: matt at domsch.com (Matt Domsch)
Date: Tue, 28 Oct 2008 13:50:20 -0600
Subject: Planning Post F10 Elections
In-Reply-To: <1222175837.3367.84.camel@fantail.jnet.net.nz>
References: <1222175837.3367.84.camel@fantail.jnet.net.nz>
Message-ID: <20081028195020.GB6714@domsch.com>
On Wed, Sep 24, 2008 at 01:17:17AM +1200, Nigel Jones wrote:
> Hi everyone,
>
> With the last slip of the Fedora 10 release I've noticed we are getting
> dangerously close to Christmas to hold the usual round of post election
> votes, from what I can tell the following are on the cards:
>
> * FAmSCo (Ambassadors)
> * Fedora Board
> * Fedora 11 Release Name
> * FESCo (Engineering)
> * FLSCo (Translation)
Is the the full list of elections needed in the next 6 months? Is
FDSCo (Documentation) up for election?
Concensus seemed to be that all the necessary elections should be run
concurrently. As this is a first-time event for Fedora, I have
volunteered to help coordinate them.
Given the F10 release schedule, and the desire to begin elections
shortly thereafter, the following schedule is proposed:
* Now - December 3, 2008: Nominations accepted on respective wiki pages
* December 7-20, 2008: Elections
You may self-nominate. If you wish to nominate someone else, please
consult with that person ahead of time. Wiki nomination pages may
carry additional details about the nominee which effectively the
nominee would write.
I would like each of the committee chairs to ensure they have a
Nominations page in the wiki ready to accept nominations. Please link
it to this wiki page:
https://fedoraproject.org/wiki/Elections
Thanks,
Matt
From fugolini at fedoraproject.org Tue Oct 28 20:32:15 2008
From: fugolini at fedoraproject.org (Francesco Ugolini)
Date: Tue, 28 Oct 2008 21:32:15 +0100
Subject: Planning Post F10 Elections
In-Reply-To: <20081028195020.GB6714@domsch.com>
References: <1222175837.3367.84.camel@fantail.jnet.net.nz>
<20081028195020.GB6714@domsch.com>
Message-ID:
2008/10/28 Matt Domsch :
> Is the the full list of elections needed in the next 6 months? Is
> FDSCo (Documentation) up for election?
>
> Concensus seemed to be that all the necessary elections should be run
> concurrently. As this is a first-time event for Fedora, I have
> volunteered to help coordinate them.
>
> Given the F10 release schedule, and the desire to begin elections
> shortly thereafter, the following schedule is proposed:
>
> * Now - December 3, 2008: Nominations accepted on respective wiki pages
> * December 7-20, 2008: Elections
>
>
> You may self-nominate. If you wish to nominate someone else, please
> consult with that person ahead of time. Wiki nomination pages may
> carry additional details about the nominee which effectively the
> nominee would write.
>
> I would like each of the committee chairs to ensure they have a
> Nominations page in the wiki ready to accept nominations. Please link
> it to this wiki page:
>
> https://fedoraproject.org/wiki/Elections
>
> Thanks,
> Matt
In IRC I listened (a month ago) that the election was planned for
January (due to US presidential), so wasn't it correct?
For me, I think it could work, my only doubt is to be able to
concentrate all the activities someone proposed (IRC meetings and so
on).
That's my point of view
Regards
Francesco Ugolini
From sebastian at when.com Tue Oct 28 21:39:44 2008
From: sebastian at when.com (Sebastian Dziallas)
Date: Tue, 28 Oct 2008 22:39:44 +0100
Subject: Requesting Trademark Approval for Sugar Spin
In-Reply-To: <1225218771.13184.20.camel@aglarond.local>
References: <48F73D5A.5090908@when.com> <1225217705.2157.73.camel@luminos.localdomain>
<1225218771.13184.20.camel@aglarond.local>
Message-ID: <490786A0.4090506@when.com>
Jeremy Katz wrote:
> On Tue, 2008-10-28 at 11:15 -0700, Jesse Keating wrote:
>> On Thu, 2008-10-16 at 15:10 +0200, Sebastian Dziallas wrote:
>>> as you may have noticed, the OLPC SIG has been working on a spin
>>> including the Sugar Desktop Environment. Recently, this spin has been
>>> pushed into the Spin SIG's GIT repository and I felt it was time to
>>> request trademark approval from the board for it.
>>>
>> I'm in approval of this, but I'm curious how it fits into the
>> ecostructure of OLPC and what the OLPC project itself is putting out for
>> images.
>
> The OLPC project images are jffs2 and intended purely for usage on the
> XO (well, or there are also the qemu images I guess).
>
>> Is this spin supposed to be used on regular hardware, or just the OLPC
>> unit?
>
> It's a spin of Fedora using Sugar, much like we have spins of Fedora
> using XFCE, KDE, GNOME, ... And much like other Fedora spins run on on
> the OLPC hardware, this should also.
>
> Jeremy
Well, I think Jeremy has already mostly answered this - thanks! This is
just another spin based on Fedora which now contains the Sugar Desktop
Environment by default.
The user would be able to download a Live CD and run Sugar directly from
a completely Fedora-based spin, since we've all the stuff now in Fedora
- there are no external sources needed.
--Sebastian
From sebastian at when.com Tue Oct 28 21:39:44 2008
From: sebastian at when.com (Sebastian Dziallas)
Date: Tue, 28 Oct 2008 22:39:44 +0100
Subject: Requesting Trademark Approval for Sugar Spin
In-Reply-To: <1225218771.13184.20.camel@aglarond.local>
References: <48F73D5A.5090908@when.com> <1225217705.2157.73.camel@luminos.localdomain>
<1225218771.13184.20.camel@aglarond.local>
Message-ID: <490786A0.4090506@when.com>
Jeremy Katz wrote:
> On Tue, 2008-10-28 at 11:15 -0700, Jesse Keating wrote:
>> On Thu, 2008-10-16 at 15:10 +0200, Sebastian Dziallas wrote:
>>> as you may have noticed, the OLPC SIG has been working on a spin
>>> including the Sugar Desktop Environment. Recently, this spin has been
>>> pushed into the Spin SIG's GIT repository and I felt it was time to
>>> request trademark approval from the board for it.
>>>
>> I'm in approval of this, but I'm curious how it fits into the
>> ecostructure of OLPC and what the OLPC project itself is putting out for
>> images.
>
> The OLPC project images are jffs2 and intended purely for usage on the
> XO (well, or there are also the qemu images I guess).
>
>> Is this spin supposed to be used on regular hardware, or just the OLPC
>> unit?
>
> It's a spin of Fedora using Sugar, much like we have spins of Fedora
> using XFCE, KDE, GNOME, ... And much like other Fedora spins run on on
> the OLPC hardware, this should also.
>
> Jeremy
Well, I think Jeremy has already mostly answered this - thanks! This is
just another spin based on Fedora which now contains the Sugar Desktop
Environment by default.
The user would be able to download a Live CD and run Sugar directly from
a completely Fedora-based spin, since we've all the stuff now in Fedora
- there are no external sources needed.
--Sebastian
From sebastian at when.com Tue Oct 28 21:43:31 2008
From: sebastian at when.com (Sebastian Dziallas)
Date: Tue, 28 Oct 2008 22:43:31 +0100
Subject: Requesting Trademark Approval for Sugar Spin
In-Reply-To: <20081016134330.GD20184@nostromo.devel.redhat.com>
References: <48F73D5A.5090908@when.com>
<20081016134330.GD20184@nostromo.devel.redhat.com>
Message-ID: <49078783.5010202@when.com>
Bill Nottingham wrote:
> Sebastian Dziallas (sebastian at when.com) said:
>> Hi everybody,
>>
>> as you may have noticed, the OLPC SIG has been working on a spin
>> including the Sugar Desktop Environment. Recently, this spin has been
>> pushed into the Spin SIG's GIT repository and I felt it was time to
>> request trademark approval from the board for it.
>>
>> The kickstart file is located here:
>>
>> http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=blob;f=fedora-livecd-sugar.ks;
>>
>> There are some things which should be explained, though.
>>
>> For example, we're disabling SELinux just temporarily - it will be
>> enabled again as soon as bug #467118 gets fixed (#466884 has already
>> been closed). Concerning the choice of the display manager, it should be
>> mentioned that we chose slim instead of gdm, since it pulls in less
>> dependencies and should be more light-weight.
>
> If you're turning off sendmail, why not remove it? Are you using cups
> and bluetooth via some other methods? (otherwise they can be removed as well.)
>
> Aside from that, looks sane to me (given the SELinux caveat.)
>
> Bill
Sorry for my late reply here :(
The slim issue has now been fixed and SELinux was enabled again recently!
Concerning the other apps, it's just the way that this kickstart file
was partly based on the desktop-default file in the spin-kickstarts
repo. I think we might well discuss some removals in the near future,
since there might also be some other stuff we could drop.
--Sebastian
From jspaleta at gmail.com Wed Oct 29 04:31:54 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Oct 2008 20:31:54 -0800
Subject: Any more info about the potential for more collaboration with
moblin?
Message-ID: <604aa7910810282131j70348380y583aac1c98af676e@mail.gmail.com>
So its been a couple of months. Did anyone do any follow-up with the
moblin guys to see if there are some additional points of
collaboration with them?
I was thinking about it again in the context of our trademark policy
rework, asking myself the question if moblin wanted to tag themselves
as a Fedora remix do they fall into the bounds of our secondary mark
usage?
And if they do, do we want to invite them to make use of the mark and
to associate more strongly with us?
Which led me to reviewing what I know about the switch over they did.
Did we ever get any feedback about additional points of collaboration
concerning extending our technical services?
Do they know about our AOS tools and feature goals?
It seems all i have are questions.
-jef
From matt at domsch.com Wed Oct 29 17:25:04 2008
From: matt at domsch.com (Matt Domsch)
Date: Wed, 29 Oct 2008 11:25:04 -0600
Subject: Planning Post F10 Elections
In-Reply-To:
References: <1222175837.3367.84.camel@fantail.jnet.net.nz>
<20081028195020.GB6714@domsch.com>
Message-ID: <20081029172504.GA17644@domsch.com>
On Tue, Oct 28, 2008 at 09:32:15PM +0100, Francesco Ugolini wrote:
> 2008/10/28 Matt Domsch :
> > Is the the full list of elections needed in the next 6 months? Is
> > FDSCo (Documentation) up for election?
> >
> > Concensus seemed to be that all the necessary elections should be run
> > concurrently. As this is a first-time event for Fedora, I have
> > volunteered to help coordinate them.
> >
> > Given the F10 release schedule, and the desire to begin elections
> > shortly thereafter, the following schedule is proposed:
> >
> > * Now - December 3, 2008: Nominations accepted on respective wiki pages
> > * December 7-20, 2008: Elections
> >
> >
> > You may self-nominate. If you wish to nominate someone else, please
> > consult with that person ahead of time. Wiki nomination pages may
> > carry additional details about the nominee which effectively the
> > nominee would write.
> >
> > I would like each of the committee chairs to ensure they have a
> > Nominations page in the wiki ready to accept nominations. Please link
> > it to this wiki page:
> >
> > https://fedoraproject.org/wiki/Elections
> >
> > Thanks,
> > Matt
>
> In IRC I listened (a month ago) that the election was planned for
> January (due to US presidential), so wasn't it correct?
US Presidential election should be over in about a week, give or take
the lawyers and press coverage. I don't expect any Fedora
contributors are so involved with those that they couldn't take a few
minutes between now and December 3 to add their name to a nomination
list should they so choose.
> For me, I think it could work, my only doubt is to be able to
> concentrate all the activities someone proposed (IRC meetings and so
> on).
Thanks for bringing that up again. I'll be happy to try to coordinate
several town-hall style IRC "debates" for each of the various
elections, if people think that would help considerably in trying to
decide whom to vote for. I personally find most IRC meetings to be
very low bandwidth (e.g. I could get 4x more done in the same time if
not using IRC). But I'm open to be swayed (and note, it's not really
up to me, I'm just kicking off the conversation). (moderated)
conference calls and/or VOIP are also possible.
I'd hope we get enough nominations for each elected position that a
healthy debate, IRC or otherwise, would be beneficial to the
electorate. But I don't anticipate needing more than one debate per
elected group, do you?
Thanks,
Matt
From fugolini at fedoraproject.org Wed Oct 29 17:41:47 2008
From: fugolini at fedoraproject.org (Francesco Ugolini)
Date: Wed, 29 Oct 2008 18:41:47 +0100
Subject: Planning Post F10 Elections
In-Reply-To: <20081029172504.GA17644@domsch.com>
References: <1222175837.3367.84.camel@fantail.jnet.net.nz>
<20081028195020.GB6714@domsch.com>
<20081029172504.GA17644@domsch.com>
Message-ID:
2008/10/29 Matt Domsch :
>
>
> US Presidential election should be over in about a week, give or take
> the lawyers and press coverage. I don't expect any Fedora
> contributors are so involved with those that they couldn't take a few
> minutes between now and December 3 to add their name to a nomination
> list should they so choose.
I just reported what I've heard. BTW, now I know that I know there
isn't a conflict between this two events. Thank you
> Thanks for bringing that up again. I'll be happy to try to coordinate
> several town-hall style IRC "debates" for each of the various
> elections, if people think that would help considerably in trying to
> decide whom to vote for. I personally find most IRC meetings to be
> very low bandwidth (e.g. I could get 4x more done in the same time if
> not using IRC). But I'm open to be swayed (and note, it's not really
> up to me, I'm just kicking off the conversation). (moderated)
> conference calls and/or VOIP are also possible.
>
> I'd hope we get enough nominations for each elected position that a
> healthy debate, IRC or otherwise, would be beneficial to the
> electorate. But I don't anticipate needing more than one debate per
> elected group, do you?
I'm agree with you in that point, a debate is worth a million ones.
Finally I personally think IRC is the best way.
Regards
Francesco Ugolini
p.s. FAmSCo is starting planning FAmSCo elections, we will stay tuned
here, trying to get updates and give updates about our status.
From kwade at redhat.com Wed Oct 29 18:34:05 2008
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 29 Oct 2008 11:34:05 -0700
Subject: Any more info about the potential for more collaboration with
moblin?
In-Reply-To: <604aa7910810282131j70348380y583aac1c98af676e@mail.gmail.com>
References: <604aa7910810282131j70348380y583aac1c98af676e@mail.gmail.com>
Message-ID: <1225305245.28007.83.camel@calliope.phig.org>
On Tue, 2008-10-28 at 20:31 -0800, Jeff Spaleta wrote:
> So its been a couple of months. Did anyone do any follow-up with the
> moblin guys to see if there are some additional points of
> collaboration with them?
A quick review of what did happen back then, from someone who rushed
over to talk with the Moblin folks at OSCON when the announcement went
over the wire.
The team lead, Dirk, essentially told us that they have all the
collaboration connection they need, his name is Dave Jones. Personally,
I'm not happy with the answer, from a community building viewpoint; Dave
rocks but he doesn't scale all that well. OTOH, it is precisely because
of our kernel maintainer, accessibility to him, and working closely with
the upstream kernel that Moblin came here in the first place. They are
going with best-of-breed-for-them solutions. For example, they are
building on OpenSUSE's build service because of some specific problems
they have with koji.
> I was thinking about it again in the context of our trademark policy
> rework, asking myself the question if moblin wanted to tag themselves
> as a Fedora remix do they fall into the bounds of our secondary mark
> usage?
>
> And if they do, do we want to invite them to make use of the mark and
> to associate more strongly with us?
>
> Which led me to reviewing what I know about the switch over they did.
> Did we ever get any feedback about additional points of collaboration
> concerning extending our technical services?
>
> Do they know about our AOS tools and feature goals?
>
> It seems all i have are questions.
I've rolled this about in my head. My instinct is, if they do know
about the new Remix mark, they don't care. It can't hurt to ask. Key
is having the actual guidelines up and referencable, so it is obvious
that i) it is an option and not a requirement, and ii) it is so easy
they don't need to call their lawyers to ask permission. :)
- Karsten
--
Karsten Wade, Community Gardener
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From poelstra at redhat.com Wed Oct 29 22:29:25 2008
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 29 Oct 2008 15:29:25 -0700
Subject: F10 Preview Release Planning Meeting Recap
Message-ID: <4908E3C5.8030709@redhat.com>
2008-10-29
Preview Release Planning Meeting
Invitees:
Spot Callaway -- Fedora Engineering manager (present)
M?ir?n Duffy -- Art (present)
Dimitris Gelzos -- Translation
Paul Frields -- Fedora Project Leader (present)
Jesse Keating -- Release Engineering (present)
Mike McGrath -- Infrastructure (present)
Bill Nottingham -- Development/FESCo (present)
John Poelstra -- Organizer (present)
Jonathan Roberts -- Marketing
Max Spevack -- Ambassadors (regrets)
Karsten Wade -- Documentation (present)
Will Woods -- Quality Assurance (present)
Ricky Zhou -- Websites (present)
== Meeting Preface ==
o Meeting to make sure we are ready for the Preview Release and
coordinate across teams as necessary
o While good ideas may come out of this meeting for how to make Fedora
better we are not here to make policy or process decisions
--those should be made in individual teams as part of their regular
decision making process
== Key Points ==
o Meeting was held in record time: 30 minutes
o Open releng ticketes:
https://fedorahosted.org/rel-eng/query?status=new&status=assigned&status=reopened&milestone=Fedora+10+Preview
o Open Infrastructure tickets:
https://fedorahosted.org/fedora-infrastructure/report/9
o QA & Releng believe we are on track for releasing preview release on
Tuesday
--only current issue of concern is a bug about plymouth and encryption
--F10Preview blocker:
https://bugzilla.redhat.com/showdependencytree.cgi?id=446449&hide_resolved=1
--need artwork package preferably today, but no later than tomorrow
o Planning to have release count down graphic ready on Preview Release Day
o Release engineering is accountable for release day announcement, Paul
volunteered help from the docs group
o Websites team responsible for get.fedoraproject.org--will change name
from "Beta" to "Preview"
o Reviewed https://fedorahosted.org/fedora-infrastructure/ticket/933 and
confirmed that space considerations are the same
o Docs team will update website with latest version of Install Guide and
release notes
o Paul is helping with marketing task of loading up USB keys with live
version of Preview Release and working on distribution via with help
from Red Hat's PR group.
o Spot spoke in passing about the present number of GA Blocker bugs
(alias: F10Blocker). He continues, along with the help of others, to
keep working this list down
o F10Blocker:
https://bugzilla.redhat.com/showdependencytree.cgi?id=438943&hide_resolved=1
o All NEW rawhide bugs: http://tinyurl.com/6llac8
From poelstra at redhat.com Wed Oct 29 22:49:44 2008
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 29 Oct 2008 15:49:44 -0700
Subject: Fedora Board Recap 2008-OCT-28
Message-ID: <4908E888.7000303@redhat.com>
https://fedoraproject.org/wiki/Board/Meetings/2008-10-28
== Roll Call ==
Attendees: John Poelstra, Karsten Wade, Seth Vidal, Jesse Keating, Matt
Domsch, Jef Spaleta, Harald Hoyer, Bill Nottingham, Paul Frields, Chris
Tyler
Regrets: Spot Callaway
== Trademark guidelines ==
* Art team has finalized secondary mark artwork
* Paul to move new trademark policy to final name space and add final links
== Fedora Sugar Spin ==
*
https://www.redhat.com/archives/fedora-advisory-board/2008-October/msg00039.html
* '''RESOLUTION:''' unanimous board approval for Fedora Sugar Spin
== Upcoming Elections ==
* Coordinate proposed dates with other teams and seek out others
** Ambassadors
** Project Board
** FESCo
** Translations
** Fedora 11 release name
* https://fedoraproject.org/wiki/Board/History
* Start a nomination process soon and close on December 3rd
* Need to set a date for Dec 7 to 20th
* The following seats will be open:
** appointed seats: Bill Nottingham and Karsten
** voted seats: Matt Domsch and Jeff Spaleta
* '''ACTIONS''':
** Matt will start mail thread on fedora-advisory-board at redhat.com
== FUDCon Fedora 11 ==
* Dates: January 9 to 11, 2009
* Location: Boston, Massachusetts with actual facilities in the process
of being confirmed
* Seth is working on getting a group hotel rate
* More details coming
From mmcgrath at redhat.com Fri Oct 31 18:27:33 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Fri, 31 Oct 2008 13:27:33 -0500 (CDT)
Subject: Spins
Message-ID:
So we've got a problem. In particular this deals with the Sugar spin.
This spin was not submitted in time for the Fedora 10 release, if it were
we wouldn't have a problem. I hark on that because it feels like a lot of
people try to get away with bypassing the freeze. Creating features like
a spin require commitment, responsibility and accountability. Not getting
features in prior to the feature freeze is irresponsible and, IMHO, a
reason to have to wait until the next release.
Having said that, Sugar and OLPC are a pretty big deal. The spin has been
approved by the board and is (or will be) an official spin. We have
hosting for unofficial spins. I know this delineation seems very minor
"well if you have hosting for unofficial spins, why not just host this
official spin there"
The reason is the accountability I mentioned earlier. There's a lot going
on in Fedora right now. There are a lot of hosting options in Fedora
Infrastructure. Each were designed and built for a specific purpose. But
I cannot allow one part of our infrastructure to be a "route around point"
for other parts of our infrastructure.
This is a small but important detail. I'd like to make an exception for
OLPC and the Sugar build. I know not the reasons this build did not make
the feature freeze but they did not. When they asked for space on Fedora
People they were told no. So they kept asking around until someone
increased their space on Fedora People and I had to be the bad guy.
So here's what I'd propose. For now we'll host the unofficial Sugar spin
at our alt.fedoraproject.org/pub/ site until it gets built as an official
spin which, according to releng, will be the F11 alpha. I'm pushing the
responsibility of this decision on to FAB because if it were up to me, I'd
say no.
If the tone of this email sounds harsh please note it is not directed at
the Sugar Spin people, this kind of stuff has happened before and we just
can't have it anymore. Fedora's policies and procedures are far from
perfect, but they are there. If you don't like them change them but don't
think Infrastructure is going to route around what has been put in place.
Since there doesn't seem to be any official decision making process for
FAB, I'll wait until Monday and if the +1's out weigh the -1's then I'll
get it copied and hosted.
-Mike
From jkeating at redhat.com Fri Oct 31 18:54:47 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 31 Oct 2008 11:54:47 -0700
Subject: Spins
In-Reply-To:
References:
Message-ID: <1225479287.31015.20.camel@luminos.localdomain>
On Fri, 2008-10-31 at 13:27 -0500, Mike McGrath wrote:
>
> Having said that, Sugar and OLPC are a pretty big deal. The spin has been
> approved by the board and is (or will be) an official spin.
Small comment. The board gave the Sugar spin the approval to use the
Fedora brand. This doesn't automatically mean that it'll become a
produced and hosted spin in binary format. All it means is that the
spin KS config can live in the spin-kickstarts repo and use the Fedora
branding should somebody create the binary spin from the config. It
would still have to have a Feature proposed and approved by the spins
SIG and by releng before it would be an official spin.
> We have
> hosting for unofficial spins.
We do? What is it?
> I know this delineation seems very minor
> "well if you have hosting for unofficial spins, why not just host this
> official spin there"
>
> The reason is the accountability I mentioned earlier. There's a lot going
> on in Fedora right now. There are a lot of hosting options in Fedora
> Infrastructure. Each were designed and built for a specific purpose. But
> I cannot allow one part of our infrastructure to be a "route around point"
> for other parts of our infrastructure.
>
> This is a small but important detail. I'd like to make an exception for
> OLPC and the Sugar build. I know not the reasons this build did not make
> the feature freeze but they did not. When they asked for space on Fedora
> People they were told no. So they kept asking around until someone
> increased their space on Fedora People and I had to be the bad guy.
>
> So here's what I'd propose. For now we'll host the unofficial Sugar spin
> at our alt.fedoraproject.org/pub/
Ah, is that the hosting space for unofficial spins?
> site until it gets built as an official
> spin which, according to releng, will be the F11 alpha. I'm pushing the
> responsibility of this decision on to FAB because if it were up to me, I'd
> say no.
>
> If the tone of this email sounds harsh please note it is not directed at
> the Sugar Spin people, this kind of stuff has happened before and we just
> can't have it anymore. Fedora's policies and procedures are far from
> perfect, but they are there. If you don't like them change them but don't
> think Infrastructure is going to route around what has been put in place.
>
> Since there doesn't seem to be any official decision making process for
> FAB, I'll wait until Monday and if the +1's out weigh the -1's then I'll
> get it copied and hosted.
Honestly this feels like a board issue, which is why I asked for it to
be brought to FAB. One of the options mentioned was to have a binary
version of the spin produced by the spin owner and hosted on OLPC
resources. I'm fine with this, the only catch is that the sources for
what goes into the spin will also have to be hosted over at OLPC for the
duration of time that the binary spin is there. This shouldn't be a big
deal, but it needs to be done.
Once the sugar spin goes through the Feature process and gets accepted
as a spin that the Fedora project will generate and host in binary form,
then we can talk about removing it from OLPC infrastructure.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
From mmcgrath at redhat.com Fri Oct 31 19:07:51 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Fri, 31 Oct 2008 14:07:51 -0500 (CDT)
Subject: Spins
In-Reply-To: <1225479287.31015.20.camel@luminos.localdomain>
References:
<1225479287.31015.20.camel@luminos.localdomain>
Message-ID:
On Fri, 31 Oct 2008, Jesse Keating wrote:
> >
> > So here's what I'd propose. For now we'll host the unofficial Sugar spin
> > at our alt.fedoraproject.org/pub/
>
> Ah, is that the hosting space for unofficial spins?
>
And other things though not much is there yet. The only iso thats there
is ltsp and some of the pre-release/staging stuff.
-Mike