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 it version "0" is fine while you're syncing up with the current GNOME release, but there's a tendency for it to get stuck there. It's that endless, asymptotic march toward claiming software to be stable or feature-complete which developers seem loathe to do. When evolution-mapi was first getting off the ground, it also used a "0" major version to indicate alpha quality. But then it stayed at version "0" for two or three years, long after it had effectively replaced evolution-exchange. Only recently did we finally bump the version to match Evolution because by then it was getting a little ridiculous. I'd suggest once evolution-kolab is ready to hop aboard the six-month release train, call it version "3.whatever-evolution-is-at" so it's clear what Evolution release it's supposed to be paired with. _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers