Re: [rkward-devel] Some thoughts on switching project hosting
Hi, putting Mario in CC, as he might be able to clear up some details, esp. with respect to what hosting on kde.org would mean. (Mario was in BCC in my first mail, as I wasn't sure, whether that email address was ok to use in public). On Sunday 05 October 2014 17:12:46 meik michalke wrote: > Am Sonntag, 5. Oktober 2014, 09:27:57 schrieb Thomas Friedrichsmeier: > > That _is_ a discussion worth having, but right now, my goal is to explore > > what hosting requirements we have, and how we would go about migrating in > > order to ensure a mostly smooth transition. > > i'm glad this comes up :-) > > i don't know so much about the infrastructure of KDE, but having seen how > smooth it is to host stuff on github, it sure is time to think about a > migration, carefully. I think github and kde.org are probably not entirely mutually exclusive, although I'm not so keen on spreading the project across ever more service providers. But of course as git is a distributed VCS, boundaries are much less absolute in either direction. I don't know too much detail about KDE's offerings and requirements for projects, myself, but here's an initial list of pros and cons, based on my understand so far: Access control: - On KDE we won't have close control over who can commit - err push - and who can't. On the other hand, this might encourage contributions from the KDE community. Code policies: - On github.com we'd have all freedom. On KDE.org, applications are expected to comply with a few rules (https://techbase.kde.org/Policies/Application_Lifecycle). This could actually be a bit of a problem, as so far we have been deliberately _not_ following certain developments in order to keep backwards compatibility with earlier kdelibs releases as much as possible. @Mario: Background is that a good deal of our users is highly conservative about updating anything on their system _except_ jumping head-first to each new release of R. Problem is that fairly often, new release of R required changes on our side. So our latest code always had to be both forward compatible with the latest R, and backwards compatible with pretty dated kdelibs. Of course, when porting to KF5, we'll have to make a clean cut, anyway. However in the not too distant future, we may again want to stay behind on some changes in KDE. Exactly how much of the problem is that? Bug tracking: - On github, we'd have a separate tracker for ourselves. On kde.org we'd be yet another category inside a huge bugzilla. OTOH, this would make it much easier to forward kdelibs-/ktexteditor-related bugs, or even weed these out on submission (if they have been reported, before). - I don't think there are any fundamental differences regarding integration of bug tracking with wiki / commits / etc. Web hosting: - KDE.org offers projects subdomains of kde.org (@Mario: Only once accepted into extragear, or already in earlier phases?). AFAICS we'd have pretty much all the flexibility we'll ever need, there. Not sure on the maintainance burden, though. Github seems much more reduced in comparison. I think for the project's main user-facing landing page, github just isn't shiny enough. Downloads: - @Mario, how exactly are KDE extragear projects expected to distribute (binary) files? Are there any limits on what / how much can be offered for download? Wiki: - KDE has some central wikis (techbase, community, userbase), although the division between these has always been confusing to me. On github the wiki would remain separate. Probably we could host a custom wiki on rkward.kde.org, too. Translations: - KDE has a translations team, that hopefully will help us out. On github, we'd have to stick with a separate solution (currently translations.launchpad.org). Other tools: - KDE.org has reviewboard, which I like a lot. I don't have first hand experience with pull requests on github. Community: - On KDE.org there's definitely more hope that skilled folks will help us with certain tasks. If it's not coding or documentation, it might still be packaging. IMO, that's probably the biggest selling point for kde.org. The brand: - Regardless of how we feel about either brand, we're technically bound to KDE for good, anyway. What I think so far: - Hosting on KDE.org seems rather natural for a KDE project targetting end users. The biggest question is whether we can and want to follow all rules KDE.org expects from us. -- > how about something along these lines: > > - we make RKWard 0.7.x the first KDE FW5 release branch >- it starts with a new git repo, no matter where > > - RKWard 0.6.x remains as the KDE 4 branch, at least as long as 4.14 is >commonly used; it will however only get bug fixes, development focusses >on 0.7.x >- it stays on sf.net SVN >- later on, it can be moved to git as well, which shouldn't be so painful > because there's no urgency Mostly agreed, except for developing one branch in SVN and the other in git. Ch
Re: [rkward-devel] Some thoughts on switching project hosting
hi, Am Sonntag, 5. Oktober 2014, 09:27:57 schrieb Thomas Friedrichsmeier: > That _is_ a discussion worth having, but right now, my goal is to explore > what hosting requirements we have, and how we would go about migrating in > order to ensure a mostly smooth transition. i'm glad this comes up :-) i don't know so much about the infrastructure of KDE, but having seen how smooth it is to host stuff on github, it sure is time to think about a migration, carefully. how about something along these lines: - we make RKWard 0.7.x the first KDE FW5 release branch - it starts with a new git repo, no matter where - RKWard 0.6.x remains as the KDE 4 branch, at least as long as 4.14 is commonly used; it will however only get bug fixes, development focusses on 0.7.x - it stays on sf.net SVN - later on, it can be moved to git as well, which shouldn't be so painful because there's no urgency as a side node: github has wikis for its projects, and kind-of offers downloadable binary files: https://github.com/blog/1547-release-your-software but it's probably easier to host bundles somewhere else. viele grüße :: m.eik -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf signature.asc Description: This is a digitally signed message part. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] power analysis plugin
hi, Am Sonntag, 5. Oktober 2014, 14:49:40 schrieb Thomas Friedrichsmeier: > On Sunday 05 October 2014 12:00:05 meik michalke wrote: > > i also fixed the sample size controls for two sample designs, and added > > the > > possibility to provide eta squared instead of cohen's f. > > a thought on that: For two samples, you could hide the "number of > observations _per sample_" note. ok, i'd have to change the spinbox label then, to make it clear that these numbers represent the sample size. but you're right of course, when there's two of them it's obvious it's per sample ;-) i'm amazed that almost half of that plugin code already is logic rules. > That might even help work around the squeezing you get when switching from > single sample to two samples (depending on dialog height). that's still an annoying bug, isn't it? by the way, while working on this i came to notice that the squeezing only happens on my laptop, not on my desktop machine -- both run the same distro, KDE and Qt versions and, from what i can see, use the same desktop theme, window layout stlye etc. on my desktop, the window is always resized accordingly (it only never shrinks after it had grown due to new elements appearing). > Another thing is: Considering this looks fairly finished (apart from > documentation), and useful to a wide audience, should we make this part of > the 0.6.2 release? sure, why not. would someone jump in to do write the help file? ;-) how would you like to do this? generally, i'd prefer to add it as a kind of bundle, so it remains a plugin on its own, at least so it can be disabled easily in the plugin configuration. this makes it easier to release updates of that part without having to wait for another RKWard release. but that's probably a bit more complex to do right, at least for the debian packaging? > On a more general note, which external plugins are "ready" for inclusion? don't you think the menus might get a bit to crowded if we include it all? perhaps we can re-think the plugin installations process instead, to make it more obvious which plugins are available (at least the ones in our own repo). that said, i think the plugins for ANOVA, factor and cluster analysis are quite useable -- except they all lack docs... > (Well, yes, I really should have thought about this, earlier. OTOH, I think > there is a point for releasing 0.6.3 rather shortly after 0.6.2 - i.e. > before end of this year - anyway. This could include dynamic i18n for > plugins, and some other bits that are mostly orthogonal to porting to KF5, > technically.) you mean like a restart button for the R backend? :-D viele grüße :: m.eik -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf signature.asc Description: This is a digitally signed message part. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] power analysis plugin
Hi, On Sunday 05 October 2014 12:00:05 meik michalke wrote: > i also fixed the sample size controls for two sample designs, and added the > possibility to provide eta squared instead of cohen's f. a thought on that: For two samples, you could hide the "number of observations _per sample_" note. That might even help work around the squeezing you get when switching from single sample to two samples (depending on dialog height). Another thing is: Considering this looks fairly finished (apart from documentation), and useful to a wide audience, should we make this part of the 0.6.2 release? On a more general note, which external plugins are "ready" for inclusion? (Well, yes, I really should have thought about this, earlier. OTOH, I think there is a point for releasing 0.6.3 rather shortly after 0.6.2 - i.e. before end of this year - anyway. This could include dynamic i18n for plugins, and some other bits that are mostly orthogonal to porting to KF5, technically.) Regards Thomas signature.asc Description: This is a digitally signed message part. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Some thoughts on switching project hosting
I gotta say, git is reeeally easy to use on the Mac... -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
[rkward-devel] please test: new plugin for power analysis
hi, here's a new RKWard plugin for you to have a look at: rk.power screenshot: http://reaktanz.de/stuff/R/screenshot_RKWard_power.png in our repo: http://rkward.sourceforge.net/R/pckg/rk.power/index.html if you're using the repo's debian packages, you can get it via sudo aptitude install r-other-rkward-rk.power it uses the pwr package for calculation, so r-cran-pwr is a good addition, if you find it in your repositories. this is version 0.01-1, so please send me your bug reports and desired features for future releases ;-) viele grüße :: m.eik -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf signature.asc Description: This is a digitally signed message part. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] power analysis plugin
hi, Am Samstag, 4. Oktober 2014, 12:08:49 schrieb meik michalke: > Am Samstag, 4. Oktober 2014, 10:34:58 schrieb Thomas Friedrichsmeier: > > - Don't forget to require(pwr) fixed. > > I figured out that for "less" you want to specify a _negative_ effect size > > (and in fact, you can't enter that in the GUI). > > good catch. yes, right now effect sizes can't be negative, i'll try to come > up with something. effect size range now covers -1 to 1 globally. it's pretty usual for correlations, at least. > > I suggest, either going with "greater", only, or showing a warning, when > > the specified effect size contradicts the hypothesis. > > if i take the first road and go astray from the pwr options, i'll probably > rename "greater" to something like "one sided test (first is greater)". i included a warning instead. it's also shown if you give a negative effect size for the other alternatives, respectively. > > - I wouldn't write the results to the workspace _by default_. fixed. i also fixed the sample size controls for two sample designs, and added the possibility to provide eta squared instead of cohen's f. to make it easier to test, i've released 0.01-1 last night. viele grüße :: m.eik -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf signature.asc Description: This is a digitally signed message part. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
[rkward-devel] Some thoughts on switching project hosting
Hi!
Recently, there has been more than one reason to be not-so-happy with our
current project hosting (i.e. SourceForge.net). At the same time the "git"
version control system gains more and more friends, and some people have
suggested switching from SVN to git. Furthermore, KDE has become a much less
monolithical environment (especially, but not only, in its new instantiation
"frameworks").
All of these are good reasons to re-consider our hosting options. I think, the
most obvious choices would be:
- Staying on SF, and keeping everything as is
- Staying on SF, but switching to a git repository
- Moving project hosting to github.com
- Advantage of having a rapidly growing community
- Moving project hosting to kde.org
- Advantage of being the community working on the same platform, and
thus
having the most obvious potential for synergies.
Well, the point of this mail is not really to discuss the pros and cons of
each of these options. That _is_ a discussion worth having, but right now, my
goal is to explore what hosting requirements we have, and how we would go
about migrating in order to ensure a mostly smooth transition.
I'll let you know that I'm currently leaning towards kde.org, though. Please
feel free to start a debate on this, esp. if you would favor another solution.
--
So: What services do we use, and what should we keep in mind about each:
1. Version control: Our needs here are fairly straight-forward. However, some
things to consider when migrating.
- Links to SVN location are at a bunch of places:
- Our wiki
- MacPorts port file
- Windows emerge build file
- (Purely informational also in Debian/Ubuntu package)
- Possibly other packages, we are not directly involved with
- Some people build from SVN, regularly
- Our Ubuntu daily builds on launchpad use a mirror of our SVN
- Launchpad translations syncs the message template from our SVN
Some of this may become obsolete when migrating (at least the launchpad
translations, when migrating to kde.org). However, to ensure a somewhat smooth
transition, we will probably have to make sure to keep our SVN at SF.net alive
for quite a while, probably as a mirror of our primary VCS, then.
2. Wiki and Web: Our "project web", i.e. the pages under http://rkward.sf.net
mostly consist of a MediaWiki installation. I think that still makes a lot of
sense, so we'll want to migrate that 1:1. Further we have a few plain HTML-
files (importantly the building-plugins docu), and some PDFs. Also an apt-
gettable repository of Debian packages.
References to our project pages are all over the place, including compiled
into RKWard itself. So we absolutely want to set up some sensible redirects,
and these should be active for quite some time.
3. Bug and feature tracker: These are a custom brew by SF.net ("Allura"). I
don't know, whether there is a smooth migration path to bugzilla, yet. If
possible, we'd like to migrate both open and closed bugs. Even closed tickets
are still valuable for later reference, at times.
In this respect, there is a further problem to solve: A bunch of comments in
the code, and commit messages references bug tickets. There should always be a
way to resolve these to an existing URL (this needs not be a really user-
friendly way, though).
The location of our bug tracker compiled into RKWard is now an automatic
redirect. However, non-redirecting links will be found in the wiki, and
probably other places.
4. Mailing lists
Anyone with experience in migrating mailing lists (mailman) to a new hostname?
Links to the rkward-de...@sf.net list are all over the net, I'm afraid, and
also compiled into RKWard. Thus the old address(es) should remain active for a
fair amount of time to come (but could be forwarding to the new mailing
lists).
It would be nice to keep the archive at
http://www.mail-archive.com/rkward-devel@lists.sourceforge.net/ functional. As
with bug tickets, many code
comments and commit messages contain references to mails. Links to mails in
the archive will also be found in the wiki.
5. Forums
The public forums were never too active. But they were used for discussing
issues at times. Preserving those discussions for reference would be really
nice, although this could be achieved with a simple HTML-mirror. A "true"
import into another forum software is probably not necessary.
6. Downloads
Obviously we need to offer file downloads. This includes some pretty large
files, esp. for the bundled binary releases (~150MB for Windows, ~400MB for
MAC, source bundles up to 800MB). We even have one file of 2.7GB for download,
currently (Windows build environment). These will probably get smaller, but
not small after porting to KF5 (aka KDE 5).
--
Please fill in the bits I forgot. To sum it up, migrating to a new hosting is
going to require a good deal of work. Some of you have been wondering, why
I've taken a rather conservative stance on t
