Re: [Evolution-hackers] [evolution-kolab] towards Upstream-Integration

[Matthew Barnes <mbarnes redhat com>]

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.