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
Re: [rkward-devel] Some thoughts on switching project hosting
Hi All, 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 < thomas.friedrichsme...@ruhr-uni-bochum.de> wrote: > > Hi all, > > On Friday 10 October 2014 21:40:42 Mario Fux wrote: > > Am Freitag, 10. Oktober 2014, 20.38:30 schrieb Thomas Friedrichsmeier: > > > - More flexibility at the cost of more fragmentation > > > > Not that I want to talk bad about github, I know it not that good but I just > > want to understand. What's the flexibility of github that KDE doesn't have? > > in short: No manifesto, including the commitment side. Which is not to say the > KDE manifesto is asking for anything unreasonable, just to state the fact that > it _is_ asking for some things. > > > > 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? 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. > > > 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. 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 In that case, we can make userbase as a place for screenshots and news - that's it. For everything else, head over to techbase. > > > > 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? And what - if anything - will change, once we are ready to > enter "extragear"? 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. What about downstream? Do the downstream distributions (stable / unstable / LTE / enterprise-ready versions) grab applications from playgorund / kdereview stage? Ideally, as Mario mentioned, it may make sense to be part of the kde-edu (https://edu.kde.org/applications/all/) group. Regards, ---
Re: [rkward-devel] Some thoughts on switching project hosting
Hi all, On Friday 10 October 2014 21:40:42 Mario Fux wrote: > Am Freitag, 10. Oktober 2014, 20.38:30 schrieb Thomas Friedrichsmeier: > > - More flexibility at the cost of more fragmentation > > Not that I want to talk bad about github, I know it not that good but I just > want to understand. What's the flexibility of github that KDE doesn't have? in short: No manifesto, including the commitment side. Which is not to say the KDE manifesto is asking for anything unreasonable, just to state the fact that it _is_ asking for some things. > > 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? > 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. > > 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? And what - if anything - will change, once we are ready to enter "extragear"? 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://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 Freitag, 10. Oktober 2014, 20.38:30 schrieb Thomas Friedrichsmeier: > Hi, Morning Thomas > On Wednesday 08 October 2014 21:26:52 Mario Fux wrote: > > Sorry for the delay to answer this long email and with my answer it will > > become even longer but I hope it helps and otherwise just ask and CC: me > > for > > no problem. This is not something to be decided in an instant. > > Thanks for your answers so far, and for your offer to be our sponsor in the > incubation process! > > In a very short summary, I think, KDE's main advantages are: > - Complete hosting solution > - More focussed community > - Very low entry barrier for those already involved in KDE > While on github's side we have: > - Potentially lower entry barrier for those not yet involved in KDE Are you sure? I know that a lot of KDE projects get patches via ReviewBoard by people not yet having a KDE identity and developer account which seems to work quite well. > - More flexibility at the cost of more fragmentation Not that I want to talk bad about github, I know it not that good but I just want to understand. What's the flexibility of github that KDE doesn't have? > I continue to lean towards heading for KDE.org. (Plus, perhaps a > semi-official repo-mirror on github as an outreach to their community?). > Fans of github, speak up. > > Either way, I'd like to be aware of the main problems before we are > half-way migrated. So I'll list the points that could be a problem on > KDE.org (some already mentioned, and commented on, before). Not all of > these are mission- critical to us, of course. @Mario, for those bits that > you can't give a definite answer, what is the best place to ask? > > Technical stuff: > 1) There are a couple of known areas, where we don't comply with KDE's code > policy, yet. Most of that is fixable, and we are certainly willing to work > on that (e.g. our plugins are not currently translatable). However, the > project is quite large, and some of this may take time, esp. when porting > to KF5 is also on the list. What is the expected time frame for taking > care of such technical problems. And will this block us from claiming > rkward.kde.org, making releases on download.kde.org, and using mailing > lists? No, this won't block you. > 2) Two other items on the code policy are a more fundamental problem to us. > My worry here is not so much about uninformed commits to our repository, > but it's quite important to know, will this non-compliance be tolerated, > will it be a problem while under review. > 2a) For one thing, we do have documentation in docbook format. However, the > main in-app documentation is based on a custom XML specification. > Essentially this is for consistency with the documentation format in our > plugins (where using docbook would have too much of an overhead, and not > allow certain features, such as dynamically filling in UI labels and > info). > 2b) A second thing is staying behind on new library features / continuing > to use deprecated functions in KDE libraries. As explained, previously, > this is because our user-base often has very old installations of KDE, but > very new installations of R, and new versions of R often need new versions > of RKWard. I don't think that you'll get a problem with KDE about this. E.g. for KF5 there is still kdelibs4support. I don't know what's the current plan for deprecating it (Kevin Krammer as the KF5 main guy might know). I think it's more likely that you get problems in and with distributions, if at all. > Wiki: > 3) The KDE wikis, yes I know the theory behind the division into three. But > I've had trouble finding the info I needed, more than once, in big part due > to this split-up. You're right. Theory and practice are not the same as usually ;-). > 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. 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 > External ressources: > 4) Some external ressources we might want to keep. The launchpad daily > builds are useful in their own right, for instance, because they cover > different series of Ubuntu (and different versions of KDE libraries, BTW). > I'm not quite clear, what that means with respect to the manifesto's > continuity > requirements. I don't see that this shouldn't work. In fact KDE has quite a good relationship with Kubuntu and IIRC they migrated some of their wiki content to one (or more) of KDE's wikis. >
Re: [rkward-devel] Some thoughts on switching project hosting
Hi, On Wednesday 08 October 2014 21:26:52 Mario Fux wrote: > Sorry for the delay to answer this long email and with my answer it will > become even longer but I hope it helps and otherwise just ask and CC: me for no problem. This is not something to be decided in an instant. Thanks for your answers so far, and for your offer to be our sponsor in the incubation process! In a very short summary, I think, KDE's main advantages are: - Complete hosting solution - More focussed community - Very low entry barrier for those already involved in KDE While on github's side we have: - Potentially lower entry barrier for those not yet involved in KDE - More flexibility at the cost of more fragmentation I continue to lean towards heading for KDE.org. (Plus, perhaps a semi-official repo-mirror on github as an outreach to their community?). Fans of github, speak up. Either way, I'd like to be aware of the main problems before we are half-way migrated. So I'll list the points that could be a problem on KDE.org (some already mentioned, and commented on, before). Not all of these are mission- critical to us, of course. @Mario, for those bits that you can't give a definite answer, what is the best place to ask? Technical stuff: 1) There are a couple of known areas, where we don't comply with KDE's code policy, yet. Most of that is fixable, and we are certainly willing to work on that (e.g. our plugins are not currently translatable). However, the project is quite large, and some of this may take time, esp. when porting to KF5 is also on the list. What is the expected time frame for taking care of such technical problems. And will this block us from claiming rkward.kde.org, making releases on download.kde.org, and using mailing lists? 2) Two other items on the code policy are a more fundamental problem to us. My worry here is not so much about uninformed commits to our repository, but it's quite important to know, will this non-compliance be tolerated, will it be a problem while under review. 2a) For one thing, we do have documentation in docbook format. However, the main in-app documentation is based on a custom XML specification. Essentially this is for consistency with the documentation format in our plugins (where using docbook would have too much of an overhead, and not allow certain features, such as dynamically filling in UI labels and info). 2b) A second thing is staying behind on new library features / continuing to use deprecated functions in KDE libraries. As explained, previously, this is because our user-base often has very old installations of KDE, but very new installations of R, and new versions of R often need new versions of RKWard. Wiki: 3) The KDE wikis, yes I know the theory behind the division into three. But I've had trouble finding the info I needed, more than once, in big part due to this split-up. 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? External ressources: 4) Some external ressources we might want to keep. The launchpad daily builds are useful in their own right, for instance, because they cover different series of Ubuntu (and different versions of KDE libraries, BTW). I'm not quite clear, what that means with respect to the manifesto's continuity requirements. Donations: 5) We never raked in too much cash, but we are currently accepting donations via PayPal and flattr. I once got paid to develop a specific feature, and - without getting anywhere near concrete - we have considered trying our luck with a fundraising campaign to finance focussed development of certain features/tasks. What's KDE.org's take on individual projects looking for revenue? (I see amarok is selling T-shirts, digiKam is accepting donations) Timeline and Procedure: 6) I think in any case, the first step for us would be moving to a git repository on git.kde.org (ok, probably some sort of formal application, too; where?). 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. But from KDE's point of view, which services will be available to us at what stage in the process, and can you give any estimates on the timeline? 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
Re: [rkward-devel] Some thoughts on switching project hosting
Am Sonntag, 05. Oktober 2014, 22.07:25 schrieb Thomas Friedrichsmeier: > Hi, Good morning Thomas, Meik and Co Sorry for the delay to answer this long email and with my answer it will become even longer but I hope it helps and otherwise just ask and CC: me for > 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: First it might be useful to read of http://manifesto.kde.org (quite short), KDE incubator (https://community.kde.org/Incubator) and maybe the KDE Code of Conduct (https://www.kde.org/code-of-conduct/ and longer) . > 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. That's right. If you have commit access on the KDE infrastructure you can commit (almost, www is an exception) everywhere. But actually I don't know of any problems with this to this point in time. And we're still using VCS systems which can revert, right ;-)? > 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. I just took a short look at this Application lifecycle page and I think this makes sense and might guarantee a certain amount of quality. But for KF5 based application and the widening to more platforms (as well on the CI system builde.kde.org) some things might change. In general we're always open for discussion. > @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. I experienced this myself while using rkward for my diploma thesis in the recent months. > 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? Actually I myself would like to see some versions of kdelibs to be supported for a longer time (I'm a Debian user ;-) and I know of other people and projects (e.g. Calligra) as well but currently kdelibs and KDE Frameworks doesn't have too many human ressources ... So at large it sounds like an interesting new project and usage example for KDE and I think these "problems" are solvable. But people with more technical knowledge (in particular about kdelibs) might help you better with this. > 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. What about more manpower for bug triaging and Co? > Web hosting: > - KDE.org offers projects subdomains of kde.org (@Mario: Only once accepted > into extragear, or already in earlier phases?). I think we're quite flexible here as well. I'm currently incubating kdenlive and they used kdenlive.org till now. There code is already on KDE infrastructure but the mailing list is still on sourceforge and the tracking system is Mantis. So it's work in progress and a lot
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] 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
