kicad-doc-devs team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hi,

Am 18.07.18 um 15:00 schrieb Marco Ciampa:
>> wouldn't it have been better to pull first all outstanding pull request
>> that are for the version 5.0.0 nonetheless?
> 
> Whenever I see a pull request that should be merged I pull it ... 
> 
>> Or at least some communication about how to handle this all?
> 
> I do not follow you now, sorry.
> How should you handle a pull request in a different way?
> 
>> I see some PRs are merged some don't. Why?
> 
> It depends on the PR. Would you please give me an example?

well, it's not the handling of the pull requests itself, these are fine
and there can't be made anything really wrong, it's just a click on button.

What I not have understood in the latest pull request series is simple
that some newer PRs are applied but some older ones, which didn't
conflict to the existing ones, aren't merged. I don't have seen any
logic on that. In between times Nick has merged the outstanding
requests. Thanks.

That's one reason I'm not really like these WebUI fancy workflow. We
have at least two communication channels (if not more) in parallel which
I need to follow. That's annoying.

> Please be patient this is all done on a volutary basis, some PR wait for
> days ... I am really sorry...

Like we all doing this on a voluntary base, that's not a problem. And we
are normally not on a rush. But, we are not on a release candidate but
on a final release. And this is getting more attention than RCs. So
there is a lot of coordination needed an all sides, but for Debian I'm
depending here on the work that upstream is doing before I can start any
packaging. For the kicad package I need three tarballs to make it
happen, KiCad itself of course, the l10n translations for kicad, wrongly
called kicad-i18n btw. and the documentation aka kicad-doc. And I need
all of them with a git tag and free time for gluing all together, before
I can't start. But I'm not the only person which is doing packaging.

What I wanted to say is that the communication by all of us can and
should be improved. I missed some statement how and when the tagging
will happen. And even if someone would have written there is no plan
every body would this knowing then.

> Well there is already a 5.1 branch in the source where there are already
> many changes in the UI that creates many new / fuzzy strings to
> translate. I thought that the i18n repo should follow the source tree to
> allow translators to update their translations on the 5.1 branch too...

Yes and no. We are just a few days behind the tagging of KiCad 5.0.0 and
I would say the KiCad devs itself can't really say what the way will be.
So no need to rush. The problem is quite easy, once a branch or tag is
made it's history, no way back! But a good branching model is important,
currently I don't see any. If there are now a lot of branches created
it's getting more difficult to pick up the correct one for the changes
if the various features branches.

A branch name 5.x would cover all major 5 releases e.g. I would have
wait a bit more time.

Are you sure you can say what exactly will go into the branch 5.1? I'm
absolutely not, probably the GTK+3 fixes, but that shouldn't need any
new l10n strings.

-- 
Regards
Carsten Schoenert