Re: [rkward-devel] Endless errors starting up org.freedesktop.dbus-system on OSX
I just realized that I said that I noticed these errors in March 2013; I meant March 2014. Sorry; Japan's fiscal/academic/everything year is April-March, and as a result, I always think of years starting in April. Last March, therefore, feels like 2013 because that's the budget/academic year it was included in! I also had a chance to check on a student's Mac on Friday. It has only ever had one installation of RKWard. The behavior was there as well, so it's not linked to multiple installs. Thanks! -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ 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
Am Dienstag, 14. Oktober 2014, 04.32:02 schrieb Prasenjit Kapat: > Hi All, Morning Prasenjit > I haven't kept up with the development in a long long while, so my comments > may seem out-of-turn! (I don't have much idea about the KDE's software > development practices, either.) > > On Mon, Oct 13, 2014 at 5:29 AM, Thomas Friedrichsmeier < [snip] > > > > is available). Would that be considered ok? For a decentral MediaWiki > > > > installation, could KDE.org accounts be used for login? > > > > > > KDE identify access works for all three wikis so it's possible. > > > > What I meant is: Could KDE.org accounts be made to work for a fourth, > > RKWard- > > > specific wiki? Or would this even be considered mandatory? > > This is, technically, a hurdle - in the sense that - a user may not want to > create a 'kde.org' account just to edit the wiki. But, thinking > practically, I think, most edits to the wiki come from within the team. Then you could create a normal account on the wiki as you need to do on almost all wikis, right? [snip] > > techbase / userbase split (e.g. the pages for installing on the various > > platforms). So, it would be much easier for us to keep things that way, > > initially, and then see where things are going, in the long run, _after_ > > migrating. > > My 2 cents worth: > If we can not get a rkward.kde.org landing, we can stick to > techbase.kde.org as the the only source of information and userbase can > simply link to techbase. As an aside, in the early days, even our sf wiki > page seemed convoluted to me. Eventually, you get used to it! So, even if > the techbase / userbase results in an unavoidable fragmentation, we will > get used to it. (But what about the users? I know.. ) > > Btw, who created this location? > https://userbase.kde.org/RKWard See: https://userbase.kde.org/index.php?title=RKWard&action=history Looks like some of the KDE Documentation team. > In that case, we can make userbase as a place for screenshots and news - > that's it. For everything else, head over to techbase. Rkward will more or less automatically get a page like this: https://www.kde.org/applications/system/krfb/ Then we'd collect the end user documentation on userbase (with the help of our docu team) and the documentation for developers on Techbase. But that will take time and that's ok. See the other mails for details about the wikis and the plans. [snip] > Reading the "Application_Lifecycle" page, I have a feeling that we will be > shunting back-and-forth between "playground" and "kdereview" a few times > before we hit the sweet spot for KDE review team's approval. Why do you think? It's not that you're stalled in the review process and can't do anything. Normally the review process is quite constructive feedback and help and nothing to keep you back. > What about downstream? Do the downstream distributions (stable / unstable / > LTE / enterprise-ready versions) grab applications from playgorund / > kdereview stage? Honestly I think they will do what you/we tell them. If we make some nice promo stuff, the software is stable and some nice dot story then they will pick what we tell them. > Ideally, as Mario mentioned, it may make sense to be part > of the kde-edu (https://edu.kde.org/applications/all/) group. And yes that makes sense. griits Mario -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ 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
Am Montag, 13. Oktober 2014, 11.29:31 schrieb Thomas Friedrichsmeier: > Hi all, Good morning Thomas and Co [snip] > > > For RKWard, a bunch of pages would fit into more than > > > one category (several into all three), and I don't think that would > > > really help. I'd like to keep the wiki in one place (on > > > rkward.kde.org, once that is available). Would that be considered ok? > > > For a decentral MediaWiki installation, could KDE.org accounts be used > > > for login? > > > > KDE identify access works for all three wikis so it's possible. > > What I meant is: Could KDE.org accounts be made to work for a fourth, > RKWard- specific wiki? Or would this even be considered mandatory? Just talked with some sysadmin and incubation guy. It's just mandatory that the sysadmins of KDE have access to the (KDE) infrastructure. Everything else is possible if it's technically possible. > > About the > > three wikis and an own for rkward that needs to be thought about. I think > > it's possible to have an own wiki but over time people will expect > > development stuff for rkward on Techbase and end user will of course > > search for end user documentation in Userbase.kde.org > > Well, not saying this is set in stone for all times to come. But right now, > essentially, the wiki is our website. I.e. it also covers news, download > links, screenshots, etc. And some pages are organized quite orthogonal to > the techbase / userbase split (e.g. the pages for installing on the > various platforms). So, it would be much easier for us to keep things that > way, initially, and then see where things are going, in the long run, > _after_ migrating. Makes sense. And their are several possibilities. Setting up a wiki on KDE infrastructure for you, leaving wiki on sf for the moment and giving sysadmins access, etc. pp. > > > Using downloads.kde.org wold have a rather high wanna-have > > > rank, as downloads are one area where SF.net tries particularly hard to > > > spoil their reputation. The target state would probably be having all > > > our services currently hosted on SF migrated to their counterparts on > > > KDE.org, and being accepted in extragear. > > > > This should then go through the review process. That means sending an > > email to kde-core-devel that you plan to move rkward from playground or > > outside ;-) to extragear (or kde-edu?) and then people will take a look, > > see if i18n works, code quality, etc. pp. This should and will be a > > constructive process of course. > > This point is not entirely clear to me, yet, too. I think we'd be > interested in starting moving (git first) rather soonish, after the > upcoming release is out. However we wouldn't really be ready for "review" > at that stage. Most importantly we'd want to take care of plugin i18n, and > KF5 porting before it makes sense to get detailed feedback. These are > among the very next high-level tasks we plan to work on, but neither is > something to manage in a day or two. > > Does that mean we'll be entering "playground", initially? Are "kdereview" > and "playground" even tangible entities any more, these days, or just > terms from the days of SVN? The git repository addresses would stay the same, but where they are logically in projects.kde.org and such would change as they are moved from playground to extragear. > And what - if anything - will change, once we > are ready to enter "extragear"? It's mostly a status thing. Showing that you're stable software rather then something planned and not yet released but hey you're already stable software anyway. The review is mostly to check if the minimal standards are met like working i18n, documentation, etc. Hope that makes it clearer and otherwise don't hesitate to ask. Next time I'll answer more quickly. Best regards Mario -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
