On Mon, Dec 8, 2014 at 2:18 PM, Brendan Conoboy 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 of an e
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 do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 8 Dec 2014 02:29:17 +
Peter Robinson wrote:
> On Thu, Dec 4, 2014 at 6:42 PM, Matthew Miller
> wrote:
> > On Thu, Dec 04, 2014 at 11:02:28AM -0600, Bruno Wolff III wrote:
> >> >For us, that would mean alternating between concentrating on
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, pr
On Thu, Dec 4, 2014 at 6:42 PM, Matthew Miller 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", we'd focus on
>> 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 releas
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 fro
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 maint
On Sat, Dec 06, 2014 at 07:25:48 +0100,
Kevin Kofler 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 this is that it creates pr
On Fri, Dec 05, 2014 at 22:57:50 -0800,
"M. Edward (Ed) Borasky" 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 process.
On Sat, Dec 06, 2014 at 07:25:48 +0100,
Kevin Kofler 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, or
install th
On Fri, Dec 05, 2014 at 20:27:37 -0800,
"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 th
On Sat, Dec 6, 2014 at 1:02 AM, Kevin Kofler wrote:
> Richard Hughes wrote:
>> On 4 December 2014 at 14:39, Matthew Miller 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
On Fri, Dec 5, 2014 at 10:25 PM, Kevin Kofler 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, or
> install the o
On Fri, Dec 5, 2014 at 10:02 PM, Kevin Kofler 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
Digital Journalists
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 bui
Richard Hughes wrote:
> On 4 December 2014 at 14:39, Matthew Miller 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 agree on
s
On Fri, Dec 5, 2014 at 6:58 PM, Michel Alexandre Salim
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 updates, but I can
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, PostgreSQL/Po
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
https://admin.fedoraproject.org
On Dec 4, 2014 9:39 AM, "Matthew Miller" 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 "tick-tock" mode
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. Dur
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 fe
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 "toc
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. Duri
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 runni
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 bef
On Thu, Dec 4, 2014 at 12:02 PM, Bruno Wolff III 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
> repeatedly
On Thu, Dec 04, 2014 at 09:39:35 -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 "to
Am 04.12.2014 um 16:48 schrieb drago01:
On Thu, Dec 4, 2014 at 3:51 PM, Reindl Harald 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 from the previous release
On Thu, Dec 4, 2014 at 3:51 PM, Reindl Harald wrote:
>
> Am 04.12.2014 um 15:46 schrieb Richard Hughes:
>>
>> On 4 December 2014 at 14:39, Matthew Miller wrote:
>>>
>>> including holding GNOME and other showcase software to the same
>>> version.
>>
>>
>> I think that would be *very* unpopular wit
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
Am 04.12.2014 um 15:46 schrieb Richard Hughes:
On 4 December 2014 at 14:39, Matthew Miller 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 because the followi
On 4 December 2014 at 14:39, Matthew Miller 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
https://admin.fedoraproject.org/mailman/listi
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
35 matches
Mail list logo
