Re: Retiring

[Myriam Schweingruber]

Hi Christoph,

On Wed, 13 Jan 2021 at 21:57, Christoph Feck  wrote:

> Hello developers,
>
> my personal situation allows for much less time for KDE
> related work, at least during the Corona times.
>
> I would like to retire as soon as possible from these
> responsibilities:
> - bug triaging
> - release service
> - KIconTheme maintainer
> - KPlotting maintainer
> - KWidgetAddons maintainer
>
> For bugzilla, I see many new and old contributors doing awesome
> work with triaging, so departing here shouldn't be a big issue.
> I hope someone can continue checking responses to NEEDINFO bugs
> and REPORTED bugs that didn't get a reply within about two weeks.
>
>
You will be sorely missed anyway, but I understand the toll these demanding
times have taken on you.
"Many thanks" will never be enough for the enormous amount of work you have
given us over the years, replacing you will be really hard, we all lack
your experience and knowledge of our bug collection.

Thank you, thank you, thank you!

Please keep safe and healthy and I would love to see you back in the
bugsquad in better times.

Regards, Myriam
-- 
Pronouns: she/her
Proud member of the Amarok and KDE Community:
https://www.kde.org
Protect your freedom and support the work of the FSFE:
https://www.fsfe.org 

Re: [kde-community] Impact of Heartbleed issue on KDE.org infrastructure

[Myriam Schweingruber]

Hi Ben,

On Tue, Apr 15, 2014 at 10:29 AM, Ben Cooksley bcooks...@kde.org wrote:
...
 Sites affected:

 forum.kde.org
 community.kde.org
 userbase.kde.org
 techbase.kde.org
 cdn.kde.org
 api.kde.org
 dot.kde.org
 blogs.kde.org
 reviewboard.kde.org (Both Git and Subversion)

 At no point were Identity, Bugzilla or SCM services affected by this issue.
 If anyone has any questions, please let us know.

So in other words: since we probably all use Identity to log into
these sites, there is no reason to change any passwords, right?


Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Klook/dolphin

[Myriam Schweingruber]

Hi Michael,

On Mon, Dec 23, 2013 at 6:36 PM, Michael Reeves reeves...@gmail.com wrote:
 Is anybody still working on Klook? If so I have an updated patch for dolphin
 integration.

Then you should ask the author of it. AFAIK the source code is still
on their server, not on the KDE ones, as the integration with Dolphin
in its current way of working is not going to happen. It would need to
change the way it works currently as it causes problems when launching
it, be this with the current shortcut that is already in use for other
things, or with an additional button. In other words: it doesn't
integrate as well as the authors suggest it would.. Also I can't find
any newer information than version 2.0 that was released with Rosa in
November 2012

Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)Hi Michael,

Re: Downtime Notification: Git and Subversion

[Myriam Schweingruber]

On Fri, Mar 22, 2013 at 5:33 PM, Aleix Pol aleix...@kde.org wrote:
 On Fri, Mar 22, 2013 at 4:36 PM, Dirk Müller muel...@kde.org wrote:

 2013/3/22 Ben Cooksley bcooks...@kde.org:

  While we will try to keep the actual period of downtime as short as
  possible during this period, due to the nature of the change, it may
  take longer than we expect.

 Hi,

 both svn and git are up again.

 Greetings,
 Dirk


 Are we sure it's ready? I cannot push yet.

 Are there any changes required?

Not it is not ready. Keep an eye on http://identi.ca/kdesysadmin

there were some unforeseen glitches...


Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Login for bug reporting

[Myriam Schweingruber]

On Thu, Feb 7, 2013 at 10:26 AM, Anders Lund and...@alweb.dk wrote:
 Onsdag den 6. februar 2013 22:20:07 skrev Frank Reininghaus:

 considering that we get lots of duplicates for any reproducible bug, my
 impression is actually not that there are to many obstacles in the bug
 reporting process. Providing any kind of contact me via email/Facebook
 channel will only make it worse. I'm already spending a lot of time marking
 reports as duplicate/invalid or telling people that reporting bugs for KDE
 4.8 or earlier is not quite as useful as they think. Please do not make it
 worse by lowering the bug reporting barriers.



 How would the demand for having an account lower the amount of duplicates?

The other way round: we already have a lot of duplicates with the
current system, if the reports don't have to make an account anymore
we would get even more useless reports.


Regards, Myriam
-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Login for bug reporting

[Myriam Schweingruber]

Hi all,

On Wed, Feb 6, 2013 at 10:20 PM, Frank Reininghaus
frank7...@googlemail.com wrote:

 Am 06.02.2013 18:57 schrieb Kevin Krammer:

 Hi folks,

 at FOSDEM I was approached by a person who asked me to relay his
 dissatisfaction with the requirement of having a KDE Bugzilla account to
 report crashes via the KDE crash handler dialog.

 The issue in his case was kind of made worse by having this obstacle
 appear
 too late, i.e. after he had followed the instructions to create a useful
 backtrace and had downloaded several tens of megabytes of debug symbols.

 Being a FOSS developer himself he said that he understands the need for
 having
 a communication channel with the reported, but just having an email
 address
 for that would be sufficient (e.g. Debian's bug tracker works that way).

 So the question is whether alternative login options [1] are something we
 could do or whether this is impossible in our setup or just something we
 don't
 want to do because of certain drawbacks.

 Cheers,
 Kevin

 [1] assuming that a KDE bugzilla login is nowadays a KDE Identity login,
 could
 we have something like on the Wikis, e.g. OpenID, or something comment
 sections of websites used, e.g. login via Facebook?

 considering that we get lots of duplicates for any reproducible bug, my
 impression is actually not that there are to many obstacles in the bug
 reporting process. Providing any kind of contact me via email/Facebook
 channel will only make it worse. I'm already spending a lot of time marking
 reports as duplicate/invalid or telling people that reporting bugs for KDE
 4.8 or earlier is not quite as useful as they think. Please do not make it
 worse by lowering the bug reporting barriers.

I fully agree with Frank here, we already get way enough useless
reports, please don't lower the barrier even more. IMHO it is already
very easy to report a bug in BKO, much easier actually than in other
bug trackers out there, and, unless you find a miracle solution to
increase the number of triagers at least 10x the current number,
lowering the barrier would also mean more bogus and spam. Please don't
make our work harder than it already is.


Regards, Myriam
-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Re: Proposed adjustments to our release cycles

[Myriam Schweingruber]

Hi everyone,

On Sun, Jun 17, 2012 at 3:16 PM, Sebastian Kügler se...@kde.org wrote:
 On Saturday, June 16, 2012 08:18:05 Maksim Orlovich wrote:
...
 What continuous integration and automated testing? How many apps have any?

 That's the point, we need to improve here. Some of this can be done centrally,
 some will be with the apps developers. In the long run, we need to improve on
 our quality processes, the Testing team has identified that, and it's a high-
 priority item in the release team as well. I hope we can create a culture with
 a sound (and not too ad-hoc) quality process, which allows us to be more
 flexible in our release management.

With my KDE Quality Team hat on:

I think we should first of all solve one big problem here:
http://techbase.kde.org/Projects/Release_Team#Coordinator_List

As long as

kdelibs
kde-baseapps
kate

don't even have a coordinator for releases, how do you expect to do
this for the upcoming frameworks? Without a release coordination this
will never work, as the current problems have shown.

I also am quite skeptical about the tarballs: it was already difficult
to get a 4.9 beta1 and it would never actually have happened without
Albert jumping in because the existing release-team was not available.
Thanks a lot again to Albert for doing that.

Comparing what we do with what the industry does is a bit blue-eyed as
we don't even have the responsible people around when it is needed.

So in my opinion we need first to strengthen the release-team and
reduce the single points of failure ( or bus number if you prefer).
The coordinators should really take responsibility to get their parts
into shape for the release, especially in regard to freezes that
apparently are not respected in several parts of the current KDE SC
package. This means better project management on all parts.

So please everybody, get your individual projects in shape and take
responsibility for releases and make sure that an actual release can
be done smoothly. Define team leads and release managers with
stand-ins, introduce commits only through reviewboard, get your CI on
Jenkins in shape, so far half of KDE is not even building on the
current build server, for various reasons that might Jenkins or
project related.

Once we have all that in place we should start discussions on how to
handle releases in the future, but with the current state this is all
future thinking.

Regards, Myriam

Please subscribe to release-team@ if your project is part of the KDE SC release

[Myriam Schweingruber]

Hi all,

The recent problems with various components of the KDE SC beta release
has shown one major barrier in problem solving:

When the distribution packagers get aware of problems they need to go
through hoops to actually reach the project people to notify the
problems. They need to go individually to the various mailing lists,
subscribe, wait for authorization etc.

Instead of asking all packagers to subscribe to the various project
mailing lists it would be much easier if the project people would
subscribe to the release-team@ mailing list.

So please, all project leads, subscribe to release-t...@kde.org here:

https://mail.kde.org/mailman/listinfo/release-team

And please, be around on release times, as it is equaly difficult for
the release-team if they have to run after various people to make a
release actually happen. Remember, we have clearly defined schedules:
http://techbase.kde.org/Schedules

It is a small step for each of you and a big leap to a better KDE Quality :)

Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: KDE mailing lists - a few questions

[Myriam Schweingruber]

On Wed, May 23, 2012 at 4:52 PM, Sebastian Kügler se...@kde.org wrote:
 On Wednesday, May 23, 2012 16:07:48 Myriam Schweingruber wrote:
 So IMHO these lists should be visible in the mailiman/listinfo, with a
 description. There already is a lot of criticism about hidden mailing
 lists with unknown agendas among the KDE community, a minimum of
 transparency about what list exist and what the lists are about is not
 asking too much.

 I think with respect to that, much of it is probably idle conspiracy theorism,
 don't pay too much attention to it. It's usual the less useful people who find
 the time to complain about that. (Makes me wonder about their agendas, but in
 fact -- not really.)

 Mailinglist which aren't meant for public consumption are not very useful in
 the list info, that only attracts spammers, adds a lot of overhead for the
 moderators, and doesn't add anything other than some false sense of
 transparency (realistically, it achieves the opposite).

I am a moderator for several mailing lists, some of these for the fsfe
and those have most likely an equal amount of spam traffic than KDE
lists. Worse even for the 3  mailing lists I moderate in the *ubuntu
space, it sometimes peaks at 30 spam messages a day for one of them,
but it is easily handled with listadmin and quite fast, so not
something I consider much overhead. Part of the morning routine with
a cup of coffee :)

A false sense of transparency - I don't see what you mean by that,
there already are mailing lists with private archives in the listinfo
and I don't see how that would cause people to try to obscure things.
But maybe I misunderstand what you mean

 I understood your email as attempt to sort out the mailinglist mess (is
 it?)...

Yes, that was definitely also part of the plan, thanks for the
information about the ones that can be removed.


Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:done
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

KDE mailing lists - a few questions

[Myriam Schweingruber]

Hi everyone,

a  quality discussion on IRC this morning triggered a few question I
think are best addressed to this list.

1. I don't question that KDE has several groups that need a mailing
list with a private archive, only accessible to subscribers, but what
is the reason to make mailing lists hidden? The KDE Community is about
Free Software after all, so why this unnecessary secrecy?

Here comes a list of those not visible on https://mail.kde.org/mailman/listinfo

akademy-announce
akademy-participant
akademy-registrations
akademy-sponsoring
akademy-talks
akademy-team
amarok-committee
amarok-devel
campkde-organizers
community-wg
dot-editors
ds-announce
ds-discuss
ds-marketing
ds-sponsoring
ds-talks
ds-team
grancanaria
k16
kde-apps-org
kde-connect-team
kde-debian-private
kde-enterprise-web
kde-ev-campaign
kde-ev-hiring
kde-ev-membership
kde-events-au
kde-hci
kde-mirrors
kde-packager
kde-pim-meeting
kde-pr
kde-press-announce
kde-soc-mentor
kde-webmaster
khtml-devel
koffice
konq-bugs
kontact
mailman

2. There are quite a few mailing lists that are dead, either because
those are obsolete or were never used. IMHO the never used ones should
be removed ASAP, for the obsolete ones the archives can be preserved
but the list closed and that should be visible from the description.
Hiding dead or obsolete lists is not a good solution IMHO.

I suggest a deadline for the dead mailing lists to be closed, how
about in a month or so?

3. There are still mailing lists with no description. Why does it have
to be so cryptic? Again, this is not questioning about the privacy of
a list, but a description should be at least available.


Regards, Myriam.

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: KDE mailing lists - a few questions

[Myriam Schweingruber]

Hi Todd,

On Tue, May 22, 2012 at 9:54 AM, todd rme toddrme2...@gmail.com wrote:
 On Tue, May 22, 2012 at 9:48 AM, Myriam Schweingruber myr...@kde.org wrote:
 Hi everyone,

 What is the criteria for a mailing list being dead?

No mails since several months. Also the sysadmins see those easily as
they usually cause a lot of bounces.

 Another issue: are mailing lists the proper way to be distributing
 bugzilla notifications, or should those be handled by subscriptions
 inside bugzilla?  From the discussions I have seen the latter is
 supposed to be the preferred method, but a bunch of mailing lists are
 still being used for bugzilla notifications.

I think it is legit to use a mailing list, yes. I think this is pretty
much one of the best ways to be subscribed to a certain group of mails
for the user. Not all users are familiar with bugzilla enough to know
how they can get themselves subscribed to all bugs of a product or a
component for example. And while this is easy for people with enough
rights, it isn't for the average bugzilla user.


Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Setting up a Quality Team within KDE

[Myriam Schweingruber]

Hi dE

On Thu, Apr 12, 2012 at 15:25, dE . de.tec...@gmail.com wrote:
...
 Apart from whatever's being discussed here, the testing phase should be
 publicized and called for testers (for e.g. the first page should talk about
 this and call for testing as a contribution).

 Instructions for testing on every popular distro should be given; we should
 go to each major distro's forum and publicize about this.

I totally agree with you, but keep in mind that beta releases will
give additional work to the distributions.

 Distros like arch, Gentoo etc... should be hot targets since they contain
 experienced and advanced users, administrators and developers (who are users
 in this case). They also tend to have a lot of patience with bugs.

Sorry to contradict you on that, my experience with both Arch and
Gentoo users is not the same, they have a lot of inexperienced users
who think of themselves as experts they simply aren't, and their
patience with bugs is close to zero. This experience comes from user
support in @amarok, @kde and the fourm.kde.org. A distro's reputation
doesn't make their users experts automatically.

On the contrary, I think we should target mass-market distributions
like Fedora, Kubuntu and Opensuse in the same way, they have a much
bigger user base and most likely not less experts than Arch or Gentoo.

But back to the beta testing: to have efficient beta testing we need
to tell people what to test specifically and under what conditions,
else it's benefit is not very high, as some cases we see as important
are seen as corner cases by the testers and what the users thinks is
essentials is a corner case for us

So it is very important that we work out a list of what should be
tested and how.

Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Setting up a Quality Team within KDE

[Myriam Schweingruber]

On Wed, Apr 11, 2012 at 00:38, Michael Jansen k...@michael-jansen.biz wrote:
 On Tuesday, April 10, 2012 09:20:57 AM Allen Winter wrote:
 On Thursday 05 April 2012 7:42:48 AM Anne-Marie Mahfouf wrote:
  Hi,
 
 
  A new mailing list has been set up in order to discuss all this: please
  subscribe to it if you would like to be part of this
  https://mail.kde.org/mailman/listinfo/kde-testing
  An IRC channel also was created on Freenode:
  #kde-quality
 
  Please join the mailing list and the IRC channel so we can setup a plan
  to start putting all this in gear!

 Let's please end this discussion about the various tools and stuff here on
 k-c-d.

 If you want to talk about those things, please use the new kde-testing
 mailing list or the IRC channel which are dedicated to the broader topic.

 I am starting to get annoyed by that please follow me to the secluded place
 over there so noone can listen in thing that is creeping up in kde.

It is neither secret nor secluded, the archives are public and it was
announce all over the place.

 I do no consider this ml a to high volume one and this stuff is in my opinion
 exactly what this list should be about. By moving the discussion out of here
 you just guarantee that whatever is chosen will sit in obscurity like before.

 Because i won't follow you. And i guess some others won't either.

The aim of the Quality team stretches way beyond kde-core as it
concerns the whole KDE community, and I am sure you would soon be
annoyed enough if testing a Game or Amarok start showing up in here,
together with questions from dozens of beta-testers on how to test one
particular feature you are not interested and which doesn't concern
kde-core-devel.

Regards, Myriam
-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Setting up a Quality Team within KDE

[Myriam Schweingruber]

Hi Aleix,

On Sat, Apr 7, 2012 at 20:34, Aleix Pol aleix...@kde.org wrote:

 Anyhow, is the mailing list created already?

Yes, it was set up the same days as the mail was sent out:
https://mail.kde.org/mailman/listinfo/kde-testing

Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Re: DrKonqi improvement idea

[Myriam Schweingruber]

Hi all,

On Mon, Mar 12, 2012 at 19:34, Martin Gräßlin mgraess...@kde.org wrote:
 On Monday 12 March 2012 19:26:27 Niko Sams wrote:
 On Sun, Mar 11, 2012 at 13:57, henry miller h...@millerfarm.com wrote:
...
 *cough*
 https://bugs.kde.org/report.cgi?x_axis_field=resolutiony_axis_field=z_axis_field=query_format=report-
 tableshort_desc_type=allwordssubstrshort_desc=product=kwinbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=NEEDSINFObug_status=VERIFIEDbug_status=CLOSEDlongdesc_type=allwordssubstrlongdesc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_id=bug_id_type=anyexactvotes=votes_type=greaterthaneqbug_severity=crashemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=emailtype3=substringemail3=chfield=[Bug+creation]chfieldvalue=chfieldfrom=2011-01-01chfieldto=Nowj_top=ANDf1=noopo1=noopv1=format=tableaction=wrap

 That's the stats for all crash reports reported against kwin since 01/01/2011
 and now. It illustrates nicely one of the major problems of DrKonqui: you can
 report the duplicates.

 Of course KWin is the worst case scenario for measuring DrKonqui as we have
 all those nice driver bugs ;-)

Worst case I don't know, if you apply the report to other large
projects you will get similar figures, see for example for Amarok:
http://bit.ly/wa6m4i

But then, we are all in the same boat with duplicates :)

Just my 2 ct: I don't think the user is able to actually judge if a
report is a duplicate one, so handling this on the server side would
be really a great idea, unless somebody (aka many) have time to triage
this on a daily basis. I agree on at least one point: duplicates
should not be reported without prior triage.

Regards, Myriam.

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Re: DrKonqi improvement idea

[Myriam Schweingruber]

On Tue, Mar 13, 2012 at 17:25, Martin Gräßlin mgraess...@kde.org wrote:
 On Tuesday 13 March 2012 17:00:29 Christoph Feck wrote:
...

 I have long been interested why users keep reporting duplicates.
 Instead of guessing, let's just ask them in a nice way. I added
 https://bugs.kde.org/show_bug.cgi?id=295919#c1 to a frequently
 reported bug, and maybe we can this way get some insights. Unless
 someone objects, this survey could be sent to reporters of frequently
 reported crashes (maybe not in the comment, but per reply).

 My guess is that DrKonqi simply does not make it clear that the bug
 has already been reported several times.

I am pretty sure it doesn't, as the list of the similar bugs appears
at the bottom of the backtrace, a place nobody is going to look for
it. And once it is reported, the user isn't likely to see it either as
s/he will not open the bug report and check what is written at the
bottom of the backtrace.

Dr. Konqi should clearly display the possible duplicates to the user,
on top of the backtrace or by a message telling that possible
duplicates were found. The message could then continue like this: if
you are unsure whether your report is a duplicate or not, stop here,
if you are an experience users who knows how to read backtraces and
find duplicates you can continue. (in a more appropriate wording of
course).

Regards, Myriam
-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: KDE Frameworks Documentation

[Myriam Schweingruber]

Hi Ignat,

On Tue, Sep 27, 2011 at 20:30, Ignat Semenov ragnarok...@gmail.com wrote:
 Hello KDE devs and users!

 You may remember me as that guy on IRC that's constantly building
 something, always finds bugs in the buildsystem and never gives back
 code. Well, for a reason, it turns out. :)

...

 1)It was all split into many processes, and thus impossible to debug
 without black magic.
 2)The API was similar to an onion, I think I did not remove all the
 layers, even after spending some time.
 3)Qt meta-information, esp. signals and slots, gets in the way.
 4)(Similar to #1) KIO or whatever it was turned out to be
 asynchronous, multi-process beast, and next to impossible to debug.
 YOu have to attach to multiple processes and watch them all, but to do
 that, you need to know where to attach and what to watch for.

 Thus, here's my proposal (one mroe blog post comment quote):

 KDE Core Libs and Frameworks *do* need good up-to-date documentation

I am not a developer, but did you have a look here: http://api.kde.org/ ?

...

 This means:

 1)API docs up-to-date and with extensive examples.

Since the API documentation is extracted automatically, I would expect
it to be rather up-to-date


Regards, Myriam

-- 
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: My Plans, Your Plans: Berlin Desktop Summit

[Myriam Schweingruber]

Hi all

On Thu, Jul 28, 2011 at 07:59, Martin Gräßlin mgraess...@kde.org wrote:
 On Wed, 27 Jul 2011 15:40:11 +0200, Aaron J. Seigo ase...@kde.org wrote:
(and others wrote as well)
...

Interestingly these plans all sound great for Akademy, but since it is
a Desktop Summit I would love to hear what cross-desktop plans there
are within our community. Or am I the only one missing something here?


Regards, Myriam

-- 
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)