kicad-doc-devs team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

Den ons. 18. jul. 2018 kl. 19.50 skrev 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.
>

This was already determined when we made the 4.0 series, so that is of
course a long time ago.

I have been wanting to summarize this a bit such that we can just
refer to this when people ask.

In very short:

Kicad gets tagged, then some dead time for i18n of a couple of weeks.
In between this time libs and docs are tagged. So in essence i18n is
the one expected to be tagged the latest, or considered the outer
bound.

For non-rc releases it is more important to align to get the last bits
in the release. For rc tags, it is more important to simply create
some tags, such that packagers can prepare and when we release it is
just a simple pkgver bump.

> > 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
>
> --
> Mailing list: https://launchpad.net/~kicad-doc-devs
> Post to     : kicad-doc-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-doc-devs
> More help   : https://help.launchpad.net/ListHelp