Re: [rkward-devel] Moving to KDE.org
Hi once more, On Thursday 06 November 2014 19:44:12 Nicolás Alvarez wrote: Non-fast-forward pushes (force pushes) and branch deletions are only allowed for the repository owners. You'll have to decide who that will be. I guess I'll state that in the ticket, whenever I request the repository to be moved to playground, right? (Mario, or would we go for kdereview, directly?) Also one more admin question: So far we had a dedicated mailing list for SCM- commits. That was quite convenient. And in fact, it would be even more convenient, if we had merged it in one list with build bot notifications(*). That would make it easy for all developers to subscribe to a single pack of all that noise that is relevant to those who commit, but not so much for other interested bystanders. I'm sort of hoping to achieve this as part of the transition to KDE.org. Now the KDE way of doing things seems to be using commitfilter.kde.org. Some questions: - Is is possible to direct commitfiltered mail to a mailing list? (Or will commitfilter mail out password reminders and some such?) - Alternatively, is it possible to set up custom notification hooks on a git repo on KDE.org? - Or is the list I have in mind a poor plan, in the first place? Regards Thomas (*) Potentially also bug tracker notifications, although perhaps it makes more sense for those to go to rkward-devel, after all. signature.asc Description: This is a digitally signed message part. -- 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://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Moving to KDE.org
Am Samstag, 08. November 2014, 20.16:19 schrieb Thomas Friedrichsmeier: Hi again, Morning Thomas On Saturday 08 November 2014 14:15:02 Thomas Friedrichsmeier wrote: ok, thanks. Next question: Now pushing the tags fails because they are not annotated. I suppose I could request another exception for this, but probably it would be better to somehow convert the tags to annotated, instead. Is there some svn2git-option for this, that I have missed? I have tried kde- ruleset/bin/fix-tags, but whatever that does, exactly, the push was still rejected. well, that part solved (mostly). Turns out there is an undocumented rule annotated true for tags. With this, most tags can be pushed. Some still fail (not sure, why, but several of those are tags that I had moved in SVN after creating), but none of these seem too important. Two of them are backups that I did not mention in the rules file. No idea why svn2git thought it necessary to create these. I hope the fact that these can't be pushed is nothing to worry about... Great to see you making good progress and even greater to see you improving the KDE wiki documenation on your way! Thanks a lot. Regards Thomas Best regards Mario -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Moving to KDE.org
Hi again, On Saturday 08 November 2014 14:15:02 Thomas Friedrichsmeier wrote: ok, thanks. Next question: Now pushing the tags fails because they are not annotated. I suppose I could request another exception for this, but probably it would be better to somehow convert the tags to annotated, instead. Is there some svn2git-option for this, that I have missed? I have tried kde- ruleset/bin/fix-tags, but whatever that does, exactly, the push was still rejected. well, that part solved (mostly). Turns out there is an undocumented rule annotated true for tags. With this, most tags can be pushed. Some still fail (not sure, why, but several of those are tags that I had moved in SVN after creating), but none of these seem too important. Two of them are backups that I did not mention in the rules file. No idea why svn2git thought it necessary to create these. I hope the fact that these can't be pushed is nothing to worry about... Regards Thomas signature.asc Description: This is a digitally signed message part. -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Moving to KDE.org
Hi! Let's get things rolling. I've started filling some gaps, and adding more todo items to that wiki page https://community.kde.org/Incubator/Projects/Rkward . Separate mail on git migration to follow. Here's a clarification on the planned handling of external plugins: On Thursday 06 November 2014 23:10:33 Mario Fux wrote: Am Samstag, 25. Oktober 2014, 13.16:51 schrieb Thomas Friedrichsmeier: One small exception to our move to KDE is that we intend to establish a small side-kick project on github.com, as a semi-official place to develop external plugins, i.e. those that are not (or not yet) targetted to be included in the official releases. This would need a separate git repository in the first place, and the idea is that this is a bit closer to the R community (but also matches well with the whole concept of external plugins). Not sure, whether this would strictly fall under the continuity requirement of KDE.org, but it certainly should not be a problem to give KDE sysadmins admin access to this. If I understand it correctly you plan to move the source code to KDE's git repos and have another close/copy of the repo on github.com. I don't see a problem. How will you merge features? You might as well use reviewboard.kde.org to encourage contributions by people that don't yet have a KDE developer account. Slight modification of the plan: We may or may not set up a mirror of RKWard's main repo on github. It's not a priority. What we do intend to do is split out part of what is currently kept in the project's main repo, namely external plugins, and host that on github. Rationale: - That SVN branch is not a branch in the git-sense, and will have to be split out into a separate repo, anyway. - The point of this branch is to allow development of plugins on an independent schedule, by independent people, potentially for different users (esp. offering specialized functionality that is of interest to small groups of people, only), and distributed independently of the official RKWard releases. - In fact, external plugins can be developped, anywhere, and to some degree that is happening, already. The idea of offering a semi-official repo for this at all is a) so RKWard developers can provide help b) identify stuff suitable for incubation more easily c) provide a ready-made area for collaboration. - In this area we partiuclarly hope for contributions from the R community, and that is to be found primarily on github. Hence the plan to set up this side-kick project, there. - Selected external plugins will be moved to RKWard's repo on KDE.org, if and when they become part of the main project. We do plan to use reviewboard to encourage contributions to the main repo from anywhere. And the main repo also includes plugins, of course. The difference is that these are plugins included, or targetted for inclusion in the official releases. The external plugins-repo/project is supposed to be a place that is deliberately more detached from the main project. Regards Thomas signature.asc Description: This is a digitally signed message part. -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Moving to KDE.org
Am Samstag, 25. Oktober 2014, 13.16:51 schrieb Thomas Friedrichsmeier: Hi all, hi Mario! Good morning Thomas and all Sorry for the delay in answering this email but the flu season is starting and my family and me already won two times ;-). I think the time has come to pin this down, and declare that the RKWard project is going to move to KDE.org, and the KDE community! Great. Let me be the first to tell you: Welcome to KDE :-). This is not going to be completed in a week or two, but we'll try to make the transition as smooth as possible. The key point of this mail is to lay out a rough plan, and start thinking about the first steps. And I setup an incubator page for Rkward: https://community.kde.org/Incubator/Projects/Rkward Don't hesitate to add stuff, items or information (it's a wiki after all) or ask me for help. One small exception to our move to KDE is that we intend to establish a small side-kick project on github.com, as a semi-official place to develop external plugins, i.e. those that are not (or not yet) targetted to be included in the official releases. This would need a separate git repository in the first place, and the idea is that this is a bit closer to the R community (but also matches well with the whole concept of external plugins). Not sure, whether this would strictly fall under the continuity requirement of KDE.org, but it certainly should not be a problem to give KDE sysadmins admin access to this. If I understand it correctly you plan to move the source code to KDE's git repos and have another close/copy of the repo on github.com. I don't see a problem. How will you merge features? You might as well use reviewboard.kde.org to encourage contributions by people that don't yet have a KDE developer account. For the rest, the plan is roughly as follows, I think: 1. Prepare any required formalities. Mario, please comment. I don't see much formalitites so: done ;-). 2. Give KDE sysadmins admin access to the SF-project, in order to ensure continuity in case we diasppear in the middle of the transition. Mario, I'm sure, there is an SF-account for this, already. Which? Get in contact with the KDE sysadmins via http://sysadmin.kde.org/tickets/ 3. Have our SVN-repo imported to a git-repo on git.kde.org. This is going to require a bit of preparation - see below. People like Nivolás Alvarez (PovAddict(W)) or Jeremy Whiting (jwhiting) might help. They are used to migrate SVN repos to Git. In paranthesis you find their nicknames on IRC. Mine is unormal btw. Don't hesitate to ping me if you need anything. Oh and I CC: these guys ;-). 4. Move translations from launchpad? 5. In no particular order, move website, mailing lists, and downloads to KDE.org. Also forums, although, for those, it should be good enough to archive existing posts, statically, and simply open new forum(s) on forum.kde.org. 6. Move bug tracker. This one should not happen too early, as there are non- redirecting links to the bug tracker in all RKWard versions up to 0.6.1. Sounds reasonable. Well, 1 and 2 should not take much time, I hope. For moving to git, here are some things we need to take care of / decide: - SVN author accounts have to be converted to git format, i.e. full name and email address. For those planning or considering to commit in the future, this should match the email used for your identity.kde.org account (if you don't have one, yet, get one, now!). Even if you do not plan to register at identity.kde.org (yet), it may still make sense to provide a current email address. I'll contact all past and present committers, and will fall back to accountn...@users.sf.net. - branches/external_plugins needs to be split out, somehow, as it is not really a branch in the git-sense. As noted above, it probably makes sense to import this branch to github.com. In fact, there is little reason not to go ahead on this one, yet. Volunteers? - branches/jss_dec_10 needs to be split, out, too. This branch is interesting for archiving, only. - Seasoned git users, please advise: Is there any point in keeping obsoleted release-branches, and fully merged development branches, or should these simply be dropped in the import? Or would they be dropped _after_ the import, in order to keep full commit history? - Beyond this, there is quite a bit of inconsistency regarding naming of branches and tags. I'd like to fix that. Is that best to be done before, during, or after the import? Ok, not much I can help other than finding people with knowledge about this. - Finally, I'm not sure, whether there are any uniform push-rules for git repositories on KDE.org. Mario? We certainly want to block non-fast-forwarded commits. But beyond this I don't really have a clue on git administration. Anybody? The KDE sysadmin will help you and tell about our infrastructure with their hooks and possibilities. Well, enough to chew on for one mail. We'll worry about steps 4
Re: [rkward-devel] Moving to KDE.org
2014-11-06 19:10 GMT-03:00 Mario Fux kde...@unormal.org: 3. Have our SVN-repo imported to a git-repo on git.kde.org. This is going to require a bit of preparation - see below. - SVN author accounts have to be converted to git format, i.e. full name and email address. For those planning or considering to commit in the future, this should match the email used for your identity.kde.org account (if you don't have one, yet, get one, now!). Even if you do not plan to register at identity.kde.org (yet), it may still make sense to provide a current email address. I'll contact all past and present committers, and will fall back to accountn...@users.sf.net. What we need for the git conversion is a plaintext file with: svnuser1 Real Name em...@example.org svnuser2 John Doe john...@example.com - branches/external_plugins needs to be split out, somehow, as it is not really a branch in the git-sense. As noted above, it probably makes sense to import this branch to github.com. In fact, there is little reason not to go ahead on this one, yet. Volunteers? - branches/jss_dec_10 needs to be split, out, too. This branch is interesting for archiving, only. - Seasoned git users, please advise: Is there any point in keeping obsoleted release-branches, and fully merged development branches, or should these simply be dropped in the import? Or would they be dropped _after_ the import, in order to keep full commit history? - Beyond this, there is quite a bit of inconsistency regarding naming of branches and tags. I'd like to fix that. Is that best to be done before, during, or after the import? In general it's best not to move things around in SVN now. For example, if branches have inconsistent names, we need to put those inconsistent names in the conversion rules anyway in order to get the history, so renaming them now only makes the conversion more complex. External plugins can be easily split into separate git repositories during the same conversion. For the rest, I'd have to look at the SVN history to give definite answers. Where is the repository, in Sourceforge? Is it possible to clone the SVN repository (not a checkout, the actual repo with all the history) via rsync or something? If not, I can use svnsync, but that takes longer :) - Finally, I'm not sure, whether there are any uniform push-rules for git repositories on KDE.org. Mario? We certainly want to block non-fast-forwarded commits. Non-fast-forward pushes (force pushes) and branch deletions are only allowed for the repository owners. You'll have to decide who that will be. -- Nicolás -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Moving to KDE.org
Thomas, Hello, I'm one of the guys that has helped with svn to git migrations in KDE and have some help I may offer here. Comments below. On Thu, Nov 6, 2014 at 3:10 PM, Mario Fux kde...@unormal.org wrote: Am Samstag, 25. Oktober 2014, 13.16:51 schrieb Thomas Friedrichsmeier: Hi all, hi Mario! Good morning Thomas and all Sorry for the delay in answering this email but the flu season is starting and my family and me already won two times ;-). I think the time has come to pin this down, and declare that the RKWard project is going to move to KDE.org, and the KDE community! Great. Let me be the first to tell you: Welcome to KDE :-). This is not going to be completed in a week or two, but we'll try to make the transition as smooth as possible. The key point of this mail is to lay out a rough plan, and start thinking about the first steps. And I setup an incubator page for Rkward: https://community.kde.org/Incubator/Projects/Rkward Don't hesitate to add stuff, items or information (it's a wiki after all) or ask me for help. One small exception to our move to KDE is that we intend to establish a small side-kick project on github.com, as a semi-official place to develop external plugins, i.e. those that are not (or not yet) targetted to be included in the official releases. This would need a separate git repository in the first place, and the idea is that this is a bit closer to the R community (but also matches well with the whole concept of external plugins). Not sure, whether this would strictly fall under the continuity requirement of KDE.org, but it certainly should not be a problem to give KDE sysadmins admin access to this. If I understand it correctly you plan to move the source code to KDE's git repos and have another close/copy of the repo on github.com. I don't see a problem. How will you merge features? You might as well use reviewboard.kde.org to encourage contributions by people that don't yet have a KDE developer account. For the rest, the plan is roughly as follows, I think: 1. Prepare any required formalities. Mario, please comment. I don't see much formalitites so: done ;-). 2. Give KDE sysadmins admin access to the SF-project, in order to ensure continuity in case we diasppear in the middle of the transition. Mario, I'm sure, there is an SF-account for this, already. Which? Get in contact with the KDE sysadmins via http://sysadmin.kde.org/tickets/ 3. Have our SVN-repo imported to a git-repo on git.kde.org. This is going to require a bit of preparation - see below. People like Nivolás Alvarez (PovAddict(W)) or Jeremy Whiting (jwhiting) might help. They are used to migrate SVN repos to Git. In paranthesis you find their nicknames on IRC. Mine is unormal btw. Don't hesitate to ping me if you need anything. Oh and I CC: these guys ;-). 4. Move translations from launchpad? 5. In no particular order, move website, mailing lists, and downloads to KDE.org. Also forums, although, for those, it should be good enough to archive existing posts, statically, and simply open new forum(s) on forum.kde.org. 6. Move bug tracker. This one should not happen too early, as there are non- redirecting links to the bug tracker in all RKWard versions up to 0.6.1. Sounds reasonable. Well, 1 and 2 should not take much time, I hope. For moving to git, here are some things we need to take care of / decide: - SVN author accounts have to be converted to git format, i.e. full name and email address. For those planning or considering to commit in the future, this should match the email used for your identity.kde.org account (if you don't have one, yet, get one, now!). Even if you do not plan to register at identity.kde.org (yet), it may still make sense to provide a current email address. I'll contact all past and present committers, and will fall back to accountn...@users.sf.net. - branches/external_plugins needs to be split out, somehow, as it is not really a branch in the git-sense. As noted above, it probably makes sense to import this branch to github.com. In fact, there is little reason not to go ahead on this one, yet. Volunteers? - branches/jss_dec_10 needs to be split, out, too. This branch is interesting for archiving, only. - Seasoned git users, please advise: Is there any point in keeping obsoleted release-branches, and fully merged development branches, or should these simply be dropped in the import? Or would they be dropped _after_ the import, in order to keep full commit history? - Beyond this, there is quite a bit of inconsistency regarding naming of branches and tags. I'd like to fix that. Is that best to be done before, during, or after the import? Ok, not much I can help other than finding people with knowledge about this. Ok, some information about doing svn to git migrations can be found here: https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git how we've done it in kde is to have a sync of the subversion
