Hi,
On 12/04/2014 02:30 AM, Matthew Miller wrote:
> On Wed, Dec 03, 2014 at 08:13:42PM +0100, Marcin Juszkiewicz wrote:
>> When I worked at Canonical there was a goal to move both internal and
>> public tools to Python 3.x version. IIRC started somewhere around 12.04
>> and today when you look at
sorry for late response to all your feedback , been off-grid ( rural AZ
+ ATT => fail )
@owen - thks for feedback re backlighting - got dimming set via xfce
power settings - dimming seems about same as osx but power use still
sucks (4 hrs) so something is missing - have noticed there seems n
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
On 01/12/14 12:26, Alec Leamas wrote:
While we're on it (in the form "how many devs do we have"): How
hard/impossible/unsuitable would it be to get a usable estimate on the #
of users, per package?
[cut]
Some 50 messages later... and stopping by Ben's question about which are
the questions w
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
\o/
Thanks everyone!
digimer
On 04/12/14 01:21 PM, Jaroslav Reznik wrote:
At the Fedora 21 Final Go/No-Go Meeting that just occurred, it was
agreed to Go with the Fedora 21 Final by Fedora QA, Release Engineering
and Development.
Fedora 21 will be publicly available on Tuesday, December 09, 2
At the Fedora 21 Final Go/No-Go Meeting that just occurred, it was
agreed to Go with the Fedora 21 Final by Fedora QA, Release Engineering
and Development.
Fedora 21 will be publicly available on Tuesday, December 09, 2014.
Meeting details can be seen here:
Minutes: http://bit.ly/1yjG357
Log: htt
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
On Qui, 2014-12-04 at 03:14 +, Sérgio Basto wrote:
> Hi,
> https://admin.fedoraproject.org/updates/firefox-34.0-1.fc20,thunderbird-31.3.0-1.fc20
> are already to be push to stable without passing to test repo .
>
> But for what I see: "stable karma: 0" it shouldn't be pulled to stable
> even
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
On Wed, Dec 03, 2014 at 12:26:11PM +0100, Vít Ondruch wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dne 3.12.2014 v 08:47 Michel Alexandre Salim napsal(a):
> > At the risk of jumping in, here's my own 2 cents on the subject...
> >
> > On 12/03/2014 12:30 AM, Stephen John Smoogen
On 12/04/2014 07:55 AM, Miroslav Suchý wrote:
On 12/03/2014 10:51 PM, David Shea wrote:
Through some series of accidents, the python-pyudev package in Fedora
is assigned to clock...@redhat.com. This account
has been closed since at least early 2013. The email address isn't
"invalid" exactly in
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
On 12/03/2014 10:51 PM, David Shea wrote:
Through some series of accidents, the python-pyudev package in Fedora is
assigned to clock...@redhat.com. This account
has been closed since at least early 2013. The email address isn't "invalid"
exactly in that emails won't bounce, but it
is a black ho
Compose started at Thu Dec 4 05:15:03 UTC 2014
Broken deps for i386
--
[3Depict]
3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[cab]
cab-0.1.
Compose started at Thu Dec 4 07:15:03 UTC 2014
Broken deps for armhfp
--
[avro]
avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce
avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client
[openstack-nova]
openstac
- Original Message -
> W dniu 03.12.2014 o 20:30, Matthew Miller pisze:
> > On Wed, Dec 03, 2014 at 08:13:42PM +0100, Marcin Juszkiewicz wrote:
> >> When I worked at Canonical there was a goal to move both internal and
> >> public tools to Python 3.x version. IIRC started somewhere around 1
27 matches
Mail list logo
