Re: new setting for SYSFONT attribute

[Tomasz Torcz]

On Fri, Nov 02, 2012 at 01:19:54AM -0400, Anish Patil wrote:
> On fedora 17, system-config-language sets attributes LANG,SYSFONT in 
> /etc/sysconfig/i18n file.
> Fedora 18, i checked the locale.conf file which has only one attribute i.e 
> LANG.
> I would like to know where SYSFONT attribute is set and do 
> system-config-language needs to set that variable?

  /etc/vconsole.conf. It has a man page, too.

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 : broken configuration for httpd 2.4

[Remi Collet]

Le 01/11/2012 18:25, Jason L Tibbitts III a écrit :
> It would have been super nice to actually include a link in all of those
> bugs, or some reference.  I mean, they must have been filed by program,
> so it's not as if you would have had to do a bunch of extra typing.
> 
> We really need a "mass bug filing howto" or something.  Preferably
> starting with "Don't."

Have you notice than all this bugs depend on #871373 which provides some
useful information ?

Remi.
> 
>  - J<
> 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 : broken configuration for httpd 2.4

[Remi Collet]

Le 01/11/2012 18:25, Jason L Tibbitts III a écrit :
> It would have been super nice to actually include a link in all of those
> bugs, or some reference.  I mean, they must have been filed by program,
> so it's not as if you would have had to do a bunch of extra typing.

No, nothing automatic here.

I have analyzed all the /etc/httpd/config.d/*conf from the spec file,
the RPM sources or the upstream sources.

When I detect possible breakage I have open a bug manually.

Remember, this issue was raised in March/April... [1]

Yes probably, I could have do it in a better way...
(and probably earlier)


> We really need a "mass bug filing howto" or something.  Preferably
> starting with "Don't."

You're right, I should have avoid this mass bug filing.

But sorry, I just try to make Fedora better, and I think that ~60 broken
web apps is not good for our image.

Ok, next time, I will think twice before doing this, and prefer use my
time on "my" packages, and only mine.


Remi.


[1] http://lists.fedoraproject.org/pipermail/devel/2012-March/165058.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 : broken configuration for httpd 2.4

[Kushal Das]

On Tue, Oct 30, 2012 at 8:14 PM, Remi Collet  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 30/10/2012 15:14, Remi Collet a écrit :
>> So I open a tracker bug for this issues
>> https://bugzilla.redhat.com/show_bug.cgi?id=871373
>
> Finally : 60 open bugs.
>
Thanks for the bugs.

Kushal
-- 
http://fedoraproject.org
http://kushaldas.in
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [rhn-client-tools] Created tag rhn-client-tools-1.8.26-1.fc19

[Nicolas Chauvet]

Hi Miroslav,

It sounds like you are missing f18 branch while creating new build

Thx for the new spacewalk release!

Nicolas (kwizart)

2012/11/2 Miroslav Suchý 

> The unsigned tag 'rhn-client-tools-1.8.26-1.fc19' was created.
>
> Tagger: Miroslav Suchý 
> Date: Fri Nov 2 11:29:04 2012 +0100
>
> check CA cert files only when needed
>
> Changes since the last tag 'rhn-client-tools-1.7.14-1.fc18':
>
> Dennis Gilmore (1):
>   - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
>
> Miroslav Suchý (1):
>   Rebase to rhn-client-tools-1.8.26-1.fc17 in rawhide.
> --
> scm-commits mailing list
> scm-comm...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/scm-commits
-- 
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))

[Stanislav Ochotnicky]

Quoting Michael Cronenworth (2012-11-01 18:33:24)
> Adam Williamson wrote:
> > I didn't want to throw this grenade into the debate, but now someone
> > else has, I'll just note that I was in favour of this before and I'm
> > still in favour of it now. :) Rolling release is a model that makes
> > clear sense for a distribution with the goals that Fedora has.
> 
> I've wanted to write up a blog post about my plan for a rolling release,
> but I'll post a snip-it here.
> 
> Fedora Rawhide - stays as is... it is a rolling release
> 
> Fedora Feature - think of it as F18 beta right now
> 
> Fedora Stable - think of it as F16/F17 right now
> 
> People choose the branch level at install time. Of course, like now,
> people can override this in the future with a change of fedora-release
> or yum --releasever. However, per-package updates from another branch
> level might not be something everyone can agree on how to handle, so it
> might be wise to limit support of it at first.
> 
> Workflow:
> A shiny new feature is introduced in Rawhide. Things go boom. Not many
> people are hurt by this. Once it has been given a few band-aids the
> feature could be submitted to Fedora Feature. After some hardening and
> polishing the feature could finally be pushed to Fedora Stable.
> 
> I feel this should give a good compromise to everyone's fears of a
> rolling release. It gives the feature freaks a place in Fedora. It gives
> the stable stubborns a place in Fedora.
> 
> I'll wake up from my dream now.

I recently came up with similar 3-layer idea. My description was a bit
different, something like this:
1. level - rawhide-like repository, more or less anything goes
2. level - package moves here after maintainer says "this package has been
   working for me for some time and looks OK. Let's integrate properly
   with rest of the system".
3. level - packages integrated and experience should be splendid :-)

However let's see how we'd handle systemd change with this system:
1. level - Lennart packages systemd, plays around with it. FESCO accepts systemd
   as worthy FEATURE for future stable (3rd level). Packages interacting
   with init system can take their time updating. 
2. level - systemd moves here. After this point, packages moving from 1st level
   here, will have to support systemd. Experience will likely be shaky
   for a time, then settle down. 
3. level - after some time (1 year, 2 years?) systemd moves here and all
   packages that have been fixed to work with it as well

There are several problems with this approach though:
1. There are always multiple big changes happening in fedora. So even stable
   would see big updates on relatively frequent basis. 
2. Several big changes will interact with each other. I.e. Gnome update will
   contain some daemons so they'd have to integrate with systemd on 2nd level.
   But then Gnome couldn't go into 3rd level before systemd.
3...x. a long list of further problems

I am hopeful that we could make this work. Would anyone be willing to do
analysis like this for multiple updates and play devil's advocate as well?
Ideally trying to see how we could create processes to handle updates of the
last 1-2 years? Because all I could come up with is: we'd end up like Debian,
where stable is...ancient. Not that that is bad in itself if you can pick. 

-- 
Stanislav Ochotnicky 
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 : broken configuration for httpd 2.4

[Jóhann B. Guðmundsson]

On 11/01/2012 05:25 PM, Jason L Tibbitts III wrote:

It would have been super nice to actually include a link in all of those
bugs, or some reference.  I mean, they must have been filed by program,
so it's not as if you would have had to do a bunch of extra typing.


Most of us do this actually manually.


We really need a "mass bug filing howto" or something.  Preferably
starting with "Don't."


The proper way to do this is exactly what Remi did as in create a 
tracker bug then have all the relevant bugs  block that tracker bug and 
you just monitor that tracker bug.


The above is the standard practice within the community...

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))

[Ian Malone]

On 1 November 2012 17:33, Michael Cronenworth  wrote:
> Adam Williamson wrote:
>> I didn't want to throw this grenade into the debate, but now someone
>> else has, I'll just note that I was in favour of this before and I'm
>> still in favour of it now. :) Rolling release is a model that makes
>> clear sense for a distribution with the goals that Fedora has.
>
> I've wanted to write up a blog post about my plan for a rolling release,
> but I'll post a snip-it here.
>
> Fedora Rawhide - stays as is... it is a rolling release
>
> Fedora Feature - think of it as F18 beta right now
>
> Fedora Stable - think of it as F16/F17 right now
>
> People choose the branch level at install time. Of course, like now,
> people can override this in the future with a change of fedora-release
> or yum --releasever. However, per-package updates from another branch
> level might not be something everyone can agree on how to handle, so it
> might be wise to limit support of it at first.
>
> Workflow:
> A shiny new feature is introduced in Rawhide. Things go boom. Not many
> people are hurt by this. Once it has been given a few band-aids the
> feature could be submitted to Fedora Feature. After some hardening and
> polishing the feature could finally be pushed to Fedora Stable.
>

How does this work with things like Anaconda? In a rolling model
(assuming you can do other major upgrades without reinstalling, if not
there's less point anyway), people aren't going to be reinstalling so
it could easily trickle through to stable before getting serious use.

How does it work with major changes like UsrMove? It might never have
been done...

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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]

On 11/02/2012 10:55 AM, Stanislav Ochotnicky wrote:

Quoting Michael Cronenworth (2012-11-01 18:33:24)

Adam Williamson wrote:

I didn't want to throw this grenade into the debate, but now someone
else has, I'll just note that I was in favour of this before and I'm
still in favour of it now. :) Rolling release is a model that makes
clear sense for a distribution with the goals that Fedora has.

I've wanted to write up a blog post about my plan for a rolling release,
but I'll post a snip-it here.

Fedora Rawhide - stays as is... it is a rolling release

Fedora Feature - think of it as F18 beta right now

Fedora Stable - think of it as F16/F17 right now

People choose the branch level at install time. Of course, like now,
people can override this in the future with a change of fedora-release
or yum --releasever. However, per-package updates from another branch
level might not be something everyone can agree on how to handle, so it
might be wise to limit support of it at first.

Workflow:
A shiny new feature is introduced in Rawhide. Things go boom. Not many
people are hurt by this. Once it has been given a few band-aids the
feature could be submitted to Fedora Feature. After some hardening and
polishing the feature could finally be pushed to Fedora Stable.

I feel this should give a good compromise to everyone's fears of a
rolling release. It gives the feature freaks a place in Fedora. It gives
the stable stubborns a place in Fedora.

I'll wake up from my dream now.

I recently came up with similar 3-layer idea. My description was a bit
different, something like this:
1. level - rawhide-like repository, more or less anything goes
2. level - package moves here after maintainer says "this package has been
working for me for some time and looks OK. Let's integrate properly
with rest of the system".
3. level - packages integrated and experience should be splendid :-)

However let's see how we'd handle systemd change with this system:
1. level - Lennart packages systemd, plays around with it. FESCO accepts systemd
as worthy FEATURE for future stable (3rd level). Packages 
interacting
with init system can take their time updating.
2. level - systemd moves here. After this point, packages moving from 1st level
here, will have to support systemd. Experience will likely be shaky
for a time, then settle down.
3. level - after some time (1 year, 2 years?) systemd moves here and all
packages that have been fixed to work with it as well

There are several problems with this approach though:
1. There are always multiple big changes happening in fedora. So even stable
would see big updates on relatively frequent basis.
2. Several big changes will interact with each other. I.e. Gnome update will
contain some daemons so they'd have to integrate with systemd on 2nd level.
But then Gnome couldn't go into 3rd level before systemd.
3...x. a long list of further problems

I am hopeful that we could make this work. Would anyone be willing to do
analysis like this for multiple updates and play devil's advocate as well?
Ideally trying to see how we could create processes to handle updates of the
last 1-2 years? Because all I could come up with is: we'd end up like Debian,
where stable is...ancient. Not that that is bad in itself if you can pick.



Trust me when I say this we have to fix other processes we have *before* 
we can properly fix the feature process.


Until that is done there is no point in trying to fix the feature process.

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 : broken configuration for httpd 2.4

[Marcela Mašláňová]

On 11/01/2012 06:25 PM, Jason L Tibbitts III wrote:

It would have been super nice to actually include a link in all of those
bugs, or some reference.  I mean, they must have been filed by program,
so it's not as if you would have had to do a bunch of extra typing.

We really need a "mass bug filing howto" or something.  Preferably
starting with "Don't."

  - J<

Bugs could contain little more info, but I hope our maintainer are aware 
of existence of dependent/blocking bugs.


Remi did wonderful job. We can track changes better than with mailing 
list and replies "fixed".


Marcela
--
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))

[Josh Boyer]

On Fri, Nov 2, 2012 at 9:03 AM, "Jóhann B. Guðmundsson"
 wrote:
>
> Trust me when I say this we have to fix other processes we have *before* we
> can properly fix the feature process.

Which?

> Until that is done there is no point in trying to fix the feature process.

I disagree.  While we might not be able to come to a set-in-stone
perfect process for Features, we can certainly make incremental
improvements to it.  It will never be set-in-stone anyway.  Perfect is
the enemy of good, etc etc.

josh
-- 
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))

[Richard W.M. Jones]

On Fri, Nov 02, 2012 at 11:55:37AM +0100, Stanislav Ochotnicky wrote:
> I recently came up with similar 3-layer idea. My description was a bit
> different, something like this:
> 1. level - rawhide-like repository, more or less anything goes
> 2. level - package moves here after maintainer says "this package has been
>working for me for some time and looks OK. Let's integrate properly
>with rest of the system".
> 3. level - packages integrated and experience should be splendid :-)

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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File Tree-DAG_Node-1.07.tgz uploaded to lookaside cache by pghmcfc

[Paul Howarth]

A file has been added to the lookaside cache for perl-Tree-DAG_Node:

1d12c1cb72a71edfdaab1b08a8f2e354  Tree-DAG_Node-1.07.tgz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Michael Cronenworth]

Ian Malone wrote:
> How does this work with things like Anaconda? In a rolling model
> (assuming you can do other major upgrades without reinstalling, if not
> there's less point anyway), people aren't going to be reinstalling so
> it could easily trickle through to stable before getting serious use.

Installer images could remain at a 6 month interval, or change to a 12
month interval, or be spun after a major feature reaches one of the
branch levels. There is more flexibility in a rolling release model to
ship a installer image.

The QA group would retain their duties in testing as they do so today.
In fact, it might make QA a stronger group as today they can only focus
on Rawhide/Branched releases. Very little QA time is spent on N+1 or
even N releases. Lacking a "version" tag doesn't mean things will go
untouched. The only way features would advance down a branch level is if
they received approval from FESCo/QA.

> 
> How does it work with major changes like UsrMove? It might never have
> been done...

How does it [something similar] work with Gentoo or Debian? :)

In the case of major file system changes, and not just package updates,
a distribution upgrade tool (fedup?) would be required. Yum would need
to gain the smarts to see "distribution updates" as well as regular
packages. Such a feature existed on my Nokia N900 phone (Debian) to
upgrade it to new major releases without reflashing or command-line usage.

-- 
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))

[Tom Lane]

Stanislav Ochotnicky  writes:
> Quoting Michael Cronenworth (2012-11-01 18:33:24)
>> I've wanted to write up a blog post about my plan for a rolling release,
>> but I'll post a snip-it here.

> I recently came up with similar 3-layer idea.

In my little corner of the system, the main thing that causes
distro-level issues is new upstream versions of libraries, carrying
API/ABI breaks.  (Recent examples include the libpng 1.2.x -> 1.5.x
and libtiff 3.9.x -> 4.0.x upgrades.)  To push one of those into
rawhide, we at least have to rebuild all dependent packages, and
typically some of them need source-level patches too.  In the current
model, once that's been done in rawhide, the problem is over: all those
packages will propagate to release branches together.  ISTM a rolling
release would make this sort of thing enormously more complicated.
Almost certainly, not all those packages would be at similar levels of
stability and so there would be no point at which they could all get
pushed to any stable branch.  How would you handle that without creating
a huge amount of extra work for packagers?  Keep in mind this type of
thing happens *constantly*, probably a dozen times per release cycle
across the whole distro.  Any significant extra burden is going to be
insupportable.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 : broken configuration for httpd 2.4

[Jason L Tibbitts III]

> "RC" == Remi Collet  writes:

RC> Have you notice than all this bugs depend on #871373 which provides
RC> some useful information ?

The useful information was not in the ticket.  Which means it wasn't in
the email.  Which means I had to get over to a web browser, wait for
bugzilla to load, and click around (and wait some more) to figure out
what on earth was going on.

People seem to think this is a great thing, and yes, I applaud Remi for
trying to help, but mass-filing tickets is the last resort, to be used
after doing a proper announcement and having discussion.

nirik are working on a proposal for some policy here.

 - J<
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-String-CRC32] Correct dependencies

[Petr Pisar]

commit aa8cdcff3aeb24f317ed1ba3dfecdf7d02f6a324
Author: Petr Písař 
Date:   Fri Nov 2 15:42:22 2012 +0100

Correct dependencies

 perl-String-CRC32.spec |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)
---
diff --git a/perl-String-CRC32.spec b/perl-String-CRC32.spec
index 4369220..67fb91a 100644
--- a/perl-String-CRC32.spec
+++ b/perl-String-CRC32.spec
@@ -1,6 +1,6 @@
 Name:   perl-String-CRC32
 Version:1.4
-Release:16%{?dist}
+Release:17%{?dist}
 Summary:Perl interface for cyclic redundancy check generation
 Group:  Development/Libraries
 License:Public Domain
@@ -8,8 +8,13 @@ URL:http://search.cpan.org/dist/String-CRC32/
 Source0:
http://search.cpan.org/CPAN/authors/id/S/SO/SOENKE/String-CRC32-%{version}.tar.gz
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires:  perl(ExtUtils::MakeMaker)
+# Run-time:
+BuildRequires:  perl(DynaLoader)
+BuildRequires:  perl(Exporter)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
+%{?perl_default_filter}
+
 %description
 This packages provides a perl module to generate checksums from strings and
 from files.
@@ -50,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Nov 02 2012 Petr Pisar  - 1.4-17
+- Correct dependencies
+
 * Fri Jul 20 2012 Fedora Release Engineering  
- 1.4-16
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-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]

On 11/02/2012 01:20 PM, Josh Boyer wrote:

On Fri, Nov 2, 2012 at 9:03 AM, "Jóhann B. Guðmundsson"
 wrote:

Trust me when I say this we have to fix other processes we have *before* we
can properly fix the feature process.

Which?


As soon as an feature depends on other components or several other 
components and their maintainers involvement/participation, then for 
example the unresponsive maintainers policy conflicts with the feature 
process given our relatively short development cycle. ( in general the 
current ownership model works against features that involve more then 
one component )   Another example cleaning up dead/deprecated packages 
which ought to happen at the beginning on new development cycle so 
feature maintainers wont work on dead or unmaintained packages etc...


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))

[Matthew Miller]

On Fri, Nov 02, 2012 at 02:52:46PM +, "Jóhann B. Guðmundsson" wrote:
> As soon as an feature depends on other components or several other
> components and their maintainers involvement/participation, then for
> example the unresponsive maintainers policy conflicts with the
> feature process given our relatively short development cycle. ( in

Can you explain that a little more? Do you mean the policy is too slow?

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
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]

On 11/02/2012 02:58 PM, Matthew Miller wrote:

On Fri, Nov 02, 2012 at 02:52:46PM +, "Jóhann B. Guðmundsson" wrote:

As soon as an feature depends on other components or several other
components and their maintainers involvement/participation, then for
example the unresponsive maintainers policy conflicts with the
feature process given our relatively short development cycle. ( in

Can you explain that a little more? Do you mean the policy is too slow?



Dead/un-maintained packages need to be removed/reassigned at the very 
*beginning* of an new development cycle so feature owners and others 
working in the community are dealing with active and actively maintained 
packages.


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))

[Matthew Miller]

On Fri, Nov 02, 2012 at 03:12:56PM +, "Jóhann B. Guðmundsson" wrote:
> >>As soon as an feature depends on other components or several other
> >>components and their maintainers involvement/participation, then for
> >>example the unresponsive maintainers policy conflicts with the
> >>feature process given our relatively short development cycle. ( in
> >Can you explain that a little more? Do you mean the policy is too slow?
> Dead/un-maintained packages need to be removed/reassigned at the
> very *beginning* of an new development cycle so feature owners and
> others working in the community are dealing with active and actively
> maintained packages.

Okay. But I'm having trouble seeing how that's a blocker for incremental
improvement to the features process.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 872158] perl-DateTime-TimeZone-1.52 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=872158

--- Comment #2 from Fedora Update System  ---
perl-DateTime-TimeZone-1.52-1.fc16 has been submitted as an update for Fedora
16.
https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.52-1.fc16

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 872158] perl-DateTime-TimeZone-1.52 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=872158

--- Comment #1 from Fedora Update System  ---
perl-DateTime-TimeZone-1.52-1.fc18 has been submitted as an update for Fedora
18.
https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.52-1.fc18

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 872158] perl-DateTime-TimeZone-1.52 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=872158

--- Comment #3 from Fedora Update System  ---
perl-DateTime-TimeZone-1.52-1.fc17 has been submitted as an update for Fedora
17.
https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.52-1.fc17

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-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]

On 11/02/2012 03:32 PM, Matthew Miller wrote:

On Fri, Nov 02, 2012 at 03:12:56PM +, "Jóhann B. Guðmundsson" wrote:

As soon as an feature depends on other components or several other
components and their maintainers involvement/participation, then for
example the unresponsive maintainers policy conflicts with the
feature process given our relatively short development cycle. ( in

Can you explain that a little more? Do you mean the policy is too slow?

Dead/un-maintained packages need to be removed/reassigned at the
very *beginning* of an new development cycle so feature owners and
others working in the community are dealing with active and actively
maintained packages.

Okay. But I'm having trouble seeing how that's a blocker for incremental
improvement to the features process.



It's pretty apparent that there is no point in working with the feature 
process et all if those issues aren't address first no matter how many 
incremental improvements you make to the process or when you do it for 
that matter.



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))

[Tom Lane]

=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=  writes:
> On 11/02/2012 03:32 PM, Matthew Miller wrote:
>> On Fri, Nov 02, 2012 at 03:12:56PM +, "Jóhann B. Guðmundsson" wrote:
>>> Dead/un-maintained packages need to be removed/reassigned at the
>>> very *beginning* of an new development cycle so feature owners and
>>> others working in the community are dealing with active and actively
>>> maintained packages.

How exactly are you going to force maintainers who go missing to do so
at a prescheduled time?  Real life is seldom that convenient.

regards, tom lane
-- 
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]

On 11/02/2012 04:25 PM, Tom Lane wrote:

=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=  writes:

On 11/02/2012 03:32 PM, Matthew Miller wrote:

On Fri, Nov 02, 2012 at 03:12:56PM +, "Jóhann B. Guðmundsson" wrote:

Dead/un-maintained packages need to be removed/reassigned at the
very *beginning* of an new development cycle so feature owners and
others working in the community are dealing with active and actively
maintained packages.

How exactly are you going to force maintainers who go missing to do so
at a prescheduled time?  Real life is seldom that convenient.


If at this point we dont have any process that can actively tell if a 
maintainer is present and active within the project then we have bigger 
fish to fry then the feature process...


Seriously it should not be anymore complex than monitoring last login 
into the relevant infrastructure pieces to determine if the relevant 
maintainer is active or not.


bash script + a cron job should suffice to achieve just that.

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: f18tc6 + texlive 2012: usable docbook, doxygen pdf toolchains

[Sérgio Basto]

On Sex, 2012-11-02 at 02:53 +, Sérgio Basto wrote: 
> On Qui, 2012-11-01 at 19:14 -0700, Benjamin De Kosnik wrote: 
> > Using F18 TC6 in a KVM install, I was able to install texlive-2012 as
> > per the updates-testing packages, and look at the state of generating
> > documenation with DocBook toolchains using dblatex and Doxygen
> > toolchains using pdflatex. 
> > 
> > This is related to RH488651, the tracker bug to update TeX in Fedora to
> > one more closely matching upstream TeX development. 
> > 
> > Although updating TeX is not an Accepted Feature in F18, texlive-2012
> > packages are in updates-testing. Using these packages, with some
> > changes, I was able to get a usable doxygen configuration for PDF, and
> > came much closer for docbook 5. The full $SUBJECT is optimistic, alas. 
> > 
> > I'm really hoping that we can merge in the new TeX bits and fix them
> > up in place with a sprint where all concerned work on it. I'm not quite
> > sure what the criteria would be for the conversion from Tex 2007 to TeX
> > 2012, but let me suggest workable docbook/doxygen/texinfo toolchains as
> > existenzminimum.
> > 
> > To that end:
> > 
> > Issues:
> > 
> > 1) docbook5-style-xsl
> > 
> > Issue with docbook.xsl typo/porting error. 
> > 
> > See GNOME BZ 687299
> > https://bugzilla.gnome.org/show_bug.cgi?id=687299
> > 
> > Fixed via hack:
> > ln -s VERSION VERSION.xsl
> > 
> > 2) doxygen-pdf needs
> > 
> > PreReq: texlive-sectsty
> > PreReq: texlive-tocloft
> > PreReq: texlive-xtab
> > PreReq: texlive-multirow
> > 
> > 3) docbook5-style-xsl needs
> > 
> > PreReq: texlive-subfigure
> > PreReq: texlive-appendix
> > PreReq: texlive-changebar
> > PreReq: texlive-bibtopic
> > PreReq: texlive-overpic
> > 
> > 4) any math formulas seem to need more than 
> > 
> > texlive-amsfonts
> > 
> > I just used the big guns:
> > 
> > yum install -y texlive-collection-fontsextra
> > texlive-collection-fontrecommended
> > 
> > These group packages for TeX fonts are great and I'm glad that Fedora
> > has them.
> > 
> > 5) dblatex seems to be not working. Not quite sure what is going on,
> > 
> > Error is: incomplete /ifmmode. 
> > 
> > I took the generated F18 .xml input and ran it thourgh dblatex on a
> > working F17 install, no problems.
> > 
> > 
> > 
> > My plan is to try and report these problems in Fedora BZ, even though
> > these packages are still in updates testing? Call me crazy? Is there a
> > better place to report these bugs?
> 
> no , I also have problems in F18.
> 
> I got problems build VirtualBox packages on F18 and rawhide, but not on
> F17, with user Manual's 
> build.log wrote:
> 
> This is pdfTeX, Version 3.1415926-2.5-1.40.13 (TeX Live 2013/dev)
>  restricted \write18 enabled.
> 
> 
> VirtualBox.spec just have :
> BuildRequires:  /usr/bin/pdflatex
> 
> have you any suggestion that I can try it ? 
> 
> I can't find any relevant error and doesn't use updates-testing 

Sorry , I found with your message that the problem is with texlive of
updates-testing, (I though I have it disabled but not).

Thanks,
-- 
Sérgio M. B.

-- 
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))

[Tom Lane]

=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=  writes:
> On 11/02/2012 04:25 PM, Tom Lane wrote:
>> How exactly are you going to force maintainers who go missing to do so
>> at a prescheduled time?  Real life is seldom that convenient.

> bash script + a cron job should suffice to achieve just that.

Somehow, we are failing to communicate.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Revamping the non responsive maintainer process

[Kevin Fenzi]

On Fri, 02 Nov 2012 16:44:06 +
"Jóhann B. Guðmundsson"  wrote:

> On 11/02/2012 04:25 PM, Tom Lane wrote:
> > =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> >  writes:
> >> On 11/02/2012 03:32 PM, Matthew Miller wrote:
> >>> On Fri, Nov 02, 2012 at 03:12:56PM +, "Jóhann B.
> >>> Guðmundsson" wrote:
>  Dead/un-maintained packages need to be removed/reassigned at the
>  very *beginning* of an new development cycle so feature owners
>  and others working in the community are dealing with active and
>  actively maintained packages.
> > How exactly are you going to force maintainers who go missing to do
> > so at a prescheduled time?  Real life is seldom that convenient.
> 
> If at this point we dont have any process that can actively tell if a 
> maintainer is present and active within the project then we have
> bigger fish to fry then the feature process...

If we have problem A and problem B, can't we work on both at the same
time? :) 

> Seriously it should not be anymore complex than monitoring last login 
> into the relevant infrastructure pieces to determine if the relevant 
> maintainer is active or not.
> 
> bash script + a cron job should suffice to achieve just that.

It's not at all that simple, I'm afraid. 

How long since last activity do you consider someone 'inactive' ?

What if the packages that maintain simply don't need any changes? 

What if they are on vacation? 

What if they are active on package A, but not doing something on
package B that you wish they would?

I've long wanted to revamp our process. 
I welcome concrete proposals to do so. 

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))

[Jon Ciesla]

Indeed.  If someone owns 4 packages that are all stable and have no bug
reports, are they inactive?

-J


On Fri, Nov 2, 2012 at 11:56 AM, Tom Lane  wrote:

> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= 
> writes:
> > On 11/02/2012 04:25 PM, Tom Lane wrote:
> >> How exactly are you going to force maintainers who go missing to do so
> >> at a prescheduled time?  Real life is seldom that convenient.
>
> > bash script + a cron job should suffice to achieve just that.
>
> Somehow, we are failing to communicate.
>
> regards, tom lane
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File App-Daemon-0.18.tar.gz uploaded to lookaside cache by iarnell

[Iain Arnell]

A file has been added to the lookaside cache for perl-App-Daemon:

0496db44622acb4478ef4bfc6be0d6e5  App-Daemon-0.18.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Revamping the non responsive maintainer process

[Jóhann B. Guðmundsson]

On 11/02/2012 04:56 PM, Kevin Fenzi wrote:

On Fri, 02 Nov 2012 16:44:06 +
"Jóhann B. Guðmundsson"  wrote:


On 11/02/2012 04:25 PM, Tom Lane wrote:

=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
 writes:

On 11/02/2012 03:32 PM, Matthew Miller wrote:

On Fri, Nov 02, 2012 at 03:12:56PM +, "Jóhann B.
Guðmundsson" wrote:

Dead/un-maintained packages need to be removed/reassigned at the
very *beginning* of an new development cycle so feature owners
and others working in the community are dealing with active and
actively maintained packages.

How exactly are you going to force maintainers who go missing to do
so at a prescheduled time?  Real life is seldom that convenient.

If at this point we dont have any process that can actively tell if a
maintainer is present and active within the project then we have
bigger fish to fry then the feature process...

If we have problem A and problem B, can't we work on both at the same
time? :)


Seriously it should not be anymore complex than monitoring last login
into the relevant infrastructure pieces to determine if the relevant
maintainer is active or not.

bash script + a cron job should suffice to achieve just that.

It's not at all that simple, I'm afraid.

How long since last activity do you consider someone 'inactive' ?

What if the packages that maintain simply don't need any changes?

What if they are on vacation?

What if they are active on package A, but not doing something on
package B that you wish they would?

I've long wanted to revamp our process.
I welcome concrete proposals to do so.



Surely if an individual has not logged into for several months into our 
infrastructure he must be inactive no?


Bash script + a cron job that monitors login should suffice to check and 
even email him asking him to confirm if he is active encase he has a low 
maintenance component and only logs in when something is filed  ;)


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Catalyst-Manual] update to latest upstream version

[Iain Arnell]

commit 46ee9ac74ade858edbf0782a09ebceef424eb6ac
Author: Iain Arnell 
Date:   Fri Nov 2 12:04:45 2012 -0600

update to latest upstream version

 .gitignore|1 +
 perl-Catalyst-Manual.spec |7 +--
 sources   |2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d355bae..21eccf1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ Catalyst-Manual-5.8004.tar.gz
 /Catalyst-Manual-5.9002.tar.gz
 /Catalyst-Manual-5.9003.tar.gz
 /Catalyst-Manual-5.9004.tar.gz
+/Catalyst-Manual-5.9005.tar.gz
diff --git a/perl-Catalyst-Manual.spec b/perl-Catalyst-Manual.spec
index 0202d4a..d8cc4ad 100644
--- a/perl-Catalyst-Manual.spec
+++ b/perl-Catalyst-Manual.spec
@@ -1,8 +1,8 @@
 Name:   perl-Catalyst-Manual
 Summary:Catalyst web framework manual
 Epoch:  1
-Version:5.9004
-Release:3%{?dist}
+Version:5.9005
+Release:1%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/Z/ZA/ZARQUON/Catalyst-Manual-%{version}.tar.gz
@@ -49,6 +49,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Nov 02 2012 Iain Arnell  1:5.9005-1
+- update to latest upstream version
+
 * Fri Jul 20 2012 Fedora Release Engineering  
- 1:5.9004-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
 
diff --git a/sources b/sources
index 5d0c660..deba026 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9683073fefb1df4928498b1b64f5ffe8  Catalyst-Manual-5.9004.tar.gz
+c0158e0ea658544eb32be6752b489faf  Catalyst-Manual-5.9005.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Catalyst-Manual] drop old test sub-package obsoletes/provides

[Iain Arnell]

commit 8ad2fd6c91fc8892254a13655da255971a4c812e
Author: Iain Arnell 
Date:   Fri Nov 2 12:04:55 2012 -0600

drop old test sub-package obsoletes/provides

 perl-Catalyst-Manual.spec |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)
---
diff --git a/perl-Catalyst-Manual.spec b/perl-Catalyst-Manual.spec
index d8cc4ad..b03d731 100644
--- a/perl-Catalyst-Manual.spec
+++ b/perl-Catalyst-Manual.spec
@@ -13,11 +13,6 @@ BuildArch:  noarch
 BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.36
 BuildRequires:  perl(Test::More)
 
-# obsolete/provide old tests subpackage
-# can be removed during F19 development cycle
-Obsoletes:  %{name}-tests < 1:5.9002-3
-Provides:   %{name}-tests = %{epoch}:%{version}-%{release}
-
 %{?perl_default_filter}
 
 %description
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Revamping the non responsive maintainer process

[Bruno Wolff III]

On Fri, Nov 02, 2012 at 17:57:57 +,
  "\"Jóhann B. Guðmundsson\""  wrote:


Surely if an individual has not logged into for several months into 
our infrastructure he must be inactive no?


Not necessarily. You can watch things without having to login to 
infrastructure. Unless you need to make changes or respond to bug 
reports there might not be anything to do.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Revamping the non responsive maintainer process

[Jon Ciesla]

On Fri, Nov 2, 2012 at 12:57 PM, "Jóhann B. Guðmundsson"  wrote:

> On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
>
>> On Fri, 02 Nov 2012 16:44:06 +
>> "Jóhann B. Guðmundsson"  wrote:
>>
>>  On 11/02/2012 04:25 PM, Tom Lane wrote:
>>>
 =?UTF-8?B?**IkrDs2hhbm4gQi4gR3XDsG11bmRzc2**9uIg==?=
  writes:

> On 11/02/2012 03:32 PM, Matthew Miller wrote:
>
>> On Fri, Nov 02, 2012 at 03:12:56PM +, "Jóhann B.
>> Guðmundsson" wrote:
>>
>>> Dead/un-maintained packages need to be removed/reassigned at the
>>> very *beginning* of an new development cycle so feature owners
>>> and others working in the community are dealing with active and
>>> actively maintained packages.
>>>
>> How exactly are you going to force maintainers who go missing to do
 so at a prescheduled time?  Real life is seldom that convenient.

>>> If at this point we dont have any process that can actively tell if a
>>> maintainer is present and active within the project then we have
>>> bigger fish to fry then the feature process...
>>>
>> If we have problem A and problem B, can't we work on both at the same
>> time? :)
>>
>>  Seriously it should not be anymore complex than monitoring last login
>>> into the relevant infrastructure pieces to determine if the relevant
>>> maintainer is active or not.
>>>
>>> bash script + a cron job should suffice to achieve just that.
>>>
>> It's not at all that simple, I'm afraid.
>>
>> How long since last activity do you consider someone 'inactive' ?
>>
>> What if the packages that maintain simply don't need any changes?
>>
>> What if they are on vacation?
>>
>> What if they are active on package A, but not doing something on
>> package B that you wish they would?
>>
>> I've long wanted to revamp our process.
>> I welcome concrete proposals to do so.
>>
>
>
> Surely if an individual has not logged into for several months into our
> infrastructure he must be inactive no?
>

No, they might simply have had nothing to do.  Sometimes applications are
stable, have no releases, and have no bugs files against them.

-J


> Bash script + a cron job that monitors login should suffice to check and
> even email him asking him to confirm if he is active encase he has a low
> maintenance component and only logs in when something is filed  ;)
>
> JBG
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.**org/mailman/listinfo/devel




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File Getopt-Long-Descriptive-0.093.tar.gz uploaded to lookaside cache by iarnell

[Iain Arnell]

A file has been added to the lookaside cache for perl-Getopt-Long-Descriptive:

3610685889c885f13fe3f4ed1360e078  Getopt-Long-Descriptive-0.093.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-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]

On 11/02/2012 04:56 PM, Tom Lane wrote:

>>How exactly are you going to force maintainers who go missing to do so
>>at a prescheduled time?  Real life is seldom that convenient.

>bash script + a cron job should suffice to achieve just that.

Somehow, we are failing to communicate.


We would not force them to do anything how could we they are awol and 
you do realize that process can be automated even if that just generates 
a list of components that *look* to be unmaintained and then what 
releng? goes through that list of components and takes the next step to 
"orphan" them...


JBG

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Revamping the non responsive maintainer process

[Jóhann B. Guðmundsson]

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...


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Revamping the non responsive maintainer process

[Aleksandar Kurtakov]

- Original Message -
> From: "Jóhann B. Guðmundsson" 
> To: devel@lists.fedoraproject.org
> Sent: Friday, November 2, 2012 7:57:57 PM
> Subject: Re: Revamping the non responsive maintainer process
> 
> On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
> > On Fri, 02 Nov 2012 16:44:06 +
> > "Jóhann B. Guðmundsson"  wrote:
> >
> >> On 11/02/2012 04:25 PM, Tom Lane wrote:
> >>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> >>>  writes:
>  On 11/02/2012 03:32 PM, Matthew Miller wrote:
> > On Fri, Nov 02, 2012 at 03:12:56PM +, "Jóhann B.
> > Guðmundsson" wrote:
> >> Dead/un-maintained packages need to be removed/reassigned at
> >> the
> >> very *beginning* of an new development cycle so feature owners
> >> and others working in the community are dealing with active
> >> and
> >> actively maintained packages.
> >>> How exactly are you going to force maintainers who go missing to
> >>> do
> >>> so at a prescheduled time?  Real life is seldom that convenient.
> >> If at this point we dont have any process that can actively tell
> >> if a
> >> maintainer is present and active within the project then we have
> >> bigger fish to fry then the feature process...
> > If we have problem A and problem B, can't we work on both at the
> > same
> > time? :)
> >
> >> Seriously it should not be anymore complex than monitoring last
> >> login
> >> into the relevant infrastructure pieces to determine if the
> >> relevant
> >> maintainer is active or not.
> >>
> >> bash script + a cron job should suffice to achieve just that.
> > It's not at all that simple, I'm afraid.
> >
> > How long since last activity do you consider someone 'inactive' ?
> >
> > What if the packages that maintain simply don't need any changes?
> >
> > What if they are on vacation?
> >
> > What if they are active on package A, but not doing something on
> > package B that you wish they would?
> >
> > I've long wanted to revamp our process.
> > I welcome concrete proposals to do so.
> 
> 
> Surely if an individual has not logged into for several months into
> our
> infrastructure he must be inactive no?

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! 
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.
All of this was to show that whatever policy might be chosen it should be PER 
PROJECT/PACKAGE not per maintainer. Do you know what happens when someone as I 
described is currently overloaded and one dares to start the inactive 
maintainer procedure for him? I can tell you - for one unmaintained package, we 
lose a number of others that he/she maintained in a decent state. 
There was such a case recently for an on and off contributor who did *a lot* in 
the years, so when we say we want to learn from mistakes let's not do it by 
making bigger ones.

Alexander Kurtakov
Red Hat Eclipse team

> 
> Bash script + a cron job that monitors login should suffice to check
> and
> even email him asking him to confirm if he is active encase he has a
> low
> maintenance component and only logs in when something is filed  ;)
> 
> 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))

[Emmanuel Seyman]

* "Jóhann B. Guðmundsson" [02/11/2012 18:59] :
>
> If at this point we dont have any process that can actively tell if
> a maintainer is present and active within the project then we have
> bigger fish to fry then the feature process...

This really does not matter. We've had maintainers that were AWOL for years
without this affecting the distribution one bit because their packages were
cared for by co-maintainers and the appropriate SIGs.

If a package is unmaintained, send out a call to co-maintain to devel@ and open
up its ACLs.

> Seriously it should not be anymore complex than monitoring last
> login into the relevant infrastructure pieces to determine if the
> relevant maintainer is active or not.

Flagging maintainers as active/inactive is fun but it doesn't actually
improve the distribution.

Emmanuel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Coordinating libffi upgrade

[Anthony Green]

Several months ago I attempted to upgrade libffi 3.0.10 to 3.0.11.  The change 
was reverted because the soname change in this version of the library broke the 
build environment.  I would still like to get 3.0.11 in Fedora.  I don't 
anticipate any future ABI-breaking changes, and 3.0.12 will include additional 
ports like Aarch64, which is likely of interest to some Fedora developers.  How 
do we coordinate a rebuild for dependent packages?  Also, I assume this will 
have to wait 'til F18 is out (fine by me), but I'd like to deal with it early 
in the F19 cycle.

Thanks,

Anthony Green
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Module-Signature] Created tag perl-Module-Signature-0.69-1.fc18

[Paul Howarth]

The lightweight tag 'perl-Module-Signature-0.69-1.fc18' was created pointing to:

 a5b4aff... Update to 0.69
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Module-Signature] Created tag perl-Module-Signature-0.69-1.fc19

[Paul Howarth]

The lightweight tag 'perl-Module-Signature-0.69-1.fc19' was created pointing to:

 a5b4aff... Update to 0.69
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Revamping the non responsive maintainer process

[Jóhann B. Guðmundsson]

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...


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))

[Jóhann B. Guðmundsson]

On 11/02/2012 06:56 PM, Emmanuel Seyman wrote:

If a package is unmaintained, send out a call to co-maintain to devel@ and open
up its ACLs.


That package would hardly be un-maintained if it has co-maintainers now 
does it...


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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]

On Fri, 2012-11-02 at 11:55 +0100, Stanislav Ochotnicky wrote:
> Quoting Michael Cronenworth (2012-11-01 18:33:24)
> > Adam Williamson wrote:
> > > I didn't want to throw this grenade into the debate, but now someone
> > > else has, I'll just note that I was in favour of this before and I'm
> > > still in favour of it now. :) Rolling release is a model that makes
> > > clear sense for a distribution with the goals that Fedora has.
> > 
> > I've wanted to write up a blog post about my plan for a rolling release,
> > but I'll post a snip-it here.
> > 
> > Fedora Rawhide - stays as is... it is a rolling release
> > 
> > Fedora Feature - think of it as F18 beta right now
> > 
> > Fedora Stable - think of it as F16/F17 right now
> > 
> > People choose the branch level at install time. Of course, like now,
> > people can override this in the future with a change of fedora-release
> > or yum --releasever. However, per-package updates from another branch
> > level might not be something everyone can agree on how to handle, so it
> > might be wise to limit support of it at first.
> > 
> > Workflow:
> > A shiny new feature is introduced in Rawhide. Things go boom. Not many
> > people are hurt by this. Once it has been given a few band-aids the
> > feature could be submitted to Fedora Feature. After some hardening and
> > polishing the feature could finally be pushed to Fedora Stable.
> > 
> > I feel this should give a good compromise to everyone's fears of a
> > rolling release. It gives the feature freaks a place in Fedora. It gives
> > the stable stubborns a place in Fedora.
> > 
> > I'll wake up from my dream now.
> 
> I recently came up with similar 3-layer idea. 



Honestly, my take on this is that anything like Debian's system would be
over-engineering.

The reason I like rolling release for Fedora is that Fedora is supposed
to be where we do cutting-edge development and integration. The way I
read Fedora's mission statement, target user statement etc is that it's
not _really_ meant to be a 'stable distribution' at all. We do a fairly
poor imitation of being one, to no great effect, but wasting a great
deal of resources.

The entire QA team (and the entire anaconda team, for that matter) is
currently spending virtually all its time trying to help bash the new
anaconda into something vaguely resembling shape for a fairly arbitrary
release deadline, so we can ship something called 'the Fedora 18 stable
release' without *completely* corpsing Jimmy Fallon-style as we do the
release announcement ("sre, this is a stable release..." *giggle*
*giggle* *guffaw* *full-blown laughing fit*). We've barely looked at the
desktop or the update mechanism or anything else. Stuff in Fedora
regresses all over the place...there all sorts of weirdness in how
fairly basic bits of our OS work, like updates and login and various
other crap. We can't really look in a mirror and say that, say, Fedora
17 is a serious stable operating system release by any reasonable
definition. It's a stable Fedora release, and we all know what that is.
We had a feature for a smooth boot process back in F12, remember? where
everything was polished and had the same background and you didn't see
any mode transitions? How's that working these days? It was supposed to
be a feature of our operating system. We almost got it done for one
release, and have been consistently regressing it ever since. That's not
what stable, mature operating systems do.

Over in kernel land, for a long time, the kernel team was wasting tons
of resources maintaining three or four different kernels for three or
four different releases - which is what they're supposed to do, under
our current policies. They have now solved that problem, but only
essentially by moving the kernel to a rolling release model: F16, F17
and F18 now have more or less the same kernel build, and F16 is like
three major versions on from where it started. Let's be honest - this is
a clear breach of what our update policy is supposed to achieve. We
wrote a get-out clause into the update policy to let the kernel team do
this and claim they're in line with the policy, but that was an obvious
process hack.

Basically what I'd like Fedora to do is 'that, only bigger'. We are not
really doing a convincing job of releasing and maintaining stable
operating systems, we're just wasting a lot of resources on pretending
to do so. Badly. Resources we could better be spending on what we're
good at - constantly building and iterating interesting new stuff in the
broad framework of a distribution that's usable enough for the job of
building and testing interesting new stuff.

If we want to look at the Debian model, I'd say we should have 'sid' and
'testing' or even just 'experimental' and 'sid' and stop lying to people
that we are even interested in, let alone that our release cycle and
processes are capable of, building a stable general purpose operating
system. That's not what we're doing in practice, it's not really wh

Re: Coordinating libffi upgrade

[Adam Jackson]

On 11/2/12 3:18 PM, Anthony Green wrote:

Several months ago I attempted to upgrade libffi 3.0.10 to 3.0.11.
The change was reverted because the soname change in this version of
the library broke the build environment.  I would still like to get
3.0.11 in Fedora.  I don't anticipate any future ABI-breaking
changes, and 3.0.12 will include additional ports like Aarch64, which
is likely of interest to some Fedora developers.  How do we
coordinate a rebuild for dependent packages?  Also, I assume this
will have to wait 'til F18 is out (fine by me), but I'd like to deal
with it early in the F19 cycle.


It looks like libffi is emitted into the minimal buildroot (rpm-build -> 
pkg-config -> glib2 -> libffi), so during the transition we'll need to 
build both sonames of libffi.  It might be worth keeping a compat-libffi 
around for a release or two anyway, the current soname has a _long_ history.


After that, though, the rebuilds should be pretty straightforward, it 
looks like all affected source packages are provenpackager+.  The caveat 
might be things like ghc which generate their prov/reqs based on a sha 
hash of, well, something; if that something includes the list of 
DT_NEEDED then we might be looking at a rebuild of many more things. 
But even that should be straightforward if tedious.


- ajax
--
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)))

[drago01]

Well your point basically is "we can't/don't ship anything that is
stable so we should give up on that."

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.

Compare it to "always cutting edge" like rawhide ... you can't get any
work done with that. It keeps breaking almost every second day.

So things aren't perfect now they aren't as bad as you paint them to
be. The current anaconda mess is just a project management failure ...
nothing else really.
-- 
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))

[Michał Piotrowski]

Hi,

Do current anaconda problems will have an impact on preupgrade?

-- 
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/
-- 
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]

On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote:
> Well your point basically is "we can't/don't ship anything that is
> stable so we should give up on that."

More or less, yes.

> 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 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 wouldn't put
Fedora 17 on my uncle Bob's computer (I don't have an uncle Bob, this is
just your hackneyed old 'regular person' example) and say 'there's your
computer'. How many of us would? Even if you get a good Fedora release
and don't hit problems with updates - which we don't do a _bad_ job of
these days, admittedly - our releases really aren't quality general
purpose OSes (we let all kinds of weirdnesses go into our releases which
a serious user-facing OS would never let go), and after 12 months, you
have to do an upgrade, which has about a 50/50 chance of exploding,
let's face it. That's not a convincing stable general purpose operating
system.

It's telling that when you meet 'normal people' who are running Fedora,
they're usually using Fedora N-5, which hasn't had security updates for
a year and a half. That's how 'normal people' use their computers - they
don't upgrade every year and find it _fun_ to fix the upgrade process
when it explodes. I don't think we're serving the (few) 'normal people'
who run Fedora in this fashion very well, frankly. They'd probably be
better off with something else.

I realize my point of view here is somewhat radical, but you need the
lunatic fringe around to keep people on their toes, I've always
thought. ;)

> Compare it to "always cutting edge" like rawhide ... you can't get any
> work done with that. It keeps breaking almost every second day.

Well, that's why I said two streams. One would be what Rawhide is now
and the other would be pretty much branched/stable level. On a broad
conceptual level - there's several ways of doing this, of course. But my
basic point is that the three stream idea works for a project like
Debian, which has a conservative approach to everything and is able,
over a very long timeframe, to produce something that actually *is* a
stable operating system. It's not appropriate to a project like Fedora,
which really isn't doing that. How often have we said we don't have the
people interested in doing LTS releases, for instance? That's the kind
of work you need to maintain a true 'stable' tier in a three-tier
system. It's boring maintenance of long-dead code, and that's not
generally what Fedora people are interested in. How many maintainers
right now are doing a convincing job of maintaining F16? How many people
are testing the updates? How many Fedora packagers wake up in the
morning and think 'hey, what I really want to do today is carefully test
and backport specific fixes to the F16 branches of my packages'?

> So things aren't perfect now they aren't as bad as you paint them to
> be. The current anaconda mess is just a project management failure ...
> nothing else really.

The current anaconda mess is an example I used in my post, but it's not
the only one. I've been thinking along these lines for a long while, not
related to any particular fire. It's a general perspective.
-- 
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: Revamping the non responsive maintainer process

[Chris Adams]

Once upon a time, "Jóhann B. Guðmundsson"  said:
> Surely if an individual has not logged into for several months into our 
> infrastructure he must be inactive no?

I maintain just a couple of low-overhead packages, and I haven't changed
either in a couple of years.  The only time I've logged into any of the
Fedora servers in that time has been related to mirror management (and
that is pretty rare as well).

And (because I'm a lazy email reader) I post here from a different email
address than my Fedora-registered one.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Coordinating libffi upgrade

[Colin Walters]

On Fri, 2012-11-02 at 16:04 -0400, Adam Jackson wrote:

> It looks like libffi is emitted into the minimal buildroot (rpm-build -> 
> pkg-config -> glib2 -> libffi), so during the transition we'll need to 
> build both sonames of libffi.  It might be worth keeping a compat-libffi 
> around for a release or two anyway, the current soname has a _long_ history.

Or just apply the patch from here:
http://lists.fedoraproject.org/pipermail/devel/2012-April/165871.html
And skip tons of pain for all the libffi consumers at the tiny cost of a
stub symbol.

Hm, no links to the patch in the archives.  Well, I'll attach it again,
since I still have it sitting around in my libffi git checkout.


>From ce7211733bd2d1748c3dcd3d3717850e28d4594d Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Sat, 14 Apr 2012 10:03:59 -0400
Subject: [PATCH] Revert to previous ABI

Bumping the SONAME just to delete 3 symbols that no one called anyways
is quite simply not worth the pain, given how many low-level modules
consume libffi.

Just keep the symbols around as empty stubs.
---
 Makefile.am |  6 +-
 libtool-version |  2 +-
 src/debug.c | 12 ++--
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 8a32794..7829a36 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -97,11 +97,7 @@ libffi_la_SOURCES = src/prep_cif.c src/types.c \
 pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = libffi.pc
 
-nodist_libffi_la_SOURCES =
-
-if FFI_DEBUG
-nodist_libffi_la_SOURCES += src/debug.c
-endif
+nodist_libffi_la_SOURCES = src/debug.c
 
 if MIPS
 nodist_libffi_la_SOURCES += src/mips/ffi.c src/mips/o32.S src/mips/n32.S
diff --git a/libtool-version b/libtool-version
index 95f48c5..b8b80e0 100644
--- a/libtool-version
+++ b/libtool-version
@@ -26,4 +26,4 @@
 #release, then set age to 0.
 #
 # CURRENT:REVISION:AGE
-6:0:0
+5:10:0
diff --git a/src/debug.c b/src/debug.c
index 51dcfcf..ae42afd 100644
--- a/src/debug.c
+++ b/src/debug.c
@@ -27,33 +27,41 @@
 #include 
 #include 
 
-/* General debugging routines */
+/* General debugging routines; note these were accidentally
+ * made public, so we keep empty stubs in the case where
+ * we weren't compiled with FFI_DEBUG.
+ */
 
 void ffi_stop_here(void)
 {
+#ifdef FFI_DEBUG
   /* This function is only useful for debugging purposes.
  Place a breakpoint on ffi_stop_here to be notified of
  significant events. */
+#endif
 }
 
 /* This function should only be called via the FFI_ASSERT() macro */
 
 void ffi_assert(char *expr, char *file, int line)
 {
+#ifdef FFI_DEBUG
   fprintf(stderr, "ASSERTION FAILURE: %s at %s:%d\n", expr, file, line);
   ffi_stop_here();
   abort();
+#endif
 }
 
 /* Perform a sanity check on an ffi_type structure */
 
 void ffi_type_test(ffi_type *a, char *file, int line)
 {
+#ifdef FFI_DEBUG
   FFI_ASSERT_AT(a != NULL, file, line);
 
   FFI_ASSERT_AT(a->type <= FFI_TYPE_LAST, file, line);
   FFI_ASSERT_AT(a->type == FFI_TYPE_VOID || a->size > 0, file, line);
   FFI_ASSERT_AT(a->type == FFI_TYPE_VOID || a->alignment > 0, file, line);
   FFI_ASSERT_AT(a->type != FFI_TYPE_STRUCT || a->elements != NULL, file, line);
-
+#endif
 }
-- 
1.7.11.7

-- 
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))

[Bill Nottingham]

Michał Piotrowski (mkkp...@gmail.com) said: 
> Do current anaconda problems will have an impact on preupgrade?

preupgrade is not the current supported upgrade tool to upgrade to Fedora 18.
So the simple answer to your question is 'yes', although not exactly for the
reasons you expect.

https://fedoraproject.org/wiki/QA%3AFedora_18_Upgrade_Testing

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Coordinating libffi upgrade

[Bill Nottingham]

Colin Walters (walt...@verbum.org) said: 
> On Fri, 2012-11-02 at 16:04 -0400, Adam Jackson wrote:
> 
> > It looks like libffi is emitted into the minimal buildroot (rpm-build -> 
> > pkg-config -> glib2 -> libffi), so during the transition we'll need to 
> > build both sonames of libffi.  It might be worth keeping a compat-libffi 
> > around for a release or two anyway, the current soname has a _long_ history.
> 
> Or just apply the patch from here:
> http://lists.fedoraproject.org/pipermail/devel/2012-April/165871.html
> And skip tons of pain for all the libffi consumers at the tiny cost of a
> stub symbol.
> 
> Hm, no links to the patch in the archives.  Well, I'll attach it again,
> since I still have it sitting around in my libffi git checkout.

And note that whatever you do, F-19 is open for doing it now - you don't 
need to wait until F-18 ships...

Bill
-- 
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)))

[Jóhann B. Guðmundsson]

On 11/02/2012 07:56 PM, Adam Williamson wrote:

Anyway, we've rather torpedo'ed the feature process discussion now, and
I'm sorry about that :/. Hence the topic change. But while we're blue
sky thinking about massive release process changes, I think it's worth
keeping a firm grasp on what Fedora is really about and what it's
capable of achieving.


I argue that we should have one "rolling release" which users would be 
forced to upgrade to every 9 months or so ( following browsers example ) 
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 foremost would need maintainers willing to maintain the 
distribution for that time, epel could maybe be simply dropped for that ).


JBG
--
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)))

[Tom Lane]

Adam Williamson  writes:
> On Fri, 2012-11-02 at 21:07 +0100, drago01 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.

Uh, no.  What you describe is usable by the kind of people who use
rawhide.  Which is what, 1% of our user base?  If that.

Abandoning any pretense of having stable releases will eliminate a huge
fraction of the user community.  For sure it will eliminate *me*.  I'm
not in the business of fighting OS bugs every single day, and I will not
be forced into that business.  I have other things that I'm more
productive at.

I'm curious what you think package maintainers will do their package
maintenance on, if there is no Fedora version that they can trust to
still work tomorrow or the day after.  (Anyone up for porting fedpkg
to Ubuntu?)

I've seen a whole lot of user demand for *more* stable versions of
Fedora.  I've seen none whatever for less stable versions.

regards, tom lane
-- 
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)))

[drago01]

On Fri, Nov 2, 2012 at 10:53 PM, Tom Lane  wrote:
> Adam Williamson  writes:
>> On Fri, 2012-11-02 at 21:07 +0100, drago01 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.
>
> Uh, no.  What you describe is usable by the kind of people who use
> rawhide.  Which is what, 1% of our user base?  If that.
>
> Abandoning any pretense of having stable releases will eliminate a huge
> fraction of the user community.  For sure it will eliminate *me*.  I'm
> not in the business of fighting OS bugs every single day, and I will not
> be forced into that business.  I have other things that I'm more
> productive at.

Exactly saves me time to write a reply to Adam's post.
-- 
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]

On Fri, 2012-11-02 at 17:53 -0400, Tom Lane wrote:
> Adam Williamson  writes:
> > On Fri, 2012-11-02 at 21:07 +0100, drago01 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.
> 
> Uh, no.  What you describe is usable by the kind of people who use
> rawhide.  Which is what, 1% of our user base?  If that.
> 
> Abandoning any pretense of having stable releases will eliminate a huge
> fraction of the user community.  For sure it will eliminate *me*.  I'm
> not in the business of fighting OS bugs every single day, and I will not
> be forced into that business.  I have other things that I'm more
> productive at.
> 
> I'm curious what you think package maintainers will do their package
> maintenance on, if there is no Fedora version that they can trust to
> still work tomorrow or the day after.  (Anyone up for porting fedpkg
> to Ubuntu?)
> 
> I've seen a whole lot of user demand for *more* stable versions of
> Fedora.  I've seen none whatever for less stable versions.

Perhaps I ought to be more clear. I think we can maintain the level of
*actual* stability our current 'stable' releases provide with a model
such as I describe, while substantially reducing the amount of resources
we're wasting at least _theoretically_ maintaining up to four releases
at once (currently, 16, 17, 18 and 19). I think there's a lot of heat
and not much light going on there.

I would envisage that people like you and drago would run the 'stabler'
branch in my plan and be happy. The idea isn't to make Fedora less
stable than it already is, it's just to be more realistic. I would say
that our current process produces the level of stability that you and
drago are happy with, but we sometimes act as if it produces a level of
stability you could put in a box and sell to people, which it doesn't.

If you're using a Fedora release today you're _already_ fighting OS bugs
more often than most people do, I'd say. I disagree with drago's
assertion that my description was of people who use Rawhide. It was not
intended to be, and it was drawn from the experience of me and other
people who do not run Rawhide. I almost never run Rawhide, only
Branched.
-- 
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: Coordinating libffi upgrade

[Toshio Kuratomi]

On Fri, Nov 02, 2012 at 04:49:01PM -0400, Bill Nottingham wrote:
> Colin Walters (walt...@verbum.org) said: 
> > On Fri, 2012-11-02 at 16:04 -0400, Adam Jackson wrote:
> > 
> > > It looks like libffi is emitted into the minimal buildroot (rpm-build -> 
> > > pkg-config -> glib2 -> libffi), so during the transition we'll need to 
> > > build both sonames of libffi.  It might be worth keeping a compat-libffi 
> > > around for a release or two anyway, the current soname has a _long_ 
> > > history.
> > 
> > Or just apply the patch from here:
> > http://lists.fedoraproject.org/pipermail/devel/2012-April/165871.html
> > And skip tons of pain for all the libffi consumers at the tiny cost of a
> > stub symbol.
> > 
> > Hm, no links to the patch in the archives.  Well, I'll attach it again,
> > since I still have it sitting around in my libffi git checkout.
> 
> And note that whatever you do, F-19 is open for doing it now - you don't 
> need to wait until F-18 ships...
> 
And has been since August.  Development starts when rawhide and F-next
branch.

https://fedoraproject.org/wiki/Schedule

-Toshio


pgpvzoWu2xWVX.pgp
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))

[Reindl Harald]

Am 02.11.2012 17:25, schrieb Tom Lane:
> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=  writes:
>> On 11/02/2012 03:32 PM, Matthew Miller wrote:
>>> On Fri, Nov 02, 2012 at 03:12:56PM +, "Jóhann B. Guðmundsson" wrote:
 Dead/un-maintained packages need to be removed/reassigned at the
 very *beginning* of an new development cycle so feature owners and
 others working in the community are dealing with active and actively
 maintained packages.
> 
> How exactly are you going to force maintainers who go missing to do so
> at a prescheduled time?  Real life is seldom that convenient

well, it would maybe a start to DROP packages which are still
missing systemd-units or do fedora tend to have this "feature"
another 5 releases, currently it is the FOURTH

do not tell me packages where the maintainer until know did not
hear the shoot that Fedora uses systemd since more than year
is well maintained at all

again: this "feature" should have been finalized at F15
_

http://fedoraproject.org/wiki/Releases/18/FeatureList

60% 
SysV to Systemd 
Porting from sysVinit init scripts to systemd unit files
2012-06-05



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)))

[Reindl Harald]

Am 02.11.2012 22:53, schrieb Tom Lane:
> Abandoning any pretense of having stable releases will eliminate a huge
> fraction of the user community.  For sure it will eliminate *me*.  I'm
> not in the business of fighting OS bugs every single day, and I will not
> be forced into that business.  I have other things that I'm more
> productive at.

+1

> I'm curious what you think package maintainers will do their package
> maintenance on, if there is no Fedora version that they can trust to
> still work tomorrow or the day after.  (Anyone up for porting fedpkg
> to Ubuntu?)

+1

> I've seen a whole lot of user demand for *more* stable versions of
> Fedora.  I've seen none whatever for less stable versions.

+1

Fedora IS USEABLE as a stable base for nearly anything
even large upgrades like systemd and UsrMove are working finally
they "only" have too much impact which could be optimized by relax
the release-schedules in a direction "ok, things are not running
like we thought at the begin of the schedule, let us take the time
it needs to make stings clean and stable"

current F18 is a good example

POSITIVE: beta delayed multiple times for good reasons
NEGATIVE: the promise to hold final release date

NO!
the right way would be to delay final release to 2013
this would greatly improve the time of testing of a
as final declared release where ALL components are
having this state at the same time

PLEASE: keep in mind this is free software NOT driven by
marketing idiots who define release dates - why wasting
this real huge benefit for "beeing first everytime"
_

as said:

i would propose that one of the two releases each year does
not bring large new features with great impact and instead
use one schedule to stabilize and fine-polish the distribution
at all which maybe save a lot of ressources for upcoming
features in the following release



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)))

[Kevin Fenzi]

On Fri, 02 Nov 2012 15:17:02 -0700
Adam Williamson  wrote:

..snip...

> If you're using a Fedora release today you're _already_ fighting OS
> bugs more often than most people do, I'd say. I disagree with drago's
> assertion that my description was of people who use Rawhide. It was
> not intended to be, and it was drawn from the experience of me and
> other people who do not run Rawhide. I almost never run Rawhide, only
> Branched.

Perhaps you have your head too much in the Branched world right now?

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. 

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)))

[Tom Lane]

Adam Williamson  writes:
> On Fri, 2012-11-02 at 17:53 -0400, Tom Lane wrote:
>> I've seen a whole lot of user demand for *more* stable versions of
>> Fedora.  I've seen none whatever for less stable versions.

> Perhaps I ought to be more clear. I think we can maintain the level of
> *actual* stability our current 'stable' releases provide with a model
> such as I describe, while substantially reducing the amount of resources
> we're wasting at least _theoretically_ maintaining up to four releases
> at once (currently, 16, 17, 18 and 19).

Well, maybe, but yeah you weren't very clear about that.  In any case,
I'm not seeing how we handle things like library ABI breaks with a
rolling release model ... at least not without more work, rather than
less, than we have now.

> If you're using a Fedora release today you're _already_ fighting OS bugs
> more often than most people do, I'd say.

I don't buy that really.  I hit very few bugs in Fedora -- fewer than
in OS X for instance.  Possibly this is because I use it as a headless
server as much as possible, and thus avoid bugs in the desktop-related
code.  As a development platform it's remarkably stable.  (Now
admittedly, I never run rawhide, and generally wait till a month after
"official release" before updating my main workstation to a new Fedora
version.  But with those simple precautions, it is very stable.)

regards, tom lane
-- 
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)))

[Brian Pepple]

On Fri, Nov 2, 2012 at 6:17 PM, Adam Williamson  wrote:
> If you're using a Fedora release today you're _already_ fighting OS bugs
> more often than most people do, I'd say. I disagree with drago's
> assertion that my description was of people who use Rawhide. It was not
> intended to be, and it was drawn from the experience of me and other
> people who do not run Rawhide. I almost never run Rawhide, only
> Branched.

Really? I don't remember the last time I had some kind of breakage in
my stable branch machines. Now, in the development branches that's a
different story, but that's to be somewhat expected due to the daily
churn there.

Later,
/B
--
Brian Pepple 

https://fedoraproject.org/wiki/User:Bpepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-- 
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)))

[Simo Sorce]

On Fri, 2012-11-02 at 13:22 -0700, Adam Williamson wrote:
> On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote:
> > Well your point basically is "we can't/don't ship anything that is
> > stable so we should give up on that."
> 
> More or less, yes.
> 
> > 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 wouldn't dream of putting any regular person on a Fedora
> install, quite frankly.

I do not know in what dreamland you live.

My wife has been running on Fedora since forever, and except some pain
points when we do an upgrade (usually every 2 release) all works just
fine.

If you are advocating for making fedora completely unusable please let
me know in advance so I can start doing my Red Hat work on some other
Linux distro ... I am sure you can read the irony ...


>  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 wouldn't put
> Fedora 17 on my uncle Bob's computer (I don't have an uncle Bob, this is
> just your hackneyed old 'regular person' example) and say 'there's your
> computer'. How many of us would? Even if you get a good Fedora release
> and don't hit problems with updates - which we don't do a _bad_ job of
> these days, admittedly - our releases really aren't quality general
> purpose OSes (we let all kinds of weirdnesses go into our releases which
> a serious user-facing OS would never let go), and after 12 months, you
> have to do an upgrade, which has about a 50/50 chance of exploding,
> let's face it. That's not a convincing stable general purpose operating
> system.
> 
> It's telling that when you meet 'normal people' who are running Fedora,
> they're usually using Fedora N-5, which hasn't had security updates for
> a year and a half. That's how 'normal people' use their computers - they
> don't upgrade every year and find it _fun_ to fix the upgrade process
> when it explodes. I don't think we're serving the (few) 'normal people'
> who run Fedora in this fashion very well, frankly. They'd probably be
> better off with something else.

No normal people run on N-1/N-2 and feel the pain points when they
switch to (a month or 2 old) N once N-2 goes out

> I realize my point of view here is somewhat radical, but you need the
> lunatic fringe around to keep people on their toes, I've always
> thought. ;)

I understand you surfing hyperbole here, but keep in mind that no users
means no developers.
Yes some people like to play with all cutting edge, but most people want
to "use" their distro too.

If it is too painful to stabilize every 6 months, may be we should
change to a rolling release for development, and cut stables only once a
year, to be maintained for 1 year only, I would totally love something
like that as long as the development version is more something like
debian testing/experimental than our current rawhide.

> > Compare it to "always cutting edge" like rawhide ... you can't get any
> > work done with that. It keeps breaking almost every second day.
> 
> Well, that's why I said two streams. One would be what Rawhide is now
> and the other would be pretty much branched/stable level.

rawhide would need to get a little bit more stable to be usable even by
developers in this scheme, doesn't need to be perfect but you can;t have
upgrades that break booting for most people (corner cases always exist
it's development). Currently there is ton of stuff that doesn't even
build until late in the release cycle.

>  On a broad
> conceptual level - there's several ways of doing this, of course. But my
> basic point is that the three stream idea works for a project like
> Debian, which has a conservative approach to everything and is able,
> over a very long timeframe, to produce something that actually *is* a
> stable operating system. It's not appropriate to a project like Fedora,
> which really isn't doing that. How often have we said we don't have the
> people interested in doing LTS releases, for instance? That's the kind
> of work you need to maintain a true 'stable' tier in a three-tier
> system. It's boring maintenance of long-dead code, and that's not
> generally what Fedora people are interested in. How many maintainers
> right now are doing a convincing job of maintaining F16? How many people
> are testing the updates? How many Fedora packagers wake up in the
> morning and think 'hey, what I really want to do today is carefully test
> and backport specific fixes to the F16 branches of my packages'?

Yes this is too much, but we *do* get updates for critical issues, and
not necessarily in form of a rebase.
If we cut the maintenance to one release (instead of the 2 we have now)
and switch deve

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]

On Fri, 2012-11-02 at 16:31 -0600, Kevin Fenzi wrote:
> On Fri, 02 Nov 2012 15:17:02 -0700
> Adam Williamson  wrote:
> 
> ..snip...
> 
> > If you're using a Fedora release today you're _already_ fighting OS
> > bugs more often than most people do, I'd say. I disagree with drago's
> > assertion that my description was of people who use Rawhide. It was
> > not intended to be, and it was drawn from the experience of me and
> > other people who do not run Rawhide. I almost never run Rawhide, only
> > Branched.
> 
> Perhaps you have your head too much in the Branched world right now?

Not really. I think I have my head more in the 'real' world than some
Fedora folks do though ;)

I usually run Branched on my desktop and current stable (F-N) on my
laptop. How stable is that? Well, the sound on my laptop broke with F17.
For several months. It only got fixed because I took the bug upstream
and then ensured the fix got ported down into Fedora...that's the
experience that *someone who knows how to get people to fix his bugs*
has with our product. Imagine the experience a normal person has.

> 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)

Sure, like I said in another mail, we've got better at that than before.
But as I also said in the same mail, you still have to do a version
upgrade every twelve months. That alone is ridiculous for a 'stable'
operating system.

I don't think we destabilize things - in the sense of 'you update and
your machine stops working' very often within a single one of our stable
releases. That isn't my point, really. My points are more:

* Upgrading every year, with an unreliable upgrade process, is not
something you have to do with a proper stable OS
* We do not insist on a level of polish or lack of functional regression
in our stable releases which is any way consistent with a true
productized general purpose OS

I'm as well placed as anyone to know _exactly_ what we as a project are
happy with signing off on as a final release, and based on my experience
working on, using, and doing user support for various distributions and
operating systems, I'm happy to maintain that that level is nowhere near
a level suitable for a general-purpose stable OS. Our standard for a
final release is, broadly, that the installer works pretty well, there
are no giant booboos on the desktop, and you can run the updater. We
don't care if a feature that was introduced in the previous release is
completely broken, unless it affects the critical path, we just say 'fix
it with an update'. We don't hold releases for cosmetic bugs, even
really obvious ones. We don't hold releases for usability issues. These
are all things that serious grown-up operating systems do.

That's fine. My posts have a general negative tone just based on the way
I'm constructing my argument, but it's important to realize I don't
think this is a _problem_. I think what we achieve is roughly what many
people who run Fedora want. But we _only_ achieve that level, and we
really don't need this unwieldy system of maintaining four releases at a
time to achieve it. My fundamental argument is there's a bit of a
disconnect between our release process - which is sort of aping the way
a stable general-purpose OS would be released, but on fast-forward and
with far fewer resources - and our actual goals for the project and the
standards we really enforce. We don't _need_ the heavy, constant release
cycle we currently employ in order to deliver the good things we already
currently deliver.

Anyway, I think the point is mashed into the ground by now, so I'll
stop. My proposal is more about trying to get people thinking at a
fundamental level than it is necessarily something I actually expect the
project to adopt wholesale - I just want to make the point that, in
designing whatever changes we may make to our processes, we should keep
a realistic view of what Fedora is actually _for_, and not over-engineer
things.
-- 
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: MPI updates

[Orion Poplawski]

On 11/01/2012 04:21 PM, Jussi Lehtola wrote:

On Thu, 01 Nov 2012 09:08:36 -0600
Orion Poplawski  wrote:

Some MPI updates:

- I built openmpi 1.6.3 in rawhide yesterday.  This had an unexpected
bump in the libmpi_f90.so soname.  I know this affects hdf5 and
netcdf-fortran, both my packages and I'll be rebuilding them later
today (hopefully).


Given that f18 has 1.6, I believe the same update should be made on f18
as well.



Sounds good. I'm holding off for now though because the soname bump in 
libmpi_f90.so may have been a mistake.  Waiting for word from upstream.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office  FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
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)))

[drago01]

On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson  wrote:
> [...]
> * Upgrading every year, with an unreliable upgrade process, is not
> something you have to do with a proper stable OS

I am not sure why you call it unreliable ... I *never* reinstall
unless I really had to (moving one installation from i386 to x86_64).
Otherwise I always upgrade using either anaconda back in the days and
then preupgrade.

There is some weird attitude that "upgrades don't work anyway people
should just reinstall". Not only is a reinstall a lot more work it is
just not something you could ask from a user to do every 6-12 months.

Technically there is no difference between an upgrade and package
updates just the package set is larger, it just makes dealing with
stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks
the whole system it will regardless whether you upgrade from FN-1 to
FN or doing a "yum update" in a rolling release.
-- 
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]

On Fri, 2012-11-02 at 16:04 -0700, Adam Williamson wrote:

> My fundamental argument is there's a bit of a
> disconnect between our release process - which is sort of aping the way
> a stable general-purpose OS would be released, but on fast-forward and
> with far fewer resources - and our actual goals for the project and the
> standards we really enforce. We don't _need_ the heavy, constant release
> cycle we currently employ in order to deliver the good things we already
> currently deliver.

Sorry, couldn't resist one more note on this; again with the emphasis on
'big picture' and 'historical perspective' that I like, I think it's
interesting to consider that the development schedule we use at present
is still more or less what Red Hat Linux was using, what, a decade ago?
I've been using Linux since around that time - 2000/2001 - and the 'six
month stable release cycle' was the norm even _then_. Yet back then
'Linux' was a far smaller world than it is now and far more static. In
recent releases the level of change has been, put into perspective,
frenetic. We seem to do massive rewrites on one fundamental chunk of
infrastructure after another. udev was considered a massive change back
in the day, which distros took years to adjust to; now we seem to toss
out bits of the bedrock on a weekly basis (hyperbole again, I know). We
seem to have been rewriting the whole cluster of systemd+udev
+udisks/DeviceKit+PolicyKit+dracut+plymouth+ConsoleKit - that whole ball
of wax - more or less constantly for several years (you may notice two
of the components in that list have been introduced and thrown away
within that space of time...one of them has been obsoleted *twice*), the
churn in that stack is crazy. We re-wrote the installer's storage code,
stopped for twenty seconds to take a breath, then introduced a new
bootloader and switched to GPT disk labels at the same time for an
encore. Now we're rewriting the entire installer UI...and we're planning
to switch to a revolutionary new filesystem whose userspace implications
have barely been mapped out...for the next release (I know this isn't an
official plan yet, but it's the stated intention of the btrfs devs). We
did the big change to kernel modesetting for graphics drivers. We
introduced PulseAudio. GNOME 3 and KDE 4 showed up. In the meantime
we've written and introduced an entire virtualization stack into the
distro, and added all kinds of other ambitious new features. And I'm
sure I'm not even scratching the surface. It kind of feels like for the
last five years we've been rewriting more or less the entire
distribution from top to bottom every few months (and this applies
outside of Fedora, albeit to a lesser extent, as well). It could be
memory playing tricks on me, but I'm pretty sure we didn't have anything
like that churn rate back when the six month release cycle became the de
facto 'industry standard' a decade or more ago.

This doesn't necessarily link into the 'rolling release model' argument
at all, it just seemed like an interesting perspective to keep in mind
in relation to the overall questions we're looking at here.
-- 
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)))

[Simo Sorce]

On Fri, 2012-11-02 at 16:04 -0700, Adam Williamson wrote:
> On Fri, 2012-11-02 at 16:31 -0600, Kevin Fenzi wrote:
> > On Fri, 02 Nov 2012 15:17:02 -0700
> > Adam Williamson  wrote:
> > 
> > ..snip...
> > 
> > > If you're using a Fedora release today you're _already_ fighting OS
> > > bugs more often than most people do, I'd say. I disagree with drago's
> > > assertion that my description was of people who use Rawhide. It was
> > > not intended to be, and it was drawn from the experience of me and
> > > other people who do not run Rawhide. I almost never run Rawhide, only
> > > Branched.
> > 
> > Perhaps you have your head too much in the Branched world right now?
> 
> Not really. I think I have my head more in the 'real' world than some
> Fedora folks do though ;)
> 
> I usually run Branched on my desktop and current stable (F-N) on my
> laptop. How stable is that? Well, the sound on my laptop broke with F17.
> For several months. It only got fixed because I took the bug upstream
> and then ensured the fix got ported down into Fedora...that's the
> experience that *someone who knows how to get people to fix his bugs*
> has with our product. Imagine the experience a normal person has.

Some time it is a bit painful, but on average it's ok, I've seen the
same kind of issues on any OS, imagine how nice it is to report a bug
like that to Microsoft or Apple ... in most cases you get back a: ask
your sound cared/laptop retailer ... and they will blame their OEM
and  ... if you are lucky they already solved it otherwise tough luck.

> Sure, like I said in another mail, we've got better at that than before.
> But as I also said in the same mail, you still have to do a version
> upgrade every twelve months. That alone is ridiculous for a 'stable'
> operating system.
> 
> I don't think we destabilize things - in the sense of 'you update and
> your machine stops working' very often within a single one of our stable
> releases. That isn't my point, really. My points are more:

I think you are confusing stable with LTS.

Stable means upgrade won't break what works, it doesn't mean that we
will fix all the known bugs and it also doesn't mean we maintain it
forever.
It does mean that it would be nice if upgrades were relatively smooth
and just plain possible.
And if you use a rolling developer model where upgrades *must* be
graceful, then you should get that for free, however you will need to do
a little bit more work to put stuff in development, just dumping the
latest upstream master tree snapshot and hoping it works won't cut it.
At the very least you need to do a smoke test upgrading from the
previous one.

> * 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 OSs
are maintained for longer time. A short release cycle puts a lot more
emphasis on working updates, but to be honest I haven't had huge issues
with Fedora, no more than I used to with debian/ubuntu
There are some cases were it went south on some releases and I had to
manually handle it. But then if that's a problem we could simply create
a /home partition by default and users can choose to reinstall just the
OS and keep the /home intact.
For a desktop that should be ok in all cases where you fear an upgrade
would be too dangerous.

> * We do not insist on a level of polish or lack of functional regression
> in our stable releases which is any way consistent with a true
> productized general purpose OS

Maybe if we cut stable releases to 1 we can improve this ?

The only real reason we maintain N-2 is that forcing a 6mo update on
everyone is just ridiculous, but a 1y cycle seems reasonable enough, and
with a rolling devel release there would be less reason for frequent
stable releases.

> I'm as well placed as anyone to know _exactly_ what we as a project are
> happy with signing off on as a final release, and based on my experience
> working on, using, and doing user support for various distributions and
> operating systems, I'm happy to maintain that that level is nowhere near
> a level suitable for a general-purpose stable OS. Our standard for a
> final release is, broadly, that the installer works pretty well, there
> are no giant booboos on the desktop, and you can run the updater. We
> don't care if a feature that was introduced in the previous release is
> completely broken, unless it affects the critical path, we just say 'fix
> it with an update'. We don't hold releases for cosmetic bugs, even
> really obvious ones. We don't hold releases for usability issues. These
> are all things that serious grown-up operating systems do.

I think this is ok, and also the reason why most people wait a month
after GA, it is usually fixed by then because *finally* developers moved
on the new "stable" release, discovered all the bigger issues, and fixed
them. It means that stable isn't really stable enough for less technical
users u

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]

On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote:
> On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson  wrote:
> > [...]
> > * Upgrading every year, with an unreliable upgrade process, is not
> > something you have to do with a proper stable OS
> 
> I am not sure why you call it unreliable ... I *never* reinstall

Because I read the forums =)

It's not usually terribly unreliable for me either. But I'm a smart
cookie like you. I update my systems with yum and I know what I have to
do to make it work properly - I follow the instructions and I know how
to wiggle my way around dependency issues. This is second nature to me
as I'm sure it is to you. You've probably dealt with bugs on upgrades
before that you've forgotten about, even. Also, I don't use third party
repositories. Normal people do. Especially with a distro like Fedora
which doesn't ship Flash, proprietary drivers, Chrome...

I've been hanging around user forums for Mandriva, Fedora and Ubuntu for
a decade now and I can tell you, every time a new release of any of
those comes out, the forums get a big dump of people with problems
upgrading. Regular as clockwork. has always happened, more or less will
always happen. operating system upgrades are an insoluble problem,
really. The number of variables involved in one is astronomical. Note
that neither Red Hat nor Microsoft actually support major version
upgrades for their operating systems, both of which have exponentially
more testing done on them, much lower levels of churn, and much smaller
sets of packages. (Also note how much trouble phone companies have
updating Android.)

I also know what we do to test upgrades before we sign off on a release,
which is 'do a clean install of F-N in a VM and check it can be upgraded
to F-N+1'. If that passes, we ship. That is not a level of testing which
allows me to declare with confidence that our upgrade process is solid
and reliable ;)

> unless I really had to (moving one installation from i386 to x86_64).
> Otherwise I always upgrade using either anaconda back in the days and
> then preupgrade.
> 
> There is some weird attitude that "upgrades don't work anyway people
> should just reinstall". Not only is a reinstall a lot more work it is
> just not something you could ask from a user to do every 6-12 months.
> 
> Technically there is no difference between an upgrade and package
> updates just the package set is larger, it just makes dealing with
> stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks
> the whole system it will regardless whether you upgrade from FN-1 to
> FN or doing a "yum update" in a rolling release.

Well, kinda. The advantage of a rolling release is that it tends to
narrow the focus. You don't have a million people hitting five hundred
potentially destabilizing updates all at once; you have a million people
all getting one potentially destabilizing update at a time (or, at
least, a fairly small set at a time). When everyone starts yelling, you
can just look at what got updated the night before and probably find the
culprit. That's what happens with Rawhide, after all. And anyway, I
don't think a rolling release would be *better* from this point of view
- as with my other points, I think a rolling release would allow us to
do *just as well* while reducing our testing and development overheads.

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.
-- 
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)))

[Simo Sorce]

On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote:
> On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson  wrote:
> > [...]
> > * Upgrading every year, with an unreliable upgrade process, is not
> > something you have to do with a proper stable OS
> 
> I am not sure why you call it unreliable ... I *never* reinstall
> unless I really had to (moving one installation from i386 to x86_64).

On one machine I did upgrade from i386 -> x86_64 just for fun.
Sure I had to drop in single user 3-4 times and manually install some
rpm but eventually I got it done (it was a VM ;)

> Otherwise I always upgrade using either anaconda back in the days and
> then preupgrade.
> 
> There is some weird attitude that "upgrades don't work anyway people
> should just reinstall". Not only is a reinstall a lot more work it is
> just not something you could ask from a user to do every 6-12 months.

it would be nice to squash 2 release cycles and use the gained time to
make a better upgrade process imo.

> Technically there is no difference between an upgrade and package
> updates just the package set is larger, it just makes dealing with
> stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks
> the whole system it will regardless whether you upgrade from FN-1 to
> FN or doing a "yum update" in a rolling release.

+1

however there is a difference, sometime many little changes over time
can run much smoother than one big change at once where you go tfrom pkg
release N-10 to N

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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)))

[Michał Piotrowski]

Hi,

2012/11/3 Adam Williamson :
> Note
> that neither Red Hat nor Microsoft actually support major version
> upgrades for their operating systems

Just take a look at this - MS rocks here
http://www.youtube.com/watch?v=vPnehDhGa14

-- 
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/
-- 
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)))

[drago01]

On Sat, Nov 3, 2012 at 12:32 AM, Adam Williamson  wrote:
> On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote:
>> On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson  wrote:
>> > [...]
>> > * Upgrading every year, with an unreliable upgrade process, is not
>> > something you have to do with a proper stable OS
>>
>> I am not sure why you call it unreliable ... I *never* reinstall
>
> Because I read the forums =)
>
> It's not usually terribly unreliable for me either. But I'm a smart
> cookie like you. I update my systems with yum and I know what I have to
> do to make it work properly - I follow the instructions and I know how
> to wiggle my way around dependency issues. This is second nature to me
> as I'm sure it is to you. You've probably dealt with bugs on upgrades
> before that you've forgotten about, even. Also, I don't use third party
> repositories. Normal people do. Especially with a distro like Fedora
> which doesn't ship Flash, proprietary drivers, Chrome...
>
> I've been hanging around user forums for Mandriva, Fedora and Ubuntu for
> a decade now and I can tell you, every time a new release of any of
> those comes out, the forums get a big dump of people with problems
> upgrading.

What kind of problems? "I did upgrade and now my sound card does not
work?" or actually problems with the upgrade itself?
The former would just have happened with a reinstall as well.


> The number of variables involved in one is astronomical. Note
> that neither Red Hat nor Microsoft actually support major version
> upgrades for their operating systems,

Microsoft does. They do even sell upgrade boxes ...

> 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
why they don't support upgrades.

> (Also note how much trouble phone companies have
> updating Android.)

That has more to do with how bad forking is for maintenance ... we
don't really have this problem in fedora (ubuntu is driving themselves
into this corner but that's OT).

> I also know what we do to test upgrades before we sign off on a release,
> which is 'do a clean install of F-N in a VM and check it can be upgraded
> to F-N+1'. If that passes, we ship. That is not a level of testing which
> allows me to declare with confidence that our upgrade process is solid
> and reliable ;)

Well it means that the process works. Everything else are bugs in the
packages itself which you would have hit during a normal yum update
otherwise.

>> unless I really had to (moving one installation from i386 to x86_64).
>> Otherwise I always upgrade using either anaconda back in the days and
>> then preupgrade.
>>
>> There is some weird attitude that "upgrades don't work anyway people
>> should just reinstall". Not only is a reinstall a lot more work it is
>> just not something you could ask from a user to do every 6-12 months.
>>
>> Technically there is no difference between an upgrade and package
>> updates just the package set is larger, it just makes dealing with
>> stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks
>> the whole system it will regardless whether you upgrade from FN-1 to
>> FN or doing a "yum update" in a rolling release.
>
> Well, kinda. The advantage of a rolling release is that it tends to
> narrow the focus. You don't have a million people hitting five hundred
> potentially destabilizing updates all at once; you have a million people
> all getting one potentially destabilizing update at a time (or, at
> least, a fairly small set at a time). When everyone starts yelling, you
> can just look at what got updated the night before and probably find the
> culprit. That's what happens with Rawhide, after all. And anyway, I
> don't think a rolling release would be *better* from this point of view
> - as with my other points, I think a rolling release would allow us to
> do *just as well* while reducing our testing and development overheads.
>
> 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.

But then you have to deal with this kind of stuff every time you
update something. That's not really usable if you want to get work
done.
While the bigger upgrade leaves only hits you once or twice a year.
-- 
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]

On Sat, 2012-11-03 at 00:44 +0100, drago01 wrote:

> > The number of variables involved in one is astronomical. Note
> > that neither Red Hat nor Microsoft actually support major version
> > upgrades for their operating systems,
> 
> Microsoft does. They do even sell upgrade boxes ...

Well, it's a bit complicated. They didn't support 'true' upgrades from
XP to Win 7, for instance - the 'upgrade' process just did a fresh
install and then tried to copy back 'important' stuff like your desktop
layout. And if it goes wrong...well you can call tech support and
they'll do their best, but you're not getting a refund. And Windows
upgrades *do* go wrong. Corporate deployments of Windows, to my
knowledge, virtually never rely on the upgrade functionality.

> > 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
> why they don't support upgrades.

True, that was a bad point; the average rate of churn is lower but the
churn between any two releases is big.

> > (Also note how much trouble phone companies have
> > updating Android.)
> 
> That has more to do with how bad forking is for maintenance ... we
> don't really have this problem in fedora (ubuntu is driving themselves
> into this corner but that's OT).
> 
> > I also know what we do to test upgrades before we sign off on a release,
> > which is 'do a clean install of F-N in a VM and check it can be upgraded
> > to F-N+1'. If that passes, we ship. That is not a level of testing which
> > allows me to declare with confidence that our upgrade process is solid
> > and reliable ;)
> 
> Well it means that the process works. Everything else are bugs in the
> packages itself which you would have hit during a normal yum update
> otherwise.

That's an oversimplification. A stock install only has a small part of
our *official* package set installed. Any given user's system might have
any of the others installed, or any third party repo (including a
graphics driver from a third party repo). On some upgrades we reinstall
the bootloader or do other disruptive things. And again, I'm not saying
we could do upgrades better; the fact that 'it'd be just as bad with
yum' is besides the point. My point is that major version upgrades are
such an intrinsically unreliable operation that any workflow which
requires people to do one once a year has problems. They're not
something you can realistically expect people to rely on.

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?

> > 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.
> 
> But then you have to deal with this kind of stuff every time you
> update something. That's not really usable if you want to get work
> done.
> While the bigger upgrade leaves only hits you once or twice a year.

My position is that the people who use Fedora and the kind of people we
really _want_ to use Fedora can cope with it. 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. Remember, I mentioned the kernel team as
a model; despite my sound gripe, they seem to be managing pretty well in
bumping older releases to newer kernels without causing massive
breakage. They do cause some problems...but we get 'some problems'
anyway.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mail

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]

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.
-- 
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)))

[Reindl Harald]

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

Filesystem created: Mon Aug 18 06:48:05 2008

this is the rootfs, which means it was installed with F9
now it has F17, this machine is from the same golden-master
as any other machine in the whole company and there is running
any service you can imagine on Fedora in production

ANY upgrade was done with yum

so NO fedora is not as bad as you thin in upgrades
the really important ting it that it does not get worser!

YES these are Vmware-guests and that is why UPGRADES becoming
more and more important - the times where you plan new hardware
and install it with a new OS are gone

these days you install the OS on hardware X, buy hardware Y
and move the whole setup live to the new hardware, the same
i am doing even for physical setups on RAID10 - bouy a new
machine, start it with the old disks, maybe re-create the
initrd and AFTER that if i find it nice change disk by
disk and re-sync the RAID or even stuck on the old disks


[root@arrakis:~]$ tune2fs -l /dev/sdb1
tune2fs 1.42.3 (14-May-2012)
Filesystem volume name:   /
Last mounted on:  /
Filesystem UUID:  918f24a7-bc8e-4da5-8a23-8800d5104421
Filesystem magic number:  0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features:  has_journal ext_attr resize_inode dir_index filetype 
needs_recovery extent flex_bg
sparse_super large_file uninit_bg dir_nlink
Filesystem flags: signed_directory_hash
Default mount options:journal_data_writeback
Filesystem state: clean
Errors behavior:  Continue
Filesystem OS type:   Linux
Inode count:  393216
Block count:  1572354
Reserved block count: 15723
Free blocks:  999376
Free inodes:  325103
First block:  0
Block size:   4096
Fragment size:4096
Reserved GDT blocks:  383
Blocks per group: 32768
Fragments per group:  32768
Inodes per group: 8192
Inode blocks per group:   512
Filesystem created:   Mon Aug 18 06:48:05 2008
Last mount time:  Sun Oct 28 19:00:37 2012
Last write time:  Sun Oct 28 19:00:36 2012
Mount count:  18
Maximum mount count:  -1
Last checked: Tue Mar 27 00:36:36 2012
Check interval:   31104000 (12 months)
Next check after: Thu Mar 21 23:36:36 2013
Lifetime writes:  1119 GB
Reserved blocks uid:  0 (user root)
Reserved blocks gid:  0 (group root)
First inode:  11
Inode size:   256
Journal inode:8
First orphan inode:   34371
Default directory hash:   tea
Directory Hash Seed:  1e9d689f-15fe-4c0d-aaba-9d323049c7f4
Journal backup:   inode blocks




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

[Michael Ekstrand]

On 11/02/2012 04:53 PM, Tom Lane wrote:
> Adam Williamson  writes:
>> On Fri, 2012-11-02 at 21:07 +0100, drago01 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.
> 
> Uh, no.  What you describe is usable by the kind of people who use
> rawhide.  Which is what, 1% of our user base?  If that.
> 
> Abandoning any pretense of having stable releases will eliminate a huge
> fraction of the user community.  For sure it will eliminate *me*.  I'm
> not in the business of fighting OS bugs every single day, and I will not
> be forced into that business.  I have other things that I'm more
> productive at.

+1. One of the major reasons I came to Fedora (after a long tour that
took me through Slackware, Gentoo, Debian Testing, Ubuntu, with brief
stints elsewhere) is that it has releases. Real releases, with most
major changes happening with the new release.

I ran Debian Testing for several years, and encountered a problem. I was
spending too time paying attention to changes and new software
developments, and when they might hit my system, at the expense of
getting work done.

It's purely selfish, my psychology, etc., but I personally basically
need a release, so I can batch up all my "ooh, what's this shiny new
thing?" tendencies in a few days twice a year, rather than an hour here
and an hour there.

Having used Fedora now since F15, I've personally found the releases to
be quite reliable and usable, with just enough software updating over
their lifecycle to keep my laptop rather comfortable. And better than my
brief previous Fedora experience back around F9, when every other kernel
update broke my wireless card[1].

Best,
- Michael

1. Literally. Whether or not my wireless networking worked toggled with
each kernel update with remarkable consistency. I'm glad things are
better now.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Coordinating libffi upgrade

[Matthew Miller]

On Fri, Nov 02, 2012 at 03:23:48PM -0700, Toshio Kuratomi wrote:
> And has been since August.  Development starts when rawhide and F-next
> branch.

We need some way to put this in bigger letters.


-- 
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)))

[Stephen John Smoogen]

On 2 November 2012 17:36, 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
>
> Just take a look at this - MS rocks here
> http://www.youtube.com/watch?v=vPnehDhGa14

Support is an  overloaded word. You and Adam are using it differently
so it of course it is going to conflict.

There is a huge difference from it will work and they will support it.
Adam is talking about the fact that if your upgrade breaks you will
get 0 support from Microsoft to fix it. That only comes with special
platinum contracts where they will come in before hand, make sure that
it might work, run it on their own machines first, and the do it for
you.


-- 
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] Fedora 18 Beta Test Compose 7 (TC7) Available Now!

[Andre Robatino]

As per the Fedora 18 schedule [1], Fedora 18 Beta Test Compose 7 (TC7)
is now available for testing. Content information, including changes,
can be found at https://fedorahosted.org/rel-eng/ticket/5349#comment:19
. Please see the following pages for download links (including delta
ISOs) and testing instructions. Normally dl.fedoraproject.org should
provide the fastest download, but download-ib01.fedoraproject.org is
available as a mirror (with an approximately 1 hour lag) in case of
trouble. To use it, just replace "dl" with "download-ib01" in the
download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Ideally, all Alpha and Beta priority test cases for Installation [2],
Base [3], and Desktop [4] should pass in order to meet the Beta Release
Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6],
or on the test list [7].

Create Fedora 18 Beta test compose (TC) and release candidate (RC)
https://fedorahosted.org/rel-eng/ticket/5349

Current Blocker and NTH bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://jreznik.fedorapeople.org/schedules/f-18/f-18-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Base_validation_testing
[4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[5] https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
[6] irc://irc.freenode.net/fedora-qa
[7] https://admin.fedoraproject.org/mailman/listinfo/test



signature.asc
Description: OpenPGP digital signature
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Hello, I am looking for a sponsor

[Sébastien Boisvert]

Hello,

I am looking for a sponsor.

I am Canadian, I know French, English, and many programming languages. I use 
Fedora 17 on
my Lenovo Thinkpad x230 and I have started using Linux in 2003 on a Red Hat 9 
installation.
Over the years, I have used: Slackware, Ubuntu, Gentoo, Fedora, CentOS, Mint, 
Debian.

I strongly believe in free software for the common good of humanity. The 
biggest disease in
Windows(R) is the bundling of libraries in everything. Package dependencies 
solve the
bundling problem and is one of the biggest strengths of Linux distributions.

I like the "delta RPM" thing in yum, that's one of the reason I use Fedora.

I am a Ph.D. student doing high-performance computing. In particular, I write 
programs
in C++ 1998 using MPI 2.2. One of my creations is Ray -- a distributed de novo 
assembler
for genomics. [1]

My personal site is [2] and my github is [3]. My tools are vim, git, screen, 
ssh, gprof,
gdb, and the likes. I use git a lot. I don't like using Google Docs, I prefer 
emails and
terminals and LaTeX too.

According to the Fedora documentation [4], I can acquire sponsorship either by 
"Submitting quality
new packages" and/or by "Reviewing packages"  and/or "Become a co-maintainer".

The problem with packaging in bioinformatics is that a sizable number of 
software pieces
contains bundles (like Velvet ships with zlib for instance, and tophat ships 
with SeqAn if
I am not mistaken).

Reading Review Requests (bioinformatics) in Red Hat Bugzilla indicates that 
almost all
"blocked" packages contain too many bundles and they are simply too painful to 
sort out (because
of patchy bundles that differ from upstream, for instance).

Ray is a high-quality software, and it does not bundle any library (the famous 
bundling problem).
The only dependency are zlib, libbz2 and a mpi library (like openmpi).

I think in that regard that my new package [5] is of high-quality. Ray is on 
its way too
for being included in Debian [6], and Ubuntu too I believe.

As it can be seen on the Ray mailing list [7], I give good support for what I 
do.

So I need a sponsor for my package to be distributed by Fedora.

I can answer questions about myself as the sponsorship I am seeking is not for 
my Ray
package, but for me.

p.s.: I have a blog too [8] and my current array of research is about hybrid 
programming
models, particularly one called "mini-ranks" that I devised with some 
researchers when I
visited Argonne National Laboratory a few weeks ago. [9]

---
Sébastien Boisvert

[1] http://denovoassembler.sourceforge.net/
[2] http://boisvert.info/
[3] http://github.com/sebhtml
[4] 
http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Convincing_someone_to_sponsor_you
[5] https://bugzilla.redhat.com/show_bug.cgi?id=872783
[6] http://anonscm.debian.org/gitweb/?p=debian-med/ray.git
[7] 
http://sourceforge.net/mailarchive/forum.php?forum_name=denovoassembler-users
[8] http://blog.boisvert.info/
[9] 
http://blog.boisvert.info/2012/11/new-mini-ranks-hybrid-programming-model.html
--
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))

[Rahul Sundaram]

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

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel