Re: [Kicad-developers] [PATCH] Implement auto annotation on component/symbol placement.

[Seth Hillbrand]

On 2019-10-09 17:08, Zficani Zficani wrote:

> Hi, 
> it's been about 10 days since my message so I just want to make sure I sent 
> it properly and you noticed it because I'm not sure as I'd want to be able to 
> actually use this feature soon because it's very useful for me. 
> 
> Thank you. 
> 
> On Sun, Sep 29, 2019 at 11:55 PM Zficani Zficani  wrote: 
> 
>> Hi,
>> I reviewed your remarks and made appropriate changes but I have a few
>> questions. 
>> Regarding your first remark, I had to make them non-reference because
>> the selection is sorted inplace which means that the original selection
>> will be modified which in turn make unhighlight hang/enter and infinite
>> loop when copying/duplicating or just unhighlighting multiple objects.
>> I'm not sure why exactly this is happening but it obviously has
>> something to do with the fact that selection is now sorted by
>> reference.
>> 
>> I did change the code according to the second and third remark though
>> and will send in the patches later (it's currently available on
>> https://github.com/Nufflee/kicad-source-mirror/tree/1335616-annotate-on-placement
>> if anyone wants to take a look).

Hi Zficani- 

I can't speak for others but I was waiting for either a patch with the
revised code or a merge request on launchpad.  I like the idea of your
feature and look forward to helping get it into merge shape.  I agree
with Ian's comments and was hoping to see how you address them. 

Best- 

Seth 

Seth Hillbrand 

Chief Technologist 

KiCad Services Corporation 

Twitter [1]

LinkedIn [2]

+1 530 302 5483 [3] | +1 212 603 9372 [4]

www.kipro-pcb.com [5]

Davis, CA

 

Links:
--
[1] https://twitter.com/KiProEDA
[2] https://www.linkedin.com/company/kicad/about
[3] tel:+15303025483
[4] tel:+12126039372
[5] https://www.kipro-pcb.com/___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GitLab migration

[Wayne Stambaugh]

I believe GitLab has a wiki so we could define the workflow there so
that it's handy for developers and users filing bug reports.

On 10/10/19 9:03 AM, Mark Roszko wrote:
> GitHub/GitLab style interfaces depend on using labels for everything. So
> yes, someone should define the workflow ahead of time, including label
> usage.
> 
> image.png
> 
> 
> 
> On Thu, Oct 10, 2019 at 5:30 AM Ian McInerney  > wrote:
> 
> On a similar note, the issue workflow will need to be modified if
> the GitLab tracker is used. Unfortunately, GitLab doesn't seem to
> have the same functionality as the Launchpad tracker with respect to
> issue status and severity. This might be a good time to finalize the
> earlier work that Nick had started to formalize the issue process
> and the bug tracker workflow before we transition to the GitLab
> tracker. That way we can define how we want to do this from the
> outset. This will probably require some trial and error and
> discussions to fully work it out.
> 
> -Ian
> 
> On Thu, Oct 10, 2019 at 8:51 AM Maciej Suminski
> mailto:maciej.sumin...@cern.ch>> wrote:
> 
> On 10/10/19 2:30 AM, Andrew Lutsenko wrote:
> 
> > In terms of issues migration I think moving open issues via
> script and
> > locking down launchpad tracker is the best option. Even if
> migrated
> > issues and comments on them will be owned by some service
> account/bot.
> > It should be doable to include enough information there so
> that it's
> > clear who originally posted it and the context is not lost.
> 
> I agree, I am not sure if there is any added value in having correct
> authors assigned to issues/comments, compared to displaying the
> information in the contents field. Since I have spent some time
> scripting both Launchpad and Gitlab, let me see how it can be done.
> 
> Cheers,
> Orson
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> -- 
> Mark
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GitLab migration

[Mark Roszko]

GitHub/GitLab style interfaces depend on using labels for everything. So
yes, someone should define the workflow ahead of time, including label
usage.

[image: image.png]



On Thu, Oct 10, 2019 at 5:30 AM Ian McInerney 
wrote:

> On a similar note, the issue workflow will need to be modified if the
> GitLab tracker is used. Unfortunately, GitLab doesn't seem to have the same
> functionality as the Launchpad tracker with respect to issue status and
> severity. This might be a good time to finalize the earlier work that Nick
> had started to formalize the issue process and the bug tracker workflow
> before we transition to the GitLab tracker. That way we can define how we
> want to do this from the outset. This will probably require some trial and
> error and discussions to fully work it out.
>
> -Ian
>
> On Thu, Oct 10, 2019 at 8:51 AM Maciej Suminski 
> wrote:
>
>> On 10/10/19 2:30 AM, Andrew Lutsenko wrote:
>> 
>> > In terms of issues migration I think moving open issues via script and
>> > locking down launchpad tracker is the best option. Even if migrated
>> > issues and comments on them will be owned by some service account/bot.
>> > It should be doable to include enough information there so that it's
>> > clear who originally posted it and the context is not lost.
>>
>> I agree, I am not sure if there is any added value in having correct
>> authors assigned to issues/comments, compared to displaying the
>> information in the contents field. Since I have spent some time
>> scripting both Launchpad and Gitlab, let me see how it can be done.
>>
>> Cheers,
>> Orson
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>


-- 
Mark
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GitLab migration

[Wayne Stambaugh]

On 10/10/19 2:50 AM, Maciej Suminski wrote:
> On 10/10/19 2:30 AM, Andrew Lutsenko wrote:
> 
>> In terms of issues migration I think moving open issues via script and
>> locking down launchpad tracker is the best option. Even if migrated
>> issues and comments on them will be owned by some service account/bot.
>> It should be doable to include enough information there so that it's
>> clear who originally posted it and the context is not lost.
> 
> I agree, I am not sure if there is any added value in having correct
> authors assigned to issues/comments, compared to displaying the
> information in the contents field. Since I have spent some time
> scripting both Launchpad and Gitlab, let me see how it can be done.
> 
> Cheers,
> Orson
> 

Thanks Orson for looking into this.

Cheers,

Wayne

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GitLab migration

[Ian McInerney]

On a similar note, the issue workflow will need to be modified if the
GitLab tracker is used. Unfortunately, GitLab doesn't seem to have the same
functionality as the Launchpad tracker with respect to issue status and
severity. This might be a good time to finalize the earlier work that Nick
had started to formalize the issue process and the bug tracker workflow
before we transition to the GitLab tracker. That way we can define how we
want to do this from the outset. This will probably require some trial and
error and discussions to fully work it out.

-Ian

On Thu, Oct 10, 2019 at 8:51 AM Maciej Suminski 
wrote:

> On 10/10/19 2:30 AM, Andrew Lutsenko wrote:
> 
> > In terms of issues migration I think moving open issues via script and
> > locking down launchpad tracker is the best option. Even if migrated
> > issues and comments on them will be owned by some service account/bot.
> > It should be doable to include enough information there so that it's
> > clear who originally posted it and the context is not lost.
>
> I agree, I am not sure if there is any added value in having correct
> authors assigned to issues/comments, compared to displaying the
> information in the contents field. Since I have spent some time
> scripting both Launchpad and Gitlab, let me see how it can be done.
>
> Cheers,
> Orson
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GitLab migration

[Thomas Pointhuber]

Hi,

if you are curious, Antonio Vázquez Blanco designed a example
ci-pipeline for gitlab. (you need to have a gitlab account to view it):

https://gitlab.com/kicad-mirror/kicad-source-mirror/tree/feature/gitlab-ci

It automatically creates Appimages for example.

Personally, I would really like it to have a continious delivery
pipeline integrated, which is able to create all the different
packages/deployment binaries.

Regards,
Thomas

Am 10.10.19 um 02:30 schrieb Andrew Lutsenko:
> Hi all,
> 
> Gitlab migration with it's proper support for CI/CD and merge requests
> can not come fast enough, I'm very excited that the move is planned.
> I've been using home-hosted gitlab instance for a while now and it's
> useful even for a single developer operation, it will be a lot more
> beneficial for a big project like KiCad. 
> 
> In terms of issues migration I think moving open issues via script and
> locking down launchpad tracker is the best option. Even if migrated
> issues and comments on them will be owned by some service account/bot.
> It should be doable to include enough information there so that it's
> clear who originally posted it and the context is not lost.
> 
> Regards,
> Andrew
> 
> 
> On Wed, Oct 9, 2019 at 4:36 PM Wayne Stambaugh  > wrote:
> 
> On 10/9/19 3:32 PM, Mark Roszko wrote:
> >>  I've applied for an open source GitLab license.  Assuming we get
> > accepted,
> >
> > Technically not required for now. The license just unlocks extra
> > features but the base free feature set is more than adequate for now.
> 
> I prefer some of the extra permission features that the license gives us
> over the free version.  I suspect we will be approved long before 5.1.5
> is released.
> 
> >
> >
> >>Would it be possible to migrate open bug reports to GitLab?  I suspect
> >>we could come up with a script like we did when we migrated from
> >>SourceForge.
> >
> > Basically, yes and no. You can copy the content of issues over no
> > problem. You cannot copy over the authors of comments and posts. It'll
> > have to done under some fake/throwaway user account for migration as
> > it'll become owner of them all.
> 
> If it's too problematic, I'm fine with leaving existing bug reports in
> Launchpad.  Not sure what to do with the open reports other than let
> them expire.
> 
> >
> >
> >>What to do about the mailing list?  GitLab doesn't support mailing
> lists
> >>yet so I'm thinking we leave the mailing list on Launchpad for the
> short
> >>term.  We can always migrate the mailing list at a later date or use
> >>some other communication tool such as discourse.
> >
> > Someone was adding mailing list functionality to GitLab a few
> months ago
> > but the PRs been sitting for a few months.
> > Yes, either a forum or google groups would be an alternative. 
> >
> > A forum can be inviting to the most inexperienced users. But because I
> > that I would say an absolute minimum is there must some level of
> > segregation to prevent developers being flooded with tech support.
> 
> That is one of the shortcomings of using a forum.  However, with
> adequate moderation (i.e. no support for non-development issues), it
> does provide a richer communication environment than a mailing list.  I
> don't have a strong preference one way or the other.  I was just
> throwing it out there as an alternative.
> 
> >
> >
> > On Wed, Oct 9, 2019 at 12:36 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>
> > >> wrote:
> >
> >     The lead development team has been discussing migrating the KiCad
> >     project to GitLab[1].  Given the issues with Launchpad, I
> think this is
> >     a good move.  I've applied for an open source GitLab license. 
> Assuming
> >     we get accepted, I would like to start this process after the
> 5.1.5
> >     release.  Here is a short list of action items that need to be
> done for
> >     the source repo transition:
> >
> >     * Freeze the Launchpad source repo.
> >     * Push the frozen repo to GitLab.
> >     * Disable the Launcpad bug tracker.
> >     * Add a note and link to the Launcpad project page that the
> project is
> >     now hosted on GitLab.
> >     * Create blog announcement once the transition is complete.
> >
> >     There are a few unknowns:
> >
> >     Would it be possible to migrate open bug reports to GitLab?  I
> suspect
> >     we could come up with a script like we did when we migrated from
> >     SourceForge.
> >
> >     What to do about the mailing list?  GitLab doesn't support
> mailing lists
> >     yet so I'm thinking we leave the mailing list on Launchpad for
> the short
> 

Re: [Kicad-developers] GitLab migration

[Maciej Suminski]

On 10/10/19 2:30 AM, Andrew Lutsenko wrote:

> In terms of issues migration I think moving open issues via script and
> locking down launchpad tracker is the best option. Even if migrated
> issues and comments on them will be owned by some service account/bot.
> It should be doable to include enough information there so that it's
> clear who originally posted it and the context is not lost.

I agree, I am not sure if there is any added value in having correct
authors assigned to issues/comments, compared to displaying the
information in the contents field. Since I have spent some time
scripting both Launchpad and Gitlab, let me see how it can be done.

Cheers,
Orson

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GitLab migration

[Nick Østergaard]

But the free Azure service has a limitation of 10GB space for a builder, so
it os not really fesible to build everything properly.

I managed to make a docker image with the MSYS2 build environment, but ran
out of space to make the installer.

tor. 10. okt. 2019 06.41 skrev Mark Roszko :

> More worth it is connecting it to Azure Pipelines. Microsoft offers free
> CI builds on Linux, Windows and macOS! with unlimited minutes and 10
> parallel jobs for open source projects. Basically blows Gitlab CI's where
> you have to BYOM out of the water :D
>
> On Wed, Oct 9, 2019 at 9:26 PM Adam Wolf 
> wrote:
>
>> I'm very excited to provide macOS builds on merge requests for folks
>> to more easily test...
>>
>> Adam
>>
>> On Wed, Oct 9, 2019 at 7:30 PM Andrew Lutsenko 
>> wrote:
>> >
>> > Hi all,
>> >
>> > Gitlab migration with it's proper support for CI/CD and merge requests
>> can not come fast enough, I'm very excited that the move is planned.
>> > I've been using home-hosted gitlab instance for a while now and it's
>> useful even for a single developer operation, it will be a lot more
>> beneficial for a big project like KiCad.
>> >
>> > In terms of issues migration I think moving open issues via script and
>> locking down launchpad tracker is the best option. Even if migrated issues
>> and comments on them will be owned by some service account/bot. It should
>> be doable to include enough information there so that it's clear who
>> originally posted it and the context is not lost.
>> >
>> > Regards,
>> > Andrew
>> >
>> >
>> > On Wed, Oct 9, 2019 at 4:36 PM Wayne Stambaugh 
>> wrote:
>> >>
>> >> On 10/9/19 3:32 PM, Mark Roszko wrote:
>> >> >>  I've applied for an open source GitLab license.  Assuming we get
>> >> > accepted,
>> >> >
>> >> > Technically not required for now. The license just unlocks extra
>> >> > features but the base free feature set is more than adequate for now.
>> >>
>> >> I prefer some of the extra permission features that the license gives
>> us
>> >> over the free version.  I suspect we will be approved long before 5.1.5
>> >> is released.
>> >>
>> >> >
>> >> >
>> >> >>Would it be possible to migrate open bug reports to GitLab?  I
>> suspect
>> >> >>we could come up with a script like we did when we migrated from
>> >> >>SourceForge.
>> >> >
>> >> > Basically, yes and no. You can copy the content of issues over no
>> >> > problem. You cannot copy over the authors of comments and posts.
>> It'll
>> >> > have to done under some fake/throwaway user account for migration as
>> >> > it'll become owner of them all.
>> >>
>> >> If it's too problematic, I'm fine with leaving existing bug reports in
>> >> Launchpad.  Not sure what to do with the open reports other than let
>> >> them expire.
>> >>
>> >> >
>> >> >
>> >> >>What to do about the mailing list?  GitLab doesn't support mailing
>> lists
>> >> >>yet so I'm thinking we leave the mailing list on Launchpad for the
>> short
>> >> >>term.  We can always migrate the mailing list at a later date or use
>> >> >>some other communication tool such as discourse.
>> >> >
>> >> > Someone was adding mailing list functionality to GitLab a few months
>> ago
>> >> > but the PRs been sitting for a few months.
>> >> > Yes, either a forum or google groups would be an alternative.
>> >> >
>> >> > A forum can be inviting to the most inexperienced users. But because
>> I
>> >> > that I would say an absolute minimum is there must some level of
>> >> > segregation to prevent developers being flooded with tech support.
>> >>
>> >> That is one of the shortcomings of using a forum.  However, with
>> >> adequate moderation (i.e. no support for non-development issues), it
>> >> does provide a richer communication environment than a mailing list.  I
>> >> don't have a strong preference one way or the other.  I was just
>> >> throwing it out there as an alternative.
>> >>
>> >> >
>> >> >
>> >> > On Wed, Oct 9, 2019 at 12:36 PM Wayne Stambaugh <
>> stambau...@gmail.com
>> >> > > wrote:
>> >> >
>> >> > The lead development team has been discussing migrating the KiCad
>> >> > project to GitLab[1].  Given the issues with Launchpad, I think
>> this is
>> >> > a good move.  I've applied for an open source GitLab license.
>> Assuming
>> >> > we get accepted, I would like to start this process after the
>> 5.1.5
>> >> > release.  Here is a short list of action items that need to be
>> done for
>> >> > the source repo transition:
>> >> >
>> >> > * Freeze the Launchpad source repo.
>> >> > * Push the frozen repo to GitLab.
>> >> > * Disable the Launcpad bug tracker.
>> >> > * Add a note and link to the Launcpad project page that the
>> project is
>> >> > now hosted on GitLab.
>> >> > * Create blog announcement once the transition is complete.
>> >> >
>> >> > There are a few unknowns:
>> >> >
>> >> > Would it be possible to migrate open bug reports to GitLab?  I
>> suspect
>> >> > we could