[Ubuntu] [SoC] UbuntuGIS Weekly Report 6

Andreas Tille andreas at an3as.eu
Mon Jul 29 01:39:52 PDT 2013


Hi,

On Sat, Jul 27, 2013 at 08:17:14PM -0700, Hamish wrote:
> Andreas:
> > I do not know this package but I'd recommend maintaining it
> > in Debian GIS team would be reasonable to let it migrate smoothly
> > to any Ubuntu version you need.
> 
> ECW is non-free, so not appropriate and generally not in line with
> DebianGIS's goals. (note the -src in the package name) Others may
> of course do as they like.

I haven't checked the license but is it just non-free or
non-distributable by Debian?

> > Please add communication with Debian GIS on this list.  Both
> > packages are inside Debian and it makes perfectly sense to do
> > the work only once.
> 
> Osmosis is handled by the OSM Team not the DebianGIS Team (I have no
> interest in conflating the two :),

Well, we discussed the conflation[1] and we had two mails pro and one
mail (yours) contra merging both *packaging* teams.  I would not call
this consensus but you did not yet responded on my second mail[2] where
I think I have given good reasons for a merge while I'm failing to see
any disadvantages (and you failed to give some).  Moreover you seem to
mix up the ideo of a Debian GIS Blend (for Blends please see [3]) with
packaging teams.  To come back to the Debian Med example there we are
including into Debian Med packages maintained by the DebiChem team into
Debian Med and the maintainers from DebiChem team are lurking on Debian
Med list (and the other way around).

If you write in your mail[4] "try to forcibly mush OSM + the OSGeo stack
together into a single box" you are IMHO showing a boxed attitude which
seems as you like to choose the smallest possible box that does not
interfere with other boxes ... which is close to single package level
(if possible at all).  I admit you need to draw a certain borderline
but by narrowing the focus to much leads to very small teams and from
the team analyses I did together with a GSoC student[5] the teams from
pkg-grass and pkg-osm are understuffed.

In case you might fear that it might be more work for you if pkg-osm and
pkg-grass would use a common repository and a common mailing list to
communicate from my personal experience is not true.  The actual people
(Uploaders) who care for specific packages will keep on working on these
as usual but it simplifies things like for instance writing a team
policy which helps newcomers (IMHO none of both teams has something like
this), simplifies organising common things etc.  So in this case this
boxed thinking is refusing a win-win strategy.

> and I believe it is mentioned
> here partly as an example of how to package java apps, not to hijack
> maintainership*.

Just from coordinating on the relevent Debian mailing list a package is
not hijacked.  I personally can not believe that the original poster
would refuse to have a look at the packaging state inside Debian once he
has received the hint nor could I imagine that any pkg-osm maintainer
might refuse to accept a patch.  Since Jerome is no Debian maintainer
and can not upload his chances for a real hijack are zero so this
apprehension is a bit exaggerated.  I just was giving a hint for
potentionally solved problems and a good chance to contact people
working in the same things.  Do I really need to explain how Free
Software works?

> I accept that sid is a couple minor versions out of
> date for it, but I'm not sure what repackaging gains us besides
> fixing the "java exceptions". I presume the idea is that the newer
> releases fix that? [*] of course the package maintainers should be
> in the loop, :)   http://packages.qa.debian.org/o/osmosis.html

Yes, I see we finally agree here. :-))

> Likewise Marble is maintained by KDE-Edu, the idea to repackage it
> for UbuntuGIS comes from the OSGeo Live DVD where if we rebuilt
> the Marble package without the KDE dependency, and drop a few
> other non-critical KDE apps we can save a load of badly needed disc
> space by avoiding installing lots of other KDE packages.

OK, avoiding libraries that are unneeded is an interesting goal.

> So neither really matters for DebianGIS or upstream.

Here again I refuse to agree.  If a package is interesting for OSGeo in
my understanding it is also an interesting thing for Debian GIS.  So if
somebody with interest in geographic applications might contact
debian-qt-kde at lists.debian.org and explain the problem it might be at
least worth a try than just doing it alone.  May be by using a
reasonably designet patch you could create marble-plain + marble-kde out
of the same source which finally helps maintaining new upstream
versions.  (Just an assumption, I did not dived into the code.)  It
seems you try to find good reasons for not communicating with each other
while my experience has teached me that it can't harm to talk to people
who potentially have the same problem / can provide help.

Kind regards

       Andreas.

[1] https://lists.debian.org/debian-gis/2013/07/msg00012.html
[2] https://lists.debian.org/debian-gis/2013/07/msg00021.html
[3] http://blends.alioth.debian.org/blends/
[4] https://lists.debian.org/debian-gis/2013/07/msg00020.html
[5] http://people.debian.org/~tille/talks/20110729-gsoc-teammetrics/

-- 
http://fam-tille.de


More information about the Ubuntu mailing list