- Original Message -
> From: "drago01"
> To: "Development discussions related to Fedora"
>
> Sent: Monday, November 5, 2012 9:39:54 AM
> Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how
> to install into a LVM partitions (or
> RAID))
>
> On Mon, Nov 5, 2012
On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> El Wed, 31 Oct 2012 10:59:54 -0700
> Jesse Keating escribió:
>> On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
>> > * Jesse Keating, Jeremy Katz, and others who helped shape the
>> > curren
# Fedora Quality Assurance Meeting
# Date: 2012-11-05
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net
Greetings testers!
It's meeting time again tomorrow. Note the time 'change', now that
daylight savings has ended in Nort
On Mon, Nov 5, 2012 at 8:02 AM, Emmanuel Seyman wrote:
> * drago01 [05/11/2012 08:00] :
>>
>> That's like selling a car and telling the customer "it might not move
>> at all in that case you are on your own sorry".
>
> This is par the course for proprietary software (with the added bonus
> that yo
* drago01 [05/11/2012 08:00] :
>
> That's like selling a car and telling the customer "it might not move
> at all in that case you are on your own sorry".
This is par the course for proprietary software (with the added bonus
that you can't actually fix it since you don't have the source code).
Em
On Sun, Nov 4, 2012 at 6:55 PM, Adam Williamson wrote:
> On Sun, 2012-11-04 at 12:18 -0500, Simo Sorce wrote:
>> On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
>> > Hi,
>> >
>> > 2012/11/3 Adam Williamson :
>> > > Note
>> > > that neither Red Hat nor Microsoft actually support major v
Michael,
Without contributors there is no need for infrastructure, right? ;)
To me it means that we need more contributors working on infrastructure (as on
every other aspect of the distro) not pruning.
Alexander Kurtakov
Red Hat Eclipse team
- Original Message -
> From: "Michael Schere
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Wed, 31 Oct 2012 10:59:54 -0700
Jesse Keating escribió:
> On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
> > * Jesse Keating, Jeremy Katz, and others who helped shape the
> > current policy and theory of our release schedule felt that the 6
> > mon
On Fri, 02 Nov 2012 13:32:33 +, Richard W.M. Jones wrote:
> If you substitute 'unstable' for level 1, 'testing' for level 2 and
> 'stable' for level 3, then this is not dissimilar to how Debian
> operates.
Sure, and if you eliminate level 3 (which leads to multi-year-long
freezes), then you h
On Fri, 02 Nov 2012 13:22:21 -0700, Adam Williamson wrote:
> 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 wouldn't dream of putting any regular person on a Fedora
> install, quite frankly. It'
On Fri, 02 Nov 2012 20:55:38 +, Jóhann B. Guðmundsson wrote:
> and one "stable" release ( valid for 2 maybe 3 years ) for those in the
> community that want something they dont constantly having to upgrade to
> and can deploy on their servers. ( ofcourse to have a stable release we
> first and
On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann wrote:
>
> This is a very valid argument. I understand this is a devel list, so we
> should stay on the technical level, but if we discuss such broad changes
> that affect the whole project, we should also take into account other
> aspects.
>
> Switc
- Original Message -
> From: "Bruno Wolff III"
> To: "Kevin Fenzi"
> Cc: devel@lists.fedoraproject.org
> Sent: Saturday, November 3, 2012 7:37:45 PM
> Subject: Re: Rolling release model philosophy (was Re: Anaconda is totally
> trashing the F18 schedule (was Re: f18:
> how to install
Le dimanche 04 novembre 2012 à 13:19 -0500, Aleksandar Kurtakov a
écrit :
> The point is that such a measurement serves nothing but pissing off people.
> You need to track activity on packages - how long bugs stay open without
> response
> (note that this doesn't mean becoming accepted as one mig
i guess so and i am pretty sure i removed it because
problems with failing service starts and since named
works for many months with the systemd-unit below
on personal as also 4 production servers i can say
for sure that nobody needs this pid-files
they are mostly for old sysvinit-scripts because
Am 04.11.2012 19:26, schrieb Brown:
> And there's the creation of the pid file directories for both named and
> ddclient
> that seem to disappear every time I reboot, also seems like a bug somewhere
man tmpfiles.d
BTW:
all these packages should be fixed a long time ago
nearly no service needs
For microsoft perhaps, but Ubuntu, Debian ? Upgrading from a release
to the next is trivial, and in general work well. Sure, probably the
update to the core system component is more light, no Usrmove, no
systemd, or something like this. And preserving, updating the new
configuration based on the pr
Okay, So this is a package specific issue and both bind and ddclient need to
remove the PidFile directives in their systemd service configuration?
Thanks,
- David Brown
From: Reindl Harald [h.rei...@thelounge.net]
Sent: Sunday, November 04, 2012 10:36 AM
T
On 11/04/2012 04:50 PM, Denis Arnaud wrote:
> Date: Sun, 04 Nov 2012 14:07:02 +0100
> Simon Lukasik wrote:
>
>> Currently, each Fedora release is kept alive for 13(+/-) months. There
>> were dozens of threads about shortening or prolonging period -- but I am
>> not sure if something like the foll
Fellow Devs,
I know you guys are talking a lot about the Fedora 18 slip and who's to blame
etc. But I decided to upgrade most of my systems anyway, I'm not here to
complain I realize I get to keep the pieces and I'm smart enough to fix them
(and work around them) until things get settled down.
The point is that such a measurement serves nothing but pissing off people.
You need to track activity on packages - how long bugs stay open without
response (note that this doesn't mean becoming accepted as one might be busy
with other things), how long the package stay with open CVEs, what is t
On Sun, 2012-11-04 at 10:13 -0500, Matthew Miller wrote:
> On Sun, Nov 04, 2012 at 05:04:40PM +0200, Jonathan Dieter wrote:
> > Not necessarily commenting on whether this whole idea is good or not,
> > but how hard would it be to just have the N release and updates
> > repositories enabled at the s
On 11/04/2012 05:05 PM, Tom Lane wrote:
> Simon Lukasik writes:
>> Currently, each Fedora release is kept alive for 13(+/-) months. There
>> were dozens of threads about shortening or prolonging period -- but I am
>> not sure if something like the following has been ever discussed:
>
>> Each N-th
On Sun, 2012-11-04 at 12:18 -0500, Simo Sorce wrote:
> On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
> > Hi,
> >
> > 2012/11/3 Adam Williamson :
> > > Note
> > > that neither Red Hat nor Microsoft actually support major version
> > > upgrades for their operating systems
>
> Adam, th
On 04.11.2012 19:25, Simo Sorce wrote:
note that this is "also" our strength in some respect because it allows
the system to evolve a lot more quickly, but it also means upgrades are
Indeed.
simply going to break stuff, and that's not so great for desktop
environments and scare the hell off
On Sat, 2012-11-03 at 00:44 +0100, drago01 wrote:
> > much lower levels of churn,
>
> No they actually have way higher levels of churn ... just think about
> it ... in fedora we are talking about 6 months worth of chrun not 5+
> years. Can't speak for Red Hat but maybe this is one of the reasons
>
On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
> Hi,
>
> 2012/11/3 Adam Williamson :
> > Note
> > that neither Red Hat nor Microsoft actually support major version
> > upgrades for their operating systems
Adam, this is plainly untrue for Microsoft, they always supported
upgrading to
Am 04.11.2012 17:05, schrieb Tom Lane:
> Simon Lukasik writes:
>> Currently, each Fedora release is kept alive for 13(+/-) months. There
>> were dozens of threads about shortening or prolonging period -- but I am
>> not sure if something like the following has been ever discussed:
>
>> Each N-t
nobody here is screwing others work
teh topic is how about to find out AUTOMATICALLY which are
they doing the work and which things are orphaned without
finding it out the hard way in the running release cycle
and if you need to find out things automatically you need
any flag to measure - this wo
Simon Lukasik writes:
> Currently, each Fedora release is kept alive for 13(+/-) months. There
> were dozens of threads about shortening or prolonging period -- but I am
> not sure if something like the following has been ever discussed:
> Each N-th Fedora release -- where N%3==1 -- is alive for
Panu Matilainen writes:
> On 11/04/2012 12:17 PM, Michael Scherer wrote:
>> And I am doubting that changing the release model will suddenly make
>> people do QA.
> Adam's point is that reducing the number of branches requiring QA should
> permit more thorough QA with the scarce resources availab
Date: Sun, 04 Nov 2012 14:07:02 +0100
Simon Lukasik wrote:
> Currently, each Fedora release is kept alive for 13(+/-) months. There
> were dozens of threads about shortening or prolonging period -- but I am
> not sure if something like the following has been ever discussed:
> Each N-th Fedora rel
On Sun, Nov 04, 2012 at 05:04:40PM +0200, Jonathan Dieter wrote:
> > > - 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.
> > Spea
On Sun, 2012-11-04 at 09:21 -0500, Matthew Miller wrote:
> On Sat, Nov 03, 2012 at 06:32:20PM -0600, Kevin Fenzi wrote:
> > - 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 mi
On Sat, Nov 03, 2012 at 06:32:20PM -0600, Kevin Fenzi wrote:
> 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.
I did for years. On F18 right now, but I'm willing to go back to all Rawhide
all the time.
Here's some impo
Compose started at Sun Nov 4 08:15:11 UTC 2012
Broken deps for x86_64
--
[LabPlot]
LabPlot-1.6.0.2-12.fc18.i686 requires libaudiofile.so.0
LabPlot-1.6.0.2-12.fc18.x86_64 requires libaudiofile.so.0()(64bit)
[PyKDE]
PyK
On 11/03/2012 12:30 AM, Simo Sorce wrote:
> On Fri, 2012-11-02 at 16:04 -0700, Adam Williamson wrote:
>> * Upgrading every year, with an unreliable upgrade process, is not
>> something you have to do with a proper stable OS
>
> On some stable OSs you cannot upgrade *at all*. It is true that some O
Compose started at Sun Nov 4 09:15:51 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 >=
Le samedi 03 novembre 2012 à 18:32 -0600, Kevin Fenzi a écrit :
> 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 thi
On 11/04/2012 12:17 PM, Michael Scherer wrote:
Le samedi 03 novembre 2012 à 09:29 -0700, Adam Williamson a écrit :
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
Le samedi 03 novembre 2012 à 09:29 -0700, Adam Williamson a écrit :
> 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
On 11/04/2012 02:32 AM, 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 ti
How does it sound? Really like the right way to build community by excluding
people? Think about this more before trying to screw others work? Your feature
might mean nothing for someone else if you want to see it happen step in and do
your part and don't tell people that there work should be re
Hmm, actually I have new proposal.
Policy about active/inactive maintainers should be decided only by actual
maintainers. In the true meritocracy way - if you don't maintain anything you
don't have a say.
Alexander Kurtakov
Red Hat Eclipse team
- Original Message -
> From: "Reindl Hara
44 matches
Mail list logo
