Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
I think we could, just for fun if you like, pursue making a good plan of how the transition would be and what changes should be done. Consider it objectively. What changes would have to be done the OS? What changes in infrastructure? What tools do we need? This could be a good exercise. The wiki might be a nice place to do it. How about that? As a sysadmin, I'd love to be able to update to a certain point in time. Like in git, you can just checkout a tag... Wouldn't it be awesome to be able to update to a certain tag? Heh, one could even have spin tags, hehe. Also, having the package manager give you warnings, pointers, suggestions and general messages would rock. I'm just sayin' ;) -- Renich Bon Ciric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide
On Sat, Nov 03, 2012 at 18:32:20 -0600, Kevin Fenzi wrote: Additionally, if some number of these folks who pledge to run rawhide full time were provenpackagers we could just go in and fix things as they hit (or soon after) instead of waiting a while for fixes to go out. I'm in proven packagers and have been using rawhide on my main desktop for a while. (Sometimes I follow branched, but I plan to use rawhide going forward.) That's what I use for day to day stuff at home. - It's been suggested before, but could we practically keep N and N-1 packages in rawhide repos? Then 'yum downgrade' becomes much more handy. Repodata size and mirror size might shoot that down though. If you want that you can just enable them in addition. That can cause problems if versions in FN or FN-1 are higher than in rawhide. I have done that for a while this release to get gnome updates early. - Anaconda folks haven't wanted rawhide installer images as they cause people to report bugs on things when not ready, etc. However, could we build nightly cloud images at least? Those could help test things and won't require hitting the installer path. Once you are using rawhide, you generally don't do installs unless you specifically want to test them. I really think if we get a pool of savvy folks running it day to day we should at least be able to identify the pain points. In my experience with my test machine, rawhide has been pretty boring for the last two cycles, if we can continue to make it so, perhaps the rolling release folks might be able to find it usable. I get occasional kernel problems. Sometimes there are boot issues. When there are soname issues, I sometimes have to choose between running the current packages or uninstalling some things I use. I had some theming issues not too long ago, but that affected both rawhide and branched, so I saw it on all of my machines. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sun, Nov 04, 2012 at 00:26:08 +0100, Michael Scherer wrote: Le samedi 03 novembre 2012 à 07:46 -0500, Bruno Wolff III a écrit : I do not run it, so I cannot judge, but I think the first step to fix something is to know the exact problems to fix. If the issue is "too much breakage", how can we ensure the most annoying issues are prevented ( I am pretty confident in autoQA personnaly ) ? Well one issue is packagers not doing rawhide builds. This has two issues. One is that rawhide doesn't pick up fixes in updates-testing so doesn't get the latest updates. The other is that the packages aren't built against rawhide libraries which can cause breakage when libraries change. And also, if rawhide start to be more used, we should ensure if doesn't divde the community in 2 groups ( as I have seen some people complain on others distributions that stable release are neglected because devs run "$dev_distro" and not the stable release ) In Fedora's case the problem is reversed. Rawhide doesn't get enough attention. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide
On 04.11.2012 01:32, Kevin Fenzi wrote: So, I have been thinking about rawhide. I agree identifying the problems/issues would be good, and I think there's something we can do to help with that: Get a nice group of at least 10 or so folks who are active on this list to agree to run it full time on their main machine. As we get close to F18 release, I am considering moving my full time laptop to rawhide. If I can get a group of folks to do likewise we can at least identify issues faster and help each other as they come up. Additionally, if some number of these folks who pledge to run rawhide full time were provenpackagers we could just go in and fix things as they hit (or soon after) instead of waiting a while for fixes to go out. I've run a rawhide vm/test machine here for many years. It's hit it's share of problems, but none were insurmountable. Some of them might have been for folks who were not more experienced tho, so increasing communication around rawhide can only help, IMHO. Additional thoughts to help rawhide: - It's been suggested before, but could we practically keep N and N-1 packages in rawhide repos? Then 'yum downgrade' becomes much more handy. Repodata size and mirror size might shoot that down though. - Autoqa could perhaps help out, but I am not holding my breath. ;) - Anaconda folks haven't wanted rawhide installer images as they cause people to report bugs on things when not ready, etc. However, could we build nightly cloud images at least? Those could help test things and won't require hitting the installer path. - I'm sure there's more ideas to improve it... I really think if we get a pool of savvy folks running it day to day we should at least be able to identify the pain points. In my experience with my test machine, rawhide has been pretty boring for the last two cycles, if we can continue to make it so, perhaps the rolling release folks might be able to find it usable. kevin While I'm not (yet) a package maintainer, I'm a regular reader of various fedora lists, and I've been using exclusively rawhide on my machine (Lenovo T400) for the past year, for anything from normal desktop usage to various scientific/programming stuff, in particular C++/Qt/OpenGL, some Gtk and also AVR microcontroller stuff. I though I'd briefly summarize my experiences: - The experience greatly depends on the desktop environment. Very early Gnome development packages are released to the wild (and hence end up in rawhide) very soon, which can cause major problems. On the other hand, KDE for instance only releases builds starting from usually quite usable betas. While previous rawhide installations on Gnome were often quite challenging to maintain, I've had very few DE-related issues in the past year as a KDE user. - My rule number one is: never reboot before any important presentations :) I've had the occasional boot-related issue. While enforcing=0 was often part of the solution, systemd and dracut related issues were the most difficult ones to work-around to have the system booting again. - I always exclude the kernel from the updates, and usually only update to kernel-*-rc3+ without debugging options (simply because KDE is terribly sluggish with debugging options). - Broken dependencies are occasionally somewhat of a pain, one issue which already came up on this list a while ago is the occasional version discrepancy between branched and rawhide. In general, I end up rebuilding a couple of packages a week manually to have all updates apply (have written a nice rebuild.sh script for that;)). Occasionally, some manual patching is necessary. - I have clean_requirements_on_remove = 1 in yum.conf, and also have installed yum-plugin-show-leaves, which makes it fairly easy to keep the installation tidy. I guess that's about it. In general I must say that I've found rawhide to be definitely more than just usable! Sandro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revamping the non responsive maintainer process
On Fri, Nov 02, 2012 at 06:12:02PM +, "Jóhann B. Guðmundsson" wrote: > On 11/02/2012 06:05 PM, Jon Ciesla wrote: > > > >No, they might simply have had nothing to do. Sometimes > >applications are stable, have no releases, and have no bugs files > >against them. > > > > Then those individuals would simply respond to the email that that > was the case and they are still alive and active within the project > and they might even have to take an step and simply "login" to > prevent them from being ping next time the cron-job runs . > > Seriously we can just cross that bridge if and when that case > happens that surely beats doing nothing as things stand now > > Have fun bringing up all the hypothetical issue in the world, I > however got better things to do with my time than trying to convince > people that is extremely necessary and deal with any hypothetical > issue that might arise should we try to automate that process... The easiest thing to convince people is to propose a concrete proposal for the time frame and show numbers of how many false positives this would lead to. Some information about how many packagers were inactive for how long would be helpful, too. All this information would be easy to get with the cron job script, which needs to be written anyway. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sun, 2012-11-04 at 02:12 +0200, Nikos Roussos wrote: > > Adam Williamson wrote: > >On Sat, 2012-11-03 at 09:37 -0200, Henrique Junior wrote: > > > >> The guys behind openSUSE created a good approach with Tumbleweed. By > >> adding this repo users can opt-in to the (semi)rolling model. > >> Tumbleweed is more like a pool where updated, stable, non disruptive > >> software can be installed and I was able to talk to the guy who > >> created Tumbleweed some time ago. He said that it is easy to maintain > >> and takes only a few minutes a day to check things. > >> It is difficult, for example, to understand why we have to wait until > >> the next release to have LibreOffice 3.6, since this seems an non > >> disruptive update that could bring major improvements in the > >> productivity of users who rely on office suites to work. > > > >I don't think that *adding* tracks is an approach that is going to > >solve > >any of our problems, though it might add convenience for a small set of > >users. We need to be making things simpler, not more complex. :) > > And in many cases it's simpler to have security updates for an LTS Fedora > version than upgrading X workstations every 6 or 12 months. I meant 'simpler for developers', not 'simpler for users'. This is, after all, the developer list :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rawhide
So, I have been thinking about rawhide. I agree identifying the problems/issues would be good, and I think there's something we can do to help with that: Get a nice group of at least 10 or so folks who are active on this list to agree to run it full time on their main machine. As we get close to F18 release, I am considering moving my full time laptop to rawhide. If I can get a group of folks to do likewise we can at least identify issues faster and help each other as they come up. Additionally, if some number of these folks who pledge to run rawhide full time were provenpackagers we could just go in and fix things as they hit (or soon after) instead of waiting a while for fixes to go out. I've run a rawhide vm/test machine here for many years. It's hit it's share of problems, but none were insurmountable. Some of them might have been for folks who were not more experienced tho, so increasing communication around rawhide can only help, IMHO. Additional thoughts to help rawhide: - It's been suggested before, but could we practically keep N and N-1 packages in rawhide repos? Then 'yum downgrade' becomes much more handy. Repodata size and mirror size might shoot that down though. - Autoqa could perhaps help out, but I am not holding my breath. ;) - Anaconda folks haven't wanted rawhide installer images as they cause people to report bugs on things when not ready, etc. However, could we build nightly cloud images at least? Those could help test things and won't require hitting the installer path. - I'm sure there's more ideas to improve it... I really think if we get a pool of savvy folks running it day to day we should at least be able to identify the pain points. In my experience with my test machine, rawhide has been pretty boring for the last two cycles, if we can continue to make it so, perhaps the rolling release folks might be able to find it usable. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Adam Williamson wrote: >On Sat, 2012-11-03 at 09:37 -0200, Henrique Junior wrote: > >> The guys behind openSUSE created a good approach with Tumbleweed. By >> adding this repo users can opt-in to the (semi)rolling model. >> Tumbleweed is more like a pool where updated, stable, non disruptive >> software can be installed and I was able to talk to the guy who >> created Tumbleweed some time ago. He said that it is easy to maintain >> and takes only a few minutes a day to check things. >> It is difficult, for example, to understand why we have to wait until >> the next release to have LibreOffice 3.6, since this seems an non >> disruptive update that could bring major improvements in the >> productivity of users who rely on office suites to work. > >I don't think that *adding* tracks is an approach that is going to >solve >any of our problems, though it might add convenience for a small set of >users. We need to be making things simpler, not more complex. :) And in many cases it's simpler to have security updates for an LTS Fedora version than upgrading X workstations every 6 or 12 months. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sun, 2012-11-04 at 00:26 +0100, Michael Scherer wrote: > Le samedi 03 novembre 2012 à 07:46 -0500, Bruno Wolff III a écrit : > > > I'd rather see us do a better job with rawhide so that more people use it > > and > > a better job at making upgrades go smoother so that people just trying > > to get stuff done with Fedora have a better experience. > > Then the question is "Why people do not use rawhide", and "how can we > fix the issue so people use it". Maybe that's just perception, maybe > there is real recurrent issue to fix one way or another. > > I do not run it, so I cannot judge, but I think the first step to fix > something is to know the exact problems to fix. If the issue is "too > much breakage", how can we ensure the most annoying issues are prevented > ( I am pretty confident in autoQA personnaly ) ? We have on our todo list to 'enforce' the existing autoqa tests, for depcheck and upgrade path, but we're a little short on people ATM and everyone keeps getting roped into validation testing. I think enforcing depcheck for Rawhide would be going a bit far, though, because then you'd have to use a side tag to do soname bumps, so we kind of have a problem there: we can't blindly reject dependency-breaking changes to Rawhide, but that's the kind of thing that usually causes problems in Rawhide... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Le samedi 03 novembre 2012 à 07:46 -0500, Bruno Wolff III a écrit : > I'd rather see us do a better job with rawhide so that more people use it and > a better job at making upgrades go smoother so that people just trying > to get stuff done with Fedora have a better experience. Then the question is "Why people do not use rawhide", and "how can we fix the issue so people use it". Maybe that's just perception, maybe there is real recurrent issue to fix one way or another. I do not run it, so I cannot judge, but I think the first step to fix something is to know the exact problems to fix. If the issue is "too much breakage", how can we ensure the most annoying issues are prevented ( I am pretty confident in autoQA personnaly ) ? And also, if rawhide start to be more used, we should ensure if doesn't divde the community in 2 groups ( as I have seen some people complain on others distributions that stable release are neglected because devs run "$dev_distro" and not the stable release ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, Nov 3, 2012 at 4:29 PM, Adam Williamson wrote: > On Sat, 2012-11-03 at 11:28 +, mike cloaked wrote: > > > Others may wish to compare Fedora with other distributions also - but > > one thought I had was that in Archlinux there are only two repos to > > maintain - whilst in Fedora it is 5 repos! One might wonder whether > > there is less effort needed to keep up to date by the developers in > > Arch or Fedora - I don't have the answer to that question but the devs > > have more knowledge about effort needed to maintain all of this to > > make a proper comparison? > > Thanks, Mike, that's a great illustration of the point I was trying to > make: the Arch model sounds much like what I was trying to suggest for > Fedora, a simple two-track 'devel' and 'stable' model with QA between > the tracks. And as you point out, on the face of it it appears to > involve much less drudgery for maintainers. I have never run Arch, but I > do get the general impression it provides a sufficiently reliable > experience for the kinds of users Fedora and Arch have. > > Indeed Adam - I guess the choice for running a rolling release or periodic stable releases, with updates for some support period, is a choice that the collective developers need to make, and which then developers are happy to work with or move to where they feel comfortable. Having said that, it is clear that both Archlinux and Fedora are mainstream distributions each with significant numbers of users who treat their installs with sufficient confidence to use their systems on a day to day basis as a stable platform. Some Fedora people also run with the updates-testing repo enabled (or in the case or arch with [testing] enabled) and are ready to fix problems as they arise with occasional not-completely-stable updates from time to time. I have only been running archlinux on three machines for less than a year but I am pretty happy with the way updates arrive and delighted that, when major upgrades of desktop packages are released upstream, it is not too long before they are tested and released to [core] so it is nice to have the very latest KDE for example, and the latest kernel pretty well too. For Fedora more recently kernels have been superbly close to upstream for all releases which I am sure must be valued by the user community. Nevertheless I am also clear that archlinux with its rolling release model works and works very well indeed. There have been issues occasionally with Archlinux with things like glibc, and the /usr move but the vast majority of users have survived with a combination of clear announcement guides as well as good wiki entries plus mailing list discussions to help with individual cases which may have been slightly unusual use cases - such as one user who had not updated at all for many many months and then did a huge update which included several key upgrades where an interaction between the order of manual interventions made things a little messy. So my personal experience of arch has been a very positive one - there are differences - for example in arch selinux is not centrally supported - whereas Fedora has been a prime developer for selinux and the vital policy packages that go with it and included as default for several releases. However the ease of maintenance means that for the machines I run with arch make life easier for me, and with careful config settings I have not come up against a security problem. Everyone has a free choice. Arch has also recently moved to systemd as its default init system which was in fact a reasonably simple process to convert to from initscripts - (it took about 10 minutes once you had read the documentation!) - the advantage for arch users is that systemd is the latest upstream or pretty close to - whereas systemd for F16 is somewhat behind current upstream. I guess that there is likely to always be a split in opinion of the developers whenever there is a major fork in philosophy options possible for which way to go in the future - but in the end one way or another a decision must be taken when everyone's views have been considered - for an established distribution there is often inertia against change - and many will see the change as needing more work than people feel may be possible - nevertheless in this case demonstrably archlinux works - so it is certainly possible to have a rolling release model and it already exists.It is simply a philosophy choice as to which model to work with. As to whether Fedora would wish to change or not is entirely up to those who do the hard work writing code and keeping all the tools and packages in working order. So such discussions as in this thread are important - and at the end of the day people doing the developing need to be on board with the philosophy of the distribution or work where they feel comfortable. There have been long discussions previously and at that time the consensus was to keep the status quo - I guess people will continue to per
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, Nov 03, 2012 at 11:11:18 -0600, Kevin Fenzi wrote: In any case, I think we do need to look at release cycle changes or at the very least Feature process revamp. And get comments from other than developers. Marketting might have serious concerns about the loss of exposure not having releases would result in. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 03.11.2012 19:17, Alek Paunov wrote: Adam, I think that the current "rolling release" discussion as many other "high interest" general ones in the recent months are pointless without some form of explicit definition and statistics of the current (and desired) distinct Fedora user profiles. Just because I said "general ones" which might be somewhat misleading, several examples: * The importance of Secure Boot workaround (in the proposed form) * The amount of the negative impact of /tmp on ramfs feature * The importance of a "Software Center" existence etc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 03.11.2012 18:26, Adam Williamson wrote: On Sat, 2012-11-03 at 10:52 +0100, drago01 wrote: Eh? That's not what I said at all. What I said was that I think in a well-managed rolling release model, users would actually run into trouble only about as often as they already do anyway. I don't mean they'd only get updates every six months, I mean they'd only get updates which _broke stuff_ on average every six months. Or less. Adam, I think that the current "rolling release" discussion as many other "high interest" general ones in the recent months are pointless without some form of explicit definition and statistics of the current (and desired) distinct Fedora user profiles. You mostly talk about the uncle Bob's profile (witch is the 2nd most present profile across the forums); Our vocal member Reinald belongs to one of the psychological subtypes of the "mad sysadmin" profile; Tom, which said yesterday that he would not be interested in rolling Fedora, into third profile, etc. BTW, personally I think, the uncle Bob profile currently most suffers the lack of the real package manager interface (at least under Gnome, I do not have a clue for KDE) - I see this issue as one with even high priority for uncle Bob than the lack of smooth upgrade scenario. So, my concrete proposal is to postpone all general discussions for a little, up to the moment when we describe as much as possible in detail let's say 16 Fedora user profiles and sub-profiles (at least on the wiki) and estimate somehow their population (may be along with the project leaders concept about the profiles witch Fedora actually is intended to seek for). Without any data at hand to back the prioritization and approach variant efficiency/suitability claims, I think it looks impossible to be achieved any level of consensus (especially in that list, as you know far better than me). Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 03 Nov 2012 09:26:43 -0700 Adam Williamson wrote: > I don't think rolling release and getting work done are incompatible. > As I mentioned, I run Branched permanently on my desktop - so it > rolls from 'pre-Alpha' state through to 'stable' state briefly and > then back to 'pre-Alpha' again, on a constant loop - and I do almost > all my work on that. We could build a light rolling-release distro > that was substantially more reliable than that. But I think that might be a non representative case. Before branched happens currently you get all the stuff like: Mass rebuilds, major upgrades that take a bunch of work to get all done, etc. So, you might not be considering them in your view above... but if we were rolling then you would have to deal with new boost, or png changing, or rpm format changing, etc, and there is seldom a way to cut these up into smaller bits. So, in a rolling release when say png changes, we would have to push all that change out to users in a big chud. They would have to do them somewhat quickly if they wanted any updates that would be depending on it/behind it. > Again, my fundamental > point is that we could achieve a sufficient level of reliability for > Fedora's purposes - the same level of reliability we currently > achieve, which I think the kinds of people we're talking about are > happy with - on a lighter release model than 'do a "stable release" > every six months come hell or high water' or 'three-track rolling, > Debian style, with a very slow-moving "stable" track'. I'm not convinced. ;) In any case, I think we do need to look at release cycle changes or at the very least Feature process revamp. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Am 03.11.2012 15:38, schrieb Emmanuel Seyman: > * "Jóhann B. Guðmundsson" [02/11/2012 20:34] : >> >> That package would hardly be un-maintained if it has co-maintainers >> now does it... > > Absolutely. Hence my request that any process we put in place be > package-focused rather than maintainer-focused why? how will you do this? if there is nothing to change on a apckage it is at it is if any maintainer not login he is INACTIVE if a package has more maintainers it is no problem retire the inactive maintainer if a package has only one maintainer and he is gone away the package has to be retired signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Am 03.11.2012 11:35, schrieb Nikos Roussos: > In that sense, and from my point of view, if we had to rethink our release > model and dedicate time and energy on a > new approach, it would make more sense to have an extended support release > (providing only security updates after > 13 months) which is vital for the enterprise desktop market. THAT would make sense if there is a upgrade path between two LTS releases - let's say the cycle is two years there would be 4 "normal" release cycles and if features with the impact of systemd are startet after the release of a LTS you have the full 2 years to polish it AND many users would also use the current leading edge releases to be first a comination of both would be really perfect signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Am 03.11.2012 01:09, schrieb Adam Williamson: > On Sat, 2012-11-03 at 01:07 +0100, Reindl Harald wrote: >> Am 03.11.2012 00:58, schrieb Adam Williamson: >>> Microsoft don't really expect you to upgrade Windows. They expect you to >>> buy a computer with Windows X on it, use it for three years, then throw >>> it away and buy a new computer with Windows Y on it. Red Hat expects >>> something similar for RHEL - they don't expect people to upgrade systems >>> from RHEL 5 to RHEL 6 on the fly. Corporations spend *years* planning OS >>> migrations, which usually involve buying new hardware, not upgrading >>> existing systems. This is an implicit acknowledgment that upgrades are >>> just not a great way to do things. I don't think we can realistically >>> expect Fedora to do it massively better. If you're going to do stable >>> releases of your operating system, it just doesn't make a lot of sense >>> to make people upgrade every twelve months. If you're going to have >>> stable releases, you should maintain them long enough that people don't >>> really rely on the upgrade function. That seems to be how the big boys >>> do it. If we can't do that, are the stable releases really achieving >>> much? >> >> look below, i prove you the opposite > > Please keep in mind the overall argument I'm making here. I'm not > interested in trivial point-scoring. I have machines that have been > upgraded for a long time too. Your mail doesn't really speak to the > higher level questions here the overall argument of MINE is Fedora IS stable Fedora CAN be upgraded Fedora has a good overall level of upgrades these things have to be improved and not thrown away by "we are doing it not good enough, so we stop doing it" and i am sure one big improvement would be to relax the meaning of a release-date, often it is OK and there are no large blockers, sometimes it is not so easy at that is the time where free software without marketing bullshit have the valif option to say WE DELAY THE NEXT VERSION TO A UNKNOWN POINT IN TIME IT WILL HAPPEN WHEN IT IS READY FOR IT in the meantime the current release would be maintained only with real important updates like security as it is done for F17/F17 now and ALL users would be happy signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 2012-11-03 at 09:37 -0200, Henrique Junior wrote: > The guys behind openSUSE created a good approach with Tumbleweed. By > adding this repo users can opt-in to the (semi)rolling model. > Tumbleweed is more like a pool where updated, stable, non disruptive > software can be installed and I was able to talk to the guy who > created Tumbleweed some time ago. He said that it is easy to maintain > and takes only a few minutes a day to check things. > It is difficult, for example, to understand why we have to wait until > the next release to have LibreOffice 3.6, since this seems an non > disruptive update that could bring major improvements in the > productivity of users who rely on office suites to work. I don't think that *adding* tracks is an approach that is going to solve any of our problems, though it might add convenience for a small set of users. We need to be making things simpler, not more complex. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 2012-11-03 at 11:28 +, mike cloaked wrote: > Others may wish to compare Fedora with other distributions also - but > one thought I had was that in Archlinux there are only two repos to > maintain - whilst in Fedora it is 5 repos! One might wonder whether > there is less effort needed to keep up to date by the developers in > Arch or Fedora - I don't have the answer to that question but the devs > have more knowledge about effort needed to maintain all of this to > make a proper comparison? Thanks, Mike, that's a great illustration of the point I was trying to make: the Arch model sounds much like what I was trying to suggest for Fedora, a simple two-track 'devel' and 'stable' model with QA between the tracks. And as you point out, on the face of it it appears to involve much less drudgery for maintainers. I have never run Arch, but I do get the general impression it provides a sufficiently reliable experience for the kinds of users Fedora and Arch have. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 2012-11-03 at 10:52 +0100, drago01 wrote: > On Sat, Nov 3, 2012 at 12:58 AM, Adam Williamson wrote: > > My position is that the people who use Fedora and the kind of people we > > really _want_ to use Fedora can cope with it. > > Maybe the majority can maybe they can't. But as evident by this thread > even fedora *developers* don't want to deal with such stuff. I think some of them were rather misunderstanding my point and my suggestion, which was my fault for phrasing my initial mail in an overly negative way (that I didn't realize until I read it back). > But rather get work done. Do you really think that users are that much > different? I don't think rolling release and getting work done are incompatible. As I mentioned, I run Branched permanently on my desktop - so it rolls from 'pre-Alpha' state through to 'stable' state briefly and then back to 'pre-Alpha' again, on a constant loop - and I do almost all my work on that. We could build a light rolling-release distro that was substantially more reliable than that. Again, my fundamental point is that we could achieve a sufficient level of reliability for Fedora's purposes - the same level of reliability we currently achieve, which I think the kinds of people we're talking about are happy with - on a lighter release model than 'do a "stable release" every six months come hell or high water' or 'three-track rolling, Debian style, with a very slow-moving "stable" track'. > > Remember, I'm not > > proposing it be as bad as Rawhide; we have the whole Bodhi karma process > > to work with. I think it's plausible to design a process where people > > only rarely have trouble with updates, even ones that are theoretically > > pretty messy; about the same frequency they'd have had trouble with > > upgrading our stable releases. > > That basically means you don't release anything and just release a > huge update every six months. Don't really see what this gains us > other then installation becoming an untested path. > The installation process and images have to be up2date though to be > able to deal with current hardware. Eh? That's not what I said at all. What I said was that I think in a well-managed rolling release model, users would actually run into trouble only about as often as they already do anyway. I don't mean they'd only get updates every six months, I mean they'd only get updates which _broke stuff_ on average every six months. Or less. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any issue with fedpkg new-sources?
On Sat, Nov 03, 2012 at 09:41:05 -0500, Bruno Wolff III wrote: On Sat, Nov 03, 2012 at 09:29:07 -0500, Bruno Wolff III wrote: Hans and I have been having a problem uploading the source for the new version of hegdewars to the lookaside cache. There is some initial network traffic, but then things hang. Has anybody successfully uploaded a new file to the lookaside cache in about the last 12 hours? It looks like there was an issue with a bad version of nss that got into updates-testing and probably rawhide. I've been advised to try an older version. With a downgraded version of nss it now works with rawhide. For f18 the bad version has been pulled from updates-testing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any issue with fedpkg new-sources?
On Sat, Nov 03, 2012 at 09:29:07 -0500, Bruno Wolff III wrote: Hans and I have been having a problem uploading the source for the new version of hegdewars to the lookaside cache. There is some initial network traffic, but then things hang. Has anybody successfully uploaded a new file to the lookaside cache in about the last 12 hours? It looks like there was an issue with a bad version of nss that got into updates-testing and probably rawhide. I've been advised to try an older version. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
* "Jóhann B. Guðmundsson" [02/11/2012 20:34] : > > That package would hardly be un-maintained if it has co-maintainers > now does it... Absolutely. Hence my request that any process we put in place be package-focused rather than maintainer-focused. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any issue with fedpkg new-sources?
* Bruno Wolff III [03/11/2012 15:30] : > > Has anybody successfully uploaded a new file to the lookaside cache > in about the last 12 hours? Uploaded Queue-DBI-2.5.0.tar.gz just now. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Any issue with fedpkg new-sources?
Hans and I have been having a problem uploading the source for the new version of hegdewars to the lookaside cache. There is some initial network traffic, but then things hang. Has anybody successfully uploaded a new file to the lookaside cache in about the last 12 hours? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, Nov 03, 2012 at 12:35:08PM +0200, Nikos Roussos wrote: > I understand that "regular users" are not Fedora's main target, but it > is a general-purpose operating system in the sense that it can be used > by people who want to have a stable working environment with all the > latest things from the Open Source world. While "regular users" are not Fedora's main target, our target user base assumes a "general productivity user", including these characteristics: We expect the majority of users to be interested in a set of general productivity tasks. These tasks are usually non-technical in nature. They involve communication and the creation, storage, location, and viewing of content. They are common to both novice and experts alike, and we should deliver a platform that allows users to engage in these tasks without interruption or disruption. Which I think supports your position. (Leading edge, not bleeding edge.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, Nov 02, 2012 at 16:32:00 -0700, Adam Williamson wrote: On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote: In a rolling release model, everyone deals with foo-1.0 to foo-2.0, then a week later they deal with bar-1.0 to bar-2.0, then a week later they deal with monkeys-1.0 to monkeys-2.0...in a 'stable' release model, everyone gets to deal with foo, bar, monkeys and five hundred other changes all at once. Which is chaos on a stick. A key difference though is that with actual releases people can do the upgrade at a good time for them to do it. With a rolling release bad things can happen at especially inconvenient time. I'd rather see us do a better job with rawhide so that more people use it and a better job at making upgrades go smoother so that people just trying to get stuff done with Fedora have a better experience. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-18 Branched report: 20121103 changes
Compose started at Sat Nov 3 09:15:19 UTC 2012 Broken deps for x86_64 -- [dhcp-forwarder] dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl [dnf] dnf-0.2.14-2.git4831982.fc18.noarch requires python-hawkey >= 0:0.3.0 [dustmite] dustmite-1-5.20120304gitcde46e0.fc17.x86_64 requires libphobos-ldc.so.59()(64bit) [func] func-0.28-1.fc17.noarch requires smolt [gcc-python-plugin] gcc-python2-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python2-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python3-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python3-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 [gdb-heap] gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15 [gnome-do-plugins] gnome-do-plugins-banshee-0.8.4-10.fc18.x86_64 requires mono(Banshee.CollectionIndexer) = 0:2.4.0.0 [gnome-shell-theme-selene] gnome-shell-theme-selene-3.4.0-5.fc18.noarch requires gnome-shell-extensions-user-theme [ip-sentinel] ip-sentinel-upstart-0.12-1303.fc18.noarch requires /sbin/initctl [libsyncml] 1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8 1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit) [mapserver] mapserver-perl-6.0.1-5.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) [milter-greylist] milter-greylist-upstart-4.2.7-1701.fc18.noarch requires /sbin/initctl [mod_pubcookie] mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [openvrml] libopenvrml-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-xembed-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-xembed-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-xembed-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [perl-Hardware-Verilog-Parser] perl-Hardware-Verilog-Parser-0.13-9.fc17.noarch requires perl(:MODULE_COMPAT_5.14.2) [perl-OpenOffice-UNO] perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) [presence] presence-0.4.6-2.fc18.x86_64 requires libcogl.so.9()(64bit) [pyfuzzy] pyfuzzy-0.1.0-5.fc18.noarch requires antlr3-python [reciteword] reciteword-0.8.4-10.fc18.x86_64 requires esound [resource-agents] resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumbgpl.so.2()(64bit) resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumb.so.2()(64bit) [ruby-revolution] ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires libedataserver-1.2.so.16()(64bit) ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires libecal-1.2.so.12()(64bit) ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires libebook-1.2.so.13()(64bit) [rubygem-activeldap] rubygem-activeldap-1.2.2-3.fc17.noarch requires rubygem(gettext_activerecord) >= 0:2.1.0 rubygem-activeldap-1.2.2-3.fc17.noarch requires ruby(abi) = 0:1.8 [rubygem-calendar_date_select] rubygem-calendar_date
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, Nov 3, 2012 at 12:37 PM, Henrique Junior wrote: > It is difficult, for example, to understand why we have to wait until the > next release to have LibreOffice 3.6, since this seems an non disruptive > update that could bring major improvements in the productivity of users who > rely on office suites to work. Well that's because we do not make a clear distinction between "operating system" and applications. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, Nov 2, 2012 at 10:31 PM, Kevin Fenzi wrote: > On Fri, 02 Nov 2012 15:17:02 -0700 > Adam Williamson wrote: > > ..snip... > > In my experience, in the last few years, Fedora stable releases have > become much more stable. My "stable" boxes here at home I have not > really had to poke at since I upgraded them to Fedora 17. I apply > updates every few days and things keep working along fine. > > In previous cycles there were some real nasty brown paper bag type > blowups that required me to do things to downgrade or tweak to keep my > stable version working, that (knock on wood) hasn't happened in f16/f17 > in my experence. > > I realize there are bugs and problems that hit, but I think the stable > updates policy has helped keep those down. (Cue KevinK to come in and > shout and tell me how wrong I am, etc etc) > > I'm personally -1 to any kind of rolling release beyond rawhide. > > There are distributions where a rolling release works very well indeed. Perhaps I could inject a couple of lines to think about since I use both Fedora and Archlinux: In Fedora what is maintained are 1) Two current releases with stable updates repos for each. 2) Updates-testing repos for both current stable releases and 3) Rawhide where volunteer users can expect potential major breakages periodically. That is five repos of packages. In Fedora to keep up to date users need a complete re-install either every year or every six months on every machine that runs Fedora. In Archlinux there are two repos - [core] and [testing] - once packages have been QA tested in [testing] then developers can move packages to [core] when they feel there is minimal risk of major failure for users of the stable repos. In Archlinux to keep up to date users need never do a full re-install again - but there are occasional periods when configs need to be tinkered with or manual commands entered as root when a major package upgrade takes place such as glibc or one or two major packages but this is only occasional. Provided users keep monitoring the news announcements where manual intervention is required then they have a system where virtually all major packages are upstream current or close to that. A complete re-install takes some hours for each machine (or indeed a yum preupgrade or similar as well) - manual intervention for the occasional major update to packages in arch linux takes some minutes usually at most. For users responsible for a significant number of machines having a rolling release knowing that all major packages are upstream current or close to that is a major advantage, and time saving, compared to Fedora's need for major upgrade of the system or re-install. Fedora is a bit simpler to install for less experienced users but for experienced linux admins an arch install is not a major issue. Both Fedora and Archnlinux are generally cutting edge if they are kept updated - but the effort to keep updated is very different. Others may wish to compare Fedora with other distributions also - but one thought I had was that in Archlinux there are only two repos to maintain - whilst in Fedora it is 5 repos! One might wonder whether there is less effort needed to keep up to date by the developers in Arch or Fedora - I don't have the answer to that question but the devs have more knowledge about effort needed to maintain all of this to make a proper comparison? Some discussion and thought about these issues are pertinent to the discussion in this thread. -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, 2012-11-02 at 13:22 -0700, Adam Williamson wrote: > > I disagree with that. Fedora releases had some small regression > > introduced via updates from time but is is *very* usable as a stable > > operating system. > > I disagree. It's usable by the kind of people who use Fedora. Who like > shiny cutting-edge stuff and don't mind dealing with wonkiness > constantly. I mind. So do many Fedora users and contributors, who want a shiny *stable* leading edge (not bleeding edge) linux distribution. > I wouldn't dream of putting any regular person on a Fedora > install, quite frankly. It's easy to get into a perspective bubble where > Fedora looks normal, but it isn't. It is not a stable general-purpose > operating system and it's absurd to represent it as such. I understand that "regular users" are not Fedora's main target, but it is a general-purpose operating system in the sense that it can be used by people who want to have a stable working environment with all the latest things from the Open Source world. In that sense, and from my point of view, if we had to rethink our release model and dedicate time and energy on a new approach, it would make more sense to have an extended support release (providing only security updates after 13 months) which is vital for the enterprise desktop market. Of course this is not in contradiction with having a rolling release model alongside, but I didn't know if we have enough human capacity to do them both. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, Nov 3, 2012 at 12:58 AM, Adam Williamson wrote: > My position is that the people who use Fedora and the kind of people we > really _want_ to use Fedora can cope with it. Maybe the majority can maybe they can't. But as evident by this thread even fedora *developers* don't want to deal with such stuff. But rather get work done. Do you really think that users are that much different? > Remember, I'm not > proposing it be as bad as Rawhide; we have the whole Bodhi karma process > to work with. I think it's plausible to design a process where people > only rarely have trouble with updates, even ones that are theoretically > pretty messy; about the same frequency they'd have had trouble with > upgrading our stable releases. That basically means you don't release anything and just release a huge update every six months. Don't really see what this gains us other then installation becoming an untested path. The installation process and images have to be up2date though to be able to deal with current hardware. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revamping the non responsive maintainer process
- Original Message - > From: "Jóhann B. Guðmundsson" > To: devel@lists.fedoraproject.org > Sent: Friday, November 2, 2012 9:20:05 PM > Subject: Re: Revamping the non responsive maintainer process > > On 11/02/2012 06:27 PM, Aleksandar Kurtakov wrote: > > Wrong. Do you know how few of the problems we see in Eclipse land > > don't need fixes upstreams? And some of these issues require > > man/months (years sometimes) upstream before there is smth to show > > in Fedora. Don't make your assumptions based on that. So if one > > logs in every few months to take a look at the number of bugs > > (nothing more) he is active but one that does fixes upstream for > > months before putting into Fedora is not. You see there is no > > black and white here! > > Then that individual would simply log in or perform some other action > to > get him off that list... > > > Plus, did you intentionally skipped the part about being active on > > A but not on B ? So if one does a good job of maintaining 9 > > packages but doesn't do it for 1 because he/she is overloaded we > > should dump him? And please don't tell me that a good maintainer > > would not do that because many of us don't know the count(not the > > names) of the things they are responsible for so it's more than > > easier for a component to goes unnoticed. > > No I simply assumed that he would have logged in to fiddle with one > or > more packages he owns and or is responsible for which would clearly > mark > him *active*. > > I know my English sucks on a good day but i thought it was clear I > was > speaking of checking logins in our infrastructure not *packages* or > number of packages* maintainer might maintain since that's totally > irrelevant and just brings unnecessary complication to the equation > from > my pov... > > Instead of people constant bringing up hypothetical solution while we > have plethora of unmaintained rotten packages in our repos why dont > you > try to come up with or propose an alternative solution to the problem > at > hand... I already wrote it: All of this was to show that whatever policy might be chosen it should be PER PROJECT/PACKAGE not per maintainer. The whole idea of non-responsive maintainer is nonsense. A person that does one thing in a year is still more valuable than a hundred of freeloaders - because he/she actually did one thing. We ship packages so every action should be per package and not per person! Alexander Kurtakov Red Hat Eclipse team > > JBG > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/03/2012 08:17 AM, Michael Scherer wrote: Le samedi 03 novembre 2012 à 11:19 +0530, Rahul Sundaram a écrit : On Fri, Nov 2, 2012 at 10:25 PM, Reindl Harald wrote: well, it would maybe a start to DROP packages which are still missing systemd-units http://fedoraproject.org/wiki/Releases/18/FeatureList 60% SysV to Systemd Dropping 40% of packages isn't going to happen. Sorry Especially since some of those packages may have more complex initscript than a simple systemd unit can produce. For example, on my system, ceph, netcf-transaction or libvirt-guests are more complex initscripts, and I could understand why they were not migrated by now. Yeah upstream often is working making some other changes surrounding the unit and the daemon + nobody said or promised this was going to be migrated within one release cycle anyway Reindl Harald just likes to make a fuzz... And people should not be staring to much into the % they do not always accurately reflect the feature completeness... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Le samedi 03 novembre 2012 à 11:19 +0530, Rahul Sundaram a écrit : > > > On Fri, Nov 2, 2012 at 10:25 PM, Reindl Harald wrote: > well, it would maybe a start to DROP packages which are still > missing systemd-units > > http://fedoraproject.org/wiki/Releases/18/FeatureList > > 60% > SysV to Systemd > > Dropping 40% of packages isn't going to happen. Sorry Especially since some of those packages may have more complex initscript than a simple systemd unit can produce. For example, on my system, ceph, netcf-transaction or libvirt-guests are more complex initscripts, and I could understand why they were not migrated by now. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
