W dniu 06.04.2014 09:57, Bernd Wachter pisze:
Filip Kłębczyk <fklebc...@gmail.com> writes:
Sorry, but this sounds like, either it will be "our" (Jolla way) or we are
taking toys and are going to different closed sandbox to play.
I find it hard to correlate that with "lets talk about being more open". Lets
not pre-judge.
No one is pre-judging - my reaction was to Thomas Perl statement:
"alternative would be to have a private/downstream fork of Mer/Nemo
and not contribute to Mer/Nemo - would that be better?"
So it sounded like we have two choices, accepting status quo (Jolla
maintainership/ownership/domination or however the current state can
be called) or that Jolla will abandon supporting open mer/nemo
(creating private fork).
Mer was designed to allow private forking from the beginning.
I think you misunderstood me. There is nothing wrong with private
forking - everybody does it, that's how open source works. I only didn't
like the statement that sounded like a choice between keeping status quo
(NemoMW taken over by Jolla with questionable collaboration quality like
it is nowadays) and alternative that Jolla completely ends to support
Mer/Nemo. It sounded a bit like a strong warning (accept this or else!).
If you look at changelogs of packages on the device you'll notice that
_all_ Jolla internal packages contain JB#xxx bug references, while
almost none of the Nemo or Mer packages have those[3]. That's because we
think it's wrong to reference a private bugtracker in a public git
repository, and we have a policy that you should not do that. The few
ones you see are either in HW adaptation related projects, or the
developer made a mistake.
What I've seen wasn't for sure in hardware adaption part and yes it was
seen on Github, not in the package changelog.
The problem is that when average person encounters that (in a project he
is potentially interested) he instantly asks himself - what the hell is
that #JB? In result it's very hard to contribute/engage to open source
parts that have such comments, because you instantly get a feeling that
there is some closed roadmap/list of issues to address/features to
implement that you don't have access to (when approaching such open
source part or subproject). It's a bit like you would play a poker and
the opponents knows what cards are on stack and you don't. I bet you
wouldn't be satisfied to play such game and especially betting money in
it (hint: think that currency here is time/engagement).
Now we start having the resources, so to improve our _internal_ release
process we need start making use of the public bugzilla again, and make
the public release process better.
That's very good to hear!
We admittedly mostly took over
Nemo MW -- just because for a long time we were the only ones doing
something.
I think that's "we were the only" is an overstatement. I remember for
example that Venemo contributed to lipstick and he is not a Jolla employee.
For example I also wanted to engage myself last summer in Nemo MW, but
when I've seen Nemo MW became a code (pull request) dump with no public
roadmap I've realized it will be very hard (not impossible, but very
hard) to engage in sth like that.
It's still run in a way enabling things like building of
Glacier UI,
Glacier UI is something where open collaboration works.
though, but basically the whole "keep Nemo running on
community OBS" is overhead for us without us benefitting from it at the
moment. We're just doing it because it should be done like this[2].
Well I wouldn't call it "overhead", the more appropriate term in my
opinion would be a "fair trade" - it gives you right to tell that
SailfishOS is mostly open source and that Jolla contributes back to open
source Nemo MW. In terms of marketing and attracting people it has a big
value, that shouldn't be underestimated - otherwise Sailfish would be
yet another mobile OS.
Regards,
Filip
_______________________________________________
SailfishOS.org Devel mailing list
