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. Many more
traditional companies don't know any other way of working, so if you
don't allow that they'll just not use it.
Now what has changed the last year was that the way of packaging
changed to webhook based packaging we thoroughly tested inside Jolla
before first taking it into use in Nemo, and later Mer. This now allows
even easier forking[1], but more importantly, it allows easier merging
as well. So it's now rather trivial to stay at a stable version of Mer
based on product program requirements, and at a suitable time go back to
a newer version.
Even more important, this allows you to keep your changes upstream --
that is, in branches of the main Mer packages. Which is exactly what
Jolla is doing -- for some packages it's too risky to pull in the latest
changes of Mer, but it would be wrong to block progress of Mer just
because we as vendor require some old version of a package. So we're
doing our own _build_ of Mer, but it's based on the git repositories of
the 'public' Mer -- just some packages are building from a Vendor
specific branch.
I'm not even sure if we should call that a fork at all -- custom private
build with some packages (like X11) dropped, sure. But everything that
gets build is in the main git repositories, either in master, or --
where it would be a problem for other vendors -- in branches.
As a side note, the webhook changes make the case "OBS community relies
on goes away" a lot less scary. The community OBS shutdown sucked up
lot's of work from us to move everything to the new OBS. Nowadays that
kind of move would basically just be "do a script to change all webhooks
on github, and trigger all of them".
>> Improving this should be on the agenda. That too much discussion does happen
>> internally is partly what drove the meeting proposal.
>
> Totally agree and it was much earlier seen already (remember when I've
> asked about bug triages when they've suddenly stopped in the summer?).
Lack of time, limited use (i.e., time spent vs. benefit was
negative). At that point our main focus needed to be to get the product
out. We still did that without breaking Mer for other vendors, though,
so 'just' communication went worse for some time.
It was planned to get back to that once we have more time, though -- and
now we start having more time for that.
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.
We're using those bug references internally in our CI system to track
changes. Which means it's currently quite hard (though not impossible,
we have good CI systems :p) to keep track of the changes in
Mer/Nemo. Which brings me back to the beginning of "why no triages" --
this was an intentional decision back in summer to make it reasonably
painful for us (and very painful for me ;)) to handle Mer/Nemo in the
release process without using a public bugtracker -- to make sure that
once we have the resources to do something about it there's enough pain
that we actually do something about it.
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. In a vendor agnostic way, you'd all
be unhappy if CI systems from 30 vendors add comments to Mer bugzilla
and you can't filter it out :)
>> Oher vendors already participate and yet more will observe Jolla's
>> experiences
>> before commiting.
>
> That's good, but I also recall there were more Mer based projects
> (e.g. Cordia) before than there are now. I would say it shows
> something.
I don't think that's related to Sailfish. We admittedly mostly took over
Nemo MW -- just because for a long time we were the only ones doing
something. It's still run in a way enabling things like building of
Glacier UI, 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].
For Mer we are as conservative as possible, and try to not spoil it for
others. Which caused several middleware bits which would be right to be
in Mer to end up in Nemo, just because we didn't have the time to do the
inclusion into Mer the right way.
Bernd
[1] You just add your own set of webhooks. One problem to make it truly
vendor agnostic / quick to set up would be some kind of webhook
proxy. Currently you need to configure your webhooks in all
repositories you're interested in, it would be nice to have a
central point where you can easily subscribe to events for packages
you're interested in
[2] About the only thing we didn't do was moving the old hardware
adaptations to webhooked packaging. It would be nice to see someone
from community to do that as part of the 'Sailfish on N9' work --
it'd allow me to easily check that I'm not breaking stuff on N9
before releasing a new version, and warn people working on that
early enough
[3] There are some exception for packages related to hardware
adaptation, there we require that for our process at the moment, as
hardware adaptation is a mix of open and closed packages. That needs
to be reworked at some point as well, though.
_______________________________________________
SailfishOS.org Devel mailing list
