Re: [Mageia-dev] Release cycles proposals, and discussion - messages from the forum
Le 18/06/2011 13:19, Michael Scherer a écrit : Le samedi 18 juin 2011 à 12:12 +0200, lebarhon a écrit : 1) can you please avoid posting as html to the list ? 2) if you wish to serve as a human gateway really between forum and ml ( which I didn't ask, I am smart enough to read forum by myself, as I helped install them among others ), can you at least be smart and forward only on topic discussion ? It was asked by the webteam, so you have to come yourselves to an agreement.
Re: [Mageia-dev] Release cycles proposals, and discussion - messages from the forum
2011/6/19 lebarhon lebar...@free.fr: Le 18/06/2011 13:19, Michael Scherer a écrit : Le samedi 18 juin 2011 à 12:12 +0200, lebarhon a écrit : 1) can you please avoid posting as html to the list ? 2) if you wish to serve as a human gateway really between forum and ml ( which I didn't ask, I am smart enough to read forum by myself, as I helped install them among others ), can you at least be smart and forward only on topic discussion ? It was asked by the webteam, so you have to come yourselves to an agreement. Nobody said anything against your efforts although I don't see any reason there (and I haven't seen any discussion in the webteam where it was decided to do so), people who read mailing lists are able to read forums as well - if they don't want to, that's their decision. But referring to the issue here I am pretty sure that nobody asked you to write in HTML nor to transfer the off-topic banter. I wonder why this has to be discussed, it's a matter of course. -- wobo
Re: [Mageia-dev] Job offer : mentoring program coordinator
On Sun, Jun 19, 2011 at 3:44 AM, andre999 and...@laposte.net wrote: Daniel Kreuter a écrit : On Sat, Jun 18, 2011 at 2:55 PM, Samuel Verschelde sto...@laposte.net mailto:sto...@laposte.net wrote: Le dimanche 12 juin 2011 15:27:59, Samuel Verschelde a écrit : ... The 2 candidates were good, which complicated my task because I had to make a choice, but I finally came to a decision : I propose andre999 as a mentoring program coordinator (or facilitator, if you think it fits the job better). ... Samuel Verschelde Congratulation andre999 for the job. If you need my help feel free to ask me. Thanks Daniel. As Magnus suggested, I think we could make a good team of three :) (With more welcome to join.) Particularly help with a presence on IRC, and any other input you would like to make. I'd like to make/refine and maintain a one-stop page in the wiki to coordinate the mentoring process, so suggestions would be more than welcome. -- Mit freundlichen Grüßen Greetings Daniel Kreuter -- André Thanks for the offer André. One suggestion would be to have a page on wiki where newcomers can put their name on if they seek for a mentor. But this can wait until the new wiki is online i think. As for now i only found a page where we can see our mentors and their apprentices, but no table of people who wait for a mentor. -- Mit freundlichen Grüßen Greetings Daniel Kreuter
Re: [Mageia-dev] Job offer : mentoring program coordinator
2011/6/19 Daniel Kreuter daniel.kreute...@googlemail.com One suggestion would be to have a page on wiki where newcomers can put their name on if they seek for a mentor. I think a good way to start. Perhaps we can help, especially if a newcomer ask a mailing list. Ask her/him for his skills and preferences and give her/him some Mageia links for mentoring and packaging. And then put it into the wiki. So Mageia shows a fast response. But this can wait until the new wiki is online i think. ok Magnus
Re: [Mageia-dev] Job offer : mentoring program coordinator
Daniel Kreuter a écrit : Thanks for the offer André. One suggestion would be to have a page on wiki where newcomers can put their name on if they seek for a mentor. But this can wait until the new wiki is online i think. As for now i only found a page where we can see our mentors and their apprentices, but no table of people who wait for a mentor. -- Mit freundlichen Grüßen Greetings Daniel Kreuter Thanks for the suggestion Daniel. I've been looking at the packages_mentoring page (which you referred to above), and was thinking of adding a So you want to be a Mageia packager section just before the section listing the mentors. With a place to insert their name. But it might be a better idea to have a separate page for that, with a link to the packages_mentoring page. Have to think about that. It is probably better to reflect a bit before making changes -- no sense in confusing people every time we change our minds. But I'm not sure that we should necessarily wait for the new wiki. Regards -- André
Re: [Mageia-dev] Job offer : mentoring program coordinator
magnus a écrit : 2011/6/19 Daniel Kreuter daniel.kreute...@googlemail.com mailto:daniel.kreute...@googlemail.com One suggestion would be to have a page on wiki where newcomers can put their name on if they seek for a mentor. I think a good way to start. Perhaps we can help, especially if a newcomer ask a mailing list. Ask her/him for his skills and preferences and give her/him some Mageia links for mentoring and packaging. And then put it into the wiki. So Mageia shows a fast response. Good idea. Would apply to forums, too. And IRC. But this can wait until the new wiki is online i think. ok Magnus We could also give a contact email address for those that wish to become packagers. Since many new to Mageia might not be familiar with editing a wiki to insert their name, but at the same time have skills useful for packagers. (Like previous packaging experience, programming experience, or even just a strong interest in packaging certain applications.) -- André
Re: [Mageia-dev] Release cycles proposals, and discussion
andre999 a écrit : Michael Scherer a écrit : Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit : Michael Scherer a écrit : Proposal 1: 6 months release cycle - 12 months life cycle ( Fedora, Ubuntu, Mandriva 2010.1 Mandriva != 2006.0 ) Proposal 2: 9 months release cycle - 18 months life cycle ( ~ opensuse and the one we used for Mageia 1 ) Proposal 3: 12 months release cycle - 24 months life cycle ( Mandriva 2010.1 ) First, suggest an amended freeze process (idea from recent report of another project) you can say the name of the project, even if I suspect it to be Fedora. I suspected that it might have been Fedora, if it wasn't a summary of the new mozilla process, but I couldn't remember. Just the concept intrigued me. Which I reflected on for a few weeks. Instead of a freeze on cauldron until everything is ready for the release, we do 1) short freeze on cauldron 2) copy cauldron to pre-release branch, which remains frozen until release 3) immediately unfreeze cauldron. - we avoid blocking cauldron, while leaving pre-release frozen for bug fixes. - updates can continue on cauldron. Bugfixes can be applied to newer versions, if present in cauldron, at the same time as corresponding bugfixes in pre-release. - activities like translation can continue in cauldron, meaning less rush for such updates. - because cauldron is open to changes (virtually) all the time, they don't have to be put off and perhaps forgotten. - the cauldron cycle is extented by the time of the pre-release freeze. e.g. In a release cycle of 6 months and a pre-release freeze of 1 month, the cauldron cycle would be 7 months. This allows more time to iron out the pre-release bugs and more time for cauldron. - with the longer pre-release freeze, it may be appropriate to modify somewhat the policy on what is accepted during freeze. (Certain more recent packages or translations, for example.) - note that we would still have to monitor cauldron to avoid freezing partially implemented complex changes, such as a major update of kde or gnome or perl, etc. But we have to do that now, anyway. So you suggest that in order to help packagers focusing on bug fixing, that we have them take care of cauldron and the bugfixes for the stable release ( ie, twice more the load ). I wouldn't quite put it that way ... Proposal 1 : --- My personal preference Pros: - better hardware support - up to date versions / upstream projects (must have for developers) - coincides with kde/gnome releases - amended freeze process (outlined above) would lengthen both pre-release freeze time and cauldron development time. A 1-month pre-release freeze would add 1 month to cauldron development time. This would tend to alleviate the rush of the 6-month release cycle. Let's do some math, shall we ? great :) If people work the same amount of time, with work divided on 2 products, they must share their time, and usually work less than if they focused only on one product, unless there is twice the ressources. But I doubt this will happen for us, so let's assume that ressources are fixed. That was my assumption : resources fixed in terms of time spent. And why would that divide a contributor's focus more than now ? They would just have a choice. Now during the freeze, someone that wants to contribute to cauldron, but can't or chooses not to contribute to pre-release bugfix, is not contributing. So in practice, we risk to have more time contributed during the freeze. Let say : - the freeze period is Y weeks, - the time between 2 release is X weeks, - people divide their time evenly on both products. That wasn't assumed. Rather that as much time would be spent on bug fixes, etc. in pre-release. But having a longer freeze period would likely result in better quality, and certainly less rush. That's a simplification, but I will come back on that later. Let's also count the time spent as the metrics for the work, even if man/month is a wrong unit in software development ( but that's a good enough approximation for our case, given the highly distributed and decentralized nature of the work of releasing a distribution ). So when there is the freeze ( at release(n) time - Y weeks ), we will have Y weeks of work done on both products ( next release, and cauldron ), so Y/2 weeks on each. We have X -Y weeks once the release(n) is out ( before the next freeze for release(n+1) ), and then again Y/2 weeks. So for the release (n+1), we spend : Y/2 + X - Y + Y/2 = 2 * Y/2 - Y + X = Y - Y + X = X So that give X weeks of work. Fascinating, isn't it ? Not really. Being my basic assumption :) Now, of course, we can say what if people do not divide their work in 2 ? So let's call : - F the time spent on bugfix during the freeze - C the time spent on cauldron during the freeze We can assume that : C + F = Y So the equation become : C + ( X - Y ) + F = C + F - Y + X = X So no matter how you divide the time, you still have the same amount
Re: [Mageia-dev] Finalizing update process
On Sat, 18 Jun 2011, Ahmad Samir wrote: qa-bugs@ can't be be set as the assignee in bug reports, it should be made possible. It should be possible now (since friday actually). This bug for instance is assigned to qa-bugs@ : https://bugs.mageia.org/show_bug.cgi?id=1554
Re: [Mageia-dev] Release cycles proposals, and discussion
Hello, The discussion about the Mageia life cycle start few days ago on the forum of the French user community of Mageia ( http://www.mageialinux-online.org/forum/topic-10576+cycle-de-vie-de-mageia.php : for those who read French ) tTo put all the answers in a nutshell, i will say that users rather having a new version if that bring big changes. If the goal is to have a windows like new version ( with a new design, new bugs, new system sounds, please buy a new printer/scanner because the new driver will never exist or please buy a new computer because yours is too old/not enough memory... and no fundamental changes on the OS ) or something like : Mageia(n) = Mageia(n-1) - some bugs + new design + some updates then it's useless to have a new version each x month. Users wants a good, strong, and long life OS. Those who like to change the design will be happy if they have something like task-newdesign.RPM those who like news or updates will be happy with update and backports repository. Currently, we just put the suitcase on the floor. ( sorry, bad translation of a french idiom ;)) The website is temporary, like the wiki and like a lot of things. It's hard to find new volunteers... So... We needn't to have the eyes bigger than the stomach ( sorry, bad translation of a French idiom O:)) Let's take time for opening the suitcase... having a good multilingual web site with an easy management, a not temporary wiki, correcting bugs, maybe make more test, create the missing and ask packages, create stronger teams with more people. Maybe we can think of a new way of working ( like the idea of Proofreading in i18n teams )... Currently I help anaselli in his project of educative Mageia version, maybe it should be great to have others version of Mageia ( like a server version for example ). Greeting, mammig PS : I think it's a good thing to have the opinion of users about that, even if they are not english. I will not make a translation of each message, I guess a small summary is enough. 2011/6/19 Oliver Burger oliver@googlemail.com: andre999 and...@laposte.net schrieb am 19.06.2011 Another thought about the amended freeze process. Have you noticed how packagers sometimes set off an exchange of 10 or more emails in attempts to get a package into the release during the freeze ? The packager wants to submit, but they can't because cauldron is frozen. Maybe if only pre-release were frozen, but cauldron open, they would accept submitting to cauldron after only 1 or 2 exchanges. They would have the at least partial satisfaction of being able to submit their package (instead of waiting, and doing something else, probably elsewhere), and others would have been releaved of the hassle of dealing with their repeated requests. I think that would be more motivating for the packager in question, as well as the others involved. And packagers would avoid wasting both time and energy. I don't know. I think most freeze push requests were due to the fact, that packagers wanted to have their baby in the release. Because every packager knows, he only has to wait some days to submit it to Cauldron again. So I don't think any packager would be any the happier by this solution. I have to agree with misc. It would only mean having more work. Oliver
Re: [Mageia-dev] Release cycles proposals, and discussion
Le samedi 18 juin 2011 à 23:49 -0400, andre999 a écrit : Michael Scherer a écrit : Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit : Michael Scherer a écrit : If people work the same amount of time, with work divided on 2 products, they must share their time, and usually work less than if they focused only on one product, unless there is twice the ressources. But I doubt this will happen for us, so let's assume that ressources are fixed. That was my assumption : resources fixed in terms of time spent. And why would that divide a contributor's focus more than now ? They would just have a choice. So before, the choice is between : - not doing anything - bugfixing After your proposal, there is : - not doing anything - bugfixing - uploading new stuff to cauldron And you fail to see how it divert focus ? Now during the freeze, someone that wants to contribute to cauldron, but can't or chooses not to contribute to pre-release bugfix, is not contributing. So in practice, we risk to have more time contributed during the freeze. My own experience tell the contrary, but maybe you should ask to Anne her opinion if you do not believe me, or to others people who did distribution releases ( and not software releases, which is slightly different, mainly because there is less ). Now, of course, we can say what if people do not divide their work in 2 ? So let's call : - F the time spent on bugfix during the freeze - C the time spent on cauldron during the freeze We can assume that : C + F = Y So the equation become : C + ( X - Y ) + F = C + F - Y + X = X So no matter how you divide the time, you still have the same amount of time spent overall. As I assumed :) No. the cauldron cycle is extented by the time of the pre-release freeze. e.g. In a release cycle of 6 months and a pre-release freeze of 1 month, the cauldron cycle would be 7 months. The cauldron cycle would be 7 months just on the calendar, but 6 months worth of work, as demonstrated. A 1-month pre-release freeze would add 1 month to cauldron development time. That's the same, you do not add real months, just months on the calendar. Now, the real important question is can we really exchange work done as part of C for work done as part of F. And so if I do regular packages updates on cauldron at the begining of the cycle, does it count as bugfixing for the release in the end of the cycle ? To me, the answer is clearly no. If it was somethig we could exchange, we would not have to make a freeze in the first place to make sure that only bugfixes are uploaded in cauldron. So the only way to maximize the time spent on bugfixes is to have F = Y, and so C = 0. Ie, do like we do now. I really don't follow this line of reasoning. The focus on bug fixes starts with the freeze. So a longer freeze would give more time to focus on bug fixes. The focus on bugfixing start with version freeze, since what introduce problem is various changes, and new versions of softwares usually bring new changes. Then we block all uploads except bug fixes, and then all uploads unless very serious bug fixes ( ie, release blocker ). So the focus start much before the last freeze, and you are quite unclear. And unless you show that letting people work on cauldron will bring more ressources , and more than the one we will lose du to people who do not want to work on bugfixes and the release, I doubt this will change. Ok. Obviously I need to clarify my point of view. Firstly, my assumption was that at least as much time would be spent on bug fixing during the longer freeze, but being less rushed, would tend to produce better quality results. (And less aggravation for ennael) (That is certainly how it works in the non-libre world.) You do not say much how you extend the freeze to be longer, nor even that the freeze appear sooner, reread your mail. Nor what kind of freeze would it be. The only mention of the duration of the freeze is : A 1-month pre-release freeze would add 1 month to cauldron development time. The version freeze started on 20 april ( https://mageia.org/pipermail/mageia-dev/20110419/004066.html ), which is more than 1 month. The release freeze was on 14 may, which is 2 weeks. Given that the version freeze is when we start to ask to people to focus on bugfixes and when we prevent packagers from uploading newer versions of packages, the proposed 1 month pre-release freeze is unclear and unexplained. I don't see how having the choice between contributing to pre-release or cauldron during the freeze will lead to us loosing _any_ contributors. We do not lose contributors, we lose the work of people that prefer to work on cauldron by uploading new versions rather than bug fixing, and from people that will prefer to test and use cauldron rather than the future stable release, because that's easier, there is no deadline, nor any
Re: [Mageia-dev] perl 5.14.1 on its way
What do you think of a fedora-like perl FSH layout? 2011/6/19 Jerome Quelin jque...@gmail.com: hi, i just submitted perl 5.14.1, which should be a smooth upgrade. no need to recompile binary modules this time. jérôme
Re: [Mageia-dev] perl 5.14.1 on its way
On 19.06.2011 19:18, Michael Scherer wrote: Le dimanche 19 juin 2011 à 15:46 +0200, Jerome Quelin a écrit : hi, i just submitted perl 5.14.1, which should be a smooth upgrade. no need to recompile binary modules this time. Some packages seems to have some errors : http://check.mageia.org/dependencies.html perl found with incorrect range == 2:5.14.1-1.mga2 (needed == 2:5.14.0) Is this a youri error or a real issue ? Applications dynamically linked to perl need to be rebuilt for new perl versions as the perl library is in a versioned directory. -- Anssi Hannula
[Mageia-dev] python-twisted
Hi, Just for info, python-twisted 11.0.0 is now in cauldron. You can test it and file bugs reports if it's needed. Cheers -- Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com IRC: Kharec (irc.freenode.net) Software/Hardware geek Conceptor Magnum's Coordinator/editor (http://magnum.tuxfamily.org) Mageia and Mandriva contributor
Re: [Mageia-dev] Release cycles proposals, and discussion - messages from the forum
Le 19/06/2011 10:28, Wolfgang Bornath a écrit : Nobody said anything against your efforts although I don't see any reason there (and I haven't seen any discussion in the webteam where it was decided to do so), Who the hell are you to dare say I am a liar ! https://forums.mageia.org/en/viewtopic.php?f=29t=570 https://forums.mageia.org/en/viewtopic.php?f=29t=570 1 - roadrunner asked if somebody could cross-post between the forum and the ML 2 - Anne posted in this thread and find nothing to say against it 3 - So, I volunteered for that 4 - maat agreed 5 - I suggested a method 6 - maat agreed again 7 - I began what I promised, and you posted behind without saying anything against it. It was not enough to be fully authorized people who read mailing lists are able to read forums as well - if they don't want to, that's their decision. They are able to, but they won't because our team members still sleep during nights. These are Anne's own words. But referring to the issue here I am pretty sure that nobody asked you to write in HTML nor to transfer the off-topic banter. Neither that nor the opposite. I never said I will re-write all the text nor I will read and sort the posts. Nobody prevented me to do that way. I stopped some of the off-topic banger, not each one. Well, I made a mistake, I was told by misc, it's ok and I don't need a parrot repeating for a second layer. I subscribed to this third Mageia ML at this purpose only and didn't read the other posts, so I am going to unsubscribe, this one at least.
Re: [Mageia-dev] perl 5.14.1 on its way
On 19.06.2011 21:02, Jerome Quelin wrote: On 11/06/19 18:18 +0200, Michael Scherer wrote: perl found with incorrect range == 2:5.14.1-1.mga2 (needed == 2:5.14.0) Is this a youri error or a real issue ? how can we find those? afaik, urpmf --requires :perl cannot be used with a specific version. any help to find those packages is welcome. e.g. to find packages depending on 2:5.14.0: $ urpmf --requires :perl\[== 2:5.14.0 or to find all packages having a version-specific require on another version than 5.14.1: $ urpmf --requires ':perl\[== (?!2:5.14.1[-\]])' -- Anssi Hannula
Re: [Mageia-dev] [RPM] cauldron core/release p-uae-2.3.2-1.gita2b6937.2.mga2
On 18 June 2011 20:12, Mageia Team buildsystem-dae...@mageia.org wrote: [This is in an unofficial branch of UAE (the Ubiquitous Amiga Emulator) with the aim of bringing the features of WinUAE to non-Windows platforms such as Linux, Mac OS X and BeOS.] obgr_seneca obgr_seneca 2.3.2-1.gita2b6937.2.mga2: + Revision: 109474 - cleaned spec file - removed buildroot tag - imported package p-uae Should this be in core? In mdv such emulators usually ended in PLF...
Re: [Mageia-dev] [RPM] cauldron core/release p-uae-2.3.2-1.gita2b6937.2.mga2
Thierry Vignaud thierry.vign...@gmail.com schrieb am 19.06.2011 On 18 June 2011 20:12, Mageia Team buildsystem-dae...@mageia.org wrote: [This is in an unofficial branch of UAE (the Ubiquitous Amiga Emulator) with the aim of bringing the features of WinUAE to non-Windows platforms such as Linux, Mac OS X and BeOS.] obgr_seneca obgr_seneca 2.3.2-1.gita2b6937.2.mga2: + Revision: 109474 - cleaned spec file - removed buildroot tag - imported package p-uae Should this be in core? In mdv such emulators usually ended in PLF... The old e-uae was in contrib_release for years. The emulator itself does not contain any legally critical stuff. You need a rom image to use it, that can't be packaged (and isn't) because of legal issues. I see no problem having p-uae in core. Oliver
Re: [Mageia-dev] [RPM] cauldron core/release drakx-installer-binaries-1.50-3.mga2
On 19/06/11 18:43, Mageia Team wrote: Name: drakx-installer-binaries Relocations: (not relocatable) Version : 1.50 Vendor: Mageia.Org Release : 3.mga2Build Date: Sun Jun 19 19:40:17 2011 Install Date: (not installed) Build Host: jonund Group : Development/Other Source RPM: (none) Size: 914415 License: GPL Signature : (none) Packager: Mageia Teamhttp://www.mageia.org URL : http://wiki.mandriva.com/Tools/DrakX Summary : DrakX binaries Description : binaries needed to build Mandriva installer (DrakX) Are the Mandriva references appropriate? Jim
Re: [Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2
On Wed, 15 Jun 2011 10:02:21 -0300, John Balcaen mik...@mageia.org wrote: 2011/6/15 JA Magallón jamagal...@ono.com: [...] This is missing the 'ifcfg-mdv' and 'keyfile' plugins... in fact only the ifcfg-mdv plugin is really missing. keyfile should be available. The plugin file is not there. only ifcfg-rh: one:~# rpm -ql networkmanager | grep /usr/lib /usr/lib64/NetworkManager /usr/lib64/NetworkManager/libnm-settings-plugin-ifcfg-rh.so /usr/lib64/nm-avahi-autoipd.action /usr/lib64/nm-crash-logger /usr/lib64/nm-dhcp-client.action /usr/lib64/nm-dispatcher.action /usr/lib64/pppd/2.4.5/nm-pppd-plugin.so If you want to say that the functionality should be there because now it is integrated instead of a plugin, it is half-working: nm can read the names and info about connections, but no wireless device is available in applet menu...it does not detect wifi hardware. Any ideas ? -- J.A. Magallon jamagallon()ono!com \ Winter is coming...
Re: [Mageia-dev] [RPM] cauldron core/release p-uae-2.3.2-1.gita2b6937.2.mga2
Le dimanche 19 juin 2011 à 22:40 +0200, Thierry Vignaud a écrit : On 18 June 2011 20:12, Mageia Team buildsystem-dae...@mageia.org wrote: [This is in an unofficial branch of UAE (the Ubiquitous Amiga Emulator) with the aim of bringing the features of WinUAE to non-Windows platforms such as Linux, Mac OS X and BeOS.] obgr_seneca obgr_seneca 2.3.2-1.gita2b6937.2.mga2: + Revision: 109474 - cleaned spec file - removed buildroot tag - imported package p-uae Should this be in core? In mdv such emulators usually ended in PLF... Unfortunately, no one ever gave a reason for having them in PLF besides that's because emulators goes to PLF, despites having zsnes and snes9x in contribs since years. Among the potential reasons would be : - copyright violation due to proprietary rom/bios ( which need to be checked on a case by case basis ) - copyright due to logo/names/brand ( again, that would be a case by case ) - fear of being attacked due to the bleem! story in 1999 ( http://en.wikipedia.org/wiki/Bleem! ). The 3rd option would be perfectly suited given the highly historical nature of the reason. Nowadays, the only important story I can find would be this one : http://mashable.com/2011/05/30/emulators-banned-android-market/ , and there isn't much information, besides the supposition this could be a TOS violation. -- Michael Scherer
Re: [Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2
Le dimanche 19 juin 2011 19:18:50, JA Magallón a écrit : On Wed, 15 Jun 2011 10:02:21 -0300, John Balcaen mik...@mageia.org wrote: 2011/6/15 JA Magallón jamagal...@ono.com: [...] This is missing the 'ifcfg-mdv' and 'keyfile' plugins... in fact only the ifcfg-mdv plugin is really missing. keyfile should be available. The plugin file is not there. only ifcfg-rh: Seems like the plugin is built in now in fact no more available as a .so file . From my log i can read : Jun 19 17:46:12 hatmehyt NetworkManager[7902]: info Loaded plugin keyfile: (c) 2007 - 2010 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. [...] If you want to say that the functionality should be there because now it is integrated instead of a plugin, it is half-working: nm can read the names and info about connections, but no wireless device is available in applet menu...it does not detect wifi hardware. Any ideas ? Currently no :/ -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Release cycles proposals, and discussion
Michael Scherer a écrit : Le samedi 18 juin 2011 à 23:49 -0400, andre999 a écrit : Michael Scherer a écrit : Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit : Michael Scherer a écrit : If people work the same amount of time, with work divided on 2 products, they must share their time, and usually work less than if they focused only on one product, unless there is twice the ressources. But I doubt this will happen for us, so let's assume that ressources are fixed. That was my assumption : resources fixed in terms of time spent. And why would that divide a contributor's focus more than now ? They would just have a choice. So before, the choice is between : - not doing anything - bugfixing - or doing something elsewhere. After your proposal, there is : - not doing anything - bugfixing - uploading new stuff to cauldron And you fail to see how it divert focus ? We have to remember that packager time is not an ubiquitous resource. If a packager cannot use their time efficiently during freeze, they have incentive to contribute their time elsewhere. It is just human nature. Admittedly this is more likely to affect packagers with less broad-based skills, but such packagers do not make insignificant contributions. As far as diverting focus, does the existance of many distros, providing much more choice, divert focus ? Likely to some extent, but not many packagers contribute to 4 to 6 distros and support in the order of 1000 packages. That's more the exception, for packagers with exceptional skills. Now during the freeze, someone that wants to contribute to cauldron, but can't or chooses not to contribute to pre-release bugfix, is not contributing. So in practice, we risk to have more time contributed during the freeze. My own experience tell the contrary, but maybe you should ask to Anne her opinion if you do not believe me, or to others people who did distribution releases ( and not software releases, which is slightly different, mainly because there is less ). Until we try it, we don't know how much effect it will have. To the best of my knowledge Mandrake/Mandriva and certainly Mageia has not tried this approach. We are both working on conjectures, and we can't know until we (or some other distro with similar resources) tries it. I find it difficult to believe that it will have a negative effect. And I think it would be useful to try it early in the development of Mageia. Even experienced programmers, who have to support different versions of the same software, run into cases where it is very convient -- and more efficient -- to do parallel updates for example. I run into that often enough myself. Now, of course, we can say what if people do not divide their work in 2 ? So let's call : - F the time spent on bugfix during the freeze - C the time spent on cauldron during the freeze We can assume that : C + F = Y So the equation become : C + ( X - Y ) + F = C + F - Y + X = X So no matter how you divide the time, you still have the same amount of time spent overall. As I assumed :) No. the cauldron cycle is extented by the time of the pre-release freeze. e.g. In a release cycle of 6 months and a pre-release freeze of 1 month, the cauldron cycle would be 7 months. Agreed. I've already said that. The cauldron cycle would be 7 months just on the calendar, but 6 months worth of work, as demonstrated. A 1-month pre-release freeze would add 1 month to cauldron development time. That's the same, you do not add real months, just months on the calendar. As I said, my basic assumption that the same number of packager hours are contributed. Certain factors suggest that one could expect somewhat more time contributed, and a number of others that the time would be used more efficiently. Nothing suggests that less time would be available. Now, the real important question is can we really exchange work done as part of C for work done as part of F. And so if I do regular packages updates on cauldron at the begining of the cycle, does it count as bugfixing for the release in the end of the cycle ? To me, the answer is clearly no. If it was somethig we could exchange, we would not have to make a freeze in the first place to make sure that only bugfixes are uploaded in cauldron. So the only way to maximize the time spent on bugfixes is to have F = Y, and so C = 0. Ie, do like we do now. I really don't follow this line of reasoning. The focus on bug fixes starts with the freeze. So a longer freeze would give more time to focus on bug fixes. The focus on bugfixing start with version freeze, since what introduce problem is various changes, and new versions of softwares usually bring new changes. Then we block all uploads except bug fixes, and then all uploads unless very serious bug fixes ( ie, release blocker ). So the focus start much before the last freeze, and you are quite unclear. It terms of freeze, I'm referring to the first freeze for
Re: [Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2
Le dimanche 19 juin 2011 20:00:20, JA Magallón a écrit : [...] So i short it seems that wpa_supplicant has to be compiled with dbus support for new networkmanager. I also see a patch in src.rpm to disable dbus I'll disable the patch add 2 more patchs from fedora, could you please test the new wpa_supplicant ? The package should land in core/updates_testing Regards, -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
