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