Re: [Mageia-dev] youri/check (was Re: Updating python-lxml)
2012/11/27 Thierry Vignaud thierry.vign...@gmail.com: On 27 November 2012 04:31, David Walser luigiwal...@yahoo.com wrote: can you update python-lxml to 3.0.1 or is there any reason it wasn't updated yet? just because http://check.mageia.org did not told me to update it ;) It's missing an awful lot these days, as it's not checking Fedora, Mandriva/ROSA, and some other things that would be helpful. I'm concerned about this, as it would be really nice if we could have things reasonably on par with Fedora 18 for Mageia 3. Fedora 18 is supposed to form the basis of RHEL 7, so having things reasonably in sync with them would be very helpful for stable support of Mageia 3 going forward. I really hope youri could be fixed soon. It used to do so. I already complained. without any result. Is there a doc or trace somewhere of what should/could be done/fixed for that? (aside from bugs in https://bugs.mageia.org/buglist.cgi?quicksearch=check.mageia.org).
Re: [Mageia-dev] what is this ????
2012/11/24 PhilippeDidier philippedid...@laposte.net: Is it a joke ? https://wiki.mageia.org/en/Paid_projects That's interesting. Someone want to be paid for his work on Mageia Does it mean that he will give some money back to Mageia ? Such a page might need an agreement before being published ... don't you think so ? I prefer the better apologize than ask for permission mantra; it helps going forward - so let's discuss this: - what's the goal? bounties? - how can it be related to https://wiki.mageia.org/en/Commercial_vendors? (it's more specific, but it looks like having a related purpose) - is it appropriate to host it/link it from mageia.org? - if so, couldn't it be linked into the bugzilla with a keyword or st specific? or to a more appropriate platform? - should there be a monetary return to Mageia? (given that it should bring a code/patch/quality return already)
Re: [Mageia-dev] what is this ????
2012/11/24 Johnny A. Solbu coo...@solbu.net: On Saturday 24. November 2012 15.06, Romain d'Alverny wrote: - is it appropriate to host it/link it from mageia.org? Whats more, the article author have linked to the articles from the wikis Front page. https://wiki.mageia.org/en/Main_Page A better place would be to link it from http://mageia.org/support/ but even here, it should be rephrased and more largely understood (what's the goal of it). (Why can any registered user edit the Front page?) Because it's a wiki, and most (99%) of the time, there is no abuse.
Re: [Mageia-dev] what is this ????
2012/11/24 PhilippeDidier philippedid...@laposte.net: Sander Lepik a écrit : 24.11.2012 18:55, PhilippeDidier kirjutas: NO ! You mean someone is paid and create a third repo for something Mageia doesn't want to import... If that thing brings a mess into Mageia, we will see bug reports in bugzilla and lot of time lost by Mageia bug-triagers, devs, packagers, before discovering that is not a Mageia problem but that this stuff brought some shit ! We suffer of lack of time... and this will consume more time from voluntary contributors to repair something badly done by someone that was paid for it ! Well, we have such repos already today and you can't stop something like that. But you saw my example the wrong way. Mageia doesn't have to support those repos and problems caused by such packages. That has been a problem for Mandrake with Thac repo, a problem for Mandriva with MIB repo... and sometimes it took a long (wasted) time to understand that a reported bug was induced by something imported from third repo. NB plf repo was something else : mandriva devs worked on it ! Still, we can't prevent that *. So perhaps should we: - analyse it and find a clear model that explains it, so we can change what could be changed; - even embrace it, that is, have a strategy to have more such external repositories to merge back into ours, or to better tag/mark/recognize what can come from something we do support as Mageia (because we produced it, or because it matches our requirements) and from something we don't. * it's a symptom that means that most of Mageia (as a whole product) works for some people, but some parts of it don't (so they duplicate/manage things on their own to make it quick, or more controlled for them). Still. The bottom line of having calls for bounties, people ready to pay to have some requests in Mageia answered in a more controlled way, is perfectly fine. Having them including in their requirements that the work be merged into (if possible), or made available to the parent project is even better.
Re: [Mageia-dev] what is this ????
2012/11/24 AL13N al...@rmail.be: like: requiring that the fixes are done in Mageia itself (no 3rd party repository), and as usual that the fixes are done in accordance to our policies. You can't: 1) it's free software. 2) those changes will be first done on a separate repository before being pushed for inclusion. I would also ask that if possible the user who solves it donates a part to mageia, not required. I wouldn't: - the person that opens the bounty already invested money into the change (and to have it pushed to the master project); - the person that takes the bounty and does/pushes the change already invested her time and skills.
Re: [Mageia-dev] [soft-commits] [6430] Do not mix tabs and spaces
2012/11/11 Thierry Vignaud thierry.vign...@gmail.com: On 9 November 2012 21:44, r...@mageia.org wrote: Revision 6430 Author neoclust Date 2012-11-09 21:44:52 +0100 (Fri, 09 Nov 2012) Log Message Do not mix tabs and spaces Please refrain to do this on soft you don't maintain. What's more this got in the way of svn/git blame... What could/should be done about fixing code style then? (not necessarily only here btw)
Re: [Mageia-dev] Mageia 3 final set of isos
2012/9/19 Pascal Terjan pter...@gmail.com: On Wed, Sep 19, 2012 at 10:11 AM, Antoine Pitrou solip...@pitrou.net wrote: Is that necessary? Instead you could have a checkbox install optional proprietary software in the installer. This allows for example magazines to distribute it Are paper magazines still relevant here? (true question)
Re: [Mageia-dev] [soft-commits] [5642] skip packages with no name
On Wed, Sep 5, 2012 at 10:03 AM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Pascal Terjan at 04/09/12 17:57 did gyre and gimble: On Tue, Sep 4, 2012 at 9:52 AM, Romain d'Alverny rdalve...@gmail.com wrote: By the way, there are some builds that get a strangely reported build duration (15588 days; always the same value when it occurs). I didn't investigate yet. So 15588 would be days since epoch. I guess it's the same as Pascal's comment. If it was submitted over 2 days ago we might not read the submit time and it ends up getting a timestamp of 0 and thus 15588 days to build. Ok. So at this point (where we do a find to get the files), what's the good approach: just leave the package/build out of the list if we can't get its name (that's the new behaviour in my pending new index page) or fix the find to get all? I'd say the former. Two others things that are aside this very point: * we could gain more insight over the whole submission/build process if we could store data about way past builds (not necessarily the full details of each build, at least not right now, but at least the basics: when, who, what package, how long it took on which host, what was the result). One way to do it would be to have a database in which we can push and update info about each submission, as it happens (today, everything is only in the filesystem). What control points would need to be modified to push information into such a database? * today, submissions are shown simply by src package. Should we show submission results per arch? (what if i586 passes and x86_64 fails for instance).
Re: [Mageia-dev] [soft-commits] [5642] skip packages with no name
On Tue, Sep 4, 2012 at 4:56 PM, Thierry Vignaud thierry.vign...@gmail.com wrote: On 4 September 2012 16:11, r...@mageia.org wrote: Revision 5642 Author rda Date 2012-09-04 16:11:36 +0200 (Tue, 04 Sep 2012) Log Message skip packages with no name Is that possible? Well, I am guilty of not having checked further why, but it happens that at the end of the list of packages being built, we used to have all the info, except the package name. So it may be that it was mis-parsed, but why on these specific occurrences? is it related to the fact that it's old packages (submitted about 48 hours before) and that some parts of the related files were already removed? By the way, there are some builds that get a strangely reported build duration (15588 days; always the same value when it occurs). I didn't investigate yet.
Re: [Mageia-dev] [soft-commits] [5663] debugging...
On Tue, Sep 4, 2012 at 8:54 PM, Thierry Vignaud thierry.vign...@gmail.com wrote: On 4 September 2012 19:29, r...@mageia.org wrote: debugging... Err... You can debug w/o commiting that... Agreed, I would welcome a way to get a sample of the files tree (what's under /home/schedbot/uploads) to replicate a more similar environment on my workstation - I don't expect to go on the production server for that :-p
Re: [Mageia-dev] Bugzilla mass assignee ping
On Fri, Jul 6, 2012 at 1:42 PM, Marja van Waes marj...@xs4all.nl wrote: Later today there'll be a mass assignee ping for Bugzilla. Couldn't we use another method than this? Like using Bugzilla's native whining feature, or an equivalent where each assignee only get notified of his assigned bugs in a single mail listing those?
Re: [Mageia-dev] [Mageia-discuss] [Mageia-bugsquad] Bugzilla mass assignee ping
On Fri, Jul 6, 2012 at 2:13 PM, Marja van Waes marj...@xs4all.nl wrote: On 06/07/2012 13:59, Romain d'Alverny wrote: On Fri, Jul 6, 2012 at 1:42 PM, Marja van Waesmarj...@xs4all.nl wrote: Later today there'll be a mass assignee ping for Bugzilla. Couldn't we use another method than this? Like using Bugzilla's native whining feature, or an equivalent where each assignee only get notified of his assigned bugs in a single mail listing those? Yes, that would be a lot better. I understood that feature was disabled to solve bug 1932 https://bugs.mageia.org/show_bug.cgi?id=1932 Ok, but there a daily reminder is nonsense. A monthly (or every 2 months) reminder of bugs fitting in your above query would sound sane, if it's sent only to the assignee. If not, then the whole mass ping itself should not be done either.
Re: [Mageia-dev] [Mageia-discuss] [Mageia-bugsquad] Bugzilla mass assignee ping
(removed -discuss from the discussion) On Fri, Jul 6, 2012 at 2:48 PM, Marja van Waes marj...@xs4all.nl wrote: On 06/07/2012 14:22, Romain d'Alverny wrote: Maybe it works better in upgraded Bugzilla :) No, it works in the current setup. A monthly (or every 2 months) reminder of bugs fitting in your above query would sound sane, if it's sent only to the assignee. If not, then the whole mass ping itself should not be done either. Waiting one month to find out whether a bug was assigned correctly is too long, in my opinion, unless the assignee is busy gathering enough information to be able to tell. I think we should ping bug reports for which we haven't got a confirmation that the assignment was correct after two weeks, except when the assignee shows activity in the report. If the assignee thinks the bug was assigned correctly, he can put OK on the whiteboard or set status to ASSIGNED, and he won't show up in this search again, so he won't be pinged for this reason again. We can make a bi-monthly check that will only whine to the assignees, and not others. That makes at most (for the unlucky ones), two mails a month summarizing what they are assigned to and that it has not been checked out of the query. Shall we try that?
Re: [Mageia-dev] [Mageia-discuss] [Mageia-bugsquad] Bugzilla mass assignee ping
On Fri, Jul 6, 2012 at 5:46 PM, Marja van Waes marj...@xs4all.nl wrote: On 06/07/2012 16:49, Romain d'Alverny wrote: Shall we try that? Well, if you replace bi-monthly by twice a month (that seems to be what you mean), then: yes, please! Yes. Ok, test will go in a few minutes to all current assignees that have bugs matching your query (I had to duplicate it to my own account).
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
On Thu, Apr 5, 2012 at 08:11, Maarten Vanraes al...@rmail.be wrote: Op woensdag 04 april 2012 22:59:30 schreef Florian Hubold: As there was no real objection, and no other comments or votes for iceape, i've dropped it from cauldron. FWIW i'm quite unhappy with this. Related, i've also not got any reply yet to my aforementioned inquiry about mozilla branding permissions. About the mozilla branding... Perhaps this should be a meeting point for packaging/council meeting... ie: someone assigned to this point so it's not forgotten. Would have been good to raise this point in Council way sooner. No other than the maintainers may answer both questions (about changes, and about contact/permissions from Mozilla). For Firefox it's dmorgan and for Thunderbird it's anssi.
Re: [Mageia-dev] freeze push mgaonline
On Fri, Mar 16, 2012 at 01:10, Anssi Hannula an...@mageia.org wrote: 15.03.2012 22:07, Dan Fandrich kirjoitti: On Thu, Mar 15, 2012 at 03:25:40PM +0100, n...@gmx.com wrote: * stop using Mandriva URLs and replace them by www.mageia.org (mga#1590) * replace Mandriva strings by Mageia in gnome-mandrakeonline.desktop * replace MIME Type application/x-mdv-exec by application/x-mga-exec Replacing Mandriva - Mageia in user-visible text makes sense, but what exactly is the MIME type used for? If the underlying data format hasn't changed (whatever it is), then this isn't something that should really be modified, any more than renaming image/vnd.microsoft.icon to something else. +1, we shouldn't change the MIME type here. Agreed. But it's not that important now: this code portion was a prototype at the time, has not been used/tested for years (no Kiosk server serving application/x-mdv-exec since Dec. 2006), and this MIME type was created for this very use case. Should we think about some sort of Web-based app store, we'd need to redesign it from scratch and in a better, modular way (options are not the same today).
Re: [Mageia-dev] freeze push mgaonline
On Thu, Mar 15, 2012 at 21:07, Dan Fandrich d...@coneharvesters.com wrote: On Thu, Mar 15, 2012 at 03:25:40PM +0100, n...@gmx.com wrote: * stop using Mandriva URLs and replace them by www.mageia.org (mga#1590) * replace Mandriva strings by Mageia in gnome-mandrakeonline.desktop * replace MIME Type application/x-mdv-exec by application/x-mga-exec Replacing Mandriva - Mageia in user-visible text makes sense, but what exactly is the MIME type used for? If the underlying data format hasn't changed (whatever it is), then this isn't something that should really be modified, any more than renaming image/vnd.microsoft.icon to something else. AFAIR, it used to be for long-dead Kiosk project, several years ago (Kiosk was declared a dead project by the end of 2006). .bundle files (downloaded through http) were containing special instructions to trigger specific urpmi behaviour (adding a media, installing RPMs from this media). It was not used since.
Re: [Mageia-dev] lighttpd and others now require apache
On Thu, Mar 15, 2012 at 21:51, Guillaume Rousse guillomovi...@gmail.com wrote: So I'd rather revert the change, and make lighttpd autonomous also. Unless someone can convince me there is an advantage having lighttpd executing as 'apache' :) Ah, interesting point. Should two or more different webservers run at the same time (may happen for server static and dynamic contents, for instance, or for different services), shouldn't they run under distinct users?
Re: [Mageia-dev] freeze push mgaonline
On Thu, Mar 15, 2012 at 22:15, Kamil Rytarowski n...@gmx.com wrote: I'm in favor of removing all unneeded parts from mgaonline. There were many parts related to megapacks, server editions, club membership. If the .bundle is unused then it too can be removed. Yes, but cutting code out of mgaonline must be done carefully (I believe tv did some cleaning already). Are there functional/features tests along with the code? That could be a start to ensure no required feature is broken.
Re: [Mageia-dev] lighttpd and others now require apache
On Thu, Mar 8, 2012 at 16:48, Guillaume Rousse guillomovi...@gmail.com wrote: My point was just 'if only a directory is needed, just add it to basesystem, and don't create another package just for this'. Ah, yes. Why not too. It doesn't take much room.
Re: [Mageia-dev] [Mageia-discuss] GSOC 2012
Ping. Any other input, mentor candidate or project idea for a potential candidacy to this GSOC? https://wiki.mageia.org/en/SummerOfCode2012 On Mon, Feb 13, 2012 at 23:38, Romain d'Alverny rdalve...@gmail.com wrote: Hi, On Wed, Feb 8, 2012 at 13:24, Michael Scherer m...@zarb.org wrote: Google announced during FOSDEM that the summer of code program 2012 have been launched officially : http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-on.html From what I understand, we have about 2 weeks to be ready to apply. What to do : - complete the page started on the wiki. There is still various TODO to put what is still needed to be fixed. - add links to various sources of information, be it others organisations applying, or summary of do and don't, etc. Updated small bits of it. - review http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/org_admin_agreement and see if we can accept that It looks acceptable to me. Everyone considering submitting a project and/or mentoring one should read it, btw; it takes 5 minutes. - find a backup for the administration of the program. Also, if someone is volunteer to be the main admin, I would be relived to not be that one ( even if, as the one proposing that we participate, I am the de facto volunteer for that position ) I can be an admin backup. - clean the proposal page from drafts before applying Moving ideas/projects to https://wiki.mageia.org/en/Summer_coding_ideas_for_2012 ? - apply I guess we could use a blog post for that, but we have first to speak of fosdem, of the sysadmin trip to datacenter, etc. Right. As soon as we have enough people involved in that.
Re: [Mageia-dev] stardict 3.0.3
On Mon, Jan 30, 2012 at 23:29, Michael Scherer m...@zarb.org wrote: Unfortunately, that's not really the opinion of the sourceforge lawyers. Where is this opinion documented? Are there source/reference/details about said copyright infringement reports? (without which the claim does not stand) I could not find on the old site, neither on the new one, neither through a quick Google search.
[Mageia-dev] Servers downtime scheduled from Feb. 1 to 2 for maintenance
Hello everyone, some Mageia servers will be down from Wednesday Feb. 1st to Thursday Feb. 2nd for maintenance. Particularly, the following services will be unavailable: - our LDAP/user identity db, - build system, - Bugzilla, - all mailing-lists hosted on ml.mageia.org, - Wiki, - forums. So... not all, but, a lot of what you use here! The exact hours of interruption are not known, so expect no availability for those 2 full days. Blog (where an equivalent warning will be posted), Web site, mailing-lists (and archives) will not be down. In the meantime, in our Marseille data center, 4 of our sysadmin team (dams, boklm, rtp and misc in this case) will do nothing less than: - upgrade servers to Mageia 1, - replace broken HDD, - add SSD in build nodes, - install our ARM build system, - install a dedicated server for backups, - install a dedicated server for QA and packagers. All hardware purchased thanks to what Mageia.Org received from so many donators (http://mageia.org/en/thank-you/ again). This is quite a short notice, we apologize for this. Thank you for your comprehension (and please spread the info to your list/team if relevant).
Re: [Mageia-dev] Fosdem 2012 - Mageia stand
On Sat, Jan 28, 2012 at 21:36, Bernard Siaud alias Troumad li...@siaud.org wrote: Can someone from mageia go to this meeting for speak with the developer of Mandriva ? Of course, if welcome *. But there's no time/place/invitation set and apart from this wiki page, no one heard of this meeting. * we will be 20+ people from Mageia (among which all Board and almost all Council members) at FOSDEM (https://wiki.mageia.org/en/Fosdem_2012#Who_will_be_there), so we will be available.
Re: [Mageia-dev] Fosdem 2012 - Mageia stand
On Sat, Jan 28, 2012 at 09:39, Bernard Siaud alias Troumad li...@siaud.org wrote: Is it possible to work together again? The right question is: do we go the same road? partial answer is: we don't know about theirs at this time. If they take the time to build such an alternative, it might be that they are not satisfied with how Mageia governance and/or plans are designed.
Re: [Mageia-dev] Official VM images for Mageia 2?
On Wed, Jan 25, 2012 at 18:35, zezinho lists.jjo...@free.fr wrote: Le mercredi 25 janvier 2012 16:30:23, Romain d'Alverny a écrit : I'd like to discuss/plan how we can build and distribute ready to use VM images of Mageia 2 along with original ISOs, from our download pages. I use LiveCD for this kinds of tests. It takes only a few seconds to install it in a VM. This is an option, but LiveCDs do not provide a minimal system, and their intended use is more for a graphical user desktop. VMs can be used for scriptable config and deployment of test/staging/prod platforms, using shared recipes (chef, puppet, other). Providing a pre-installed, predictable minimal system is helpful in this case. I'm especially thinking about Vagrant boxes, but other images can be used for the same goals. It's not about changing/diminishing the current dev/packaging focus for Mageia 2 of course (not the same priority), it's to complement the build chain with an alternative way to use the platform in the end.
Re: [Mageia-dev] Official VM images for Mageia 2?
On Thu, Jan 26, 2012 at 11:16, Buchan Milne bgmi...@staff.telkomsa.net wrote: On Wednesday, 25 January 2012 17:30:23 Romain d'Alverny wrote: Generic VM images, or ones targetted at specific uses? If specific uses, it might be worthwhile considering live ISOs targetted at the use case with installation support. In my case, I would consider looking at a minimal XBMC-based (possibly with samba and a few other tools as well) live ISO/USB. I would consider at least those 3: - a generic minimal system install ISO (quick to download and base from which we can generate more elaborate images) - equivalent generic minimal system VM - derivatives: - a Vagrant image (same as above + a specific user/packages setup) - your XBMC-based one I started playing with a boot.iso + auto_inst.cfg (this is really great, we ought to document it better somewhere about it) + Vagrant a few weeks ago, but didn't make it yet. Will clean this up and post it somewhere. Target VMs: Xen, VMWare, Virtualbox, Vagrant (with a minimal install + specific config), other, you name it, as long as it can be managed (best would be to have these build automatically from source ISOs + ad-hoc auto_install.cfg + post install conf). Most of these tools support OVF, so do we have tools that can generate OVF easily? No idea. What about publishing official images to Amazon EC2? Yes! I don't know if there is that much value in providing specific VM images, when instead we may want to look at providing good tools for sharing VM configs and tools for easily generating images from those configs. I'd say both. Sharing configs and tools is great, having a few small images available is great too for those that prefer to focus on using it at once (and for cloud hosts too). If we were to automate the process, could we chain somehow this: - bcd with a minimal system image - isocheck - vmbuild? foreach each vm config provided (we can store all this in svn), does: - push specific auto_inst script into the install ISO - run the ISO into the virtual environment - package the VM - checks - deliver to download
[Mageia-dev] Official VM images for Mageia 2?
Hi there, I'd like to discuss/plan how we can build and distribute ready to use VM images of Mageia 2 along with original ISOs, from our download pages. Target VMs: Xen, VMWare, Virtualbox, Vagrant (with a minimal install + specific config), other, you name it, as long as it can be managed (best would be to have these build automatically from source ISOs + ad-hoc auto_install.cfg + post install conf). Uses can be: evaluation, development/staging environments, you name it too. hurdman has some experience and is a first volunteer to work on this; others? (input, recipes, hands).
Re: [Mageia-dev] Mozilla is switching to MPLv2
On Tue, Jan 17, 2012 at 09:10, Florian Hubold doktor5...@arcor.de wrote: Am 17.01.2012 01:20, schrieb Kamil Rytarowski: Please be aware of licenses. http://tech.slashdot.org/story/12/01/06/1752240/mozilla-public-license-20-released https://www.mozilla.org/MPL/2.0/ https://wiki.mozilla.org/MPL_Upgrade It essentially means that the current triple-licensing will be removed in favour of MPLv2 only, which in turn means mozilla stuff can't be linked anymore to GPL stuff, IIUC. Yes it can. See https://wiki.mozilla.org/MPL_Upgrade#Why_is_it_better.3F and https://wiki.mozilla.org/MPL_Upgrade#What_will_be_the_difference_in_terms_of_forward_licence_compatibility.3F https://www.gnu.org/licenses/license-list.html#MPL Beware, now, it's https://www.gnu.org/licenses/license-list.html#MPL-2.0 we're talking about.
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Thu, Jan 12, 2012 at 21:25, Christian Lohmaier lohmaier+mag...@googlemail.com wrote: On Thu, Jan 12, 2012 at 8:42 PM, Florian Hubold doktor5...@arcor.de wrote: Am 12.01.2012 19:01, schrieb Christian Lohmaier: [..] PS: Maybe next time you could improve on your wording, the policy may currently be incorrect, not reflecting good packaging practices, but as it's only a policy written by humans, it's not dumb. Just a hint. ;) No, I disagree. The policy as written is dumb in my opinion. But that doesn't mean I consider the people who edited the wiki to be dumb. That is a huge difference in my opinion. If I tell someone Ugh, that's an ugly shirt you're wearing today it is not the same as telling the person you are ugly - but people on this list do get it that way. Agreed. Still, let's cut it short and to the point. Can someone rewrite it as it should be then (adding the missing exception if I understood correctly)? By the same time, could the document be written short and straightforward: - start the document with the very policy (at this time, it's in the 3rd sub-section); - write it in a more assertive way (not should do but does); - all other subsections should be there to explain status, context, roles, etc. It might be my lack of understanding the English language, but stupid just is a regular word - it is not like I'd be using something like moth.*ker here. Also my thesaurus only lists words that I consider more harsh (like retarded, brainless,...). You could have said misleading, deceptive, heartbreaking, disheartening, expectations breaking, amusingly inaccurate or unusual. The fact is that this policy document starts with a warning that it is a first pass - so it may be improved. In short: let's behave a bit more like gentlemen this year, shall we? :)
Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
On Wed, Jan 11, 2012 at 21:13, nicolas vigier bo...@mars-attacks.org wrote: The main problem is that there seems to be a majority of people who think it should be enabled, that there is no good reason to not do it, or at least try it for a few months (as was proposed several times by different people), but it is still not done, because someone decided it shouldn't be done. It could have been enabled in 2 minutes 8 months ago and we would have avoided those endless debates. So it goes back to a Council discussion/decision, where the above was decided. Next Monday meeting.
[Mageia-dev] references to outside web sites/wiki
Hi! (same post sent to mageia-dev) If you find, or wrote, in our wiki (http://wiki.mageia.org/en/ ) stuff that references documentation hosted on the MDV wiki (http://wiki.mandriva.com/ ), it is a good idea to not only reference it now, but to really import the content into our own wiki, now. That is valid for other sources as well, of course, but wiki.mandriva.com may be shut down for good in just a few days (no comment about the thing, just stating a fact). wiki.mandriva.com contents are licensed under CC-By-SA 2.5 (see http://wiki.mandriva.com/en/Mandriva:Copyrights). So you can import contents from it, please comment your commit with a mention to the original URL + a mention in the end of the article, like Portions of this are imported from ..., licensed under CC-By-SA 2.5. It can be portions, or full articles. Would be good too to be able to mount a static mirror copy of it, if it's needed, but I am not sure how to import it (wget'ing a mediawiki instance is tricky). Btw, do we have hard dependencies (documentation, I mean) in other MDV's online resources? Bugzilla? List archives? or are these properly archived elsewhere? other? (note to self, push forward the contributions db licensing policy to make it really explicit that it will be encouraged to do so with Mageia's stuff)
Re: [Mageia-dev] references to outside web sites/wiki
On Wed, Jan 4, 2012 at 22:36, Johnny A. Solbu coo...@solbu.net wrote: On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote: wiki.mandriva.com may be shut down for good in just a few days What? Are Mandriva serisouly considering closing down the Wiki? Mandriva is on the path to filing for bankruptcy on January 16th. Sources (in French): * https://linuxfr.org/users/jaypee/journaux/fin-de-mandriva * http://www.boursorama.com/forum-mandriva-ex-mandrakesoft-courrier-de-mandriva-414340508-1 In the event it does occur, their servers may be shut down anytime.
[Mageia-dev] isocheck, quick basic checks for built ISOs
Hello there, Damien and I uploaded soft/isocheck (http://svnweb.mageia.org/soft/isocheck/trunk/) several days ago. It tests for basic rule-based things in a built ISO (name, size, checksums, headers, and some contents so far) and can start to save a lot of time. While it still needs improvements, it's ready for some action, right from the output of bcd. And it's up for review. Usage, dependencies are described in the README. Anyone can use it individually on its own copy of images, the person building ISOs first, as a task just after bcd (might be good to try it for alpha3). This could be used too as a filter in an automated build scenario: built ISOs are staged in a repository where a cron picks them one by one, runs isocheck tests, appends the log and stage them further for QA team (or a deeper automated test tool), unless there's a failure (and it notifies building person/team). Speaking of failure, should the script test fail at once at the first issue, or continue to test other potential issues? (for instance, an ISO may be too big and have misconfigured ISO headers and ..., etc.). So far, the script fails at the first failed assertion. The next step in automation would be misc's Viviane (https://www.mageia.org/pipermail/mageia-dev/2011-August/007539.html) and/or http://www.os-autoinst.org/ or other test assistant tool . That will help QA team and testers to focus on other, manual-only, categories of tests. Feel free to suggest additional tests for isocheck (and for the rest too)! Romain
Re: [Mageia-dev] [soft-commits] [2359] coding style update (perl_checker)
On Sat, Dec 10, 2011 at 18:59, Thierry Vignaud
thierry.vign...@gmail.com wrote:
On 10 December 2011 18:29, r...@mageia.org wrote:
coding style update (perl_checker)
uh? Tools.pm doesn't currently pass perl_checker
Right; but I couldn't see why that was a syntax error at that point
(and the script did work). Anyway, now it looks much better (but for
used modules or not recognised yet).
just do sg like this:
[...]
if ((@info{qw(name version release variant arch medium build
ext)}) = $name =~
m/^(Mageia)-(\d+)-((?:alpha|beta|RC)\d*)?(-(?:.*))?-(i586|x86_64|dual)?(?:-(CD|DVD|BD))?(?:-(build_\w+))?\.(.*)$/)
{
$info{full} = $name;
}
[...]
Looks much more compact, thanks. Added a else { %info = (); } to
satisfy the expected behaviour (empty array returned if no match).
open(my $file, temp_media_on_iso.log) if -r temp_media_on_iso.log;
while ($media = $file) {
just reuse cat_() from MDK::Common (simpler, easier to read)
Thanks!
By the way, is there a best Web-based doc for MDK Perl libraries?
(could find one, but not at once, and I didn't count many). Or shall
we think about it?
Re: [Mageia-dev] [soft-commits] [2359] coding style update (perl_checker)
On Sat, Dec 10, 2011 at 20:37, Thierry Vignaud
thierry.vign...@gmail.com wrote:
On 10 December 2011 20:25, Romain d'Alverny rdalve...@gmail.com wrote:
if ((@info{qw(name version release variant arch medium build
ext)}) = $name =~
m/^(Mageia)-(\d+)-((?:alpha|beta|RC)\d*)?(-(?:.*))?-(i586|x86_64|dual)?(?:-(CD|DVD|BD))?(?:-(build_\w+))?\.(.*)$/)
{
$info{full} = $name;
}
Looks much more compact, thanks. Added a else { %info = (); } to
satisfy the expected behaviour (empty array returned if no match).
This is wrong.
Once declared (aka my %info), %info is initialized and is equal to ().
Yes, but otherwise, testing the code you provided, even if the regexp
test fails, returned %info is still populated with keys, pointing to
undef values.
By the way, is there a best Web-based doc for MDK Perl libraries?
(could find one, but not at once, and I didn't count many). Or shall
we think about it?
perldoc MDK::Common
Thanks, this is cool for a local access. Looking for a way to export
this into HTML.
Re: [Mageia-dev] Teamviewer and X86_64 build . . .
Bringing a small bit of controversy, not on the very topic, sorry, but on a few remarks. On Mon, Nov 28, 2011 at 15:25, Oliver Burger oliver@googlemail.com wrote: Am Montag, 28. November 2011, 15:10:01 schrieb Florian Hubold: I don't agree. I do think our main goal should be to provide a good linux distro with as few proprietary packages as possible. Guys, please reread our announcement (http://mageia.org/en/about/2010-sept-announcement.html ); quoting a small part of it: keep a high-level of integration between the base system, the desktop (KDE/GNOME) and applications; especially improve third-parties (be it free or proprietary software) integration;. That was a plan, and plans are made to change and adapt, but still. But I don't like us providing more and more nonfree applications. If we are not to provide (that is package, host and distribute - and that is perfectly fair) these, couldn't we at least ease that for others (that would like to package their own apps, or host a specific, separate repository of nonfree apps that would still appeal to a significant fraction of users)? That would mean some more doc and tools for 3rd party packagers. And would solve in the same time one of the question that was opened on Council and not yet ported to -dev (aka, very large nonfree packages, such as games -data). Or do we let them in the cold? It really is not that difficult to install things like flash, skype, teamviewer and so on. In my eyes it would be the far better solution to provide documentation on how to install them then provide a lot of those get-foo packages. Right. Although easy usability is a good thing, people should remember they are working on the most complex machine they do have in their homes. They wouldn't use it if they had this in mind. No one would. :-) While nobody expects to be able to use a modern video recorder without reading the manual first, everybody expects to be able to use a far more complex machine like a computer without reading anyting? That's a fallacy. There's no excuse for making things more complicated that they need to be. It's not absurd that most people _expect_ that installing an application on their system is as simple (and as safe) as a drag'n drop or as typing an URL in their browser. Their focus is beyond that. Romain
Re: [Mageia-dev] alpha 1 release info preparation
On Tue, Nov 22, 2011 at 20:58, Dick Gevers dvgev...@xs4all.nl wrote: On Tue, 22 Nov 2011 20:04:56 +0100, Romain d'Alverny wrote about Re: So please see https://wiki.mageia.org/en/Mageia_2_alpha1 as the canvas and update as you see fit. Ping? Alpha 1 release is in 3 days, and it cannot go outside without this info available. And you guys know what to say there. Till now qa recorded all in http://piratepad.net/owkBzzoJId Thanks. Well, this is cool for QA, but difficult to summarize as such for release notes by an outsider. Release notes are in this shape at this time: https://wiki.mageia.org/en/Mageia_2_alpha1#Major_new_features - and this directly shapes the release announcement (to be managed by Patricia). At this time, that means we have near to nothing to say... although there are quite some changes. Are we to push the ISOs online tomorrow, without a status of what's new (packaging team?) and without a public plan for tests technical review (QA team?) and without a drafted roadmap for the big items to work on for the next alpha? (and without an announcement) Anne and me will manage the download links, for all the rest, insiders summarized input is more than welcome for their own part. Ahoy! Romain
Re: [Mageia-dev] alpha 1 release info preparation
On Mon, Nov 21, 2011 at 17:43, Romain d'Alverny rdalve...@gmail.com wrote: alpha1 ISOs are on their way for this Friday (Nov. 25th) and we need to gather and prepare info about: - what ISOs will be available, - what's new and how to handle it (systemd, but not only) - what's is already known not to work, - what to test and how to report bugs. So please see https://wiki.mageia.org/en/Mageia_2_alpha1 as the canvas and update as you see fit. Ping? Alpha 1 release is in 3 days, and it cannot go outside without this info available. And you guys know what to say there. Romain
[Mageia-dev] alpha 1 release info preparation
Hi there, alpha1 ISOs are on their way for this Friday (Nov. 25th) and we need to gather and prepare info about: - what ISOs will be available, - what's new and how to handle it (systemd, but not only) - what's is already known not to work, - what to test and how to report bugs. So please see https://wiki.mageia.org/en/Mageia_2_alpha1 as the canvas and update as you see fit. This will serve as a basis for the release announcement. I'll see with marcom and web teams for the other parts of the release. Thanks! Romain
Re: [Mageia-dev] Proposal for bug statuses and workflow
On Wed, Oct 19, 2011 at 23:30, Samuel Verschelde sto...@laposte.net wrote: CLOSED replaces RESOLVED, because I think it's nicer for the bug reporter if we close bugs rather than consider them resolved when the reason for closing is WONT-FIX, DUPLICATE, OLD, etc., statuses that obviously don't match the meaning of RESOLVED. RESOLVED does match. Beware, this is a known false friend in English/French (although it is used in a equivalent meaning as in Je suis résolu à or J'ai pris la ferme résolution de). To resolve is to decide firmly, not to solve (well, as well, but in a later meaning). If the RESOLVED status in Bugzilla had been understood as SOLVED, then RESOLVED - FIXED would be a pleonasm. Romain
Re: [Mageia-dev] Proposal for bug statuses and workflow
On Thu, Oct 20, 2011 at 10:43, Guillaume Rousse guillomovi...@gmail.com wrote: Le 20/10/2011 10:26, Romain d'Alverny a écrit : If the RESOLVED status in Bugzilla had been understood as SOLVED, then RESOLVED - FIXED would be a pleonasm. You can solve a problem differently than fixing it, for instance by claiming it is not a problem, or that it is too old to really care. That's precisely the resolution to the problem: fixed (and the solution is provided along here) or discarded or reported elsewhere. https://bugs.mageia.org/page.cgi?id=fields.html#status is more visual about this. Romain
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On Tue, Jul 12, 2011 at 23:08, Balcaen John mik...@mageia.org wrote: On Tuesday 12 July 2011 16:48:58 andre999 wrote: [...] For all these reasons, I think that it is much more appropriate to wait to be approached by the patent holder. (If not ourselves, then some other distro.) I hope you're not serious when writing thoses lines. Actually, this is what seems to be a standard process in the industry when you read the headlines. One doesn't hear about (software) patents when licensing occurs as expected, but when someone in the industry challenges (or is challenged by) some other actor patent. Because that's the only way to prove a patent to be ineffective (for various reasons) before it expires. (I am not proposing one or the other option - and it's going out of the initial question in this thread - tmb reframed it well). Romain
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Speaking of the software patent stuff, the Debian Project just released a Community Distribution Patent Policy FAQ here: http://www.debian.org/reports/patent-faq (announce: http://www.debian.org/News/2011/20110709 ). Romain
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornath molc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Romain
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On Wed, Jul 6, 2011 at 14:04, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 6 July 2011 13:58, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornath molc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Third point is wrong, a license that is might be free or open source, which, I think, means only software with an open source software License. I understand this as: software that might be free or open source = can be not free or open source. might expressed the possibility, not the requirement. IOW, tainted does not discriminate free and non free software. Although the wording should be clearer / more precise. Indeed. Romain
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On Wed, Jul 6, 2011 at 15:04, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 6 July 2011 14:27, Romain d'Alverny rdalve...@gmail.com wrote: I understand this as: software that might be free or open source = can be not free or open source. might expressed the possibility, not the requirement. IOW, tainted does not discriminate free and non free software. It does differentiate; given that Anssi is the one who worked on the tainted policy the most, and he doesn't think faac should be in tainted, is enough to say that the wording in the wiki needs to express our stance on the issue in a clearer way... Ok, fine then, fix this in the definition on the wiki. But make sure to explicit what becomes of software that is non free and questionable regarding patents (id est, it goes nowhere), so that the layout is clearer (here with a changed triage): - core: 100% free software - tainted: 100% free software, but locally subject to software patents or local legal terms - nonfree: non-free software - nowhere, we don't package/distribute this: non-free software, for which we may still have the source code or binaries, and a license to redistribute from author but patent law or other local provision may prevent to redistribute it anyway. (I am not taking sides here, just re-explaining your understanding) Romain
Re: [Mageia-dev] Mageia Advisories Database
Hi, On Tue, Jun 28, 2011 at 15:34, Samuel Verschelde sto...@laposte.net wrote: Le mardi 28 juin 2011 15:20:33, nicolas vigier a écrit : In order to send updates advisories, and have a web page listing all previous advisories, we need to create a database to store them. So I think it should have the following info for each advisory : - advisory ID: something like MGA-[NUMBER] ? - advisory date - affected source packages - affected distribution versions - CVE numbers - list of binary packages with sha1sum - Mageia Bug # - Reference URLs - advisory text Anything else ? If using SQL, make sure to normalize the db schema a bit (that is, for instance, an advisory table, with a distributions table, and a relationship). MDV security advisory web app had a single table, with new columns added each time a new release was published and that was really not good, neither safe to maintain. In this perspective, there could be the following tables: - advisories (id, date, text, list of URLs, list of bug #) - distributions (id, name) - source packages (id, name, version) - CVE numbers Not sure about the rest; depends on the data details and what type of queries would be expected: - do we only query after the advisory id or do we plan to have stats per distribution, source package? - what screens do you expect? - are there several CVE numbers for a single advisory? - is there a link from source packages and binary packages? Romain
Re: [Mageia-dev] Release cycles proposals, and discussion - messages from the forum
On Tue, Jun 14, 2011 at 15:38, Lee Forest lee...@gmail.com wrote: And keeping one golden rule of software development in mind, don't let your system do redundant tasks. As golden as the need to not to have redundancy: it depends. Redundancy can be very, very appreciated. But not always in a discussion (be it with mail or web-based forum) where appropriately quoting is very, very appreciated too. :-) What about being able to [...] Yes, that could be nice, only, Mageia is not about building first an improved mail/forum gateway, but about building first an improved operating system. You can't blame people for focusing on this and doing it with tools they are productive with already. Migrating everyone to forums is, here, not acceptable. Dismissing others from each side as well. Migrating everyone to ml was not even considered (or we wouldn't have planned to have forums, or we would have let them to local groups only). That this question gets discussed on and on is a (good) sign that people are motivated to participate. But are you motivated enough to cross the bridge, to change your habits and to meet the people where they gather to build this thing, and to instill improvements? The bridge is wide open and there's so much to built it further. Only, it's not necessarily what you expect it to be, at first. There have been several suggestions as to build a forum/mail gateway, only without the means to actually implement it within our infrastructure. For what is existing, tux99 used to provide a 3rd place showcase gateway in the past but I am not sure what its future status will be; or you have http://news.gmane.org/gmane.linux.mageia.devel or http://blog.gmane.org/gmane.linux.mageia.devel or we could consider another gateway if it's worth it (Google groups? other?) and if there's someone to lend a hand to... no, to join sysadmin team for that (and other things). Speaking of focus, this thread is about the release cycle. Now you are welcome to open a bug http://bugs.mageia.org/ in the Websites, forums.mageia.org section I guess; if you think it's worth it to dig/document this ml/forum thing further (and even better, if you have a better workable solution at hand). But please let this thread on topic. Romain
Re: [Mageia-dev] Tainted build
On Tue, May 31, 2011 at 16:31, andre999 and...@laposte.net wrote: Michael Scherer a écrit : Supixel rendering, there is a patent on it : http://lists.gnu.org/archive/html/freetype/2006-09/msg00064.html The reference is from September 2006, almost 5 years old. There is no indication of expiry dates, and rather limited details on the patent claims involved, apparently now held by Microsoft. (The further link to Microsoft is no longer valid.) It would seem advisable to have more info before making a decision. And you're welcome to search for it and document this situation. Such as with: * http://www.freetype.org/patents.html * http://en.wikipedia.org/wiki/ClearType#Patents * http://en.wikipedia.org/wiki/Subpixel_rendering#Patents Said patents are due to expire in 2018/19 according to these sources. Romain
Re: [Mageia-dev] Possible workaround of bug related to Orphans: need opinions
On Fri, May 27, 2011 at 14:49, Marcello Anni marcello.a...@alice.it wrote: no (as i explain below), the communication is ok, is the kindness and the explanation of Anne that disappointed me. Note to self for next time: take a photo of ennael handing a huge sign It's freeze time! with a large smile + a link to a tutorial that explains what that means for everyone - and put it in a corner of all mageia.org web sites. but in fact i know that we are in freeze, but i see also that some packages (e.g. mageiaonline) continue to be improved for release, Not improved, but fixed. Because this one is release critical - this has nothing to do with a cosmectic change. but do you consider a change in a language string as a difficult change? i don't have technical skills but i don't think so... No, but being in freeze disregards totally that a change is trivial (changing the string) or not (fixing the behaviour). It's not a release critical bug, so it just does not get on the table past the freeze date. And even less (because there are exceptions) when the release time is approaching. Romain
Re: [Mageia-dev] Credits for Mageia
On Wed, May 25, 2011 at 16:05, Anne nicolas enn...@mageia.org wrote: Quick questions about credits. I'm on it to update credits about Mageia contributors. What shall we do about previous Mandriva contributors inside ? - remove it as we are talking about Mageia current distro - keep all list as they contributed to Mandriva (list is not complete, and still a long one to maintain) - add a general mention to Mandriva contributors about their hard work Keep a separate, frozen credits file about Mandriva contributors and reference it from the main credits file with current distribution contributors?
Re: [Mageia-dev] about icon Join Mageia Community
Hi, On Fri, May 20, 2011 at 22:20, Luc Menut lme...@free.fr wrote: Currently, the desktop's icon Join Mageia Community still directs to htts://identity.mageia.org. It was a good link for testers of pre-release. But I wonder if it isn't a bit harsh for newcomers and average linux users of official release. I would see better a page which explains what is the community, and how users can found informations and help on forums, how reporting bugs on bugzilla, how they can contribute in various ways to the project, ... WDYT? Ideally, it would redirect to http://mageia.org/contribute/ - that for now redirects to http://mageia.org/ but that would turn into the contributors landing page as soon as ready (contributions welcome there - there's the wiki how to contribute page that can be used as a guide for that). Identity is not the best place to land at, unless some work is made on it. But the point is timing - for the change to be pushed there. Would have been nice this to be reported sooner, but that's already nice :-) Romain
Re: [Mageia-dev] Suggestion: what to do with iso?
On Thu, Apr 28, 2011 at 08:52, Maarten Vanraes maarten.vanr...@gmail.com wrote: So, I was talking to someone i know about Mageia, and she poked around the site, but then asked how to put the iso on an usbstick, since her netbook didn't have cdrom. I had to admit i didn't know exactly how, which brings me to my point: Perhaps it would be nice to have a link on the download page, on how to handle the iso for people who don't know how? (ie: burn it; or usb-stick-ify it) WDYT? It's always good to have this kind of documentation, that we can provide on the download page for after use. Related docs: * http://wiki.mandriva.com/en/Draklive#Building_a_live_CD_or_live_USB * http://wiki.mandriva.com/en/Docs/Installing_Mandriva_Linux#Installation_from_a_USB_stick * maybe others I didn't find about this, but no equivalent doc on our side for now (in Wiki or website). So someone to write an article about this is welcome. Romain
Re: [Mageia-dev] [Mageia-Dev]Default directory for wallpapers
On Sat, Apr 30, 2011 at 19:26, Ahmad Samir ahmadsamir3...@gmail.com wrote: As you can see it's a jumble, each DE has a different idea of where wallpapers should go; and it becomes more confusing when the same issue is re-discussed afresh in a whole new thread, saying the same things that were said in the old one :) Is there a bug that states the problem? And can the problem be stated in a single sentence, like Wallpapers are scattered/duplicated around, because each DE has a different idea of where they should go? Romain
Re: [Mageia-dev] Tainted Software - once more
On Thu, Apr 14, 2011 at 16:02, Frank Griffin f...@roadrunner.com wrote: On 04/14/2011 07:28 AM, Tux99 wrote: Does anyone know what the status of the buildsystem with regards to building dual core/tainted packages from a single source rpm is? Not done yet. It's in sysadmin team's TODO (the usual sysadmin team members welcomes people to help is still valid). And to re-ask a related question that was never resolved: is tainted supposed to be a replacement for PLF, or will PLF still be required for those who want/need packages with legal limitations ? We still need to improve on that yes (would it be only for Tier2 mirrors). To be discussed at the next Council? Anyway, there's no general rule for that, further than: what goes here is: - what is either free software or not (could go in core or nonfree), - but that may not be redistributable in some areas (because of software patents or other issues). Defining what is the valid reference area to allow redistribution is not done yet, but we can aim at Europe/France (this is where the primary mirror is) - the only main threat I can see here is the coming European Patent initiative, however I am not sure what stance this one will take regarding the possibility of software patents. That in turn doesn't mean that redistribution of tainted _is_ forbidden out of this reference area. But it means that software that could be forbidden, may be included in tainted. Others may confirm that this will cover most of what PLF provides already - but that there will be some packages left anyway. For all the rest (stuff we can't, for certain, legally distribute within EU/France), you'll need a separate repository Mageia.Org can't Now, what the precise list of packages in tainted is... depends on packagers. See current: http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/i586/media/tainted/release/ However, for sure, there should be a list maintained somewhere of the list of software that cannot be added in tainted, and for what reason (and what the resolution of it would need to be). So that each request for a potential package in tainted gets documented. Romain
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
On Fri, Mar 25, 2011 at 10:09, Tux99 tux99-...@uridium.org wrote: You are missing the point. QT3 is already part of Mageia and it wasn't me who added it. All I'm asking is if there is any compelling reason not to enable qt3-devel in the existing qt3 source package that is part of Mageia. Then ask the qt3 maintainer - and as long as you don't expect to give a hand in this maintaince, live by her/his answer (if it's only about qt3). And if you're not satisfied with the recommandations/answers you got from there, just push the topic as a clear question to a next coming Council meeting to decide on this and you'll see (but it's likely the Council will stand by the maintainer recommandation, unless there's really something big at stake on the contrary). If there isn't any COMPELLING reason, then qt3-devel should be reenabled as long as someone wishes it. If it's deprecated stuff, is there any compeling reason to reenable a devel package of it. And if someone wishes it back, and the maintainers thinks it's not worth it (too old, deprecated, unstable, complex, unclear, not the plan), the maintainer has the hand (so one can become the maintainer if it's really needed for her). What everyone here seems to forget is that a community distro should be first and foremost about FREEDOM. Freedom to let others enjoy their preferred software, not ARTIFICIAL RESTRICTIONS imposed by personal preferences or unnecessarily restrictive ARBITRARY RULES made up along the way by a few of the core members. Wait. What you seem to forget is that this is not only about rights but too about duties. The freedom above comes from people that take their time to craft and package things, so they are verily in their right and duty to make choices - documented, discussed, agreed. And it's not because just one or two people argue and argue the contrary that the maintainer should ... obey. See above posts, we've been several to suggest you a more practical path for everyone. That choices made here in this project do/will not satisfy everyone is plain obvious. Those choices don't prevent one from reverting them on ones end, demonstrate they are worth it in the project main line, and have them integrated. Romain
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
On Fri, Mar 25, 2011 at 10:37, Tux99 tux99-...@uridium.org wrote: Quote: rdalverny wrote on Fri, 25 March 2011 10:30 Wait. What you seem to forget is that this is not only about rights but too about duties. The freedom above comes from people that take their time to craft and package things, so they are verily in their right and duty to make choices - documented, discussed, agreed. And it's not because just one or two people argue and argue the contrary that the maintainer should ... obey. As a general principle in a community that values freedom anything that doesn't affect others negatively shouldn't be arbitrarily restricted. You can't force a maintainer to do something you want and that she judges not right for her set of packages. At best you can ask a community (council) decision about that, and that may lead to you (or someone else) taking the maintainance of the said package. If you can't work here by that, or if you are not happy with how things go here, you are free to discuss this openly with members of the council or of the board to sort it out. Here was only a discussion where you get overly alarmed without any necessity when people start to answer their views contrary to your plans. Nowhere was a decision to block you. If you wanted a consensus, you've seen in this thread what it was; that still doesn't block you from doing/pushing your changes as long as they don't break anything. If you wanted a decision, you'd have to formally ask for that the packagers team, or the council, or the board: that was not done. So what are you complaining about? Also I never asked anyone else to do anything, I said I would reenable qt3-devel unless there is a COMPELLING (i.e. blocking) reason not to do so. So why all the fuss? Take the maintainance of the package, make your changes, submit it and here you are. romain
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
On Fri, Mar 25, 2011 at 11:33, Tux99 tux99-...@uridium.org wrote: Quote: rdalverny wrote on Fri, 25 March 2011 10:53 If you can't work here by that, or if you are not happy with how things go here, you are free to discuss this openly with members of the council or of the board to sort it out. Is there a procedure for that somewhere? I would think such discussions are supposed to happen on the MLs (rather than in private) and given that board/council members posted in this thread I would assume that this discussion is happening here. That's still a discussion, where views and directions are given. No strict decision. Because I'm a board member does not mean that everything I say in any discussion is a de-facto board view/decision (thankfully). It can hint about what my views are and how I would express them in a board meeting; but it doesn't mean that this will necessarily be what I'll vote for either. Are you saying that the members of the council that posted here in this thread would give a different answer if I contacted them formally (how?) as members of the council? Not necessarily, but it can happen. As a reminder: - council meeting/decisions are made by team representatives, that express their team's views; - board meeting/decisions are made by board members, that express their own views, with consideration given to the council (hence teams) and community views at large + project objectives means. That does not prevent individual members of each, out of these instances, to express their own views, without these having the force of a rule at once (again, thankfully). I have no problem co-maintaining the package (with regards to the devel side of it) but I'm not aware of any formal procedure to take maintenance of a package. Is there such a procedure formalized somewhere? See that with your mentor. Romain
Re: [Mageia-dev] Non-free firmwares in installer
On Thu, Mar 24, 2011 at 11:39, Wolfgang Bornath molc...@googlemail.com wrote: But I don't think it would be a good idea to include non-free contents in the distribution ISOs at all. That this assumed majority does not care about the issue does not mean we should not care either. We should rather stress the point. We already made such a difference by using different repositories, we not continue this in our product line? We use a different repo for non-free, we also should use a different ISO for non-free. Well, that's precisely debatable (and why I'll try to setup a relevant survey through marcom). The ISO can be seen as a static commodity storage; that it holds core and nonfree makes no such difference as that those two media are available from the network without discrimination. So yes, the ISO in itself would not be free anymore; but as long as the install process does not pick into the nonfree media unless the user asks to, what does it make an issue (not that I have no idea about that, just that I'd like to see it expressed again from a different POV of mine - and that will help for the survey definition too). And that would make the case for a consistent installing experience that, no matter you're doing an exclusively ISO-based install or a network-based install, you get through the same steps (with a consistent opt-in or opt-out, clearly explained). It would only happen that non-free media is available locally if asked for. The alternative, if we're not to mix things on the static media, is to have distinct ISOs: free and nonfree/tainted ones. Times the format: DVD/CD/arch/USB through which we would have to decide to ease: building, qa and distribution (we will have to choose a default one to provide to visitors on the download page for instance). Romain
Re: [Mageia-dev] Non-free firmwares in installer
On Thu, Mar 24, 2011 at 12:03, Wolfgang Bornath molc...@googlemail.com wrote: In the public appearance this would make a difference. As soon as there is non-free contents on the ISO it is a non-free ISO. That we provide non-free on the mirrors doesn't make Mageia a non-free distro, only what we offer as products. Yes. That's why I also don't like the idea to have a free ISO and an ISO including core non-free. Why not? (genuine question - that was what Powerpack used to be - and there are places where shipping a DVD is still more affordable than getting it through the wire). No. As I already wrote: a small dualarch driver ISO is all that's needed. No issue about what kind of distro Mageia supplies, no issue about build efforts. Ok. Romain
Re: [Mageia-dev] qt3-devel needed for Trinitydesktop (KDE 3.5 successor)
On Thu, Mar 24, 2011 at 09:13, Tux99 tux99-...@uridium.org wrote: Like I said before, KDE3.5 coexisted very well with KDE4 since 2009.1 on Mandriva and Trinity is even more so being developed with coexistence in mind, so there shouldn't be any unsolvable issues. Maybe it did coexist well at a significant cost on the packaging side? (time, packaging compromises) and maybe the situation isn't exactly the same as then? This is exactly what I would call a reasonable factual argumentation. But an argument is not going to make anyone progress one way or the other here obviously. If there are fears, then provide facts to counter them (no argument, but facts). You propose to add TDE in the repository. After this discussion, the next step is you to first package TDE, build and test and see/demonstrate how it goes, regarding at least these 5 points (summarized from above) before an integration is considered: 1. no conflict on files 2. install in %_prefix (not in /opt) 3. no duplicate software name (do not confuse user to decide between tde-k3b and k3b for instance - or find a realistic workaround use case). 4. at this point, no apps outside of the TDE project should require TDE 5. committed maintainers Romain
Re: [Mageia-dev] Non-free firmwares in installer
On Thu, Mar 24, 2011 at 20:08, Anssi Hannula anssi.hann...@iki.fi wrote: On 24.03.2011 19:35, Romain d'Alverny wrote: Summary (from http://mageia.org/wiki/doku.php?id=licensing_policy): * core: stuff that is not Free/Open Source according to OSI/FSF does not belong here. Not even closed-source stuff that we can redistribute. So if there is at this time, that's something to fix. Most of files in kernel-firmware (which is in core) are not OSI/FSF free (approximate list from 2010 [1]). There was a short thread about that [2] where I asked the question if they should be moved to non-free due to them not being OSI/FSF free, and tmb agreed, while pterjan disagreed (saying BSD without source code (where a portion of the firmware files in question fall) is eligible for core). [1] http://lists.mandriva.com/cooker/2010-01/msg00525.php [2] https://mageia.org/pipermail/mageia-dev/20110115/002172.html Ah right, sorry for overlooking this. So what do we do? amend core inclusion definition for that? or move these to nonfree? (and at what cost?) topic for next Council meeting to decide? would you like to write a summary for this in http://mageia.org/wiki/doku.php?id=meeting:council_notes_2011_03_28#open_questions ? Romain
[Mageia-dev] buildsystem = maintainers db link test
Hi there, maintdb is making some progress and we could test it already with the buildsystem to push it some data. Here is how it works so far: * a package P gets submitted by ennael; * buildsystem builds it; * buildsystem POSTs (P, ennael) to maintdb; * maintdb keeps a record of that; * as a default, ennael (first person to push the package) is the official maintainer of the package; later people pushing the same package would be co-maintainer; * we will implement in maintdb a method to manually change that (assigning maintainance to someone specific); * we can envision maintdb to keep stats of submissions as well. Maintdb dev instance is here: http://www.maintdb2.mageia.org.uk/ (see current spec on http://mageia.org/wiki/doku.php?id=web:maintdb#specs_actions ) Misc righly pointed out that: * someone triggering a massive rebuild may not want to be seen as a maintainer of packages uploaded by this; several possible solutions: - first uploader is set as the maintainer by default; - this will be manually editable from the maintdb app anyway; - would a specific flag be raised in the buildsystem (or a package) when such a massive rebuild is triggered? - instead of strict associations, we can associate maintainership by frequency of uploads/activity on a given package (unless massive rebuilds are triggered more often by a single packager than regular package uploads by the actual maintainer) * submissions stats publishing may require your validation (and actually, for that specifically and future topics, we'll need to see how we can publish contributors activity stats through our platform - as a de-facto feature or as a preference, per contributor). Anyway, in all that, we need your input. Thanks! Romain
Re: [Mageia-dev] [717] do not hardcode mirrors API path, use variables from product.id
On Tue, Mar 22, 2011 at 04:21, Thierry Vignaud thierry.vign...@gmail.com wrote: On 21 March 2011 23:57, r...@mageia.org wrote: Modified: drakx/trunk/perl-install/mirror.pm === --- drakx/trunk/perl-install/mirror.pm 2011-03-21 22:36:43 UTC (rev 716) +++ drakx/trunk/perl-install/mirror.pm 2011-03-21 22:57:27 UTC (rev 717) @@ -59,7 +59,7 @@ #- contact the following URL to retrieve the list of mirrors. #- http://wiki.mageia.org/en/Product_id BTW this URL doesn't exist either The current original is http://wiki.mandriva.com/en/Product_id and we will need to import it into our wiki. But indeed, at this time, it's not there yet. Romain
[Mageia-dev] building a dashboard for the whole build chain
Hi there, just a quick request for comments on feasibility for the attached mockup (with lots of improbable figures). It's still ugly of course. The goal is to have a high-level report of the whole chain of building the distribution, step by step to visually advocate: * checkpoints along the process to be implemented progressively and reported as such; * some sort of a continuous integration/test/build cycle; * what it takes to make a distribution. There are certainly totally fake/useless figures named there and others misreported that would show a misunderstanding of the processes at hand. And there are too missing figures. Feel free to correct (and suggest why/where/how to get those values). And of course, some blocks suggest existing, deeper level reports or processes; that's the point of identifying those needed/existing and putting them all together. Romain Mockup! Mageia factory status dashboard This document aggregates various reports from Mageia build chain, from source code to shipped test ISOs. Upstream Projects 32 in mageia/soft, view svnweb 2343 in other places 143 out of sync with upstream view detailed report Source Packages Status: OK. 2.1GB 4325 packages 23 orphans 432 out-of-upstream-sync 432 patches 234 open bugs on 43 packages 54 rpmlint errors in 23 packages (5%) 5433 rpmlint warnings in 3325 packages view svn, git, detailed report Packages Build (past 24 hours) Status: READY. 5 nodes working out of 6 used 78% of the time queue size: 0/20/4 built time: min/max/avg wait time: min/max/avg 1234 built packages 321 not built (%): missing dependencies % other view pkgsubmit, detailed report Cauldron Compiled Packages Status: NOT READY. 9.2GB 4324 packages Broken hdlist (i586/nonfree) Signatures: 23 missing (i586/nonfree, i586/tainted) Dependencies: 32 missing, 2 circular 15 packages are not in sync with their source 432 missing/broken signatures 213 bugs @todo: per package test suite? rpmlint, other @todo: src => 32/64/arm Basesystem size: 437MB, w/o suggests: 163MB view repository, detailed report how to visualize several trees at once? (stable cauldron at least) Cauldron ISO Build / QA / Publication (past 3 days) Status: READY, OK. Built packages tree is not ready no build planned.Or: Next build 1a1 should start in about 12 hours (at 2011-03-15-20:23:33), with a new context.Or: Build 1a0 (context diff w/ build 199) 2011-03-14 23:03:15 DVD i586, build ok (log), tests failed (log), cauldron-2-dvd-i586-1a0-qafail.iso DVD x86_64, build ok (log), tests ok (log), cauldron-2-dvd-i586-1a0-ok.iso CD dual, build failed (log) building netinstall image... Build 199 (context diff w/ build 198) 2011-03-12 23:03:15 Item Build Tests Download DVD i586 OK (log) OK (log) cauldron-2-1a0-dvd-i586-ok.iso DVD x86_64 OK (log) FAILED (log) cauldron-2-1a0-dvd-x86_64-qafail.iso CD dual FAILED (log)
Re: [Mageia-dev] Seamonkey package
On Fri, Mar 11, 2011 at 00:35, Michael Scherer m...@zarb.org wrote: Le vendredi 11 mars 2011 à 00:28 +0100, nicolas vigier a écrit : On Thu, 10 Mar 2011, Christiaan Welvaart wrote: On Thu, 10 Mar 2011, nicolas vigier wrote: Unfortunately the seamonkey name and logos are trademarked and the license terms are most likely not acceptable so it seems to me we'll have to rename/rebrand it. Is it different than firefox license terms ? Same rules AFAIK, see http://www.mozilla.org/foundation/trademarks/policy.html Wasn''t there a license change regarding the Firefox logo in the end of 2010, that was related to this? Does anyone know if we had to request permission to use firefox and thunderbird trademarks ? For mandriva, it was done IIRC, but I think that sharing a part of the building eased the dialog :) If needed, I can forward the request through the Mozilla Europe guys (across the street) who will certainly route us to the right people to ask. As far as I remember, having discussed about that with them in the past, there are two orthogonal product visions at stake here; so even in the long run, that will certainly be beneficial to work upstream to ease Firefox packaging and tuning on Linux platforms in general (and Mageia in particular). Romain
Re: [Mageia-dev] Seamonkey package
On Fri, Mar 11, 2011 at 10:51, nicolas vigier bo...@mars-attacks.org wrote: On Fri, 11 Mar 2011, Romain d'Alverny wrote: Wasn''t there a license change regarding the Firefox logo in the end of 2010, that was related to this? Yes : http://glandium.org/blog/?p=933 Right, thanks. But that doesn't solve the trademark usage issue, actually. So the question is still open. Romain
[Mageia-dev] artwork team, packager/dev assistance needed
Hi there, artwork team is getting its hands on the bootstrap and installer processes; backgrounds/screensavers are incoming too; and it will need to do so on the graphic theme (ia ora so far). For now, the team needs assistance from packagers/developers on these modules: - drakx (installer - perl/gtk skills/interest needed) - theme (bootstrap, hibernate, shutdown, backgrounds, screensavers - plymouth skills/interest needed) to help to: - better understand how graphics/animations are and can be used (and maybe, later, build quick mockup tools); - replace them; - cleanup (remove obsolete stuff, maybe break these modules into smaller, more to-the-point ones); - document (help future artwork and dev people to get a better grasp on these modules). This is not for alpha2 (although a quick overview would be welcome) but for beta1 (and later of course); work would start at once anyway. Volunteers? if you are, please join mageia-artwork@ and/or #mageia-artwork. Thanks! Romain
Re: [Mageia-dev] Organizing work with apprentices packagers
On Thu, Mar 3, 2011 at 11:04, Angelo Naselli anase...@linux.it wrote: Is there a way to get it in other way (ical for contact or similar) without the need of creating another mail account? Reload http://mageia.org/en/calendar/ , you now have direct links to ICS calendars at the bottom (thanks for the notice). Romain
[Mageia-dev] Contributors using real name/working email? or not? or maybe?
Hi there, in the past few days/hours, on sysadmin list has a discussion arisen about publishing packager email into commit/change log; you can check the whole thread, here are three starting points of it: * https://mageia.org/pipermail/mageia-sysadm/2011-March/002946.html * https://mageia.org/pipermail/mageia-sysadm/2011-March/002952.html * https://mageia.org/pipermail/mageia-sysadm/2011-March/002955.html And you would perhaps like to read the whole thread; not everyone agrees there. The discussion slipped to whether: * packagers/contributors [sh|w]ould use publish their real name (as registered in identity), * packagers/contributors [sh|w]ould publish their contact email (same), * in their contributions to the project (here, in the changelog), * if it should be strictly enforced or not, and why. for practical or personal reasons. It's a general, pretty key matter, it's been rightly suggested to raise the point here, so here it is. We can't enforce anything unless we decide on this first and this thread is here to gather views. What we (Council) will decide later on about this depends on the outcomes of the discussion (and if we ever decide or not btw). It will be part of the project's privacy policy. And please try to keep this discussion to the point, focused and civilized; state your views, don't infer on others' ones, stay cool. Or your point will become shallow and the discussion will be wasted. The points to decide here are: a) should a contributor provide a public email address, to be used in changelogs, commits and everywhere her contribution to the project needs an id or contact id? (for instance changelog, commit, document authoring) b) should a contributor provide a real name for the same goals? or is a fake name/alias ok, as long as there are people that do know/meet the person? I won't comment on pros and cons below (not exclusive of others), but those were raised in the discussion before: The pros (as in yes one should): - that is the common way used in MDV and other major distributions - (email or name) it identifies the author of a change to the project/code - (email) it helps identifying contacting directly someone in the project (peer review or any ad hoc matter) - (email name) it helps building confidence among contributors and from the outside - (name) it encourages people to adopt a consistent behaviour - (email name) it builds one's contributions list for future/outside reference The cons (as in no, one should be free not to) - public email addresses get spammed - personal preferences to not reveal one's name - there are situations where anonymity is a requirement or nice to have (from a personal or corporate point of view) - it will encourage people to contact directly contributors instead of using other expected channels Note that one may use a fake name/identity anyway to stay anonymous (but unless one already has a network of trust within a group, she would not have a past public record to help building her new reputation). What is at stake is the accountability for each contributor, hence for the whole project. What will matter is what one does and how. And again, let's have this point discussed in a cool, informative, constructive and efficient way, please. Cheers, Romain
Re: [Mageia-dev] Identity verification broken ?
On Mon, Feb 28, 2011 at 19:39, Frank Griffin f...@roadrunner.com wrote: I previously registered with the Mageia identity server, but when I try to log in, I get incorrect user name or password . I went through the Reset Password process, and the server must know me because it included my name. I entered the same password I had set previously, and it seemed to accept it and then put up a login prompt, but when I entered my email and the password I had just set, I got the same error. Known problem ? - did the password reset process go smoothly? - did you try alternatively with your login, instead of your email? (wondering, only) Romain
Re: [Mageia-dev] Identity verification broken ?
On Wed, Mar 2, 2011 at 18:44, Frank Griffin f...@roadrunner.com wrote: Romain d'Alverny wrote: - did you try alternatively with your login, instead of your email? That did it, using just ftg rather than the full email address. The confusion stems from the fact that bugzilla, which keeps you logged in via a cookie, displays Log out f...@roadrunner.com, implying that the full address is the username (as in fact it was in MDV registrations). Ok, so that's a matter of consistency, allowing to log in with both login and email. Thanks for noticing it (https://bugs.mageia.org/show_bug.cgi?id=252 ). Romain
Re: [Mageia-dev] mirror policy howto updates
On Tue, Mar 1, 2011 at 14:28, Olivier Thauvin nanar...@nanardon.zarb.org wrote: * Romain d'Alverny (rdalve...@gmail.com) wrote: * have a clear expiration policy (hard to define before having the support policy setup) This cycle cannot be less the support time of a distrib, but the distro can be archived later. At time I don't know what the support policy... hard to said much, indeed. * have an archive section in the mirror What is this for ? To move its contents to cheaper/slower storage systems. It's related to above expiration policy: expired stuff would go into the archive section. * keep on explaining the tainted section outcomes, so mirror admins have better facts info to decide * provide clear rsync modules to help admins quickly pick up what fits best for them. Since all mirrors sync their tree from tier1, and we don't have the hand on tier1 servers, we cannot provides rsync share as we want... Well, the question was to ease tier1 admins in this regard. But we might as well just provide guidance and ready-to-use script for tier2 and others. Romain
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On Fri, Feb 18, 2011 at 10:57, Michael Scherer m...@zarb.org wrote: Le vendredi 18 février 2011 à 10:13 +0100, Philippe DIDIER a écrit : Just seen that mikala added panotools in the repository . (some algorythms library to build panoramic photographs) Very happy with this ! (thanks a lot...) That's one of the first patent problems we may encounter : Yes, that's a good sample to use to improve our policy draft. Long time ago, How long is a long time ago? because every patent has a term and here it may have expired. iPIX, a company from USA muliplied patent lawsuit against these free algorythms inventor and photographers using them (this company is now dead because of bankruptcy but the patent problem is still live... ) Well, who own the patents now ? From http://wiki.panotools.org/Ipix it looks a former competitor got a hold on all assets from iPix. On the decision/sorting out side, for this and for any other patent issue, do we document already (in source code or a separate file) the reasons to activate or not pieces of a software (or to exclude them from packages), because of some patents? List of questions to check would be at least: - what is exactly covered by what patent (reference, registration, territory/ies for which it has been registered)? - where is it implemented exactly in the source code? ( - who owns this patent? - did the patent holder announce his clear intention upon it? (that is, is he using it to control/restrain use or not? *) - are there obvious prior art that could make this patent obviously invalid? - what is decided and when (and what may change the decision, later)? - what would be alternative ways to implement the function (if the patent does not just cover the function, but a specific implementation of it)? * one does not necessarily register a patent to be offensive with it; here, we knew about iPix, what about the new holder? Btw, a draft policy for patents management was discussed among founders and other people (lawyers) months ago and a tentative summary written by me here: http://mageia.org/wiki/doku.php?id=software_patents_policy . Cheers, Romain
Re: [Mageia-dev] New bugzilla proposal
On Mon, Jan 10, 2011 at 00:46, Michael Scherer m...@zarb.org wrote: Le vendredi 07 janvier 2011 à 19:04 +0100, Romain d'Alverny a écrit : So trying to summarize above discussion, I suggest as products: [...] * Websites with components: [...] - (for versions, live/dev does not make much sense here; so maybe just numbering, maybe just no version for a start; depends on the release process) If we intend ( and Buchan do, and I am sure that Stormi also ) to reuse and let people reuse some of the web software we wrote outside of Mageia ( ie, Buchan spoke of having identity to be proposed to the openldap community ), I would keep website for the installation we have, and also treat them as software for people who deployed it on their own server. But that doesn't apply to everything, obviously. So in website, we treat our instances, and then I think that depend on the number of instance we have. Even if I doubt we will have more than stable no stable ( or trunk / stable, whatever the name ). Yep. Ok, so for Mageia web apps/sites, we start with a single production version and leave the possibility to have the software code available in the Software products or in any other upstream bugtracker. * Infrastructure - ? (misc?) I do think that people should fill bug report against me elsehwere than on mageia bugzilla. :D For infrastructure, I guess we can simply put 1 product, and later decide once we see what is buggy ( because we did not plan to have bugs yet, so we cannot tell where they should be filled ). Sounds good yes. Maybe say that we review the component every year with bug triage team ? Or whenever raised as necessary, yes. Romain
Re: [Mageia-dev] Java-Policy first draft published
On Mon, Jan 10, 2011 at 21:02, Farfouille farfouill...@laposte.net wrote: Licence discrepency : dokuwiki template says licence is 'CC Attribution-Share Alike 3.0 Unported' but web application policy (http://mageia.org/wiki/doku.php?id=web_applications_policy) claims 'Creative Commons Attribution-ShareAlike 2.5 License' (end of the page) I used the quick admin feature of dokuwiki to set it, only the 3.0 Unported was used. I have still to learn/get the differences between these versions (notwithstanding that the By-SA provisions mean the same thing), or whether they are even conflicting (there may be a natural update path in here). Anyway, help/insights (separate thread, please) about this is welcome. Romain
Re: [Mageia-dev] Mageia policies
On Sun, Jan 9, 2011 at 22:30, Samuel Verschelde sto...@laposte.net wrote: Le dimanche 9 janvier 2011 20:58:24, Remy CLOUARD a écrit : I’ve missed an important point in the process. The license used on mandriva wiki is the Creative Commons Attribution-ShareAlike 2.5, and we use the license we use is Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported. Is there a reason why we need a NC clause ? It seems very restrictive to me. It may be that, the default license in default setup footer of dokuwiki is a CC By-NC-SA. But that was _not_ on purpose, we just did not checked this. Until now (thanks baud for the notification about this on webteam list). I fixed [1] this on the wiki footer, using now the By-SA CC license. I expect it is understandable that, using material being under By-SA (MDV wiki) requires to keep it under the same license. And that the NC provision is, at best, counter-productive in a open source/free software context. [1] provided it was a clear dokuwiki setup and that we did not change the footer license, I think we can assume that no specific license was used until now. Choosing for By-SA was made with the perspective of the above. Open for debate of course; we should have been more careful about this bit on day 1. :-/ Cheers, Romain
Re: [Mageia-dev] New bugzilla proposal
Ok, the point of this discussion is to know what we put as: - Products - Components This can be updated later (as in: adding/renaming products/components). So we should just aim at the smallest acceptable set, so that we can open our Bugzilla instance, see what it shows, update and open it for actual usage. So trying to summarize above discussion, I suggest as products: * Mageia with components: - installation - software - new software request - release (media, process) - (for versions, cauldron first, we'll see later for the rest) * Websites with components: - www - forum - blog - wiki - maint-db - (for versions, live/dev does not make much sense here; so maybe just numbering, maybe just no version for a start; depends on the release process) * Infrastructure - ? (misc?) If that's ok (or if we can make it smaller so that it's working), we can move forward and set this up finally (modulo the rpm field setup, but that's not blocking for once). Cheers, Romain
Re: [Mageia-dev] New bugzilla proposal
On Fri, Jan 7, 2011 at 19:04, Romain d'Alverny rdalve...@gmail.com wrote: * Mageia with components: - installation - software + RPM package - new software request replace with new RPM package request - release (media, process) - (for versions, cauldron first, we'll see later for the rest) And or maybe have the software component brought up as a separate Product, actually (would make even more sense), with the list of actual software involved. Romain
[Mageia-dev] maintainers database
Hi there, it looks like we will need a database to know who maintains what, basically. It used to be http://maintainers.mandriva.com/ - its source code has no explicit license, so we've got to build this again. I drafted a very quick page for this here: http://mageia.org/wiki/doku.php?id=web:maintdb with basic entites and relationships. Now, it would good to know what packagers (and others) need for this. For instance: * instead of having a single maintainer for a given package, have several maintainers (with an admin maybe) over a given package (easy); * should there be groups of packages defined? (this adds/replicates some logic that may already be somewhere else) * should there be explicity groups of maintainers? or implicit (as made of people maintaining the same package)? * should there be (customizable) alerts/warnings for people, when a new package is added, or removed, or that has no more maintainer? * ? Thing is, this should be a really small, basic, simple component app. So it plays easily with other components. I don't know how this could be implemented/used or replaced by mageia-app-db however. Thanks for your insights. Cheers, Romain
Re: [Mageia-dev] Mirror layout
On Thu, Dec 16, 2010 at 10:47, Ernest N. Wilcox Jr. ewil...@bex.net wrote: If the Mageia community chooses to ignore the laws of some countries for any reason (even if the community can not be prosecuted), I want nothing to do with it. So you do already. The common subset of laws of all countries in the world is like... almost empty. The global tendency in the past decades is to grow this common subset but it's far from being achieved (and may as well reverse, history showed us). As a matter of fact, Mageia as an organisation fostering free software and innovation through collaboration is likely to ignore/refute/fight, by whatever mean and at whatever relevant scale, laws that would censor/prohibit, as such: - reverse-engineering - cryptography tools - freedom of speech - user privacy - to name just 4 of them. See? There are significant countries in this case. Obey the law is not rule #0 in life (even more if unbalanced). If it were, we would mostly all be slaves, instead of free citizens. A strongly stated position, honestly presented should never cause offense to any one. You cannot please everyone. Law of life. If I havce offended you, I appologize as that was not my intent, but I will not appologize for my beliefs. And you should not. :-) As long as things are said with respect. The variety of laws that exist is not the issue, the fact that they do exist is, and this is why I think PLF is a good place for questionable software. If we choose to provide such software ourselves, then it should be in a tainted listing or repo. Yes. But this is still an imperfect solution as the frontier between what should be in tainted and core will vary according to the territory you are in. So we have to decide on a _reasonable_ frontier, that will not match strictly everyone anyway. I have no problem with such software being distributed where it is legal. I simply want to make it easy for end users and miror hosts to exclude this software where it is illegal. We can't do it totally for three reasons: * law is not universally the same; * law changes, wherever it is. What is legal today may be illegal tomorrow. What was illegal today may be legal tomorrow. * patents may be invalid or have expired (although properly registered). So again, that does not help us but realize that we cannot have a stable layout policy for what comes under core, non-free and tainted. This is a matter of finding a reasonable balance, regarding a given set of laws (likely, European/US laws). Because, otherwise: * as soon as someone claims having a patent anywhere on some methods implemented in some software of core, it should move to tainted (with all consequences). * as soon as a patent expire (or its invalidity is revealed through a court decision), all related tainted packages may move into core or non-free. So indeed, we've got to build this tainted repository and fill it with what we think it should reasonably be with; that means having a policy (list of questions to ask to qualify the package/software to enter tainted or not). I proposed one earlier, that was extreme (that was the goal). We should have a similar one, amended. I will not enter into the argument that it is not illegal untill the patent holder comes after you. To my way of thinking, that feels very similar to saying that stealing is not a crime untill you get caught. Do not map physical/concrete world metaphors to immaterial world. It is not the same. Not the same rules apply. And thinking/law is lagging a lot in this regard, as for any new/young stuff. Cheers, Romain
Re: [Mageia-dev] Mirror layout
On Fri, Dec 10, 2010 at 17:04, Wolfgang Bornath molc...@googlemail.com wrote: 2010/12/10 Romain d'Alverny rdalve...@gmail.com: Let's try this: what if we consider, at first, that software patents were a non-issue? (that is, we just consider they are all invalid as such). From a mirror maintainer's view: If I am in a country like France (not acknowledging SP) I can ignore safely the issue If I am in a country which does acknowledge SP I will have to decide for myself if I want to take that risk. THis may be an easy decision in some countries but in others (like the USA) it may be a hard decision, also depending on who I am (a private person or a large institution/organisation). From the users's view: Living in a country without SP (or not caring about the issue) it is the easiest way. I can use automagical setup of media and need not worry about an extra repo to set before I can watch my DVDs :) Again in a country like USA I have to decide for myself - this would be a nightmare if the whatever-dubious software is included in the normal repos. I would have to find out by myself which is ok to use and which is not. Ok, but you still take into account SP in your answer. :-p (we would have come to that, but the idea was to think about it from a naïve, software-patent-free perspective). So... let's take the European Union case, namely, no SP (see next §). We just don't have to split the media. Easier for everyone in this territory. Well, thing is, even though there is a European policy about that... it's been unbalanced and challenged for years. In the end, it's just a mess and law is lagging behind; if not just broken. So it's going to be, anyway, a battle of positions before something clear and definitive comes out. Still. What if? Where is it an issue to distribute/mirror then? Only where: - SP do exist by law; - and specific SP are registered on pieces of software distributed/mirrored; - and these SP are not invalidated (de facto or obviously) by some prior art; - and those SP are likely to be enforced (that is, practically, there is a minimum incentive for a patent holder to raise his hand; or, that it is worth it to enforce it). Coming back to my previous post, maybe we should just try something simple and go from that. Shall we take a stance despite SP (for they are just not relevant), worldwide or more reasonably have a simple, risk-management based attitude to alter our media/mirror policy only if something happens? That would relate somehow to Debian policy in this regard, as misc mentionned in the Why validate software patents ? thread on mageia-dev, Dec. 8th, ~12:58. And that sounds a decent attitude; see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365390#20 or http://lists.debian.org/debian-project/2005/01/msg00316.html . So why not take it the same way, not have a distinct media and see what happens on notices? Yes, this would raise mirroring issues (that would occur anyway), that we can minify with a policy to manage that globaly; that when an issue is raised: - try to fix it for the whole project, not just for some area, so the weight of the whole community (not only Mageia for that matter) is behind the case, and not only a local chapter; - remove only software that gets a full score through this list (to be updated): * has an identifiable patent registered on it (exact code/method, exact patent description); * has been notified about by the holder (or representative); * whose holder is identifiable; * whose holder does not provide a free use license; * which patent: - has not expired; - is not already invalidated; - has no obvious prior art; - is being actively enforced; * other? - such software or components would be made separately available only (so we still manage that it depends on the territory). So we start with an empty tainted/whatever media. And again, see what happens. That's an option. Romain
Re: [Mageia-dev] Mirror layout
On Fri, Dec 10, 2010 at 19:14, Wolfgang Bornath molc...@googlemail.com wrote: 2010/12/10 Romain d'Alverny rdalve...@gmail.com: Ok, but you still take into account SP in your answer. :-p (we would have come to that, but the idea was to think about it from a naïve, software-patent-free perspective). If there were no software patents anywhere what would be the issue of this discussion? IMHO it makes no sense to discuss something which does not exist It does. Because it helps looking at a problem from a totally different perspective, build from that, and see the missing/conflicting pieces when you look back at the full problem (or as you used to look at it before). Which conflicting/missing pieces may not be the ones one thought they were. I see the strategy in your proposition but: 1. We know from the start that there ARE packages with software which is patented in some countries. So, the let's start empty and see what comes up is already done with. Are there issues with it? (looking at my previous check-list, maybe to improve). If so, yes, let's fill this up. If not, let's leave it alone in the core. I mean, what difference does it make with PLF repositories that are already mirrored? what differences does it make with Debian stuff that is already mirrored? do they get cease desist? do we hear about this? 2. In some countries mirror maintainers can not wait until somebody raises his hand, there are lawyers who write nice cease and desist letters, attached is a bill you have to pay. In Germany this is called Kostenpflichtige Abmahnung and has grown to a habit of some lawyers. Then in these cases, two options: - just do not mirror; and people use mirrors on the borders; - Mageia (or some related entity) provides legal services about this (taking responsibility for the hosting or other). Why just do not mirror? Because, taking the strict statu-quo point of view regarding the software patent thing, that is just follow the most restrictive set of rules, we won't be able to cope with just medias to separate patented software from non-patented sw. It will be a matter of tags, because the situation is different from territory to territory. And there are more than two for that matter. Meaning: you can't wait and see what happens, you have to make sure that it does not happen from the start. We can't be sure at all of anything. That's why that's to take a risk-management attitude, provided what we want to achieve, what stance we want to take. I mean, opinions about software patents set aside for a minute, software patents are protected by official law in those countries. You can not break the law on the basis of let's see what happens. Many do. Not only for software, but for everything. For many reasons, among which can be: the law is broken, the law is becoming obsolete, people do not enforce it, the law should be changed, etc. Well, actually, there are two options: break the law/try it as it is. Or follow it strictly to demonstrate its absurdity. What I propose here is a middle-ground some other projects already take. With the reasonable attitude to manage cases that _are precisely identified_ (so we avoid reports such as this piece of software is likely to be patented; point needed is: is it? or not? how, why, by who, is it valid, is it free, is it enforced, are we noticeable/a target, does it matter given our size? As said before, regarding law on software patents, the situation today is, that's a battlefield anyway. Although the situation in EU should be clear (no SP), it's not (as many other things at the moment too, sadly). That's a proposal. It has shortcomings too of course; what I find interesting in this is that: - it makes Mageia put a few steps into the software patents debate (instead of only trying to cope with an inconsistent, unpracticable set of rules that we mostly even don't find legitimate at the very start); - it may reveal to be less of a burden than we currently think; it may be worse; either case, we can adapt from a situation we will have _experienced_. Now, that's nothing more than a proposal. :-p Romain
Re: [Mageia-dev] Mirror layout, round two
On Tue, Nov 30, 2010 at 13:29, Samuel Verschelde sto...@laposte.net wrote: What I'm saying is totally different : In the first case : - no one steps in to maintain it. We drop it. In the second case : - no one steps in to maintain it. Because we promised to support it, and because there are people who care about that (the QA Team Leader for example), we would *try very hard* to find a solution. this is a problem, we identify the problem, we try to solve it. Maybe we fail, but at least we try hard, because the package is on the supported list. Ok, it's a degree of support management: - first case, dropping is automatic, - second case, we turn the red light on and try to organise around this to find a best effort solution. But, in the second case, relying exclusively on the community, for the support promise to work, you have to show that you have either some separate incentive, either a large enough community to grow the chances for this to happen. another solution : we do no promises of supporting anything. This is a solution. Not mine however. Not promising of something to happen is not a promise of this thing not to happen. Such a promise of support is much more sustainable if you have a clear, identifiable incentive or reason or experience (for the people you promise to) to keep it. There are differences between: * guaranteed, * trying very hard, * best effort, * good will, * nothing pretended support promises. Let me present the idea differently. There are 2 levels of support : - top guaranteed support (a subset of packages) : those are packages your can rely on blindly, they'll be updated in a timely manner. Those are the packages the QA Team puts its limited resources on (doesn't mean the QA Team provides support, but they check that good support is provided). The maintainer is responsible for the package, but the QA Team is vigilant about them. - supported packages (every other package) : those are maintained packages, however the QA Team doesn't have to check them. It's up to the maintainer. - unsupported packages are dropped. So everything is supported, but there a special level of support for some critical components. Just saying, but as packages support is to be distributed, we may as well have commercial companies step around and manage this kind of support: * within/through Mageia through their employees (so, it matches our policies, that's the idea), * because it matches their activity/interest (they build the software, they consult/sell/build around it). To help thinking about that (in the future, because now we have nothing to track/compare) we need to collect and report relevant data about packages management experience (supported, not supported, number of updates, maintainers, time to push an update, etc.) against a first policy. So we can measure what happens and what can be reasonably changed/expected in the future. Romain
Re: [Mageia-dev] Mirror layout, round two
On Sat, Nov 27, 2010 at 00:44, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op zaterdag 27 november 2010 00:25:17 schreef Thomas Backlund: [...] A) i see no reason for codecs and firmware to be separate. However, i do understand that some people would not want to install firmware, but i think we should do this in another way, (like installing a meta package that enforces some limits.) codecs seem odd to be separate, if they have patented problems they should go in non_free, if no problem, they can go in core. That is doable. The reason for having it separate was because its the most problematic one. (codecs have more issues than firmware) What i meant here, is why is firmware separate from core? why is codecs separate from core? imo, i would put firmware and codecs in either core or non_free. I guess we should separate concerns? - non_free as in not (really) free software (source code may be available, but license, redistribution conditions, etc.) - problematic stuff as in binary closed thing (most firmware, but not only eventually) - problematic stuff as in (likely) patented (some codecs) so that we don't mix issues when one has to decide what to mirror/use or not. Romain
Re: [Mageia-dev] Mirror list for apps (LONG mail)
On Thu, Nov 4, 2010 at 08:30, Funda Wang fundaw...@gmail.com wrote: Just a question, why couldn't we just use the same architecture with opensuse, which is based on metalink? http://mirrorbrain.org/metalinks/ http://www.metalinker.org/ (for reference about this). Romain
Re: [Mageia-dev] Mirror tree structure
On Wed, Oct 20, 2010 at 18:34, Olivier Thauvin nanar...@nanardon.zarb.org wrote: Now come the question: what is a valid mirror ?, eg, what a mirror should have as file to be valid ? Not sure if we discussed in depth MirrorBrain (http://www.mirrorbrain.org/ ) for managing mirrors index and redirections. If we were going to use it, could we, for instance, leave mirrors some liberty to mirror what branch they want (with some guidances and preferences of course) and let our MirrorBrain instance check and build the list of valid mirrors for the file actually requested? This, provided that _consistent_ branches of the tree are mirrored, and not only a file here, a file there. On one hand, this would introduce at least to other things to check: - having enough distributed mirrors that map the whole tree; - having download/install tools take this into account. On the other hand, this could allow more mirrors to take part in this, in that it may require less storage space and less bandwidth usage. It's not the only reason to use MirrorBrain anyway, but I wondered if this could be a complementary reason. Not sure, insights welcome. Cheers, Romain
Re: [Mageia-dev] How will be the realese cycle?
On Sat, Oct 16, 2010 at 21:29, Marc Paré m...@marcpare.com wrote: Le 2010-10-16 12:36, Ahmad Samir a écrit : It's much better to help the user formulate a useful bug report, that's easier / more productive for all involved parties. There would be no middle man. Once the middle-man could replicate the bug and verify the bug with other users, then the middle-man would submit to bugzilla. That's it. From there on, the middle-man will take care of testing requests from devs. As far as reporting back to the original user who reported the bug, as an extra gesture of kindness, the middle-man would just post on the Report a bug forum that the bug has been quashed or is still under review ... but not to the user but to the Report a bug forum. The idea is to keep the flow of possible bug reports coming in an organised way. The middle-man would have to be someone with a little more experience than that of a new user and also someone who has an interest in working this way. We will get more bug reports from users by keeping it simple and easy. Yes, and for everyone. I tend to agree with Ahmad, as well as with you. You may as well imagine we improve the Bugzilla process with a front-process, guiding the reporter about her bug report. That may be a forum with people active there, educating the user about the bug and the reporting process; And/or that may be a better designed bug reporting process with a better flow (providing and getting info to/from the user), querying a knowledge-base, filtering known/resolved queries out of yet-another-duplicate-bug-report and ultimately opening a bug in Bugzilla with a specific interaction to the user (so she knows what happens next).* That removes the middle-man issue and that filters out as well people that are not concerned enough to report/follow-up on a bug (provided the process is, indeed, better designed and better welcomes the end user). * moreover, I believe this type of improvement would benefit many, many, if not all, projects using a bug report tool. Cheers, Romain
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On Fri, Oct 15, 2010 at 07:43, Olivier Méjean omej...@yahoo.fr wrote: Le vendredi 15 octobre 2010 01:18:37, Michael scherer a écrit : On Thu, Oct 14, 2010 at 09:57:03PM +0200, Olivier Méjean wrote: Since the only people who will have issue with this are the president ( aka Anne ) and the people who distribute this ( ie mirrors admins ), I think we should ask them and follow their opinions, and only theirs. Because we can speak of we have no problem, we will have nothing what ever we do, because we are likely not liable. Anne and mirrors owners are. So their words is what does count. So is Mageia a community project or not ? Yes and? That doesn't prevent that there is an association that will own trademark, servers, manage money, etc. and that is a legal construction that may be liable, in France or in regard to international laws. Then when we will talk about Marketing stuff we will follow only marketing group opinions ? Who talks about marketing here? Please stay on topic. Misc is talking about official representatives, board members liability - not only in France, but abroad. We're not in Merovingian times where one was judged according to his original land's law. Of course their views count, but there is a difference between the responsability of Mageia association that must comply with French Laws Sure but we can't just say that. See below. I do quite accept that Fedora, OpenSuse, Debian comply with US Law since there are located in the USA, thus accepting their policy about software patents. I would like that the same occurs for Mageia that is located in France. As misc said, there is no guarantee, neither definitive rule that the build system (or parts of it) would be only located in France. There is no guarantee that board members will always be in France. There is no guarantee that we won't setup affiliate not-for-profit orgs abroad. Etc. We're going to distribute software all around the world in several ways, potentially, so we must think global here, and not only local. If we were to follow the let's only check local law, believe me, we wouldn't have located the association in France. There are other places far more interesting in this regard. So the question is not where is it allowed? and is it allowed where we build it? but: - what do we _want_ to have in software repositories and _why_? - what are legal constraints that we must deal with (building/packaging/distributing/using), and how? - how can we make this a predictable process for future situations? Romain
Re: [Mageia-dev] How will be the realese cycle?
Does anyone take notes to summarize and make a consistent proposal (be it in some way or the other) of what should be done, as well as defining some sort of personas for users (unaware, new, occasional, frequent, expert) for evaluation? Romain
Re: [Mageia-dev] How will be the realese cycle?
On Thu, Oct 14, 2010 at 18:32, Marc Paré m...@marcpare.com wrote: Is there a dedicated mailist for the leaders of the different communities? It would probably make sense to have a closed list for them to coordinate projects such as polls, marketing, sharing of resource materials agreemtns etc. Just a place where they could meet and conference to build consensus on different issues. Does this exist? Do we have a list of all the communities that have come on-board to the project? You mean, the Mageia Community Council? or something else? We're in the process to setup the Council, but we will need each team to coordinate on its own first (so we're blocked by the mailing-list availability, which should come soon - we've been delayed because of hosting issues). Romain
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On Wed, Oct 13, 2010 at 06:50, Marc Paré m...@marcpare.com wrote: Let the user then assume that responsibility/liability. This is where, I consider the easy urpmi served its purpose well. It installed repos where the available software that most users would need was made available, but this again was by user choice. I don't really see how this would fix the issue; by using a third-party repository (plf or through easy urpmi) you just move the concerns to another provider: - if the user is liable anyway, having a single or several providers doesn't matter; - if the user is not liable anyway, having several providers only moves the liability from one provider to the other one. This particular point, about _patented_ software is a tricky one indeed. Dealing with local/international laws is tricky. Especially when both change over time. However, first point is not to mix different issues here: - supported software and not-supported (and what means supported) - free vs. non-free/proprietary software (as in FSF/OSI definitions) - gratis vs. paid software - for non-free software, distribution/usage cases may be tricky (skype, opera for instance) - software implementation/distribution that violates/have to comply specific laws (encryption, DRMs) - for patented software/methods, implementation/distribution/usage cases are tricky as well (a patent may or may not block you from using the method, depends on who holds the patent and for what purpose). - maybe more with more details; Anssi pretty much defined categories in his first message here. We definitely can't say bluntly let's ignore all laws because we can't enforce them all. We must define our policies for what goes in Mageia repositories, what stays out, what goes out (and why). These policies must align with (and be part of) Mageia values and direction. Cheers, Romain
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
Le 9 oct. 2010 à 09:57, Margot mar...@otfordduckscomputers.co.uk a écrit : There has been a lengthy debate about users' wishes for the Mageia release cycle, but one important voice has been missing from this debate: the collective voice of the devs who will be responsible for producing the releases. Before we start having polls and surveys, it would be useful to hear from our devs. Before devs may comment on the technical in's and out's of a proposal, there must exist such a specific proposal, understood and agreed on by several people. To this day, we only have discussions, so a lot of different views and tracks coming from a common statement. The wiki page I drafted a few days ago (http://mageia.org/wiki/doku.php?id=rollingdebate - maybe misnamed in this regard) serves as a draft for this documentation/proposal purpose: - first gather views on perceived issues with the release/update lifecycle of the system and apps; - then dive in depth into these to get common issues and understand the real bottom line (that may not ne obvious as of today) - then have proposals + analysis of feasability. This involves makers and users at all steps. That requires not discussing specificities of solutions before having agreed on the problem to solve. Without that (making sure all think about the same thing in a documented way), the discussion will stay cloudy. However no proposal has been formally posted over there, so it may have been wrongly understood as a method or it may just not be a fit here? I don't know. However, if you _do_ have such a proposal to post, please take the time to post it as an article somewhere. Or propose another structured way. As Oliver reminded it, the first milestone we have is releasing our first ISO to test-drive the whole infrastructure and project organisation. That includes test-driving methods to state, discuss, refine issues/solutions or new ideas and then decide to put them into production or not (what we could do right here, not relying only on ml conversations but on stable docs too). Cheers, Romain
Re: [Mageia-dev] About Mandriva tools future : Host Mandriva tools on github
On Fri, Oct 1, 2010 at 15:15, Fabrice Facorat fabrice.faco...@gmail.com wrote: 2010/10/1 Tux99 tux99-...@uridium.org: Substance counts a lot more than appearance to me. again you're somewhat wrong iPod and iPhones are inferirors products technically speaking, but they have better appearance ( good marketing, which is about appearance ) and so are successful. Appearance is not their only reason to be successful at this time. Both (substance, appearance) are crucial. If you only consider one without balancing, making it consistent with the other, you're not going down the right path. The interface, the whole experience with it is the product. Romain
Re: [Mageia-dev] When the jobs will start???
hey, euphoria's so big we're still trying to cope with all incoming emails! :-) We're setting up a temp wiki to start listing people roles, a blog, a basic website and discussing for basic hosting services. We expect to post an update by this evening about all this + the org. statutes and registration and the following steps. Stay tuned. Cheers, Romain On Tue, Sep 21, 2010 at 14:44, Gabriel Duarte confuso...@gmail.com wrote: I have seen a huge euphoria around Mageia, people joining to help, developing, translating, managing, anyway... When we'll consolidate a new structure to start developing our goal? Cheers! -- Gabriel Duarte Linux User #471185 Rio de Janeiro - RJ http://w3.impa.br/~gabrield Phones: (55) (21) 9463-7760 - Mobile (55) (21) 2464-9302 - Home (55) (21) 2529-5080 - Work ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev
