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 itself? > 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-lies&component=l10n.gnome.org Again, I assume this will take place at a later point, porting to 3.x coming first, then starting translation stuff? > [Stuff in between seems fairly clear, will get back to that later on] > > 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 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? > I think this is enough to get you started. Phew, that's quite some maze you have here. :) > There's a lot to digest here Not yet finished devouring... > and a lot I'm probably taking for granted, but Chen and I are > happy to try and clarify points or answer questions. Thanks a lot. We'll be trying our best to comply. I guess a step-by-step approach will be what I'll try, with some sort of a traceback algo for error recovery. ;-) Kind regards, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.