On Mon, Dec 8, 2014 at 2:18 PM, Brendan Conoboy b...@redhat.com wrote:
On 12/04/2014 06:39 AM, Matthew Miller wrote:
What do you think? Would this help towards the goals listed above?
Would it help _other_ things? What downsides would it bring?
It sounds a lot like releasing a new compose
On Thu, 2014-12-04 at 20:01 +0100, Reindl Harald wrote:
Am 04.12.2014 um 19:57 schrieb Adam Jackson:
I think it's a bit misguided to even think of these things as related.
Polish in an end-user-visible sense is itself a list of tasks and
criteria that require dedicated attention, preferably
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 8 Dec 2014 02:29:17 +
Peter Robinson pbrobin...@gmail.com wrote:
On Thu, Dec 4, 2014 at 6:42 PM, Matthew Miller
mat...@fedoraproject.org wrote:
On Thu, Dec 04, 2014 at 11:02:28AM -0600, Bruno Wolff III wrote:
For us, that would mean
On 12/04/2014 06:39 AM, Matthew Miller wrote:
What do you think? Would this help towards the goals listed above?
Would it help _other_ things? What downsides would it bring?
It sounds a lot like releasing a new compose of an existing release
with updates included in the repository. Why not
What do you think? Would this help towards the goals listed above?
Would it help _other_ things? What downsides would it bring?
I think it is not useful to set up a general mechanism of alternating
releases and borrow a name for it before you've discussed what concrete
tasks in release
On Thu, Dec 4, 2014 at 6:42 PM, Matthew Miller mat...@fedoraproject.org wrote:
On Thu, Dec 04, 2014 at 11:02:28AM -0600, Bruno Wolff III wrote:
For us, that would mean alternating between concentrating on release
features and on release engineering and QA process and tooling. During
the tick,
On Fri, Dec 05, 2014 at 20:27:37 -0800,
M. Edward (Ed) Borasky zn...@znmeb.net wrote:
PostgreSQL is a good example - 9.4 is in the release candidate stage
right now and will probably be declared stable within a month. If it
doesn't at least make it into updates-testing before F22, I'll be
On Sat, Dec 06, 2014 at 07:25:48 +0100,
Kevin Kofler kevin.kof...@chello.at wrote:
And unfortunately, a new PostgreSQL IS incompatible, because if you just run
yum update, your databases will cease to work. You have to actually dump
them BEFORE doing the upgrade (or downgrade PostgreSQL for
On Fri, Dec 05, 2014 at 22:57:50 -0800,
M. Edward (Ed) Borasky zn...@znmeb.net wrote:
I thought PostgreSQL fixed that a couple of years ago - upgrade in
place was the most-requested feature for a long time. But I can see
why DBAs wouldn't trust it after having mastered the
dump-upgrade-restore
On Sat, Dec 06, 2014 at 07:25:48 +0100,
Kevin Kofler kevin.kof...@chello.at wrote:
The updates-testing repository is only supposed to be used for packages that
will eventually hit the regular updates repository. It is NOT a dumping
ground for incompatible upgrades.
Part of the reason for
Michael DePaulo wrote:
That is not part of the tick-tock proposal.
That is part of the polish release proposal.
I don't care how you call it. The fact remains that doing a release without
taking in new upstream releases is a complete no-go from the standpoint of
desktop environment
On Sun, Dec 07, 2014 at 04:59:54AM +0100, Kevin Kofler wrote:
That is not part of the tick-tock proposal.
That is part of the polish release proposal.
I don't care how you call it. The fact remains that doing a release without
taking in new upstream releases is a complete no-go from the
On 04.12.2014 15:39, Matthew Miller wrote:
...
What do you think? Would this help towards the goals listed above?
Would it help _other_ things? What downsides would it bring?
Tip-Top is what Fedora needs.
--
devel mailing list
devel@lists.fedoraproject.org
On 12/05/2014 01:32 AM, M. Edward (Ed) Borasky wrote:
As a user/re-mixer, I don't like it. I'm at the point now where I need
a rolling release. I can live with a six-month or eight-month lag
between desktop updates, but I can't live without regular updates to R
and R packages,
On Fri, Dec 5, 2014 at 6:58 PM, Michel Alexandre Salim
sali...@fedoraproject.org wrote:
On 12/05/2014 01:32 AM, M. Edward (Ed) Borasky wrote:
As a user/re-mixer, I don't like it. I'm at the point now where I need
a rolling release. I can live with a six-month or eight-month lag
between desktop
Richard Hughes wrote:
On 4 December 2014 at 14:39, Matthew Miller mat...@mattdm.org wrote:
including holding GNOME and other showcase software to the same
version.
I think that would be *very* unpopular with the desktop team.
And for once I think the KDE SIG and the GNOME Desktop Team will
M. Edward (Ed) Borasky wrote:
PostgreSQL is a good example - 9.4 is in the release candidate stage
right now and will probably be declared stable within a month. If it
doesn't at least make it into updates-testing before F22, I'll be
adding 9.4 from the PostgreSQL project's RPM repos or
On Fri, Dec 5, 2014 at 10:02 PM, Kevin Kofler kevin.kof...@chello.at wrote:
And for once I think the KDE SIG and the GNOME Desktop Team will agree on
something. :-)
Other than the fact that LXDE doesn't use enough RAM? ;-)
--
Twitter: http://twitter.com/znmeb; OSJourno: Robust Power Tools for
On Fri, Dec 5, 2014 at 10:25 PM, Kevin Kofler kevin.kof...@chello.at wrote:
And unfortunately, a new PostgreSQL IS incompatible, because if you just run
yum update, your databases will cease to work. You have to actually dump
them BEFORE doing the upgrade (or downgrade PostgreSQL for the dump,
On Sat, Dec 6, 2014 at 1:02 AM, Kevin Kofler kevin.kof...@chello.at wrote:
Richard Hughes wrote:
On 4 December 2014 at 14:39, Matthew Miller mat...@mattdm.org wrote:
including holding GNOME and other showcase software to the same
version.
I think that would be *very* unpopular with the
While I'm waiting for an RC5 test install to complete... :)
At yesterday's FESCo meeting, while discussing the Fedora 22 schedule,
Stephen Gallagher suggested the idea of moving to a release schedule
modeled after Intel's tick-tock model for CPUs, where they alternate
between new architectures
On 4 December 2014 at 14:39, Matthew Miller mat...@mattdm.org wrote:
including holding GNOME and other showcase software to the same
version.
I think that would be *very* unpopular with the desktop team.
Richard
--
devel mailing list
devel@lists.fedoraproject.org
Am 04.12.2014 um 15:46 schrieb Richard Hughes:
On 4 December 2014 at 14:39, Matthew Miller mat...@mattdm.org wrote:
including holding GNOME and other showcase software to the same
version.
I think that would be *very* unpopular with the desktop team
you should not stop read before answer
On Thu, Dec 04, 2014 at 09:39:35AM -0500, Matthew Miller wrote:
[tick tock] would mean alternating between concentrating on release
features and on release engineering and QA process and tooling. During
the tick, we'd focus on new features and minimize unrelated rel-eng
change. During the
On Thu, Dec 4, 2014 at 3:51 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 04.12.2014 um 15:46 schrieb Richard Hughes:
On 4 December 2014 at 14:39, Matthew Miller mat...@mattdm.org wrote:
including holding GNOME and other showcase software to the same
version.
I think that would be
Am 04.12.2014 um 16:48 schrieb drago01:
On Thu, Dec 4, 2014 at 3:51 PM, Reindl Harald h.rei...@thelounge.net wrote:
+1 for the proposal in general from me because i am one of them suggesting
for years that every second release should have the focus on bugfixes /
polish / get large features
On Thu, Dec 04, 2014 at 09:39:35 -0500,
Matthew Miller mat...@mattdm.org wrote:
For us, that would mean alternating between concentrating on release
features and on release engineering and QA process and tooling. During
the tick, we'd focus on new features and minimize unrelated rel-eng
On Thu, Dec 4, 2014 at 12:02 PM, Bruno Wolff III br...@wolff.to wrote:
I think when developing goals for releases we look for conflicts and defer
some things where there is a potential conflict. We'd want to make sure that
desired goals eventually get done and not keep deferring the same goal
On Thu, 2014-12-04 at 09:39 -0500, Matthew Miller wrote:
What do you think? Would this help towards the goals listed above?
Would it help _other_ things? What downsides would it bring?
I think it is not useful to set up a general mechanism of alternating
releases and borrow a name for it
As a user/re-mixer, I don't like it. I'm at the point now where I need
a rolling release. I can live with a six-month or eight-month lag
between desktop updates, but I can't live without regular updates to R
and R packages, PostgreSQL/PostGIS, QGIS, the Python data science
tools, etc. And I'm
On Thu, Dec 04, 2014 at 11:02:28AM -0600, Bruno Wolff III wrote:
For us, that would mean alternating between concentrating on release
features and on release engineering and QA process and tooling. During
the tick, we'd focus on new features and minimize unrelated rel-eng
change. During the
On Thu, 2014-12-04 at 09:39 -0500, Matthew Miller wrote:
For us, that would mean alternating between concentrating on release
features and on release engineering and QA process and tooling. During
the tick, we'd focus on new features and minimize unrelated rel-eng
change. During the tock,
Am 04.12.2014 um 19:57 schrieb Adam Jackson:
I think it's a bit misguided to even think of these things as related.
Polish in an end-user-visible sense is itself a list of tasks and
criteria that require dedicated attention, preferably from someone with
the breadth of experience and lack of
On Thu, Dec 4, 2014 at 10:17 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Thu, Dec 04, 2014 at 09:39:35AM -0500, Matthew Miller wrote:
[tick tock] would mean alternating between concentrating on release
features and on release engineering and QA process and tooling. During
On Dec 4, 2014 9:39 AM, Matthew Miller mat...@mattdm.org wrote:
While I'm waiting for an RC5 test install to complete... :)
At yesterday's FESCo meeting, while discussing the Fedora 22 schedule,
Stephen Gallagher suggested the idea of moving to a release schedule
modeled after Intel's
35 matches
Mail list logo
