Re: how to withdraw glusterfs from epel?
- Original Message -
From: Kaleb S. KEITHLEY kkeit...@redhat.com
To: devel@lists.fedoraproject.org
Sent: Friday, October 18, 2013 10:30:53 AM
Subject: Re: how to withdraw glusterfs from epel?
On 10/18/2013 10:09 AM, Frank Murphy wrote:
On Fri, 18 Oct 2013 10:03:28 -0400
Kaleb S. KEITHLEY kkeit...@redhat.com wrote:
Okay, I'm okay with that. How about instead of a /etc/yum.repos.d/
file if it's a /usr/share/doc/glusterfs.README containing
instructions for how to use the community GlusterFS yum repo?
Are you allowed make a people repo?
http://repos.fedorapeople.org/repos/
Like http://repos.fedorapeople.org/repos/kkeithle?
That's not what I want.
My vision is to make it easy for (RH)EL users to find glusterfs. I
already experience lots of people who don't/can't find the repos we
already have on download.gluster.org or even my old fedorapeople.org repos.
People install Fedora, yum {install,search} glusterfs, they're golden.
Right now people who install RHEL (or CentOS), add EPEL, yum install
glusterfs, and get an outdated version of glusterfs (reasons it's
outdated already given previously). They're not golden.
Soon, if I have to fully withdraw glusterfs from EPEL, they'll install
and get the client side gluster bits from the base RHEL channel. They're
semi-golden.
But I think it's be a good thing if they did a yum search and saw a
glusterfs-community-doc package (containing the README) that that would
be a reasonable alternative to thinking they were stuck with only client
side or nothing.
Or I just withdraw it completely and RHEL users will live mostly in the
dark until they find the community YUM repos by chance. (But I will add
that the nice people at CentOS are bending over backwards to add it to
their centos-extras repo and CentOS users who are looking for glusterfs
will have, IMO, a much nicer experience.)
Would it be against the guidelines to move to packaging it (the software
itself, not a repo file) in Fedora/EPEL as glusterfs-community?
Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf installs cron.hourly
- Original Message - From: Daniel P. Berrange berra...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 15, 2013 11:48:41 AM Subject: Re: dnf installs cron.hourly On Fri, Mar 15, 2013 at 10:45:03AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default That's about starting system services by default though, so isn't directly relevant to the question of whether cron jobs are allowed to be enabled by default. Do we have any package docs about cron job enablement ? I couldn't find any in my search attempts. Daniel The list of files sitting in my /etc/cron.*/ directories would certainly indicate that even if there is such a rule it is being ignored. Not that I necessarily have a problem with that given the jobs that are there (mlocate, cups, logrotate, man-db are all examples I don't remember setting up myself). Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
- Original Message - From: seth vidal skvi...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: sgor...@redhat.com Sent: Friday, March 15, 2013 12:07:00 PM Subject: Re: dnf installs cron.hourly On Fri, 15 Mar 2013 11:58:33 -0400 (EDT) Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Daniel P. Berrange berra...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 15, 2013 11:48:41 AM Subject: Re: dnf installs cron.hourly On Fri, Mar 15, 2013 at 10:45:03AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default That's about starting system services by default though, so isn't directly relevant to the question of whether cron jobs are allowed to be enabled by default. Do we have any package docs about cron job enablement ? I couldn't find any in my search attempts. Daniel The list of files sitting in my /etc/cron.*/ directories would certainly indicate that even if there is such a rule it is being ignored. Not that I necessarily have a problem with that given the jobs that are there (mlocate, cups, logrotate, man-db are all examples I don't remember setting up myself). To be fair - none of those call out to the network. they all act on things locally. Right, but the packaging guidelines don't seem to mention whether you should enable cron jobs in packages by default (or not) at all - let alone provide enough detail to specify what types of jobs it's appropriate for. I'd agree with Jon's comment that there is probably some clarification required in the guidelines here. Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
- Original Message - From: Neal Becker ndbeck...@gmail.com To: devel@lists.fedoraproject.org Sent: Tuesday, May 29, 2012 4:42:30 PM Subject: another upgrade, another disaster [SNIP] On reboot, I found a huge mess. Duplicate packages (f16/f17) all over. I did the upgrade using yum and ended up with the same end result. The steps to prepare the /usr split worked fine but when I brought the system back up after all was said and done I found I had both fc16 and fc17 versions of most if not all packages. So, 1) Could I have actually recovered from this mess without a complete re-install? I eventually hit it with a hammer and did yum remove '*fc16*', when I reviewed the resultant transaction there were a handful of fc17 packages also removed as a result of dependencies but these were easily installed again, pulling in their fc17 dependencies instead. At this point I now appear to have a stable system and everything working, we'll see how long that lasts for though ;). 2) Can't we make the install fail more gracefully? 3) Would it be possible to continue an failed install, and have it actually work? -- 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: another upgrade, another disaster
- Original Message - From: Przemek Klosowski przemek.klosow...@nist.gov To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, May 29, 2012 4:58:35 PM Subject: Re: another upgrade, another disaster On 05/29/2012 04:50 PM, Kevin Fenzi wrote: 1) Could I have actually recovered from this mess without a complete re-install? Sure. Confirm the correct repos were enabled, 'yum distro-sync' and work through any dep issues that show up. I think they changed it to 'yum distribution-sychronization'. Both are still valid. Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
- Original Message - From: Steve Clark scl...@netwolves.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, February 16, 2012 6:47:03 AM Subject: Re: /usrmove? - about the future On 02/15/2012 10:34 PM, Matthew Garrett wrote: On Wed, Feb 15, 2012 at 07:23:24PM -0500, Steve Clark wrote: On 02/15/2012 05:19 PM, mike cloaked wrote: I use bash completion all the time every single day - I guess I have become a corner case! No you haven't. All the developers I have worked with since the early nineties use it all the time every day. We would be lost without it. You may have been working with them since the earliy nineties, but the feature was only introduced in 2.04 in 2000. Programmable completion is fairly modern compared to the rest of bash... bash 1.14 used readline which had completions. Circa 1994. Thank you very much. And yet still, has nothing at all to do with the bash-completion package being discussed here. Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Friday, February 10, 2012 10:43:07 AM Subject: Re: /usrmove? - about the future Am 10.02.2012 16:06, schrieb Peter Hutterer: On Fri, Feb 10, 2012 at 01:13:13PM +0100, Reindl Harald wrote: POSSIBLE SOLUTION: each second release does not introduzce those big changes and only optimize existing things and bringing only new versions of packages require a simple mass rebuild for so-changes you can call it F17, F17.5 where F17 have a big chnage affecting the whole distribution and F17.5 is only a careful upgrade without intention to break stuff and require actions from all involved people take away the current pressure from maintainers as well users give the involved people time to breath this is opensource, there is NO SINGLE NEED to implement any possible good idea under pressure NOW and beeing first only for beeing first is not always the right hting I think this would increase the pressure to push unpolished features into the distribution. Allowing big feature changes only every two releases means that the waiting time should the feature not get merged is 12 months. For some features that's quite unacceptable. So the likely effect is that these features will be called ready whenever they need to be (according to the process) with the rest simply called optimizing. if people do not care the can destroy every process if someone calls repeatly non-ready features as ready he is the wrong person for any sort of decision maybe the project should get rid of some people who do not care or guidelines which have the power to ENFORCE contributors or get rid of them yes this may sound hard but what is the alternative? burn down ressources with each relese more and more Hi, Where can I review your formal submission(s) for such improvements? Thanks, Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hi all, My name is Steve Gordon, I'm a content author by day but I also have previous experience as a developer (primarily Java and...COBOL...). My current interests are primarily in virtualization and cloud software. I already have a FAS account through my membership of the documentation group but I'm introducing myself to the devel group because I want to package aqemu (http://sourceforge.net/projects/aqemu/) for Fedora! I have some prior experience packaging software for my own use/re-use but this is the first time I've submitted anything in the hope of ultimately getting formal inclusion into a distribution. For what it's worth my package review request is: https://bugzilla.redhat.com/show_bug.cgi?id=734275 Thanks all! Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
