On Wed, 2012-11-21 at 14:01 -0600, David Lehman wrote:
On Wed, 2012-11-21 at 12:09 -0600, Ian Pilcher wrote:
On 10/19/2012 10:01 AM, David Lehman wrote:
This is the main piece of functionality that's still missing: allocating
devices from preexisting VGs.
You can create and destroy
On 10/19/2012 10:01 AM, David Lehman wrote:
This is the main piece of functionality that's still missing: allocating
devices from preexisting VGs.
You can create and destroy lvm devices. You can reuse existing LVs,
optionally reformatting them. You can encrypt or decrypt them. What you
On Wed, 2012-11-21 at 12:09 -0600, Ian Pilcher wrote:
On 10/19/2012 10:01 AM, David Lehman wrote:
This is the main piece of functionality that's still missing: allocating
devices from preexisting VGs.
You can create and destroy lvm devices. You can reuse existing LVs,
optionally
On 11/21/2012 03:01 PM, David Lehman wrote:
snip
Yes. I've just completed testing of patches for this stuff. It was
decided that it's too late to try to get them into the Beta. I can
provide you with an updates image that adds the functionality if you are
interested.
David
I, for one, would
On 11/21/2012 02:01 PM, David Lehman wrote:
On Wed, 2012-11-21 at 12:09 -0600, Ian Pilcher wrote:
It looks like this is still the case in beta RC1, right?
Yes. I've just completed testing of patches for this stuff. It was
decided that it's too late to try to get them into the Beta. I can
On Mon, 05 Nov 2012 13:53:37 +0100, Ralf Corsepius wrote:
That's called CentOS,
Nope ... CentOS/RHEL is a different end of extremes.
7 years+ life-time, no API changes, etc.
What is lacking is a middle ground between Fedora and CentOS.
Something with a life-time of ~2 years, with API
On 11/05/2012 09:39 AM, drago01 wrote:
On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore den...@ausil.us wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Wed, 31 Oct 2012 10:59:54 -0700
Jesse Keating jkeat...@j2solutions.net escribió:
On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
*
mike cloaked píše v Ne 04. 11. 2012 v 21:44 +:
On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann jeisc...@redhat.com
wrote:
This is a very valid argument. I understand this is a devel
list, so we should stay on the technical level, but if we
On Monday, November 05, 2012 06:56 PM, Jiri Eischmann wrote:
mike cloaked píše v Ne 04. 11. 2012 v 21:44 +:
On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann jeisc...@redhat.com
wrote:
This is a very valid argument. I understand this is a devel
list, so we should stay on
On 11/05/2012 01:13 PM, Mathieu Bridon wrote:
On Monday, November 05, 2012 06:56 PM, Jiri Eischmann wrote:
mike cloaked píše v Ne 04. 11. 2012 v 21:44 +:
Does anyone have any reliable statistics about the number of users who
feel that release parties and codenames are important to them?
On Mon, Nov 5, 2012 at 10:56 AM, Jiri Eischmann eischm...@redhat.comwrote:
Release parties and codenames were just examples. It's about the buzz
around releases. You can check Google Trends where you find peaks in
number of searches for Fedora after every release. Or fp.org monthly
stats.
On 11/05/2012 01:11 AM, Matěj Cepl wrote:
On Fri, 02 Nov 2012 20:55:38 +, Jóhann B. Guðmundsson wrote:
and one stable release ( valid for 2 maybe 3 years ) for those in the
community that want something they dont constantly having to upgrade to
and can deploy on their servers. ( ofcourse to
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
On Sun, 2012-11-04 at 19:47 +0200, Alek Paunov wrote:
On 04.11.2012 19:25, Simo Sorce wrote:
note that this is also our strength in some respect because it allows
the system to evolve a lot more quickly, but it also means upgrades are
Indeed.
simply going to break stuff, and that's
On Mon, Nov 05, 2012 at 08:35:53 -0500,
Kamil Paral kpa...@redhat.com wrote:
My idea would be to have two releases:
== Fedora Stable ==
* A release for general users with low volume of security fixes and important
bug fixes.
** Bug fixes would be pushed monthly and QA would be performed on
On Mon, Nov 5, 2012 at 5:56 AM, Jiri Eischmann eischm...@redhat.com wrote:
Release parties and codenames were just examples. It's about the buzz
around releases. You can check Google Trends where you find peaks in
number of searches for Fedora after every release. Or fp.org monthly
stats. You
Tom Lane t...@redhat.com wrote:
Simon Lukasik isim...@fedoraproject.org writes:
Currently, each Fedora release is kept alive for 13(+/-) months.
There
were dozens of threads about shortening or prolonging period -- but I
am
not sure if something like the following has been ever discussed:
Hi,
If/when the real work behind a feature has been done early enough,
getting from Fedora alpha to final consists of just a few bugfixes
Ah well.. only if everybody else did this so all the dependencies are stable.
In which case you just moved the development freeze to earlier date. No
On 11/02/2012 07:04 PM, Adam Williamson wrote:
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.
This is an
* A release for general users with low volume of security fixes and
important bug fixes.
** Bug fixes would be pushed monthly and QA would be performed on
this monthly batch of updates.
Some packages need more than bug fix updates (unless you are taking a
very
broad view of what a bug is).
This tool is still not going to be able to do magic and there will
be
config
things that still need to be redone. Third party repos will still
be
an issue.
It's a clean installation, I don't think it needs any magic. Also
third-party repos are not a problem, we just ignore them and
On Mon, Nov 05, 2012 at 13:23:59 -0500,
Kamil Paral kpa...@redhat.com wrote:
This tool is still not going to be able to do magic and there will
be
config
things that still need to be redone. Third party repos will still
be
an issue.
It's a clean installation, I don't think it needs any
On Mon, Nov 5, 2012 at 6:34 PM, Bruno Wolff III br...@wolff.to wrote:
It's a clean installation, I don't think it needs any magic. Also
third-party repos are not a problem, we just ignore them and they
won't influence the new system. People will add them manually again
once in 18 months.
From: Jóhann B. Guðmundsson johan...@gmail.com
On 11/05/2012 05:28 PM, Przemek Klosowski wrote:
On 11/02/2012 07:04 PM, Adam Williamson wrote:
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
On 4 November 2012 23:57, drago01 drag...@gmail.com wrote:
On Sun, Nov 4, 2012 at 6:55 PM, Adam Williamson awill...@redhat.com wrote:
On Sun, 2012-11-04 at 12:18 -0500, Simo Sorce wrote:
On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
Hi,
2012/11/3 Adam Williamson
On 05.11.2012 15:57, Simo Sorce wrote:
A possibly viable alternative for the ABIs freezing (which we can not
ensure anyway) is the C/C++/etc tooling - If we arm upstreams, packagers
and 3rd parties with powerful source tools (API migration/checking),
just like Google does internally, unsing the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Mon, 5 Nov 2012 08:39:54 +0100
drago01 drag...@gmail.com escribió:
On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore den...@ausil.us
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Wed, 31 Oct 2012 10:59:54 -0700
Jesse Keating
Hmm, actually I have new proposal.
Policy about active/inactive maintainers should be decided only by actual
maintainers. In the true meritocracy way - if you don't maintain anything you
don't have a say.
Alexander Kurtakov
Red Hat Eclipse team
- Original Message -
From: Reindl
How does it sound? Really like the right way to build community by excluding
people? Think about this more before trying to screw others work? Your feature
might mean nothing for someone else if you want to see it happen step in and do
your part and don't tell people that there work should be
Le samedi 03 novembre 2012 à 09:29 -0700, Adam Williamson a écrit :
On Sat, 2012-11-03 at 11:28 +, mike cloaked wrote:
Others may wish to compare Fedora with other distributions also - but
one thought I had was that in Archlinux there are only two repos to
maintain - whilst in Fedora
On 11/04/2012 12:17 PM, Michael Scherer wrote:
Le samedi 03 novembre 2012 à 09:29 -0700, Adam Williamson a écrit :
On Sat, 2012-11-03 at 11:28 +, mike cloaked wrote:
Others may wish to compare Fedora with other distributions also - but
one thought I had was that in Archlinux there are
On 11/03/2012 12:30 AM, Simo Sorce wrote:
On Fri, 2012-11-02 at 16:04 -0700, Adam Williamson wrote:
* Upgrading every year, with an unreliable upgrade process, is not
something you have to do with a proper stable OS
On some stable OSs you cannot upgrade *at all*. It is true that some OSs
Panu Matilainen pmati...@laiskiainen.org writes:
On 11/04/2012 12:17 PM, Michael Scherer wrote:
And I am doubting that changing the release model will suddenly make
people do QA.
Adam's point is that reducing the number of branches requiring QA should
permit more thorough QA with the scarce
Simon Lukasik isim...@fedoraproject.org writes:
Currently, each Fedora release is kept alive for 13(+/-) months. There
were dozens of threads about shortening or prolonging period -- but I am
not sure if something like the following has been ever discussed:
Each N-th Fedora release -- where
nobody here is screwing others work
teh topic is how about to find out AUTOMATICALLY which are
they doing the work and which things are orphaned without
finding it out the hard way in the running release cycle
and if you need to find out things automatically you need
any flag to measure - this
Am 04.11.2012 17:05, schrieb Tom Lane:
Simon Lukasik isim...@fedoraproject.org writes:
Currently, each Fedora release is kept alive for 13(+/-) months. There
were dozens of threads about shortening or prolonging period -- but I am
not sure if something like the following has been ever
On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
Hi,
2012/11/3 Adam Williamson awill...@redhat.com:
Note
that neither Red Hat nor Microsoft actually support major version
upgrades for their operating systems
Adam, this is plainly untrue for Microsoft, they always supported
On Sat, 2012-11-03 at 00:44 +0100, drago01 wrote:
much lower levels of churn,
No they actually have way higher levels of churn ... just think about
it ... in fedora we are talking about 6 months worth of chrun not 5+
years. Can't speak for Red Hat but maybe this is one of the reasons
why
On 04.11.2012 19:25, Simo Sorce wrote:
note that this is also our strength in some respect because it allows
the system to evolve a lot more quickly, but it also means upgrades are
Indeed.
simply going to break stuff, and that's not so great for desktop
environments and scare the hell off
On Sun, 2012-11-04 at 12:18 -0500, Simo Sorce wrote:
On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
Hi,
2012/11/3 Adam Williamson awill...@redhat.com:
Note
that neither Red Hat nor Microsoft actually support major version
upgrades for their operating systems
Adam,
On 11/04/2012 05:05 PM, Tom Lane wrote:
Simon Lukasik isim...@fedoraproject.org writes:
Currently, each Fedora release is kept alive for 13(+/-) months. There
were dozens of threads about shortening or prolonging period -- but I am
not sure if something like the following has been ever
The point is that such a measurement serves nothing but pissing off people.
You need to track activity on packages - how long bugs stay open without
response (note that this doesn't mean becoming accepted as one might be busy
with other things), how long the package stay with open CVEs, what is
For microsoft perhaps, but Ubuntu, Debian ? Upgrading from a release
to the next is trivial, and in general work well. Sure, probably the
update to the core system component is more light, no Usrmove, no
systemd, or something like this. And preserving, updating the new
configuration based on the
Le dimanche 04 novembre 2012 à 13:19 -0500, Aleksandar Kurtakov a
écrit :
The point is that such a measurement serves nothing but pissing off people.
You need to track activity on packages - how long bugs stay open without
response
(note that this doesn't mean becoming accepted as one might
- Original Message -
From: Bruno Wolff III br...@wolff.to
To: Kevin Fenzi ke...@scrye.com
Cc: devel@lists.fedoraproject.org
Sent: Saturday, November 3, 2012 7:37:45 PM
Subject: Re: Rolling release model philosophy (was Re: Anaconda is totally
trashing the F18 schedule (was Re:
On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann jeisc...@redhat.com wrote:
This is a very valid argument. I understand this is a devel list, so we
should stay on the technical level, but if we discuss such broad changes
that affect the whole project, we should also take into account other
On Fri, 02 Nov 2012 20:55:38 +, Jóhann B. Guðmundsson wrote:
and one stable release ( valid for 2 maybe 3 years ) for those in the
community that want something they dont constantly having to upgrade to
and can deploy on their servers. ( ofcourse to have a stable release we
first and
On Fri, 02 Nov 2012 13:22:21 -0700, Adam Williamson wrote:
I disagree. It's usable by the kind of people who use Fedora. Who like
shiny cutting-edge stuff and don't mind dealing with wonkiness
constantly. I wouldn't dream of putting any regular person on a Fedora
install, quite frankly. It's
On Fri, 02 Nov 2012 13:32:33 +, Richard W.M. Jones wrote:
If you substitute 'unstable' for level 1, 'testing' for level 2 and
'stable' for level 3, then this is not dissimilar to how Debian
operates.
Sure, and if you eliminate level 3 (which leads to multi-year-long
freezes), then you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Wed, 31 Oct 2012 10:59:54 -0700
Jesse Keating jkeat...@j2solutions.net escribió:
On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
* Jesse Keating, Jeremy Katz, and others who helped shape the
current policy and theory of our release schedule
Michael,
Without contributors there is no need for infrastructure, right? ;)
To me it means that we need more contributors working on infrastructure (as on
every other aspect of the distro) not pruning.
Alexander Kurtakov
Red Hat Eclipse team
- Original Message -
From: Michael Scherer
On Sun, Nov 4, 2012 at 6:55 PM, Adam Williamson awill...@redhat.com wrote:
On Sun, 2012-11-04 at 12:18 -0500, Simo Sorce wrote:
On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
Hi,
2012/11/3 Adam Williamson awill...@redhat.com:
Note
that neither Red Hat nor Microsoft
* drago01 [05/11/2012 08:00] :
That's like selling a car and telling the customer it might not move
at all in that case you are on your own sorry.
This is par the course for proprietary software (with the added bonus
that you can't actually fix it since you don't have the source code).
On Mon, Nov 5, 2012 at 8:02 AM, Emmanuel Seyman emman...@seyman.fr wrote:
* drago01 [05/11/2012 08:00] :
That's like selling a car and telling the customer it might not move
at all in that case you are on your own sorry.
This is par the course for proprietary software (with the added bonus
On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore den...@ausil.us wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Wed, 31 Oct 2012 10:59:54 -0700
Jesse Keating jkeat...@j2solutions.net escribió:
On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
* Jesse Keating, Jeremy Katz, and others
- Original Message -
From: drago01 drag...@gmail.com
To: Development discussions related to Fedora
devel@lists.fedoraproject.org
Sent: Monday, November 5, 2012 9:39:54 AM
Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how
to install into a LVM partitions
Le samedi 03 novembre 2012 à 11:19 +0530, Rahul Sundaram a écrit :
On Fri, Nov 2, 2012 at 10:25 PM, Reindl Harald wrote:
well, it would maybe a start to DROP packages which are still
missing systemd-units
On 11/03/2012 08:17 AM, Michael Scherer wrote:
Le samedi 03 novembre 2012 à 11:19 +0530, Rahul Sundaram a écrit :
On Fri, Nov 2, 2012 at 10:25 PM, Reindl Harald wrote:
well, it would maybe a start to DROP packages which are still
missing systemd-units
On Fri, 2012-11-02 at 13:22 -0700, Adam Williamson wrote:
I disagree with that. Fedora releases had some small regression
introduced via updates from time but is is *very* usable as a stable
operating system.
I disagree. It's usable by the kind of people who use Fedora. Who like
shiny
On Fri, Nov 2, 2012 at 10:31 PM, Kevin Fenzi ke...@scrye.com wrote:
On Fri, 02 Nov 2012 15:17:02 -0700
Adam Williamson awill...@redhat.com wrote:
..snip...
In my experience, in the last few years, Fedora stable releases have
become much more stable. My stable boxes here at home I have not
On Sat, Nov 3, 2012 at 12:37 PM, Henrique Junior henrique...@gmail.com wrote:
It is difficult, for example, to understand why we have to wait until the
next release to have LibreOffice 3.6, since this seems an non disruptive
update that could bring major improvements in the productivity of
On Fri, Nov 02, 2012 at 16:32:00 -0700,
Adam Williamson awill...@redhat.com wrote:
On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote:
In a rolling release model, everyone deals with foo-1.0 to foo-2.0, then
a week later they deal with bar-1.0 to bar-2.0, then a week later they
deal with
On Sat, Nov 03, 2012 at 12:35:08PM +0200, Nikos Roussos wrote:
I understand that regular users are not Fedora's main target, but it
is a general-purpose operating system in the sense that it can be used
by people who want to have a stable working environment with all the
latest things from the
* Jóhann B. Guðmundsson [02/11/2012 20:34] :
That package would hardly be un-maintained if it has co-maintainers
now does it...
Absolutely. Hence my request that any process we put in place be
package-focused rather than maintainer-focused.
Emmanuel
--
devel mailing list
On Sat, 2012-11-03 at 10:52 +0100, drago01 wrote:
On Sat, Nov 3, 2012 at 12:58 AM, Adam Williamson awill...@redhat.com wrote:
My position is that the people who use Fedora and the kind of people we
really _want_ to use Fedora can cope with it.
Maybe the majority can maybe they can't. But
On Sat, 2012-11-03 at 11:28 +, mike cloaked wrote:
Others may wish to compare Fedora with other distributions also - but
one thought I had was that in Archlinux there are only two repos to
maintain - whilst in Fedora it is 5 repos! One might wonder whether
there is less effort needed to
On Sat, 2012-11-03 at 09:37 -0200, Henrique Junior wrote:
The guys behind openSUSE created a good approach with Tumbleweed. By
adding this repo users can opt-in to the (semi)rolling model.
Tumbleweed is more like a pool where updated, stable, non disruptive
software can be installed and I was
Am 03.11.2012 01:09, schrieb Adam Williamson:
On Sat, 2012-11-03 at 01:07 +0100, Reindl Harald wrote:
Am 03.11.2012 00:58, schrieb Adam Williamson:
Microsoft don't really expect you to upgrade Windows. They expect you to
buy a computer with Windows X on it, use it for three years, then throw
Am 03.11.2012 11:35, schrieb Nikos Roussos:
In that sense, and from my point of view, if we had to rethink our release
model and dedicate time and energy on a
new approach, it would make more sense to have an extended support release
(providing only security updates after
13 months)
Am 03.11.2012 15:38, schrieb Emmanuel Seyman:
* Jóhann B. Guðmundsson [02/11/2012 20:34] :
That package would hardly be un-maintained if it has co-maintainers
now does it...
Absolutely. Hence my request that any process we put in place be
package-focused rather than maintainer-focused
On Sat, 03 Nov 2012 09:26:43 -0700
Adam Williamson awill...@redhat.com wrote:
I don't think rolling release and getting work done are incompatible.
As I mentioned, I run Branched permanently on my desktop - so it
rolls from 'pre-Alpha' state through to 'stable' state briefly and
then back to
On 03.11.2012 18:26, Adam Williamson wrote:
On Sat, 2012-11-03 at 10:52 +0100, drago01 wrote:
Eh? That's not what I said at all. What I said was that I think in a
well-managed rolling release model, users would actually run into
trouble only about as often as they already do anyway. I don't
On 03.11.2012 19:17, Alek Paunov wrote:
Adam, I think that the current rolling release discussion as many
other high interest general ones in the recent months are pointless
without some form of explicit definition and statistics of the current
(and desired) distinct Fedora user profiles.
Just
On Sat, Nov 03, 2012 at 11:11:18 -0600,
Kevin Fenzi ke...@scrye.com wrote:
In any case, I think we do need to look at release cycle changes or at
the very least Feature process revamp.
And get comments from other than developers. Marketting might have serious
concerns about the loss of
On Sat, Nov 3, 2012 at 4:29 PM, Adam Williamson awill...@redhat.com wrote:
On Sat, 2012-11-03 at 11:28 +, mike cloaked wrote:
Others may wish to compare Fedora with other distributions also - but
one thought I had was that in Archlinux there are only two repos to
maintain - whilst in
Le samedi 03 novembre 2012 à 07:46 -0500, Bruno Wolff III a écrit :
I'd rather see us do a better job with rawhide so that more people use it and
a better job at making upgrades go smoother so that people just trying
to get stuff done with Fedora have a better experience.
Then the question
On Sun, 2012-11-04 at 00:26 +0100, Michael Scherer wrote:
Le samedi 03 novembre 2012 à 07:46 -0500, Bruno Wolff III a écrit :
I'd rather see us do a better job with rawhide so that more people use it
and
a better job at making upgrades go smoother so that people just trying
to get
Adam Williamson awill...@redhat.com wrote:
On Sat, 2012-11-03 at 09:37 -0200, Henrique Junior wrote:
The guys behind openSUSE created a good approach with Tumbleweed. By
adding this repo users can opt-in to the (semi)rolling model.
Tumbleweed is more like a pool where updated, stable, non
On Sun, 2012-11-04 at 02:12 +0200, Nikos Roussos wrote:
Adam Williamson awill...@redhat.com wrote:
On Sat, 2012-11-03 at 09:37 -0200, Henrique Junior wrote:
The guys behind openSUSE created a good approach with Tumbleweed. By
adding this repo users can opt-in to the (semi)rolling model.
On Sun, Nov 04, 2012 at 00:26:08 +0100,
Michael Scherer m...@zarb.org wrote:
Le samedi 03 novembre 2012 à 07:46 -0500, Bruno Wolff III a écrit :
I do not run it, so I cannot judge, but I think the first step to fix
something is to know the exact problems to fix. If the issue is too
much
I think we could, just for fun if you like, pursue making a good plan of
how the transition would be and what changes should be done.
Consider it objectively.
What changes would have to be done the OS?
What changes in infrastructure?
What tools do we need?
This could be a good exercise. The
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
On 1 November 2012 17:33, Michael Cronenworth m...@cchtml.com 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
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. :)
On Fri, Nov 2, 2012 at 9:03 AM, Jóhann B. Guðmundsson
johan...@gmail.com 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.
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
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.
Stanislav Ochotnicky sochotni...@redhat.com 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
On 11/02/2012 01:20 PM, Josh Boyer wrote:
On Fri, Nov 2, 2012 at 9:03 AM, Jóhann B. Guðmundsson
johan...@gmail.com 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
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
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
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
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
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com 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
On 11/02/2012 04:25 PM, Tom Lane wrote:
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com 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
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com 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
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 t...@redhat.com wrote:
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com
writes:
On 11/02/2012 04:25 PM, Tom Lane wrote:
How
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
* 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
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
1 - 100 of 252 matches
Mail list logo
