Re: [Kicad-developers] GitLab migration

[Seth Hillbrand]

On 2019-10-14 16:09, Ian McInerney wrote:


Orson,

Great work so far.

I was noticing as you were testing migrating the issues that our @names 
in the text seem to not transfer well. In one of the issues just now 
(the pcbnew segfault issue #228 [2]) it pulls in a different user for 
Seth whenever @seth is mentioned, and also for my name. Do you think it 
would be possible to do two things with the message text:
1) Replace the @name usage for the most common people with their GitLab 
user (this would require us to know all of them and have a map between 
name and user). This should also be case insensitive, since we don't 
always seem to capitalize names.
2) Escape the @name usage in other cases (maybe add a space between the 
@ and the name?).


At the very least we should probably escape them so we don't randomly 
mention unrelated people in all our issues.


On the topic of labels, I was doing some research and if we can get the 
OSS license for GitLab I think we can turn the Launchpad status and 
priority into scoped labels [1]. The nice thing about those is only one 
label per scope can be applied to an issue at a time, and adding a new 
label to an issue automatically removes the old one. I think we could 
define scopes such as

priority::{wishlist, low, medium, etc...}
status::{new, confirmed, in progress, as designed, fix committed, 
etc...}


By doing this I think it is nice and obvious what the open/close status 
of the bug is (instead of just having open/close).


I'll second Ian's suggestion that the priorities and status both get 
labels.  I'd like to see Heat map to GitLab's weight.  You can't really 
search much with weight in GitLab (no range operators that I can find), 
so it seems mostly useful for sorting after you get the results.


I think we'll need to figure out how to deal with our version 
information in KiCad not being nicely formatted for markdown.  The 
blockquote for variable indents is readable but distracting.  Maybe we 
can get it into a block like:


KiCad Version Info
All the details here



Overall, this is great!  Looking forward to the move.

-Seth

___
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]

Orson,

Great work so far.

I was noticing as you were testing migrating the issues that our @names in
the text seem to not transfer well. In one of the issues just now (the
pcbnew segfault issue #228 [2]) it pulls in a different user for Seth
whenever @seth is mentioned, and also for my name. Do you think it would be
possible to do two things with the message text:
1) Replace the @name usage for the most common people with their GitLab
user (this would require us to know all of them and have a map between name
and user). This should also be case insensitive, since we don't always seem
to capitalize names.
2) Escape the @name usage in other cases (maybe add a space between the @
and the name?).

At the very least we should probably escape them so we don't randomly
mention unrelated people in all our issues.


On the topic of labels, I was doing some research and if we can get the OSS
license for GitLab I think we can turn the Launchpad status and priority
into scoped labels [1]. The nice thing about those is only one label per
scope can be applied to an issue at a time, and adding a new label to an
issue automatically removes the old one. I think we could define scopes
such as
priority::{wishlist, low, medium, etc...}
status::{new, confirmed, in progress, as designed, fix committed, etc...}

By doing this I think it is nice and obvious what the open/close status of
the bug is (instead of just having open/close).

I was going to start redrafting Nick's Launchpad guidance into something
for GitLab using the labels in the next week hopefully. Then we can get
some more comments on it.

[1]
https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels-premium
[2] https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/228#note_230289955

Thanks for doing this.
-Ian

On Mon, 14 Oct 2019, 23:52 Maciej Suminski,  wrote:

> I have started working on the bug tracker migration script [1], and now
> you can check out a test batch of 100 bug reports converted to Gitlab
> [2]. I am looking forward to your comments.
>
> What is transferred accurately?
> - description
> - messages (including attachments and dates)
> - milestones
> - tags
> - duplicates ('related bugs' in Gitlab)
>
> What is different?
> - text formatting:
> Gitlab uses markdown to format the text, while Launchpad reports are
> plain text. From what I see, verbatim text transfer between the
> platforms does not look terrible, but if you see anything that demands a
> fix - let me know.
>
> - importance:
> In Gitlab bugs are described with 'weight' property, which is an
> integer. I imagine the higher the weight, the more important is a bug.
> For the moment I use the following mapping:
> 'Critical': return 50
> 'High': return 40
> 'Medium':   return 30
> 'Low':  return 20
> 'Wishlist': return 10
>
> - status:
> Gitlab offers only two status types: opened/closed. It is a pity, but I
> doubt we can do anything about it. Here is a mapping proposal:
> 'New':   return 'active'
> 'Incomplete':return 'active'
> 'Opinion':   return 'active'
> 'Invalid':   return 'close'
> 'Won\'t Fix':return 'close'
> 'Expired':   return 'close'   # TODO should be closed or active?
> 'Confirmed': return 'active'
> 'Triaged':   return 'active'
> 'In Progress':   return 'active'
> 'Fix Committed': return 'close'
> 'Fix Released':  return 'close'
>
> - authors:
> The whole contents is currently transferred under a single author
> (myself, but I plan to use a dedicated account for the migration). If we
> were admins of a Gitlab instance, then we could use 'sudo' [3] to
> impersonate users. This would still require users to create their
> accounts before the migration.
> My workaround is adding a first line indicating the original author
> ('xxx wrote:').
>
> To-do:
> - assignees:
> I plan to create a user map linking Launchpad and Gitlab accounts to
> transfer. If an account is not mapped, then I will try to search
> gitlab.com for an exact match (I cannot guess correctly if search
> results contain multiple accounts).
>
> - optimization:
> The script is painfully slow (100 issues in 0.5h), and I have not
> profiled it yet.
>
> - URLs:
> I would like to convert Launchpad links occurring in the reports to
> their Gitlab counterparts.
>
> Other notes:
> KiCad Janitor may retire after the migration, as Gitlab provides a way
> to close issues using commit messages [4].
>
> Cheers,
> Orson
>
> 1. https://gitlab.com/orsonmmz/kicad-bug-tracker
> 2.
> https://gitlab.com/orsonmmz/kicad-bug-tracker/issues?scope=all=all
> 3. https://docs.gitlab.com/ee/api/#sudo
> 4.
>
> https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#default-closing-pattern
>
> ___
> 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

[Maciej Suminski]

I have started working on the bug tracker migration script [1], and now
you can check out a test batch of 100 bug reports converted to Gitlab
[2]. I am looking forward to your comments.

What is transferred accurately?
- description
- messages (including attachments and dates)
- milestones
- tags
- duplicates ('related bugs' in Gitlab)

What is different?
- text formatting:
Gitlab uses markdown to format the text, while Launchpad reports are
plain text. From what I see, verbatim text transfer between the
platforms does not look terrible, but if you see anything that demands a
fix - let me know.

- importance:
In Gitlab bugs are described with 'weight' property, which is an
integer. I imagine the higher the weight, the more important is a bug.
For the moment I use the following mapping:
'Critical': return 50
'High': return 40
'Medium':   return 30
'Low':  return 20
'Wishlist': return 10

- status:
Gitlab offers only two status types: opened/closed. It is a pity, but I
doubt we can do anything about it. Here is a mapping proposal:
'New':   return 'active'
'Incomplete':return 'active'
'Opinion':   return 'active'
'Invalid':   return 'close'
'Won\'t Fix':return 'close'
'Expired':   return 'close'   # TODO should be closed or active?
'Confirmed': return 'active'
'Triaged':   return 'active'
'In Progress':   return 'active'
'Fix Committed': return 'close'
'Fix Released':  return 'close'

- authors:
The whole contents is currently transferred under a single author
(myself, but I plan to use a dedicated account for the migration). If we
were admins of a Gitlab instance, then we could use 'sudo' [3] to
impersonate users. This would still require users to create their
accounts before the migration.
My workaround is adding a first line indicating the original author
('xxx wrote:').

To-do:
- assignees:
I plan to create a user map linking Launchpad and Gitlab accounts to
transfer. If an account is not mapped, then I will try to search
gitlab.com for an exact match (I cannot guess correctly if search
results contain multiple accounts).

- optimization:
The script is painfully slow (100 issues in 0.5h), and I have not
profiled it yet.

- URLs:
I would like to convert Launchpad links occurring in the reports to
their Gitlab counterparts.

Other notes:
KiCad Janitor may retire after the migration, as Gitlab provides a way
to close issues using commit messages [4].

Cheers,
Orson

1. https://gitlab.com/orsonmmz/kicad-bug-tracker
2. https://gitlab.com/orsonmmz/kicad-bug-tracker/issues?scope=all=all
3. https://docs.gitlab.com/ee/api/#sudo
4.
https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#default-closing-pattern



signature.asc
Description: OpenPGP digital signature
___
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] [PATCH] Implement auto annotation on component/symbol placement.

[Zficani Zficani]

Hi,
No problem, I just wanted to make sure I sent the message properly. Here's
a single squashed patch with all previous changes and these comments about
copying selection.

Thank you so much for your review.

On Mon, Oct 14, 2019 at 12:13 AM Ian McInerney 
wrote:

> Zifcani,
>
> Sorry for the delay in the response. Yes, you can just attach the new
> patches to an email and send it to the list. You can either squash them all
> into 1 patch, or create 2 patches (the first just the wxFormbuilder dialog
> class, so all the _base.fbp/cpp/h files, and the second the remaining
> files).
>
> In regard to the selection return type, it sounds like the sorting
> operation is invalidating an iterator held in another object for iterating
> over the selection, causing the hang/crash. I guess that for now it is fine
> to make these a full copy instead of a reference, but it would be good if
> you included a comment with them explaining why they are a copy instead of
> the reference. We can look into which iterators are being broken by the
> sort operation later (unless you want to do it now).
>
> -Ian
>
> On Fri, Oct 11, 2019 at 9:09 AM Zficani Zficani  wrote:
>
>> Hi,
>> I see, I will send in new patches later today. Do I just send them in an
>> email like this?
>>
>> On Fri, 11 Oct 2019, 02:10 Seth Hillbrand,  wrote:
>>
>>>
>>> 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 [image: Twitter]    LinkedIn [image:
>>> LinkedIn] 
>>> +1 530 302 5483 <+15303025483> | +1 212 603 9372 <+12126039372>
>>> www.kipro-pcb.com
>>> Davis, CA
>>>
>>
diff --git a/.gitignore b/.gitignore
index 619c7f963..f62e05e15 100644
--- a/.gitignore
+++ b/.gitignore
@@ -74,6 +74,7 @@ pcbnew/Info.plist
 .*.swp
 *~
 .idea
+.vscode
 .DS_Store
 *.png
 *.kiface
diff --git a/eeschema/CMakeLists.txt b/eeschema/CMakeLists.txt
index f22886414..86569a39d 100644
--- a/eeschema/CMakeLists.txt
+++ b/eeschema/CMakeLists.txt
@@ -97,6 +97,8 @@ set( EESCHEMA_DLGS
 dialogs/panel_eeschema_display_options_base.cpp
 dialogs/panel_eeschema_settings.cpp
 dialogs/panel_eeschema_settings_base.cpp
+dialogs/panel_eeschema_annotation_options.cpp
+dialogs/panel_eeschema_annotation_options_base.cpp
 dialogs/panel_libedit_settings.cpp
 dialogs/panel_libedit_settings_base.cpp
 dialogs/panel_sym_lib_table.cpp
diff --git a/eeschema/component_references_lister.cpp b/eeschema/component_references_lister.cpp
index 867fd18e3..503202ea3 100644
--- a/eeschema/component_references_lister.cpp
+++ b/eeschema/component_references_lister.cpp
@@ -112,21 +112,7 @@ bool SCH_REFERENCE_LIST::sortByRefAndValue( const SCH_REFERENCE& item1,
 bool SCH_REFERENCE_LIST::sortByReferenceOnly( const SCH_REFERENCE& item1,
   const SCH_REFERENCE& item2 )
 {
-int ii;
-
-ii = UTIL::RefDesStringCompare( item1.GetRef(), item2.GetRef() );
-
-if( ii == 0 )
-{
-ii = item1.m_RootCmp->GetField( VALUE )->GetText().CmpNoCase( item2.m_RootCmp->GetField( VALUE )->GetText() );
-}
-
-if( ii == 0 )
-{
-ii = item1.m_Unit - item2.m_Unit;
-}
-
-return ii < 0;
+return item1.m_RootCmp->CompareRefDes(item2.m_RootCmp);
 }
 
 
diff --git a/eeschema/dialogs/panel_eeschema_annotation_options.cpp 

Re: [Kicad-developers] GitLab migration

[Maciej Suminski]

Recently I have been trying to set up a Gitlab instance using the CERN
OpenShift instance. The theory is simple and well described, but in
practice we do not have enough privileges to run it. This is what I
noticed myself and then confirmed with the admins.

If we can get a professional service from the company that develops the
software, then I would go for it. We can move it somewhere else later if
need be, and it should much easier than migrating from one platform to
another.

Cheers,
Orson

On 10/14/19 2:35 PM, Mark Roszko wrote:
> We would just run it on the same CERN openshift cluster as the website.
> 
> 
> I would volunteer as this is literally what I do at work (maintain a 100+
> man GitLab instance among many other bits of infrastructure) but the real
> question is what is the benefit?
> You really don't want to be modifying GitLab itself as it's one hell of a
> rabbit hole and gitlab is constantly releasing new versions and if you
> start modifying things you end up even deeper in the rabbithole trying to
> keep up with patches.
> 
> At work we self-host only for intellectual property and the US has
> third-world internet reasons.
> 
> 
> On Mon, Oct 14, 2019 at 6:20 AM Simon Richter 
> wrote:
> 
>> Hi,
>>
>> On 14.10.19 08:31, Dick Hollenbeck wrote:
>>
>>> Is there a reason to try and host gitlab ourselves?
>>
>> I'd think that'd be a manpower issue, I still have three feature
>> branches that were started before 4.0.
>>
>> If anyone volunteers, I still have some space on my server, and even
>> more if it can replace Jenkins for the nightly builds.
>>
>>Simon
>>
>> ___
>> 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
> 



signature.asc
Description: OpenPGP digital signature
___
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

[Dick Hollenbeck]

> gitlab in a Docker container

Here's an on going effort which would reduce the work:

https://docs.gitlab.com/ee/install/docker.html


>some of these augmentation needs are not all foreseeable now.


>> but the real question is what is the benefit?


There are more than one benefit, and this is not the real question, because 
there are
multiple questions.

Like most things in life it is a cost benefit analysis.  That analysis cannot 
be done in
2-3 emails.


Here are some more benefits:

*) Owning your own data,
*) only having to move it once launchpad; not a second time, after the list of 
feature
voids gets so long and you then find a rabbit willing to go down into Mark's 
rabbit hole
and play house.  One man's rabbit hole is a rabbit's masterpiece. This would be 
merely
using the open source model, and pushing changes upstream.  Hopefully *we* of 
all people,
don't indict that in one sentence.


git with rebasing helps, but you knew that.  And the receptiveness of upstream 
plays a big
role in weighing the pain factor and the patch backlog.  Overall it is an 
additional
element of freedom, and yes it does come with a cost.



HTH,

Dick


___
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]

We would just run it on the same CERN openshift cluster as the website.


I would volunteer as this is literally what I do at work (maintain a 100+
man GitLab instance among many other bits of infrastructure) but the real
question is what is the benefit?
You really don't want to be modifying GitLab itself as it's one hell of a
rabbit hole and gitlab is constantly releasing new versions and if you
start modifying things you end up even deeper in the rabbithole trying to
keep up with patches.

At work we self-host only for intellectual property and the US has
third-world internet reasons.


On Mon, Oct 14, 2019 at 6:20 AM Simon Richter 
wrote:

> Hi,
>
> On 14.10.19 08:31, Dick Hollenbeck wrote:
>
> > Is there a reason to try and host gitlab ourselves?
>
> I'd think that'd be a manpower issue, I still have three feature
> branches that were started before 4.0.
>
> If anyone volunteers, I still have some space on my server, and even
> more if it can replace Jenkins for the nightly builds.
>
>Simon
>
> ___
> 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]

Hi Dick,

On 10/14/19 2:31 AM, Dick Hollenbeck wrote:
> Wayne,
> 
> Maybe this has been asked and answered, but
> 
> Is there a reason to try and host gitlab ourselves?
> 
> We have a few clever people available to augment the install with bells and 
> whistles, and
> some of these augmentation needs are not all forseeable now.
> 
> Improvements might be submitted upstream even...
> 
> Just wanted to make sure this has been considered.  It is not particularly 
> important to me
> personally, but I thought it might be worth discussing because it could solve 
> some
> problems down the road and lead to greater freedom.


I was planning on leaving the hosting to gitlab unless we have the
infrastructure and manpower to support our own instance.  I'm not
opposed to having our own instance if we have the resources to pull it
off.  I still haven't heard back from gitlab yet about our license
application.  Once I have an answer, we can decide which direction we
want to go.

Cheers,

Wayne

> 
> BTW, I used KiCad again recently and you'll are doing a wonderful job on the 
> enhancements.
>  It was a joy to use.
> 
> 
> Regards,
> 
> Dick
> 
> 
> 
> 
> ___
> 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

[Dick Hollenbeck]

On 10/14/19 1:31 AM, Dick Hollenbeck wrote:
> Is there a reason to try and host gitlab ourselves?

I would look for gitlab in a Docker container, could be easy for the experienced
volunteer.

___
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

[Dick Hollenbeck]

Wayne,

Maybe this has been asked and answered, but

Is there a reason to try and host gitlab ourselves?

We have a few clever people available to augment the install with bells and 
whistles, and
some of these augmentation needs are not all forseeable now.

Improvements might be submitted upstream even...

Just wanted to make sure this has been considered.  It is not particularly 
important to me
personally, but I thought it might be worth discussing because it could solve 
some
problems down the road and lead to greater freedom.

BTW, I used KiCad again recently and you'll are doing a wonderful job on the 
enhancements.
 It was a joy to use.


Regards,

Dick




___
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