>From www.gitorious.org
> System notice: Gitorious is being acquired by GitLab and
> gitorious.org will shut down end of May. Please import your
> repositories to
We still have a few projects on there. One notable being Grantlee (at
least, my kdesrc-build looks for it over there).
I guess this sh
> If by *we* you mean KDE, no we don't have anything there
Not meant to be a yet-another-what-is-a-kde-project type of thread.
Just a heads-up of what is happening with the host that more than a
few people from KDE are using for KDE-related things.
Heads-up mail on KCD because I have *not* recei
> And thanks for being on-top of this :).
No problem. :)
kdesrc-build/kf5-kdepim-build-include updated and pushed.
--
Cheerio,
Ivan
-
kio/CMakeLists.txt b517621
kio/kfile/krecentdocument.cpp a7f9283
Diff: https://git.reviewboard.kde.org/r/101885/diff/
Testing
---
Been testing for a couple of months now
Thanks,
Ivan Čukić
> 7. the gui thread listens to dbus and sends a signal to the other threads?
It can not send signals since those are not loopy threads.
There is no need for a lot of locking if you put one instance of
KSycoca. You could do something like this (class names are not real :)
):
class MainThread {
>> I prefer the first option, it's the way forward and if someone was using
>
> I'd say that requiring a newer gcc just like that would go against the
> nature of the KF5 project.
I don't really see why it is "against the nature of KF5". It would not
be the first time we require a higher compiler
> What I don't like in this story is that we set up a rule, an promise with
> users, which was broken and now it's like it does not matter.
Yes, we did set up the rule requirements for gcc 4.5 and MSVC10 back in 2013.
Since then, we broke the rule and increased to MSVC11 (VS2012).
Now, we can in
This is from the "Officially supported platforms" page at
http://doc.qt.io/QtSupportedPlatforms/
Qt 5.5:
Windows * - MinGW 4.9, MinGW 4.8 (apart from MSVC)
Linux - 32/64bitgcc 4.8.1, gcc 4.9.1
I thought that was official enough.
Cheers,
Ivan
> It isn't. The page is just plainly wrong.
In that case, I retract my previous comments. Where are the *proper*
requirements documented then (for future reference)?
> That's the list of platforms the Qt CI tests on.
It lists both CI tested and untested things there.
--
Cheerio,
Ivan
> I would have said the docs or the wiki somewhere, but I've just discovered
> that the docs are wrong... :-)
Heh, I had the same approach. :)
--
Cheerio,
Ivan
Hi,
Which cmd line options are available in KSnapshot and not in
Spectacle? Is it only --freeregion and --child?
If those are not supported by Spectacle, a shim (as opposed to a
symlink) would not help much IMO. I don't see what a shim would be
able to do when passed those arguments if the receiv
Is there any reason for not changing the command line arguments of
Spectacle to fit KSnapshot? It is not like anyone is used to them yet.
Cheers,
Ivan
--
KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key id: 850B6F76
Hi Boudhayan,
Before this happens, Spectacle needs to have its own product on BKO.
As far as I see, there is only the kscreengenie component in
ksnapshot, which was a weird place to have a new application in the
first place, and is impossible to find out unless one knows the
history of Spectacle.
> Oh yes, I had completely forgotten about that. Thank you so much for
> bringing this to notice, Ivan!
No problem. I've noticed the issue when I wanted to submit a couple of
bugs/wishlist things. :)
Cheers,
Ivan
http://blog.qt.io/blog/2015/12/18/qt-5-6-beta-released/
> Webkit and Qt Quick 1 Removed
>
> We have removed WebKit and Qt Quick 1 from Qt 5.6 release content.
> The source code is still available in the repositories, but these are not
> packaged with Qt 5.6 any more. **Qt Script remains deprecated
> QtScript support in Kross depends on Qt's QtScript.
Meant to reimplement the scripting mechanisms we have to use Kross
instead of QtScript - to expose the scriptable objects to Kross.
IIRC (haven't checked Kross for a long time) it supported accessing Qt
objects and properties/methods, was able
> Isn't the designated successor for QtScript QJSEngine
> (I even assumed there should be some porting tools?)
That's what I meant under 'qml engines'. :)
A relevant mail by Frederik:
http://lists.qt-project.org/pipermail/interest/2015-June/017446.html
Cheers,
Ivan
--
KDE, ivan.cu...@kde.org, h
Hi all,
We currently have two ways to track recent documents - KRecentDocument
and KActivities.
The later provides a more nuanced approach:
- it records usage events per activity (document opened, closed,
etc.) which allows for different recent documents for different
activities - this is alrea
Hi everyone,
As previously announced, KActivities has been split into a few
separate repositories. This mail is mostly intended to notify our dear
packagers of the change, and the plan for the transition period.
KActivities framework 5.19 (as released a few days ago) contains
everything that it u
Hi Albert,
What schedule kio-extras have?
Cheerio,
Ivan
p.s. I'm thinking more and more that kactivities-workspace repository
might be a better solution ...
--
KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key id: 850B6F76
If used for crypto, it is a security issue.
Now, while I don't expect anyone who implements the crypto stuff to use
KRandom, I do agree that KRandom docs should explicitly state this.
Cheers,
Ivan
Hi all,
I'm announcing that Plasma Vault is in the review phase - you can get
it from kde:plasma-vault or with kdesrc-build plasma-vault.
Plasma Vault is a system for easy creation of encrypted data storage
(not for whole system encryption - we have distribution installers for
that).
It is consi
Hi all,
Just an update, so far, the following has been changed so far:
- One Messages.sh to create a catalogue used by all components, needs testing;
- Applet renamed to org.kde.plasma.vault and plasma_applet_vault.so
(to fit the rest);
- Icons for the applet added to the breeze plasma and icon t
Hi all,
All i18n issues should be fixed now, and other ones as well, so I'll
be requesting plasma-vault to be moved to the workspace module.
I'll also add it to the kdesrcbuild after it is moved.
Cheers,
Ivan
Hi all,
Would it be possible for sysadmins to just rename master ->
master-kde4, and master-kf5 -> master?
Cheers,
Ivan
On Tue, Jan 16, 2018 at 9:20 AM, Pali Rohár wrote:
> On Tuesday 16 January 2018 09:05:41 Alexander Semke wrote:
>>
>> On 16.01.2018 00:45, Pali Rohár wrote:
>> > Because it d
t it. If people want to use liquidshell
instead of plasma or lxqt, why would we stop them?
I don't think we've had 'political' discussions in the review phase before,
and I don't think we should now.
Cheers,
Ivan
--
dr Ivan Čukić
KDE, ivan.cu...@kde.org, https://cuk
Hi all,
While I do like the invent name, I agree there should be a redirect of some
sort from git.kde.org to it.
The aforementioned Debian salsa server has one as well - https://
git.debian.org/ - a message stating that the new server is 'salsa.debian.org'
Cheers,
Ivan
--
dr Iv
to both sentiments - that projects should have different names and that
this is a bit off topic for the gitlab migration.
Cheers,
Ivan
--
dr Ivan Čukić
i...@cukic.co, https://cukic.co/
gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
On Sunday 01 September 2013 01:03:59 Ben Cooksley wrote:
> Hi everyone,
>
> Due to an unfortunate accident involving git merge, several branches
> of the plasma-framework repository were rendered unusable.
>
> To correct this, two branches have been forcibly rewound. They are:
> - master: now at
> hidden under org.kde.* but that isn't the case anymore if you
> introduce private.org.kde.*
>From my POV, Sebastian's proposal is spot-on for that reason alone - it is
not a (public) 'qml kde import'. It is a private thing.
Cheerio,
Ivan
p.s. and, in all honesty grepping for org.kde will retur
Hi all,
Following kde-workspace (and stealing a few sentences from that announcement),
we're planning to merge the frameworks-scratch branch of kactivities into
master later today. That means if you're building 4.x branch of Plasma
yourself from Git, you should switch to the
KDE/4.11 branch. Th
> Please no. We have a 4.12 release to make in 2 weeks and back when we did
> the 4.12 planning the only agreed repo to be freezed for 4.11 was
> kde-workspace.
What about doing an early KDE/4.12 branch from master so that the release can
continue as planned, while not slowing us down for further
> I was planning to branch master into KDE/4.12 after October 30 and
> before November 6.
>
Forget about it. Decided not to create problems - I'll use the same name
for the branch as kdelibs do for the time being - frameworks :)
Also it means that you don't want a 4.13.x for kactivities, right?
>
> Well, to be honest, if you don't want a 4.13 release i'd prefer you actually
> use master for KF5. Otherwise people might random-commit fixes to master
> and then wonder why they never got into a release, so the two situations i
> think make sense are:
People don't really contribute to kactivit
/startactive.
- Ivan Čukić
On Oct. 24, 2013, 2:04 p.m., Martin Klapetek wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.
saw it on a
different screen to the one I had when I made it.
If you want to try it with a radial gradient, mind that around the logo, the
background needs to be pitch-black. Because the masking for the gear is a
simple black overlay.
- Ivan Čukić
On Oct. 24, 2013, 3:15 p.m., Martin Klapetek
> On Oct. 24, 2013, 3:35 p.m., Ivan Čukić wrote:
> > Actually, this is something that I wanted to do ever since I saw it on a
> > different screen to the one I had when I made it.
> >
> > If you want to try it with a radial gradient, mind that around the logo,
>
> On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote:
> > What's the cold startup time like for KSplashQML compared to KSplashX?
> >
> > Let's not forget that the reason KPlash was rewritten to only depend on
> > X + libjpeg + libpng was so that the startup time would be limited by
> > the time
time would be limited by
> > the time it takes to load the images for the theme.
> >
>
> Martin Gräßlin wrote:
> but that's a long time ago, isn't it? So Moore's Law... Anyway could be
> interesting to do such comparisons on spinning metal.
>
> I
time would be limited by
> > the time it takes to load the images for the theme.
> >
>
> Martin Gräßlin wrote:
> but that's a long time ago, isn't it? So Moore's Law... Anyway could be
> interesting to do such comparisons on spinning metal.
>
> I
> > and adding cifs to the list of mounttypes that are "probablySlow"?
>
> It's not my place to object since the code isn't mine. Yet i do
Whether it is a good to use probablySlow in okular is one question. The other
one is whether cifs should be in the probablySlow category.
>From my point of
Aloha,
> - Resource Description Framework (RDF)
> The biggest problem with RDF is that it raises the knowledge needed to
I'm not sure this was *the* problem with nepomuk adoption, but lets ignore
that for a moment :)
So, nepomuk was based on rdf and sparql. Essentially, a simple and
standardiz
> If we all decide to store stuff in sqlite, then it doesn't matter if they
> are separate database files or the same one.
I might be missing a few things here, but asking questions is the road to
enlightenment :)
- There is no way to query across different stores, which was the main appeal
of
> for the Plasma Active shell as it currently is, single-store querying might
> be workable as we tend to keep most of the different resources separated in
> the UI (though that’s one thing i want to change in future releases, so you
> can group a set of bookmarks with a given file, e.g.)
Piggy-b
> today before 17:00; this weekend i’m busy, and then next week i’m relatively
> available again.
Monday or later for me.
--
Science gathers knowledge faster than society gathers wisdom.
-- Isaac Asimov
> If both are sqlite, then it's one query -
>
> select fid from tagRelation, activityRelation where aid = 'activityId' and
> tid = 'TagIdentifier';
Now your talkin'
This looks nice
- It needs to be abstracted into a proper api that can understand that those
are separate dbs. (this removes my p
> As I understand it there are no plans to remove the nepomuk-core or
> nepomuk-widget libraries. If you switch to Baloo, anything compiled against
> nepomuk will still run but will act as if nepomuk is disabled. This is
> something clients previously had to cope with anyway.
Meaning that everyth
On Tuesday, 24. December 2013. 22.03.28 Àlex Fiestas wrote:
> As I see it, the nepomuk maintainer says it works better than Nepomuk for
> all cases covered by SC. I don't see any reason not to move forward then.
The truthfulness of Vishesh's claim does not enter into it. If we believe it
(and I d
> The most notorious exceptions are to this rule are nepgoogle and webminer.
> Maintainers of both projects are already working on porting them to Baloo.
This I like.
Baloo seems to be working very nice (I've been running it for some time now),
so if all clients are being ported, then I have no
Hi all,
I wanted to post this on the blog, but my server has some issues lately, so
I decided this is the best alternative.
Some people at Tokamak desired to have completion for kdesrc-build, so I
made a very dirty and ugly completion function for it.
--
function _ksrccomp() {
reply=(`grep ide
You are evil :) Thank you dude!
On 11 January 2014 21:34, Ivan Čukić wrote:
> You are evil :) Thank you dude!
>
>
> On 11 January 2014 17:04, Thiago Macieira wrote:
>
>> On sábado, 11 de janeiro de 2014 11:38:25, Ivan Čukić wrote:
>> > function _ksrccomp() {
> Ideally this would be exposed in the File object, maybe with some sort
> of QVariantMap userProperties() method.
Please don't make it load all attributes and values into the memory if the
most common use-case is to load a value for a desired key.
I'd rather go for something like
some_iterat
Well, the 'worst case' is actually the real case.
But, the thing is that it will be actively tested and developed simply
because we will have both filesystems with xattr (home etc.), and without
(vfat usb-s, encfs stuff and similar).
So, both are used at the same time, and regressions will be not
> To move a file to another machine and have the metadata be copied and re-
> indexed on that new machine as well. The copy process just needs to take
> care of transfering the xattr. This can even work when using a USB stick or
> so as interim medium.
I'm all for xattrs, but this thread really r
> Ping, 4.13 is looming over. If you want to make it so there's no new
> releases of 4.12.x anymore and master is KF5 based, please discuss now.
>
> Personally I'd suggest against it since seems that even if we dicussed for
> that happening to kde-workspace people did not get the memo and got ang
Hi all,
Since we have changed the location of our config files not to use .kde
anymore, we will need some way of moving the old configuration files to their
new locations.
Should we use kconf_update for this, or is something else in the works?
Cheerio,
Ivan
--
Make your code readable. Prete
On Friday 04 Apr 2014 21:36:11 Luca Beltrame wrote:
> David Faure wrote:
> > Kevin Krammer had thoughts on the topic - iirc along the lines of "every
> > application should take care of migrating the relevant data" ? (cc'ed)
>
> To give more context on this question: kactivities (KF5 based) can be
> +for (const auto testSubdir: { ".kde", ".kde5" }) {
> Shouldn't that be .kde4?
Yes, already fixed in the next commit. :)
> That block of code ($KDEHOME, otherwise ~/.kde, otherwise ~/.kde4) sounds
> like code that could be shared. Should we have a kde4ConfigHome() and
> kde4DataHom
Hi all,
What do you think about splitting the kactivities repository into these:
- library (would remain in the kactivities repo)
- daemon (kactivities-service)
- workspace stuff (kcm, doplhin file linking, activities:/ kio, something
else?)
The reason why this came up again is that the library
> > * there is a flag which allows building only the library at the moment,
> > but
> > that seems not enough.
>
> Using that flag allowed me to successfully compile the library on Windows.
Sorry, didn't mean that it did not help compiling, just that it seems that a
flag does not seem enough fo
> Does the library make sense without the daemon? If not then it falls into
> this constraint from https://community.kde.org/Frameworks/Policies :
>
> "Solutions have a mandatory runtime dependencies, it is part of their design
> and where their added value comes from"
That is the reason it ended
> my understanding was that it's still possible to bypass the code review, so
> I cannot see that it's against the KDE Manifesto as it's only a kind of
> social contract. Or am I missing something.
>
> Personally I like the idea of having the +2 limited to the devs familiar
> with the code.
I ag
> that needs to be reverted because it's actively objectiona-
> ble. As Ivan pointed out, few of us will ever commit any-
> thing if we're not confident it would meet with the approval
While I do agree that we have a strange and unreally awesome community that
behaves really well (and I do trust
> I got this question from Boris, but do not feel qualified to answer,
> so forwarding it here. Please CC Boris in reply.
If the report is not separated into components, then I'd guess kde-devel is
the right place for it.
Lets see what the others will say.
A question that I'd have for Boris is
> Yyou need to setup git correctly, so that "gerrit" in that command is
>> valid,
>>
>
> I see what you're saying, and you're probably right -- there's a bar,
> indeed. That bar could however be effectively removed by having a
> spoonfeeding,
>
An alternative to the setup documentation is to actua
> I'd add Applications/* and Plasma/* to this.
>Would it be possible to add the Calligra/* release branches to that
Seems that release branches are starting with capital letters. Would that be
possible and sufficient for the deletable-branch heuristic?
--
Cheerio,
Ivan
KDE, ivan.cukic at k
> I want:
> * A dashboard to see the patches/Merge requests/whatever against the
> projects i care
> * A dashboard to see the patches/Merge requests/whatever against all
> projects * Upload patches via git diff + web
+ Web APIs for the above. I always wanted to have an applet that shows my
rev
> > Therefore sysadmin proposes that both clone and scratch repositories
> > be eliminated as a concept with the next iteration of our Git
> > infrastructure.
>
> N not scratch repos. I can see clones being useless as branches
> in the actual repos should be used instead, but I personally con
Hi,
Because of the short release cycle for the frameworks, it is hard to
have bigger new features included into one of them. Slowly evolving
APIs while developing stuff leaves a lot of crud and deprecated
methods later.
What is our policy about having experimental (unstable API/ABI) parts
in a fr
missed.
I'd propose to go for:
- experimental namespace to force the user to see that something is not stable
- 0 soversion to show that the library has no stable ABI.
Cheerio,
Ivan
On 10 January 2015 at 10:23, Ivan Čukić wrote:
>> The C++ committee uses (for example)
>> std::e
wrote:
> Ivan Čukić wrote:
>> - 0 soversion to show that the library has no stable ABI.
>
> I'd actually set both the soname and the fully-versioned name to
> libfoo.so.0.1, then if you change something binary-incompatibly,
> libfoo.so.0.2, etc. (or use libfoo.so.
Hi,
I'm volunteering KActivities for the test.
Cheerio,
Ivan
line at the
end of the function:
bargs.setForcesNewWindow(forcesNewWindow);
Replacing this with false is IMO more readable as you don't need to scroll up
to check what the value of forcesNewWindow is:
bargs.setForcesNewWindow(false);
Cheers,
Ivan
--
dr Ivan Čukić
i...@cu
ize) before you start appending (this is for m_units).
BTW, these for loops can be replaced with std::transform and
std::back_inserter, but I don't want to go overload the review. ;)
Cheers,
Ivan
--
dr Ivan Čukić
i...@cukic.co, https://cukic.co/
gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
e a purpose.
Cheers,
Ivan
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/
p0323r8.html#expected.synop
--
dr Ivan Čukić
i...@cukic.co, https://cukic.co/
gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
he function you need to pass to
`then` when calling it, which you lose if you switch from std::function to
a generic Fn parameter. But you can (since you're already using C++20)
restrict it with the std::invocable concept to avoid this loss of API usage
information.
Cheers,
Ivan
--
understood by QVariant.
The type in the future can be QVariant-able while the lambda you pass to
`then` might be move only because it uses a unique_ptr somewhere inside.
Cheers,
Ivan
--
dr Ivan Čukić
i...@cukic.co, https://cukic.co/
gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
ile this can lead to problems, I'd rather have a different (tooling-based -
maintainer notifications when something is merged or pushed directly) solution
for this, than changing one of the things that, for me, define the KDE
community.
Cheers,
Ivan
--
dr Ivan Čukić
i...@cukic.co, https://
> But I'm all for everyone can create a clone of a already hosted project. This
> will fix the concerns above and still keep the focus on KDE.
+1
--
Cheerio,
Ivan
--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the shinin
> Are the developers not monitoring these mailing lists? I thought the
> whole point of having them is so developers know when there are
> updates to bug reports. Is there some other way developers find out
> when there are new or updated bugs?
We are.
One question, the unmoderated mails are in
> if i'm correct, the plasma bugs are now redirected to the main
> plasma-de...@kde.org
I don't think so (I've checked the headers of a bug-mail - no mention
of plasma-devel). It was the case some time ago and we were fed up
with it so plasma-bugs list was introduced.
Cheerio
--
While you wer
> if we go ahead with this time and place, this sprint will coincide with a
> Nepomuk and KDE Multimedia sprint, so it will be _quite_ the busy place,
> though i think that would be a good thing in this case as having more people
This is (from my POV) both good and bad.
Bad: I guess there are mor
> Example:
> [KDevPlatform] fafd165: Don't completely ignore the retrieved top-context
For me, this is more useful, so +1
Maybe adding a keyword 'commit' before the short hash like this
[KDevPlatform] Commit fafd165: Don't completely ignore the retrieved
top-context
--
Cheerio,
Ivan
--
Whil
>> Sebastian concluded that storing all the events in Nepomuk wouldn't be
>> wise, so it was agreed to store them in Zeitgeist which was designed with
>> that sole purpose.
>
> to be precise: I wanted to test storing all in Nepomuk first which I
> have not done yet.
I didn't know that. If it turns
Another topic for Platform 11 - Moving stuff from libkonq to kdelibs?
It has a quite significant number of users.
Cheerio
> - It should be mostly source compatible with Qt4, and is just an opportunity
> to break binary compatibility.
Well, even if we do nothing, we are breaking ABI. So, from my point of
view, this is a perfect time to do some API cleanup (all those
deprecated methods, faking virtuals with slots etc.
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101885/
---
Review request for kdelibs.
Summary
---
KRecentDocument now sends inf
nything
apart from that, can I commit?
- Ivan
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101885/#review4590
---
On Jul
> On July 11, 2011, 11:24 a.m., Aaron J. Seigo wrote:
> > kio/kfile/krecentdocument.cpp, line 103
> > <http://git.reviewboard.kde.org/r/101885/diff/1/?file=26347#file26347line103>
> >
> > should be an asyncCall?
>
> Ivan Čukić wrote:
> yes
> On July 11, 2011, 11:24 a.m., Aaron J. Seigo wrote:
> > kio/kfile/krecentdocument.cpp, line 103
> > <http://git.reviewboard.kde.org/r/101885/diff/1/?file=26347#file26347line103>
> >
> > should be an asyncCall?
>
> Ivan Čukić wrote:
> yes
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101885/
---
(Updated July 20, 2011, 10:11 a.m.)
Review request for kdelibs.
Changes
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101885/
---
(Updated July 20, 2011, 10:16 a.m.)
Review request for kdelibs.
Summary
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101885/
---
(Updated July 31, 2011, 6:11 p.m.)
Review request for kdelibs.
Summary (
> To avoid confusion and having overlapping installations of libkactivities
> I think you need to rename the new kactivities.
>
> Maybe even go so far as to deprecate the old kactivities in kdelibs 4.7
>
> kactivities-ng or some-such for the new version
Are there any decisions about lib naming in
> Both "kactivities/master" and "kdelibs/4.7" install the file
> "lib/libkactivities.so", preventing package generation, so something
> has to change.
kdelibs/4.7 shouldn't be used with a separate libkactivities. This is
for 4.8 and further.
The problem can be that some (plasma active 1.o) packag
>> kdelibs/4.7 shouldn't be used with a separate libkactivities. This is
>> for 4.8 and further.
>
> I believe we are supposed to build the rest of KDE (git) against the 4.7
> branch of kdelibs now, since master is stale and frozen? Has that changed
> again?
It seems so... I thought there will be
I guess I should have posted this to release team mailing list, but
this way the topic will have more people involved.
As you all (probably) know, Dennis Ritchie has passed away. In my
opinion, we should somehow make tribute to him.
I'm not sure the idea to name a release after him would be fitti
> You want the release team for this ;-)
Yes, as I said:
> I guess I should have posted this to release team mailing list, but
> this way the topic will have more people involved.
Just wanted a general core-dev response, not only those who make releases.
--
Ivan
> Sure, if a naming flamefest can't be big enough on a small list, let's do it
> on a list with more subscribers.
Ok, I apologize. Didn't really exoect something like this to become a
flamefest. Mail sent to the r-t.
>> [Components-platform]
>> name=touch
>
> something Sune just noted to me..
> maybe an environment variable would be better to chose this?
As on override? For that, I'd say +1, otherwise -1 :)
--
Cheerio,
Ivan
--
While you were hanging yourself on someone else's words
Dying to believe in what
1 - 100 of 149 matches
Mail list logo
