Re: [Evolution-hackers] [evolution-kolab] towards Upstream-Integration
Hi, On Friday, 15 July 2011, Matthew Barnes wrote: Sorry for the delayed response... NP at all, thanks for your input! [...] The process really isn't as formal as the wiki makes it out to be. Because you're an extension module for an application that has already met these requirements, and because you're using a compatible license, I think for the most part you're grandfathered in. Sounds fine. Just wanted to make sure we don't miss something important. From there, I took the hop to http://live.gnome.org/CopyrightAssignment and found myself puzzled again. :) Of how much relevance are the details listed there for an Evolution plugin? Our source is LGPL v2.1+, the user docs and stuff are CC BY-SA ... so, are any details of that copyright stuff applicable to us? Obviously IANAL, but I believe as long as you're not engaged in such nefarious activities as requiring outside evolution-kolab contributors to hand over copyrights of their own code to you or your organization, or are holding or seeking patents on parts of the evolution-kolab code, there shouldn't be anything to worry about. Honest LGPL v2.1+, no tricks, no pitfalls. We're not evil(tm). ;-) [...] Translations will come when the project is added to Damned Lies (http://l10n.gnome.org/). Long as the software is set up to receive translations using gettext and intltool, which you said below it is, you're fine. Yep. The gettext/intltool infrastructure needs some love still, but that should cause no harm. From there, the hop was to http://live.gnome.org/ReleasePlanning/ModuleProposing and the following questions arose: * does evolution-kolab as an Evo plugin need to go through the module proposal cycle? [...] * Judgement Criteria ... can I deduce from what is listed there, that evolution-kolab [...] Again, because you're an extension module for an application that has already passed this process, I think you're pretty much grandfathered in. Maybe check with the release team about jhbuild, but otherwise I see no need for evolution-kolab to undergo this process. Just start uploading release tarballs when you're ready. Very well. jhbuild will be waiting for us somewhere farther down the road then. Thanks for the insights. We should be fine to continue from here. Kind regards, Christian PS.:I'll be on leave for a month, so I'll be able to continue with this topic only after returning from vacation and and being back inside my cubicle. Most likely, there will be some bugs and issues waiting for me to fix them, so I can just as well fix them first and push upstream next. -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] towards Upstream-Integration
Sorry for the delayed response... On Tue, 2011-07-12 at 18:00 +0200, Christian Hilberg wrote: ...this leads to http://live.gnome.org/ProjectPrerequisites where a list of prerequisites is presented. I think we do match all of these (see my follow-up to Chen's mail). However, it states there, that To satisfy these requirements, particularly number 3, please send us any relevant URLs such as project homepage, list archives, ... -- who is we in the case of evolution-kolab? The Evolution team? GNOME people? I'm not sure whom to contact for the paperwork. :) The process really isn't as formal as the wiki makes it out to be. Because you're an extension module for an application that has already met these requirements, and because you're using a compatible license, I think for the most part you're grandfathered in. From there, I took the hop to http://live.gnome.org/CopyrightAssignment and found myself puzzled again. :) Of how much relevance are the details listed there for an Evolution plugin? Our source is LGPL v2.1+, the user docs and stuff are CC BY-SA ... so, are any details of that copyright stuff applicable to us? Obviously IANAL, but I believe as long as you're not engaged in such nefarious activities as requiring outside evolution-kolab contributors to hand over copyrights of their own code to you or your organization, or are holding or seeking patents on parts of the evolution-kolab code, there shouldn't be anything to worry about. My traceback algorithm next pointed to http://live.gnome.org/ReleasePlanning/ModuleRequirements, where there is much about modules, and the following (among other things) was not instantly clear to me: * Which will be the status for evolution-kolab? Will it be a module in the sense presented on the ModuleRequirements page? * We do have UI strings (in EPlugin), but no translation as yet - how about this? The term module as presented on the ModuleRequirements page is equivalent to a git repository. Translations will come when the project is added to Damned Lies (http://l10n.gnome.org/). Long as the software is set up to receive translations using gettext and intltool, which you said below it is, you're fine. From there, the hop was to http://live.gnome.org/ReleasePlanning/ModuleProposing and the following questions arose: * does evolution-kolab as an Evo plugin need to go through the module proposal cycle? * (from here, loop back to ModuleRequirements and the question whether evolution-kolab is a module in that sense, if you like... :-) * is the email to the desktop-devel mailing list needed? * (from here, loop back to ProjectPrerequisites and the question whom to contact for the paperwork in case of evolution-kolab, if you like... :-) * 3.0 readiness: (void). We're 2.30(.3), porting to 3.x pending. How to deal with that? * Build testing: no jhbuild as yet -- only relevant once a new release from within the GNOME git is planned for? * Judgement Criteria ... can I deduce from what is listed there, that evolution-kolab is _not_ a module in the sense of ModuleRequirements? I frankly do not know what to make out of this stuff in evolution-kolab context... does this fall under the don't care (yet)-clauses? Again, because you're an extension module for an application that has already passed this process, I think you're pretty much grandfathered in. Maybe check with the release team about jhbuild, but otherwise I see no need for evolution-kolab to undergo this process. Just start uploading release tarballs when you're ready. Okay with that, should be fine. I guess I should mention the current (i.e. SourceForge) website in the bug report requesting a tracker for evolution-kolab? And is there a sensible way to migrate bugs from SF to bugzilla, or will we need to start anew? I'm guessing you'll have to start anew. I know it's possible to import data from one Bugzilla instance to another (Ximian merged their Bugzilla database into GNOME's back in the day), but I don't think different bug tracking systems can talk to each other... not without a great deal of pain anyway. I might be wrong though so it's worth a little research. Hum. We're set up to use intltool/gettext, but no translation has taken place as yet. Moreover, the release of gnome-2-30 has vanished into history, so I assume it will be okay to push master from SF-Git to GNOME-Git and start translation preparations for a later (3.x) release there itself? That sounds fine. I think I'd like to stick with the major.minor.patchlevel scheme, if possible. Some guidance in choosing proper numbers here will be appreciated. I'll probably to something like 0.30.3 for the gnome-2-30 branch back at SourceForge, but a major 0 will not be a good choice for GNOME 3.x it seems? GNOME's version numbering doesn't necessarily reflect maturity. Because we do time-based releases, the version numbers are more like timestamps. Calling
Re: [Evolution-hackers] [evolution-kolab] towards Upstream-Integration
Hi everyone, On Thursday 07 July 2011, Matthew Barnes wrote: On Fri, 2011-07-01 at 23:33 +0200, Christian Hilberg wrote: The first step could be to create an evolution-kolab git repository at gnome.org, at least this is what came to my mind instantly. In order to get the prerequisites right, I have applied for a GNOME account with git access. This has been vouched for by the Evolution team (thanks, Matt), and I have received confirmation from the GNOME account management team today. Since neither my kernel concepts evolution-kolab team mates nor myself have done upstream integration for an Evolution plugin yet, I would like to know how we should best proceed from here. If there is any reading we should have done prior to further acting, we'll gladly accept pointers to the relevant documents. David (or anyone else involved there), I heard that you did the same with your EWS team recently, so if there are any lessons-learned which we should heed to, we will also be happy to know. Long story short, we will just be happy for any directing through this process so we can get through it smoothly. First of all, welcome to the family! It's great to have more developers supporting new backends for Evolution. Thanks for the welcome. Reading through the available documentation and Matt's braindump, a few questions remained open, so I'll post them here (a) for my own education and (b) for the record: I agree that getting the code into git.gnome.org is the first step. Chen already pointed you in the right direction: http://live.gnome.org/Git/NewRepository ...this leads to http://live.gnome.org/ProjectPrerequisites where a list of prerequisites is presented. I think we do match all of these (see my follow-up to Chen's mail). However, it states there, that To satisfy these requirements, particularly number 3, please send us any relevant URLs such as project homepage, list archives, ... -- who is we in the case of evolution-kolab? The Evolution team? GNOME people? I'm not sure whom to contact for the paperwork. :) From there, I took the hop to http://live.gnome.org/CopyrightAssignment and found myself puzzled again. :) Of how much relevance are the details listed there for an Evolution plugin? Our source is LGPL v2.1+, the user docs and stuff are CC BY-SA ... so, are any details of that copyright stuff applicable to us? My traceback algorithm next pointed to http://live.gnome.org/ReleasePlanning/ModuleRequirements, where there is much about modules, and the following (among other things) was not instantly clear to me: * Which will be the status for evolution-kolab? Will it be a module in the sense presented on the ModuleRequirements page? * We do have UI strings (in EPlugin), but no translation as yet - how about this? From there, the hop was to http://live.gnome.org/ReleasePlanning/ModuleProposing and the following questions arose: * does evolution-kolab as an Evo plugin need to go through the module proposal cycle? * (from here, loop back to ModuleRequirements and the question whether evolution-kolab is a module in that sense, if you like... :-) * is the email to the desktop-devel mailing list needed? * (from here, loop back to ProjectPrerequisites and the question whom to contact for the paperwork in case of evolution-kolab, if you like... :-) * 3.0 readiness: (void). We're 2.30(.3), porting to 3.x pending. How to deal with that? * Build testing: no jhbuild as yet -- only relevant once a new release from within the GNOME git is planned for? * Judgement Criteria ... can I deduce from what is listed there, that evolution-kolab is _not_ a module in the sense of ModuleRequirements? I frankly do not know what to make out of this stuff in evolution-kolab context... does this fall under the don't care (yet)-clauses? When you're ready to start accepting bug reports, you'll also want to get evolution-kolab added to bugzilla.gnome.org as a new project. The steps for that are here: http://live.gnome.org/Bugsquad/ForMaintainers#To_add_a_project_to_the_bugzilla_database Okay with that, should be fine. I guess I should mention the current (i.e. SourceForge) website in the bug report requesting a tracker for evolution-kolab? And is there a sensible way to migrate bugs from SF to bugzilla, or will we need to start anew? Assuming evolution-kolab includes translatable strings, you'll want to make sure the project is properly set up for localization using gettext and intltool. This is kind of a broad topic, but there's lots of documentation about that here: http://live.gnome.org/TranslationProject/DevGuidelines Hum. We're set up to use intltool/gettext, but no translation has taken place as yet. Moreover, the release of gnome-2-30 has vanished into history, so I assume it will be okay to push master from SF-Git to GNOME-Git and start translation preparations for a later (3.x) release there
Re: [Evolution-hackers] [evolution-kolab] towards Upstream-Integration
On Fri, 2011-07-01 at 23:33 +0200, Christian Hilberg wrote: Hi everyone. Since the last announcement of the evolution-kolab team here on the list, our source code (hosted at http://evolution-kolab.sourceforge.net/) has seen some more polishing and now compiles on Debian/Squeeze in addition to Ubuntu/Lucid. We will make available a (source) release 0.0.13 soon, which contains the fixes for Squeeze. Next week will see some performance improvements over the current state, and by the end of next week, I am planning to have the post-0.0.13 release ready. The code base has received quite some testing (under Ubuntu/Lucid) already, mainly in the area of Kolab inter-client compatibility. Online and offline operational modes are working, including conflict resolution. More testing is always welcome, of course. The evolution-kolab team now feels that we have reached a state where we can begin working towards upstream integration. During the planning and coding phases so far, we aligned all of our project decisions with the Evolution team as closely as our time schedule and resources permitted. This was done in order to promote for an easy upstream integration process. We would like to thank everyone here who helped us in the various aspects of creating a new Evolution plugin. We would very much like to be hosted at gnome.org with our project. SourceForge is a nice breeding platform, but we feel it is a little too far away from GNOME, and since we are a true GNOME project, we think it would be nice to add evolution-kolab directly to the Evolution project at its GNOME site. The first step could be to create an evolution-kolab git repository at gnome.org, at least this is what came to my mind instantly. In order to get the prerequisites right, I have applied for a GNOME account with git access. This has been vouched for by the Evolution team (thanks, Matt), and I have received confirmation from the GNOME account management team today. Since neither my kernel concepts evolution-kolab team mates nor myself have done upstream integration for an Evolution plugin yet, I would like to know how we should best proceed from here. If there is any reading we should have done prior to further acting, we'll gladly accept pointers to the relevant documents. David (or anyone else involved there), I heard that you did the same with your EWS team recently, so if there are any lessons-learned which we should heed to, we will also be happy to know. Long story short, we will just be happy for any directing through this process so we can get through it smoothly. You could create a package naming eg: evolution-kolab and create a new repository in git.gnome.org. http://live.gnome.org/Git/NewRepository has all the details required. Thanks, Chenthill. Thanks a lot in advance, Kind regards, Christian ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] towards Upstream-Integration
Hi, On Thu 07 July 2011, Chenthill wrote: On Fri, 2011-07-01 at 23:33 +0200, Christian Hilberg wrote: Since neither my kernel concepts evolution-kolab team mates nor myself have done upstream integration for an Evolution plugin yet, I would like to know how we should best proceed from here. If there is any reading we should have done prior to further acting, we'll gladly accept pointers to the relevant documents. David (or anyone else involved there), I heard that you did the same with your EWS team recently, so if there are any lessons-learned which we should heed to, we will also be happy to know. Long story short, we will just be happy for any directing through this process so we can get through it smoothly. You could create a package naming eg: evolution-kolab and create a new repository in git.gnome.org. http://live.gnome.org/Git/NewRepository has all the details required. Let's see what http://live.gnome.org/ProjectPrerequisites says: 1. The project must be free/open source software. 2. It must use GTK+/GNOME technologies. 3. It must be maintained, and already have had at least one public release. 4. To the best of your knowledge, it must not infringe on patents (most gnome.org servers are in the US). 5. If copyright assignment is required, please first read our policy on copyright assignments; it's simpler to not have any copyright assignment. For evolution-kolab: 1. [ok] we're all LGPL 2. [ok] it is an Evo/EDS plugin 3. [ok] see http://evolution-kolab.sf.net/ 4. [ok] we're confident about that 5. [ok] should be no trouble, we're LGPL, no other copyright assignments apply I will thus proceed and create an evolution-kolab Git repo at gnome.org. Thanks, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] towards Upstream-Integration
On Fri, 2011-07-01 at 23:33 +0200, Christian Hilberg wrote: The first step could be to create an evolution-kolab git repository at gnome.org, at least this is what came to my mind instantly. In order to get the prerequisites right, I have applied for a GNOME account with git access. This has been vouched for by the Evolution team (thanks, Matt), and I have received confirmation from the GNOME account management team today. Since neither my kernel concepts evolution-kolab team mates nor myself have done upstream integration for an Evolution plugin yet, I would like to know how we should best proceed from here. If there is any reading we should have done prior to further acting, we'll gladly accept pointers to the relevant documents. David (or anyone else involved there), I heard that you did the same with your EWS team recently, so if there are any lessons-learned which we should heed to, we will also be happy to know. Long story short, we will just be happy for any directing through this process so we can get through it smoothly. First of all, welcome to the family! It's great to have more developers supporting new backends for Evolution. I agree that getting the code into git.gnome.org is the first step. Chen already pointed you in the right direction: http://live.gnome.org/Git/NewRepository When you're ready to start accepting bug reports, you'll also want to get evolution-kolab added to bugzilla.gnome.org as a new project. The steps for that are here: http://live.gnome.org/Bugsquad/ForMaintainers#To_add_a_project_to_the_bugzilla_database Assuming evolution-kolab includes translatable strings, you'll want to make sure the project is properly set up for localization using gettext and intltool. This is kind of a broad topic, but there's lots of documentation about that here: http://live.gnome.org/TranslationProject/DevGuidelines Then when you're ready for the software to start receiving translations, file a bug asking for evolution-kolab to be added to Damned Lies (the translation hub for GNOME projects): http://bugzilla.gnome.org/enter_bug.cgi?product=damned-liescomponent=l10n.gnome.org If you have any developer documentation, the wiki would be a good place to post it and keep it up-to-date. I'd suggest putting the top-level page here: http://live.gnome.org/Evolution/Kolab Once you have evolution-kolab synchronized with the latest Evolution and Evolution-Data-Server release, we'll need to discuss release scheduling and frequency. As you probably know, GNOME works to a six-month release schedule and we follow that schedule, which can always be found here: http://www.gnome.org/start/unstable/ At minimum you should aim for a new evolution-kolab release to coincide with each major GNOME release, which usually occurs at the end of March and the end of September of each year. You'll also need to adhere to GNOME's string and code freezes as a major release approaches, all of which is detailed on the release schedule. I would also suggest once you've synchronized evolution-kolab's code with the latest E-D-S release, that you also synchronize its version number (major.minor at least, such as 3.2) so it's easy to keep them paired up properly. I think this is enough to get you started. There's a lot to digest here, and a lot I'm probably taking for granted, but Chen and I are happy to try and clarify points or answer questions. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
