Re: [Kicad-developers] GitLab migration

[Rene Pöschl]

What gave you the impression we were keen on moving shop? Github does 
everything we need it to do (unlike launchpad). My guess is that you 
chose gitlab over github because it can be installed on your own servers 
so is more future proof. (Nobody really explained why gitlab was chosen 
so i could be wrong.)


Also see https://gitlab.com/kicad/kicad_migration/issues/20

TlDr: Move will happen after the v6 file format is useable enough for us 
to close down the symbol side for contributions and convert. This will 
hide the negative effects of moving shop at least for half the open pull 
requests. Unless somebody gets a full syncroniszation of pull request going.



Plus lack of manpower. If somebody other than be gets our travis scripts 
to run then that would already be a massive help. (The move will still 
happen after the v6 format change unless we get a massive boost in 
manpower that allows us to handle two platforms during the transition.)



On 03/01/2020 23:31, Nick Østergaard wrote:

What is the blocker for the libs to move to gitlab.
I was under the impression that the librarians where the people most 
keen on moving to gitlab.


On Wed, 27 Nov 2019 at 21:39, Seth Hillbrand > wrote:


On 11/27/19 11:42 AM, Rene Pöschl wrote:

On 26/11/2019 21:54, Seth Hillbrand wrote:

On 2019-11-26 12:41, Jeff Young wrote:

OK, I’ve enabled 2FA.  Do I need to do something to get added
back to
the project?  (When I go to members, all I see are the bot,
Seth and
Wayne.)

Cheers,
Jeff.

Hi Jeff-

Wayne and the bot have permissions for the entire project.  I'm
there
while sorting out the transition work.  Coding permissions are
specific
to https://gitlab.com/kicad/code/ .  Library permissions are
specific to
https://gitlab.com/kicad/libraries/ , etc.

If you'd like push permissions in libraries, you'll want to
check with
Rene.  I think Nick or Marek will be managing the website section
(someone fill me in).  I'll also need to know who to assign to
managing
the documentation section (Nick also?).  Once I get the packaging
section set up, we'll have folks in charge of their relative
builds that
we can run through the GitLab CI runner interface.

-Seth



Hi,

well it seems i do not have access to the group either.


Hi Rene-

I've added you to the top-level group.  There is a sub-group
called librarians where everyone goes but group permissions can
only be assigned to repositories and not other groups (missed that
part).

Let me know if anything else looks amiss.

I'm going to re-sync the repositories this weekend to see if we
pick up any additional folks who are creating GitLab accounts.

-Seth


-- 
KiCad Services Corporation KiCad Services Corporation Logo

Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬ 
Davis, CA
www.kipro-pcb.com  i...@kipro-pcb.com

https://twitter.com/KiProEDA 
https://www.linkedin.com/company/kicad


___
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




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

What is the blocker for the libs to move to gitlab.
I was under the impression that the librarians where the people most keen
on moving to gitlab.

On Wed, 27 Nov 2019 at 21:39, Seth Hillbrand  wrote:

> On 11/27/19 11:42 AM, Rene Pöschl wrote:
>
> On 26/11/2019 21:54, Seth Hillbrand wrote:
>
> On 2019-11-26 12:41, Jeff Young wrote:
>
> OK, I’ve enabled 2FA.  Do I need to do something to get added back to
> the project?  (When I go to members, all I see are the bot, Seth and
> Wayne.)
>
> Cheers,
> Jeff.
>
> Hi Jeff-
>
> Wayne and the bot have permissions for the entire project.  I'm there
> while sorting out the transition work.  Coding permissions are specific
> to https://gitlab.com/kicad/code/ .  Library permissions are specific to
> https://gitlab.com/kicad/libraries/ , etc.
>
> If you'd like push permissions in libraries, you'll want to check with
> Rene.  I think Nick or Marek will be managing the website section
> (someone fill me in).  I'll also need to know who to assign to managing
> the documentation section (Nick also?).  Once I get the packaging
> section set up, we'll have folks in charge of their relative builds that
> we can run through the GitLab CI runner interface.
>
> -Seth
>
>
> Hi,
>
> well it seems i do not have access to the group either.
>
>
> Hi Rene-
>
> I've added you to the top-level group.  There is a sub-group called
> librarians where everyone goes but group permissions can only be assigned
> to repositories and not other groups (missed that part).
>
> Let me know if anything else looks amiss.
>
> I'm going to re-sync the repositories this weekend to see if we pick up
> any additional folks who are creating GitLab accounts.
>
> -Seth
>
>
> --
> KiCad Services Corporation [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ <+12126039372>
> Davis, CA
> www.kipro-pcb.comi...@kipro-pcb.com
> https://twitter.com/KiProEDA 
> https://www.linkedin.com/company/kicad
> 
> ___
> 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

[Marco Ciampa]

On Wed, Dec 04, 2019 at 08:20:21AM -0500, Wayne Stambaugh wrote:
> Eventually, all official KiCad repositories will be migrated to GitLab.
> I think the documentation and translation repos have already been
> migrated from GitHub.

Yes and you (all devs) did a GREAT work!

Many thanks!

--

Saluton,
Marco Ciampa

___
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 Seppe,

On 12/3/19 6:39 PM, Seppe Stas wrote:
> Just wanted to say I love this and I'm sure it will improve visibility
> of the KiCad project and lower the barrier of entry for new developers.

We shall see.  I'm probably a less optimistic about this.  The main
reason for the move was to make the lead development team's life a bit
easier.  Launchpad never fully integrated git into their workflow like
they originally did for Bazaar.

> 
> Some questions:
> 
>   * Are there any plans to use the Gitlab CI system in the future?

We already have some CI implementations on other systems.  I suspect
much of this will be migrated to GitLab.

>   * Will the KiCad libraries also be migrated or is the plan to keep
> them on Github?

Eventually, all official KiCad repositories will be migrated to GitLab.
 I think the documentation and translation repos have already been
migrated from GitHub.

Cheers,

Wayne

> 
> Just be sure to make some backups once in a while, Gitlab.com has some
> history with Database issues.
> 
> Seppe
> 
> On Sat, Nov 30, 2019 at 8:59 PM Wayne Stambaugh  > wrote:
> 
> This is intentional.  GitHub automatically appends the luanchpad url
> with is now a mirror of the GitLab repo.  I may change the mirror url to
> GitLab when I get a chance but that will only decrease the refresh
> latency.
> 
> On 11/30/19 3:24 PM, Diego Herranz wrote:
> > Just a quick comment.
> >
> > The description of https://github.com/KiCad/kicad-source-mirror
> has been
> > updated to mention gitlab, but still has a link to launchpad. Is that
> > intentional?
> >
> > Thanks,
> > Diego
> >
> > On Fri, 29 Nov 2019, 18:25 Wayne Stambaugh,  
> > >> wrote:
> >
> >     We will have to figure this out as we go.  What ever platform
> we use, it
> >     will not be the free for all that we currently have.
> >
> >     On 11/29/2019 1:19 PM, Jon Evans wrote:
> >     > As far as I know, there is not fine-grained access control
> on Wiki
> >     > pages.  The only way to do something like this to create a
> separate
> >     > project just for a public wiki.  Then a limited set of people
> >     would have
> >     > permissions to copy things from the public wiki to the main
> KiCad
> >     > project wiki.
> >     >
> >     > To be honest, that sounds less useful than the current
> status quo,
> >     which
> >     > is to use Google Docs for pre-implementation design
> collaboration.
> >     > I know not everyone likes Google or wants to create an account,
> >     and I'd
> >     > be happy to try alternatives that have the same
> functionality.  But, I
> >     > think it's important to have similar functionality: A few
> people have
> >     > access to edit, and more people (i.e. the public) can only make
> >     > suggestions or comments.
> >     >
> >     > -Jon
> >     >
> >     > On Fri, Nov 29, 2019 at 1:09 PM Simon Richter
> >     mailto:simon.rich...@hogyros.de>
> >
> >     >  
> >       >     >
> >     >     Hi Wayne,
> >     >
> >     >     On Fri, Nov 29, 2019 at 12:49:30PM -0500, Wayne
> Stambaugh wrote:
> >     >
> >     >     > I will also be disabling the Launchpad blueprint and
> answers
> >     pages as
> >     >     > well.  We not going to migrate the blueprints to GitLab
> >     because the
> >     >     > entire blueprint system is a mess due to the lack of sane
> >     permissions.
> >     >     > We may have to manually migrate the useful blueprints
> to GitLab
> >     >     once we
> >     >     > have a reasonable process for doing so.
> >     >
> >     >     One of my main hopes for the migration is to get a
> workflow for
> >     >     collaborative pre-implementation design. Blueprints were
> a nice
> >     >     idea, but
> >     >     they were never fully implemented on Launchpad, and it
> shows.
> >     >
> >     >     It'd probably make sense to use the Wiki for that, do
> you know
> >     if it is
> >     >     possible for non-committers to have limited Wiki editing
> >     rights (e.g. an
> >     >     "ideas" namespace with looser permissions, and moving
> the page
> >     to the
> >     >     "roadmap" namespace later)?
> >     >
> >     >        Simon
> >     >
> >     >     ___
> >     >     Mailing list: https://launchpad.net/~kicad-developers

Re: [Kicad-developers] GitLab migration

[Seppe Stas]

Just wanted to say I love this and I'm sure it will improve visibility of
the KiCad project and lower the barrier of entry for new developers.

Some questions:

   - Are there any plans to use the Gitlab CI system in the future?
   - Will the KiCad libraries also be migrated or is the plan to keep them
   on Github?

Just be sure to make some backups once in a while, Gitlab.com has some
history with Database issues.

Seppe

On Sat, Nov 30, 2019 at 8:59 PM Wayne Stambaugh 
wrote:

> This is intentional.  GitHub automatically appends the luanchpad url
> with is now a mirror of the GitLab repo.  I may change the mirror url to
> GitLab when I get a chance but that will only decrease the refresh latency.
>
> On 11/30/19 3:24 PM, Diego Herranz wrote:
> > Just a quick comment.
> >
> > The description of https://github.com/KiCad/kicad-source-mirror has been
> > updated to mention gitlab, but still has a link to launchpad. Is that
> > intentional?
> >
> > Thanks,
> > Diego
> >
> > On Fri, 29 Nov 2019, 18:25 Wayne Stambaugh,  > > wrote:
> >
> > We will have to figure this out as we go.  What ever platform we
> use, it
> > will not be the free for all that we currently have.
> >
> > On 11/29/2019 1:19 PM, Jon Evans wrote:
> > > As far as I know, there is not fine-grained access control on Wiki
> > > pages.  The only way to do something like this to create a separate
> > > project just for a public wiki.  Then a limited set of people
> > would have
> > > permissions to copy things from the public wiki to the main KiCad
> > > project wiki.
> > >
> > > To be honest, that sounds less useful than the current status quo,
> > which
> > > is to use Google Docs for pre-implementation design collaboration.
> > > I know not everyone likes Google or wants to create an account,
> > and I'd
> > > be happy to try alternatives that have the same functionality.
> But, I
> > > think it's important to have similar functionality: A few people
> have
> > > access to edit, and more people (i.e. the public) can only make
> > > suggestions or comments.
> > >
> > > -Jon
> > >
> > > On Fri, Nov 29, 2019 at 1:09 PM Simon Richter
> > mailto:simon.rich...@hogyros.de>
> > >  > >> wrote:
> > >
> > > Hi Wayne,
> > >
> > > On Fri, Nov 29, 2019 at 12:49:30PM -0500, Wayne Stambaugh
> wrote:
> > >
> > > > I will also be disabling the Launchpad blueprint and answers
> > pages as
> > > > well.  We not going to migrate the blueprints to GitLab
> > because the
> > > > entire blueprint system is a mess due to the lack of sane
> > permissions.
> > > > We may have to manually migrate the useful blueprints to
> GitLab
> > > once we
> > > > have a reasonable process for doing so.
> > >
> > > One of my main hopes for the migration is to get a workflow for
> > > collaborative pre-implementation design. Blueprints were a nice
> > > idea, but
> > > they were never fully implemented on Launchpad, and it shows.
> > >
> > > It'd probably make sense to use the Wiki for that, do you know
> > if it is
> > > possible for non-committers to have limited Wiki editing
> > rights (e.g. an
> > > "ideas" namespace with looser permissions, and moving the page
> > to the
> > > "roadmap" namespace later)?
> > >
> > >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
> > >
> >
> > ___
> > 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 : 

Re: [Kicad-developers] GitLab migration

[Wayne Stambaugh]

This is intentional.  GitHub automatically appends the luanchpad url
with is now a mirror of the GitLab repo.  I may change the mirror url to
GitLab when I get a chance but that will only decrease the refresh latency.

On 11/30/19 3:24 PM, Diego Herranz wrote:
> Just a quick comment.
> 
> The description of https://github.com/KiCad/kicad-source-mirror has been
> updated to mention gitlab, but still has a link to launchpad. Is that
> intentional?
> 
> Thanks,
> Diego
> 
> On Fri, 29 Nov 2019, 18:25 Wayne Stambaugh,  > wrote:
> 
> We will have to figure this out as we go.  What ever platform we use, it
> will not be the free for all that we currently have.
> 
> On 11/29/2019 1:19 PM, Jon Evans wrote:
> > As far as I know, there is not fine-grained access control on Wiki
> > pages.  The only way to do something like this to create a separate
> > project just for a public wiki.  Then a limited set of people
> would have
> > permissions to copy things from the public wiki to the main KiCad
> > project wiki.
> >
> > To be honest, that sounds less useful than the current status quo,
> which
> > is to use Google Docs for pre-implementation design collaboration.
> > I know not everyone likes Google or wants to create an account,
> and I'd
> > be happy to try alternatives that have the same functionality.  But, I
> > think it's important to have similar functionality: A few people have
> > access to edit, and more people (i.e. the public) can only make
> > suggestions or comments.
> >
> > -Jon
> >
> > On Fri, Nov 29, 2019 at 1:09 PM Simon Richter
> mailto:simon.rich...@hogyros.de>
> >  >> wrote:
> >
> >     Hi Wayne,
> >
> >     On Fri, Nov 29, 2019 at 12:49:30PM -0500, Wayne Stambaugh wrote:
> >
> >     > I will also be disabling the Launchpad blueprint and answers
> pages as
> >     > well.  We not going to migrate the blueprints to GitLab
> because the
> >     > entire blueprint system is a mess due to the lack of sane
> permissions.
> >     > We may have to manually migrate the useful blueprints to GitLab
> >     once we
> >     > have a reasonable process for doing so.
> >
> >     One of my main hopes for the migration is to get a workflow for
> >     collaborative pre-implementation design. Blueprints were a nice
> >     idea, but
> >     they were never fully implemented on Launchpad, and it shows.
> >
> >     It'd probably make sense to use the Wiki for that, do you know
> if it is
> >     possible for non-committers to have limited Wiki editing
> rights (e.g. an
> >     "ideas" namespace with looser permissions, and moving the page
> to the
> >     "roadmap" namespace later)?
> >
> >        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
> >
> 
> ___
> 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

[Seth Hillbrand]

On 2019-11-29 10:15, Wayne Stambaugh wrote:

Hi Simon,

On 11/29/2019 1:09 PM, Simon Richter wrote:

Hi Wayne,

On Fri, Nov 29, 2019 at 12:49:30PM -0500, Wayne Stambaugh wrote:


I will also be disabling the Launchpad blueprint and answers pages as
well.  We not going to migrate the blueprints to GitLab because the
entire blueprint system is a mess due to the lack of sane 
permissions.
We may have to manually migrate the useful blueprints to GitLab once 
we

have a reasonable process for doing so.


One of my main hopes for the migration is to get a workflow for
collaborative pre-implementation design. Blueprints were a nice idea, 
but

they were never fully implemented on Launchpad, and it shows.


It was impossible to implement because anyone with a launchpad account
could create a blueprint and edit any other blueprint.  It was very
poorly implemented so it quickly became meaningless.



It'd probably make sense to use the Wiki for that, do you know if it 
is
possible for non-committers to have limited Wiki editing rights (e.g. 
an

"ideas" namespace with looser permissions, and moving the page to the
"roadmap" namespace later)?


Maybe, but I would rather have a system that a few maintainers who will
ensure the sanity of the system that can edit "blueprints" and anyone
with a GitLab account can comment on but not modify.  Certainly anyone
on the mailing list can recommend a blueprint but it will in no way be
the wild west like the current blueprint system.




On GitLab, we (the lead dev team) can create "epics".  These are 
multi-issue items that allow us to track the overall progress to a 
specific goal that depends on a number of sub-elements.  Users can 
comment on the epic or individual issues related to it.


This may address some of the desires while still preventing the 
Blueprints situation where devs couldn't find anything or maintain 
consistent progress tracking due to the overall lack of structure on 
Launchpad.


Pre-implementation design may be best handled by collecting interested 
parties from the mailing list to a specific group wiki.  
Creating/editing wiki pages requires developer permissions to a group.  
So this would require granting a specific group of users that permission 
for a specific purpose.


-Seth


Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

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

We will have to figure this out as we go.  What ever platform we use, it
will not be the free for all that we currently have.

On 11/29/2019 1:19 PM, Jon Evans wrote:
> As far as I know, there is not fine-grained access control on Wiki
> pages.  The only way to do something like this to create a separate
> project just for a public wiki.  Then a limited set of people would have
> permissions to copy things from the public wiki to the main KiCad
> project wiki.
> 
> To be honest, that sounds less useful than the current status quo, which
> is to use Google Docs for pre-implementation design collaboration.
> I know not everyone likes Google or wants to create an account, and I'd
> be happy to try alternatives that have the same functionality.  But, I
> think it's important to have similar functionality: A few people have
> access to edit, and more people (i.e. the public) can only make
> suggestions or comments.
> 
> -Jon
> 
> On Fri, Nov 29, 2019 at 1:09 PM Simon Richter  > wrote:
> 
> Hi Wayne,
> 
> On Fri, Nov 29, 2019 at 12:49:30PM -0500, Wayne Stambaugh wrote:
> 
> > I will also be disabling the Launchpad blueprint and answers pages as
> > well.  We not going to migrate the blueprints to GitLab because the
> > entire blueprint system is a mess due to the lack of sane permissions.
> > We may have to manually migrate the useful blueprints to GitLab
> once we
> > have a reasonable process for doing so.
> 
> One of my main hopes for the migration is to get a workflow for
> collaborative pre-implementation design. Blueprints were a nice
> idea, but
> they were never fully implemented on Launchpad, and it shows.
> 
> It'd probably make sense to use the Wiki for that, do you know if it is
> possible for non-committers to have limited Wiki editing rights (e.g. an
> "ideas" namespace with looser permissions, and moving the page to the
> "roadmap" namespace later)?
> 
>    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
> 

___
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

[Jon Evans]

As far as I know, there is not fine-grained access control on Wiki pages.
The only way to do something like this to create a separate project just
for a public wiki.  Then a limited set of people would have permissions to
copy things from the public wiki to the main KiCad project wiki.

To be honest, that sounds less useful than the current status quo, which is
to use Google Docs for pre-implementation design collaboration.
I know not everyone likes Google or wants to create an account, and I'd be
happy to try alternatives that have the same functionality.  But, I think
it's important to have similar functionality: A few people have access to
edit, and more people (i.e. the public) can only make suggestions or
comments.

-Jon

On Fri, Nov 29, 2019 at 1:09 PM Simon Richter 
wrote:

> Hi Wayne,
>
> On Fri, Nov 29, 2019 at 12:49:30PM -0500, Wayne Stambaugh wrote:
>
> > I will also be disabling the Launchpad blueprint and answers pages as
> > well.  We not going to migrate the blueprints to GitLab because the
> > entire blueprint system is a mess due to the lack of sane permissions.
> > We may have to manually migrate the useful blueprints to GitLab once we
> > have a reasonable process for doing so.
>
> One of my main hopes for the migration is to get a workflow for
> collaborative pre-implementation design. Blueprints were a nice idea, but
> they were never fully implemented on Launchpad, and it shows.
>
> It'd probably make sense to use the Wiki for that, do you know if it is
> possible for non-committers to have limited Wiki editing rights (e.g. an
> "ideas" namespace with looser permissions, and moving the page to the
> "roadmap" namespace later)?
>
>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

Re: [Kicad-developers] GitLab migration

[Wayne Stambaugh]

Hi Simon,

On 11/29/2019 1:09 PM, Simon Richter wrote:
> Hi Wayne,
> 
> On Fri, Nov 29, 2019 at 12:49:30PM -0500, Wayne Stambaugh wrote:
> 
>> I will also be disabling the Launchpad blueprint and answers pages as
>> well.  We not going to migrate the blueprints to GitLab because the
>> entire blueprint system is a mess due to the lack of sane permissions.
>> We may have to manually migrate the useful blueprints to GitLab once we
>> have a reasonable process for doing so.
> 
> One of my main hopes for the migration is to get a workflow for
> collaborative pre-implementation design. Blueprints were a nice idea, but
> they were never fully implemented on Launchpad, and it shows.

It was impossible to implement because anyone with a launchpad account
could create a blueprint and edit any other blueprint.  It was very
poorly implemented so it quickly became meaningless.

> 
> It'd probably make sense to use the Wiki for that, do you know if it is
> possible for non-committers to have limited Wiki editing rights (e.g. an
> "ideas" namespace with looser permissions, and moving the page to the
> "roadmap" namespace later)?

Maybe, but I would rather have a system that a few maintainers who will
ensure the sanity of the system that can edit "blueprints" and anyone
with a GitLab account can comment on but not modify.  Certainly anyone
on the mailing list can recommend a blueprint but it will in no way be
the wild west like the current blueprint system.

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

Re: [Kicad-developers] GitLab migration

[Simon Richter]

Hi Wayne,

On Fri, Nov 29, 2019 at 12:49:30PM -0500, Wayne Stambaugh wrote:

> I will also be disabling the Launchpad blueprint and answers pages as
> well.  We not going to migrate the blueprints to GitLab because the
> entire blueprint system is a mess due to the lack of sane permissions.
> We may have to manually migrate the useful blueprints to GitLab once we
> have a reasonable process for doing so.

One of my main hopes for the migration is to get a workflow for
collaborative pre-implementation design. Blueprints were a nice idea, but
they were never fully implemented on Launchpad, and it shows.

It'd probably make sense to use the Wiki for that, do you know if it is
possible for non-committers to have limited Wiki editing rights (e.g. an
"ideas" namespace with looser permissions, and moving the page to the
"roadmap" namespace later)?

   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

[Kicad-developers] GitLab migration

[Wayne Stambaugh]

In case you haven't been paying attention, KiCad is in the process of
migrating to GitLab.  This process will happen slowly starting with the
source repo and eventually culminating in all of the repos that KiCad
directly and indirectly depend on being migrated as well.

The first thing to migrate will be the source repo.  I plan on making
the current main repo read only tomorrow morning.  If you have anything
you wish to merge, please do so by tomorrow by 8AM EST.  I will make the
announcement when the change over is complete.

We are going to try out the merge request system provided by GitLab
instead of our current patch submission method.  The means that you need
to get a GitLab account if you do not already have one.  Any outstanding
patches and merger request should be resubmitted using GitLab.  In the
long run this will be less work for the lead devs so please be patient
while we work through this transition.

In the next few weeks the bug reporting system will be migrated to
GitLab so if you want to continue filing bug reports, you will have to
create a user account on GitLab if you do not already have one.  I will
make am announcement of the date that the Launchpad bug tracker will be
disabled and when you will be able to resume filing bug on GitLab.

I will also be disabling the Launchpad blueprint and answers pages as
well.  We not going to migrate the blueprints to GitLab because the
entire blueprint system is a mess due to the lack of sane permissions.
We may have to manually migrate the useful blueprints to GitLab once we
have a reasonable process for doing so.

One thing that will stay on Launchpad for the time being are the mailing
lists.  GitLab doesn't support mailing lists so we will continue using
the mailing lists we have set up on Launchpad  until there is a better
solution.

Thank you for your cooperation and patience during this transition.
Hopefully when the GitLab transition is complete, having the project
under a single hosting system will make life a little easier for the
lead dev team and project leader.

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

[Seth Hillbrand]

On 11/27/19 11:42 AM, Rene Pöschl wrote:

On 26/11/2019 21:54, Seth Hillbrand wrote:

On 2019-11-26 12:41, Jeff Young wrote:

OK, I’ve enabled 2FA.  Do I need to do something to get added back to
the project?  (When I go to members, all I see are the bot, Seth and
Wayne.)

Cheers,
Jeff.

Hi Jeff-

Wayne and the bot have permissions for the entire project.  I'm there
while sorting out the transition work.  Coding permissions are specific
to https://gitlab.com/kicad/code/ .  Library permissions are specific to
https://gitlab.com/kicad/libraries/ , etc.

If you'd like push permissions in libraries, you'll want to check with
Rene.  I think Nick or Marek will be managing the website section
(someone fill me in).  I'll also need to know who to assign to managing
the documentation section (Nick also?).  Once I get the packaging
section set up, we'll have folks in charge of their relative builds that
we can run through the GitLab CI runner interface.

-Seth



Hi,

well it seems i do not have access to the group either.


Hi Rene-

I've added you to the top-level group.  There is a sub-group called 
librarians where everyone goes but group permissions can only be 
assigned to repositories and not other groups (missed that part).


Let me know if anything else looks amiss.

I'm going to re-sync the repositories this weekend to see if we pick up 
any additional folks who are creating GitLab accounts.


-Seth


--
KiCad Services Corporation KiCad Services Corporation Logo
Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬ 
Davis, CA
www.kipro-pcb.com  i...@kipro-pcb.com 

https://twitter.com/KiProEDA  
https://www.linkedin.com/company/kicad 



___
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 Rene,

On 11/27/19 2:42 PM, Rene Pöschl wrote:
> On 26/11/2019 21:54, Seth Hillbrand wrote:
>> On 2019-11-26 12:41, Jeff Young wrote:
>>> OK, I’ve enabled 2FA.  Do I need to do something to get added back to
>>> the project?  (When I go to members, all I see are the bot, Seth and
>>> Wayne.)
>>>
>>> Cheers,
>>> Jeff.
>> Hi Jeff-
>>
>> Wayne and the bot have permissions for the entire project.  I'm there
>> while sorting out the transition work.  Coding permissions are specific
>> to https://gitlab.com/kicad/code/ .  Library permissions are specific to
>> https://gitlab.com/kicad/libraries/ , etc.
>>
>> If you'd like push permissions in libraries, you'll want to check with
>> Rene.  I think Nick or Marek will be managing the website section
>> (someone fill me in).  I'll also need to know who to assign to managing
>> the documentation section (Nick also?).  Once I get the packaging
>> section set up, we'll have folks in charge of their relative builds that
>> we can run through the GitLab CI runner interface.
>>
>> -Seth
>>
> 
> Hi,
> 
> well it seems i do not have access to the group either.
> 
> 
> As a sidenote, i am unable to use 2FA with my current phone (too old).
> 
> So i hope this is not a requirement for continuing to work for the kicad
> team.

I decided not to make 2FA mandatory.  It is more of an issue for source
contributors than it is for the library, doc, and translation contributors.

___
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

[Rene Pöschl]

On 26/11/2019 21:54, Seth Hillbrand wrote:

On 2019-11-26 12:41, Jeff Young wrote:

OK, I’ve enabled 2FA.  Do I need to do something to get added back to
the project?  (When I go to members, all I see are the bot, Seth and
Wayne.)

Cheers,
Jeff.

Hi Jeff-

Wayne and the bot have permissions for the entire project.  I'm there
while sorting out the transition work.  Coding permissions are specific
to https://gitlab.com/kicad/code/ .  Library permissions are specific to
https://gitlab.com/kicad/libraries/ , etc.

If you'd like push permissions in libraries, you'll want to check with
Rene.  I think Nick or Marek will be managing the website section
(someone fill me in).  I'll also need to know who to assign to managing
the documentation section (Nick also?).  Once I get the packaging
section set up, we'll have folks in charge of their relative builds that
we can run through the GitLab CI runner interface.

-Seth



Hi,

well it seems i do not have access to the group either.


As a sidenote, i am unable to use 2FA with my current phone (too old).

So i hope this is not a requirement for continuing to work for the kicad 
team.



___
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

[Seth Hillbrand]

On 2019-11-26 12:41, Jeff Young wrote:

OK, I’ve enabled 2FA.  Do I need to do something to get added back to
the project?  (When I go to members, all I see are the bot, Seth and
Wayne.)

Cheers,
Jeff.


Hi Jeff-

Wayne and the bot have permissions for the entire project.  I'm there 
while sorting out the transition work.  Coding permissions are specific 
to https://gitlab.com/kicad/code/ .  Library permissions are specific to 
https://gitlab.com/kicad/libraries/ , etc.


If you'd like push permissions in libraries, you'll want to check with 
Rene.  I think Nick or Marek will be managing the website section 
(someone fill me in).  I'll also need to know who to assign to managing 
the documentation section (Nick also?).  Once I get the packaging 
section set up, we'll have folks in charge of their relative builds that 
we can run through the GitLab CI runner interface.


-Seth

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

___
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

[Jeff Young]

OK, I’ve enabled 2FA.  Do I need to do something to get added back to the 
project?  (When I go to members, all I see are the bot, Seth and Wayne.)

Cheers,
Jeff.


> On 26 Nov 2019, at 19:36, Wayne Stambaugh  wrote:
> 
> While wearing my official project leader hat, I'm not going to force
> anyone to use 2FA but I suggest you do.  If you are unwilling to use
> 2FA, pleasing enable commit notifications for the main repo master and
> 5.1 branches.  I'm figuring if you get a commit notification in your
> name that you did not do, you will notify the lead dev team immediately
> so we can resolve it.
> 
> Cheers,
> 
> Wayne
> 
> On 11/26/19 8:13 AM, Jeff Young wrote:
>> Was there a resolution on the 2FA question?  (I used to have to use it for 
>> Adobe’s VPN and hated it, but it is what it is.)
>> 
>> I assume git merges will still go through SSH and not require 2FA either way?
>> 
>> Cheers,
>> Jeff.
>> ___
>> 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


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

While wearing my official project leader hat, I'm not going to force
anyone to use 2FA but I suggest you do.  If you are unwilling to use
2FA, pleasing enable commit notifications for the main repo master and
5.1 branches.  I'm figuring if you get a commit notification in your
name that you did not do, you will notify the lead dev team immediately
so we can resolve it.

Cheers,

Wayne

On 11/26/19 8:13 AM, Jeff Young wrote:
> Was there a resolution on the 2FA question?  (I used to have to use it for 
> Adobe’s VPN and hated it, but it is what it is.)
> 
> I assume git merges will still go through SSH and not require 2FA either way?
> 
> Cheers,
> Jeff.
> ___
> 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]

> I assume git merges will still go through SSH and not require 2FA either
way?

Yes, this just protects the account from third party remote compromise.

On Tue, Nov 26, 2019 at 8:13 AM Jeff Young  wrote:

> Was there a resolution on the 2FA question?  (I used to have to use it for
> Adobe’s VPN and hated it, but it is what it is.)
>
> I assume git merges will still go through SSH and not require 2FA either
> way?
>
> Cheers,
> Jeff.
> ___
> 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

[Jeff Young]

Was there a resolution on the 2FA question?  (I used to have to use it for 
Adobe’s VPN and hated it, but it is what it is.)

I assume git merges will still go through SSH and not require 2FA either way?

Cheers,
Jeff.
___
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

[Adam Wolf]

If providing the cheap U2F yubikeys to some folks on the dev team
would help this happen, please let me know.

Adam

On Mon, Nov 25, 2019 at 3:48 PM Jon Evans  wrote:
>
> While there are many forms of 2FA in the world, GitLab does not support all 
> of them.
> Currently, TOTP and U2F are the only supported methods [1]
>
> This means that if we enabled it, everyone with commit access would need 
> either a device running a TOTP-compliant program, or a U2F device such as a 
> YubiKey.
> There are desktop TOTP software options such as Authy, oathtool, and Gnome 
> Authenticator[2]
>
> [1] 
> https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html
> [2] https://gitlab.gnome.org/World/Authenticator
>
> On Mon, Nov 25, 2019 at 4:41 PM Andy Peters  wrote:
>>
>>
>> > On Nov 25, 2019, at 10:10 AM, jp charras  wrote:
>> >
>> > Le 25/11/2019 à 17:53, Kevin Cozens a écrit :
>> >> On 2019-11-25 11:03 a.m., Seth Hillbrand wrote:
>> >>> 2FA would be using something like Google Authenticator on your phone,
>> >>> a YubiKey or SMS message code to verify your login on a computer in
>> >>> addition to the password.
>> >>
>> >> It may not affect me as I'm a user of KiCad and occasional reporter of
>> >> bugs. What gitlab activities would require 2FA? Reading the link
>> >> supplied about 2FA says it would send a message to a phone. I don't
>> >> have, or want, a cell phone. How would requiring 2FA affect others
>> >> without a cell phone who want to use the gitlab repo site?
>> >>
>> >
>> > I am also like Kevin:
>> > I don't have, or want, a cell phone (or any Google account).
>> >
>> > A simple password is not perfect, but at least it is easy to use and
>> > works from any computer install.
>> > Kicad gitlab repo is for a FOSS development.
>> > It is not for Fort Knox access management.
>>
>> 2FA will work with an email address — this is how one of my banks does it. 
>> They send the code to the email address. It works, and isn’t too annoying, 
>> except when the mail servers are slow to respond.
>>
>> I prefer SMS to my iPhone, which when used with iMessages, the code sent to 
>> my iPhone goes to all of the devices connected to my iCloud account, and 
>> then magically Safari “knows” that the message was sent and offers to fill 
>> in the code.
>>
>> 2FA is going to be the way of the world as all banking and such move to it, 
>> at least until a better authentication mechanism comes along.
>> ___
>> 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

___
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

[Jon Evans]

While there are many forms of 2FA in the world, GitLab does not support all
of them.
Currently, TOTP and U2F are the only supported methods [1]

This means that if we enabled it, everyone with commit access would need
either a device running a TOTP-compliant program, or a U2F device such as a
YubiKey.
There are desktop TOTP software options such as Authy, oathtool, and Gnome
Authenticator[2]

[1]
https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html
[2] https://gitlab.gnome.org/World/Authenticator

On Mon, Nov 25, 2019 at 4:41 PM Andy Peters  wrote:

>
> > On Nov 25, 2019, at 10:10 AM, jp charras  wrote:
> >
> > Le 25/11/2019 à 17:53, Kevin Cozens a écrit :
> >> On 2019-11-25 11:03 a.m., Seth Hillbrand wrote:
> >>> 2FA would be using something like Google Authenticator on your phone,
> >>> a YubiKey or SMS message code to verify your login on a computer in
> >>> addition to the password.
> >>
> >> It may not affect me as I'm a user of KiCad and occasional reporter of
> >> bugs. What gitlab activities would require 2FA? Reading the link
> >> supplied about 2FA says it would send a message to a phone. I don't
> >> have, or want, a cell phone. How would requiring 2FA affect others
> >> without a cell phone who want to use the gitlab repo site?
> >>
> >
> > I am also like Kevin:
> > I don't have, or want, a cell phone (or any Google account).
> >
> > A simple password is not perfect, but at least it is easy to use and
> > works from any computer install.
> > Kicad gitlab repo is for a FOSS development.
> > It is not for Fort Knox access management.
>
> 2FA will work with an email address — this is how one of my banks does it.
> They send the code to the email address. It works, and isn’t too annoying,
> except when the mail servers are slow to respond.
>
> I prefer SMS to my iPhone, which when used with iMessages, the code sent
> to my iPhone goes to all of the devices connected to my iCloud account, and
> then magically Safari “knows” that the message was sent and offers to fill
> in the code.
>
> 2FA is going to be the way of the world as all banking and such move to
> it, at least until a better authentication mechanism comes along.
> ___
> 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

[Andy Peters]

> On Nov 25, 2019, at 10:10 AM, jp charras  wrote:
> 
> Le 25/11/2019 à 17:53, Kevin Cozens a écrit :
>> On 2019-11-25 11:03 a.m., Seth Hillbrand wrote:
>>> 2FA would be using something like Google Authenticator on your phone,
>>> a YubiKey or SMS message code to verify your login on a computer in
>>> addition to the password.
>> 
>> It may not affect me as I'm a user of KiCad and occasional reporter of
>> bugs. What gitlab activities would require 2FA? Reading the link
>> supplied about 2FA says it would send a message to a phone. I don't
>> have, or want, a cell phone. How would requiring 2FA affect others
>> without a cell phone who want to use the gitlab repo site?
>> 
> 
> I am also like Kevin:
> I don't have, or want, a cell phone (or any Google account).
> 
> A simple password is not perfect, but at least it is easy to use and
> works from any computer install.
> Kicad gitlab repo is for a FOSS development.
> It is not for Fort Knox access management.

2FA will work with an email address — this is how one of my banks does it. They 
send the code to the email address. It works, and isn’t too annoying, except 
when the mail servers are slow to respond.

I prefer SMS to my iPhone, which when used with iMessages, the code sent to my 
iPhone goes to all of the devices connected to my iCloud account, and then 
magically Safari “knows” that the message was sent and offers to fill in the 
code.

2FA is going to be the way of the world as all banking and such move to it, at 
least until a better authentication mechanism comes along.
___
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

[Eeli Kaikkonen]

ma 25. marrask. 2019 klo 20.11 Mark Roszko (mark.ros...@gmail.com)
kirjoitti:

> > I don't have, or want, a cell phone (or any Google account).
> You do not need a cell phone. You can use a computer based TOTP supporting
> authentication app such as Authy or FOSS KeePassXC (
> https://keepassxc.org/screenshots/)
>

It's also possible to use a USB dongle. A handy KiCad hacker makes one
him/herself, of course :)

https://support.google.com/accounts/answer/185839?co=GENIE.Platform%3DDesktop=en
https://www.tomsguide.com/us/make-2fa-key-shmoocon,news-24282.html
https://hackaday.com/tag/two-factor-authentication/

How about designing, making and selling KiCad 2fa dongles to support the
development? Releasing it as OSHW of course, like the one mentioned in the
tomsguide article.

Eeli Kaikkonen
___
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

[Bob Gustafson]

2FA can also use a normal land-line audio only telephone. The daemon at 
the other end just reads a code and you write it down. As secure (or 
more so) than a text message.


On 11/25/19 12:11 PM, Mark Roszko wrote:

> I don't have, or want, a cell phone (or any Google account).
You do not need a cell phone. You can use a computer based TOTP 
supporting authentication app such as Authy or FOSS KeePassXC 
(https://keepassxc.org/screenshots/)


> A simple password is not perfect, but at least it is easy to use and 
works from any computer install.


The problem with passwords is there's no way to force users to have 
unique passwords per website they made accounts for.


> Kicad gitlab repo is for a FOSS development.

And time and time again, FOSS software repos get hacked because 
somebody didn't have 2FA enabled and malicious code is injected 
stealthily.
It is a real security issue in the year 2019. Everything from desktop 
apps to 4 lines of code libraries in programming package libraries are 
high value targets and are at constant risk.



On Mon, Nov 25, 2019 at 12:11 PM jp charras > wrote:


Le 25/11/2019 à 17:53, Kevin Cozens a écrit :
> On 2019-11-25 11:03 a.m., Seth Hillbrand wrote:
>> 2FA would be using something like Google Authenticator on your
phone,
>> a YubiKey or SMS message code to verify your login on a computer in
>> addition to the password.
>
> It may not affect me as I'm a user of KiCad and occasional
reporter of
> bugs. What gitlab activities would require 2FA? Reading the link
> supplied about 2FA says it would send a message to a phone. I don't
> have, or want, a cell phone. How would requiring 2FA affect others
> without a cell phone who want to use the gitlab repo site?
>

I am also like Kevin:
I don't have, or want, a cell phone (or any Google account).

A simple password is not perfect, but at least it is easy to use and
works from any computer install.
Kicad gitlab repo is for a FOSS development.
It is not for Fort Knox access management.

-- 
Jean-Pierre CHARRAS


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

> I don't have, or want, a cell phone (or any Google account).
You do not need a cell phone. You can use a computer based TOTP supporting
authentication app such as Authy or FOSS KeePassXC (
https://keepassxc.org/screenshots/)

> A simple password is not perfect, but at least it is easy to use and
works from any computer install.

The problem with passwords is there's no way to force users to have unique
passwords per website they made accounts for.

> Kicad gitlab repo is for a FOSS development.

And time and time again, FOSS software repos get hacked because somebody
didn't have 2FA enabled and malicious code is injected stealthily.
It is a real security issue in the year 2019. Everything from desktop apps
to 4 lines of code libraries in programming package libraries are high
value targets and are at constant risk.


On Mon, Nov 25, 2019 at 12:11 PM jp charras  wrote:

> Le 25/11/2019 à 17:53, Kevin Cozens a écrit :
> > On 2019-11-25 11:03 a.m., Seth Hillbrand wrote:
> >> 2FA would be using something like Google Authenticator on your phone,
> >> a YubiKey or SMS message code to verify your login on a computer in
> >> addition to the password.
> >
> > It may not affect me as I'm a user of KiCad and occasional reporter of
> > bugs. What gitlab activities would require 2FA? Reading the link
> > supplied about 2FA says it would send a message to a phone. I don't
> > have, or want, a cell phone. How would requiring 2FA affect others
> > without a cell phone who want to use the gitlab repo site?
> >
>
> I am also like Kevin:
> I don't have, or want, a cell phone (or any Google account).
>
> A simple password is not perfect, but at least it is easy to use and
> works from any computer install.
> Kicad gitlab repo is for a FOSS development.
> It is not for Fort Knox access management.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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 11/25/19 12:10 PM, jp charras wrote:
> Le 25/11/2019 à 17:53, Kevin Cozens a écrit :
>> On 2019-11-25 11:03 a.m., Seth Hillbrand wrote:
>>> 2FA would be using something like Google Authenticator on your phone,
>>> a YubiKey or SMS message code to verify your login on a computer in
>>> addition to the password.
>>
>> It may not affect me as I'm a user of KiCad and occasional reporter of
>> bugs. What gitlab activities would require 2FA? Reading the link
>> supplied about 2FA says it would send a message to a phone. I don't
>> have, or want, a cell phone. How would requiring 2FA affect others
>> without a cell phone who want to use the gitlab repo site?
>>
> 
> I am also like Kevin:
> I don't have, or want, a cell phone (or any Google account).
> 
> A simple password is not perfect, but at least it is easy to use and
> works from any computer install.
> Kicad gitlab repo is for a FOSS development.
> It is not for Fort Knox access management.
> 

I'm not going to force anyone to do this so please use your best
judgment if you have commit access to the master repo.  For those of you
who are willing to use 2FA, please do so.  I already have my account set up.

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

[jp charras]

Le 25/11/2019 à 17:53, Kevin Cozens a écrit :
> On 2019-11-25 11:03 a.m., Seth Hillbrand wrote:
>> 2FA would be using something like Google Authenticator on your phone,
>> a YubiKey or SMS message code to verify your login on a computer in
>> addition to the password.
> 
> It may not affect me as I'm a user of KiCad and occasional reporter of
> bugs. What gitlab activities would require 2FA? Reading the link
> supplied about 2FA says it would send a message to a phone. I don't
> have, or want, a cell phone. How would requiring 2FA affect others
> without a cell phone who want to use the gitlab repo site?
> 

I am also like Kevin:
I don't have, or want, a cell phone (or any Google account).

A simple password is not perfect, but at least it is easy to use and
works from any computer install.
Kicad gitlab repo is for a FOSS development.
It is not for Fort Knox access management.

-- 
Jean-Pierre CHARRAS

___
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

[Kevin Cozens]

On 2019-11-25 11:03 a.m., Seth Hillbrand wrote:
2FA would be using something like Google Authenticator on your phone, a 
YubiKey or SMS message code to verify your login on a computer in addition 
to the password.


It may not affect me as I'm a user of KiCad and occasional reporter of bugs. 
What gitlab activities would require 2FA? Reading the link supplied about 
2FA says it would send a message to a phone. I don't have, or want, a cell 
phone. How would requiring 2FA affect others without a cell phone who want 
to use the gitlab repo site?


--
Cheers!

Kevin.

http://www.ve3syb.ca/   | "Nerds make the shiny things that
https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
| that's why we're powerful"
Owner of Elecraft K2 #2172  |
#include  | --Chris Hardwick

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

GitLab does send emails when SSH keys are added by default, but it's not
enough.
It's about GitLab (and even GitHub) allowing you to edit code right in the
web interface without needing to touch git.

But yes, GitLab does support 2FA. It is optional per account by default BUT
it can be mandated on a group like KiCad in the settings for anyone with
commit access to have enabled.



On Mon, Nov 25, 2019 at 11:13 AM Wayne Stambaugh 
wrote:

> On 11/25/19 11:03 AM, Seth Hillbrand wrote:
> > On 2019-11-25 06:08, Wayne Stambaugh wrote:
> >> Hi Mark,
> >>
> >> Do you mean using a GPG key?  I see the gitlab supports signed commits
> >> so would that be an adequate solution?  I'm fine with this, it's
> >> probably something we should be doing anyway.  Anyone else object to
> >> this?
> >>
> >
> > 2FA would be using something like Google Authenticator on your phone, a
> > YubiKey or SMS message code to verify your login on a computer in
> > addition to the password.
> >
> > The worry is that SSH keys can be added to a compromised account that
> > would allow an attacker to change the code/website/packages/etc.
>
> If gitlab supports this, I don't have an issue with it.  I don't see it
> as a major inconvenience.  I didn't look but I wonder if gitlab can be
> configured to send out alerts when your user account settings are changed.
>
> >
> > -S
> >
> > Seth Hillbrand
> > KiCad Services Corporation
> > https://www.kipro-pcb.com
> > +1 530 302 5483 | +1 212 603 9372
> >
> > ___
> > 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 11/25/19 11:03 AM, Seth Hillbrand wrote:
> On 2019-11-25 06:08, Wayne Stambaugh wrote:
>> Hi Mark,
>>
>> Do you mean using a GPG key?  I see the gitlab supports signed commits
>> so would that be an adequate solution?  I'm fine with this, it's
>> probably something we should be doing anyway.  Anyone else object to
>> this?
>>
> 
> 2FA would be using something like Google Authenticator on your phone, a
> YubiKey or SMS message code to verify your login on a computer in
> addition to the password.
> 
> The worry is that SSH keys can be added to a compromised account that
> would allow an attacker to change the code/website/packages/etc.

If gitlab supports this, I don't have an issue with it.  I don't see it
as a major inconvenience.  I didn't look but I wonder if gitlab can be
configured to send out alerts when your user account settings are changed.

> 
> -S
> 
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
> 
> ___
> 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

[Seth Hillbrand]

On 2019-11-25 06:08, Wayne Stambaugh wrote:

Hi Mark,

Do you mean using a GPG key?  I see the gitlab supports signed commits
so would that be an adequate solution?  I'm fine with this, it's
probably something we should be doing anyway.  Anyone else object to 
this?




2FA would be using something like Google Authenticator on your phone, a 
YubiKey or SMS message code to verify your login on a computer in 
addition to the password.


The worry is that SSH keys can be added to a compromised account that 
would allow an attacker to change the code/website/packages/etc.


-S

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

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

Mm, no, just two factor auth, this is not about signed commits.

man. 25. nov. 2019 15.09 skrev Wayne Stambaugh :

> Hi Mark,
>
> Do you mean using a GPG key?  I see the gitlab supports signed commits
> so would that be an adequate solution?  I'm fine with this, it's
> probably something we should be doing anyway.  Anyone else object to this?
>
> Cheers,
>
> Wayne
>
> On 11/24/19 4:13 PM, Mark Roszko wrote:
> > Can the use of 2FA be mandated across the entire group since we have a
> > fresh start?
> >
> > It's been killing me that it's not required for GitHub and it really is
> > a vulnerability to not enforce. KiCad is a decent value target for
> > malicious code placement since it is a desktop app.
> >
> >
> https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforcing-2fa-for-all-users-in-a-group
>
> >
> > On Tue, Nov 12, 2019 at 7:58 AM Wayne Stambaugh  > > wrote:
> >
> > Hey Orson,
> >
> > I'm on the fence on this one.  I remember similar issues when we
> > migrated from SourceForge.  It would be nice if we could migrate just
> > the bug reports that were fixed for 5.1 and later but I'm sure that
> is
> > not going to be possible because we did not do a great job in the
> past
> > of setting the bug report milestone.  This would at least make it
> > possible to search for bugs that have already been fixed in the
> current
> > stable branch without having to fall back to launchpad.  I'm not
> > concerned about closed bug reports for 5.0 and earlier since we no
> > longer support those branches.  We could migrate all the closed
> reports
> > with a milestone of 5.1.0 or later.  I know this wont be a complete
> > solution but it may be good enough.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 11/12/19 2:37 AM, Maciej Suminski wrote:
> > > Hi Andrew,
> > >
> > > I deliberately skipped the closed bugs, as I thought they do not
> carry
> > > much value, and they would still be available in the Launchpad
> > tracker.
> > > If majority prefers to migrate the closed bugs, then there is
> > nothing in
> > > the way.
> > >
> > > Cheers,
> > > Orson
> > >
> > > On 11/11/19 11:54 PM, Andrew Lutsenko wrote:
> > >> Is it possible to migrate closed bugs as well? I think gitlab
> search
> > >> indexing is much more useful, having history conserved there will
> > likely
> > >> be handy.
> > >>
> > >> On Mon, Nov 11, 2019 at 2:31 AM Maciej Suminski
> > mailto:maciej.sumin...@cern.ch>
> > >>  > >> wrote:
> > >>
> > >> Excellent, thanks for the verification! I have also checked a
> > few other
> > >> reports that had original authors incorrectly assigned, so I
> > believe the
> > >> bug has been fixed.
> > >>
> > >> Cheers,
> > >> Orson
> > >>
> > >> On 11/11/19 10:29 AM, Eeli Kaikkonen wrote:
> > >> > Now the example bug report ("Implicit 4-way junction" etc.)
> is
> > >> correctly
> > >> > attributed to "eelik".
> > >> >
> > >> > Eeli Kaikkonen
> > >> >
> > >> > su 10. marrask. 2019 klo 19.44 Maciej Suminski
> > >> (maciej.sumin...@cern.ch 
> > >
> > >> >  >   > >>)
> > >> kirjoitti:
> > >> >
> > >> > On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> > >> > > On 2019-11-10 08:43, Seth Hillbrand wrote:
> > >> > >
> > >> > >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> > >> > >>
> > >> > >>> OK. Would it be worth re-importing everything even
> for
> > >> this test
> > >> > database to avoid false impressions?
> > >> > >>>
> > >> > >>> Eeli Kaikkonen
> > >> > >>
> > >> > >> What false impression?  Is there a report that is
> > listed as
> > >> being
> > >> > created by different people in launchpad vs. GitLab?
> > >> > >
> > >> > > Oops.  Disregard.  I see a broken report here:
> > >> > >
> https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367
> > >> > >
> > >> > > Looks like the Launchpad API doesn't handle users who
> > have since
> > >> > deleted
> > >> > > their accounts nicely and the script is falling back
> > on Fabien's
> > >> > > account, probably because his is index 0.
> > >> >
> > >> > Good catch, thanks! I think I have already found the
> bug, I
> > >> will let you
> > >> >

Re: [Kicad-developers] GitLab migration

[Wayne Stambaugh]

Hi Mark,

Do you mean using a GPG key?  I see the gitlab supports signed commits
so would that be an adequate solution?  I'm fine with this, it's
probably something we should be doing anyway.  Anyone else object to this?

Cheers,

Wayne

On 11/24/19 4:13 PM, Mark Roszko wrote:
> Can the use of 2FA be mandated across the entire group since we have a
> fresh start?
> 
> It's been killing me that it's not required for GitHub and it really is
> a vulnerability to not enforce. KiCad is a decent value target for
> malicious code placement since it is a desktop app.
> 
> https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforcing-2fa-for-all-users-in-a-group
>   
> 
> On Tue, Nov 12, 2019 at 7:58 AM Wayne Stambaugh  > wrote:
> 
> Hey Orson,
> 
> I'm on the fence on this one.  I remember similar issues when we
> migrated from SourceForge.  It would be nice if we could migrate just
> the bug reports that were fixed for 5.1 and later but I'm sure that is
> not going to be possible because we did not do a great job in the past
> of setting the bug report milestone.  This would at least make it
> possible to search for bugs that have already been fixed in the current
> stable branch without having to fall back to launchpad.  I'm not
> concerned about closed bug reports for 5.0 and earlier since we no
> longer support those branches.  We could migrate all the closed reports
> with a milestone of 5.1.0 or later.  I know this wont be a complete
> solution but it may be good enough.
> 
> Cheers,
> 
> Wayne
> 
> On 11/12/19 2:37 AM, Maciej Suminski wrote:
> > Hi Andrew,
> >
> > I deliberately skipped the closed bugs, as I thought they do not carry
> > much value, and they would still be available in the Launchpad
> tracker.
> > If majority prefers to migrate the closed bugs, then there is
> nothing in
> > the way.
> >
> > Cheers,
> > Orson
> >
> > On 11/11/19 11:54 PM, Andrew Lutsenko wrote:
> >> Is it possible to migrate closed bugs as well? I think gitlab search
> >> indexing is much more useful, having history conserved there will
> likely
> >> be handy.
> >>
> >> On Mon, Nov 11, 2019 at 2:31 AM Maciej Suminski
> mailto:maciej.sumin...@cern.ch>
> >>  >> wrote:
> >>
> >>     Excellent, thanks for the verification! I have also checked a
> few other
> >>     reports that had original authors incorrectly assigned, so I
> believe the
> >>     bug has been fixed.
> >>
> >>     Cheers,
> >>     Orson
> >>
> >>     On 11/11/19 10:29 AM, Eeli Kaikkonen wrote:
> >>     > Now the example bug report ("Implicit 4-way junction" etc.) is
> >>     correctly
> >>     > attributed to "eelik".
> >>     >
> >>     > Eeli Kaikkonen
> >>     >
> >>     > su 10. marrask. 2019 klo 19.44 Maciej Suminski
> >>     (maciej.sumin...@cern.ch 
> >
> >>     >    >>)
> >>     kirjoitti:
> >>     >
> >>     >     On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> >>     >     > On 2019-11-10 08:43, Seth Hillbrand wrote:
> >>     >     >
> >>     >     >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> >>     >     >>
> >>     >     >>> OK. Would it be worth re-importing everything even for
> >>     this test
> >>     >     database to avoid false impressions?
> >>     >     >>>
> >>     >     >>> Eeli Kaikkonen
> >>     >     >>
> >>     >     >> What false impression?  Is there a report that is
> listed as
> >>     being
> >>     >     created by different people in launchpad vs. GitLab?
> >>     >     >
> >>     >     > Oops.  Disregard.  I see a broken report here:
> >>     >     > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367
> >>     >     >
> >>     >     > Looks like the Launchpad API doesn't handle users who
> have since
> >>     >     deleted
> >>     >     > their accounts nicely and the script is falling back
> on Fabien's
> >>     >     > account, probably because his is index 0.
> >>     >
> >>     >     Good catch, thanks! I think I have already found the bug, I
> >>     will let you
> >>     >     know after the next run is finished.
> >>     >
> >>     >     Cheers,
> >>     >     Orson
> >>     >
> >>     >     ___
> >>     >     Mailing list: https://launchpad.net/~kicad-developers
> >>     >     Post to     : kicad-developers@lists.launchpad.net
> 

Re: [Kicad-developers] GitLab migration

[Seth Hillbrand]

On 2019-11-24 13:13, Mark Roszko wrote:

Can the use of 2FA be mandated across the entire group since we have a 
fresh start?


It's been killing me that it's not required for GitHub and it really is 
a vulnerability to not enforce. KiCad is a decent value target for 
malicious code placement since it is a desktop app.


https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforcing-2fa-for-all-users-in-a-group



Hi Mark-

Can you open an issue for this in the transition repository[1]?  It 
makes sense to me but it would be good to track that in the transition 
in case other issues arise from it.


Best-
Seth


[1] https://gitlab.com/kicad_pcb/kicad_migration

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

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

Can the use of 2FA be mandated across the entire group since we have a
fresh start?

It's been killing me that it's not required for GitHub and it really is a
vulnerability to not enforce. KiCad is a decent value target for malicious
code placement since it is a desktop app.

https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforcing-2fa-for-all-users-in-a-group


On Tue, Nov 12, 2019 at 7:58 AM Wayne Stambaugh 
wrote:

> Hey Orson,
>
> I'm on the fence on this one.  I remember similar issues when we
> migrated from SourceForge.  It would be nice if we could migrate just
> the bug reports that were fixed for 5.1 and later but I'm sure that is
> not going to be possible because we did not do a great job in the past
> of setting the bug report milestone.  This would at least make it
> possible to search for bugs that have already been fixed in the current
> stable branch without having to fall back to launchpad.  I'm not
> concerned about closed bug reports for 5.0 and earlier since we no
> longer support those branches.  We could migrate all the closed reports
> with a milestone of 5.1.0 or later.  I know this wont be a complete
> solution but it may be good enough.
>
> Cheers,
>
> Wayne
>
> On 11/12/19 2:37 AM, Maciej Suminski wrote:
> > Hi Andrew,
> >
> > I deliberately skipped the closed bugs, as I thought they do not carry
> > much value, and they would still be available in the Launchpad tracker.
> > If majority prefers to migrate the closed bugs, then there is nothing in
> > the way.
> >
> > Cheers,
> > Orson
> >
> > On 11/11/19 11:54 PM, Andrew Lutsenko wrote:
> >> Is it possible to migrate closed bugs as well? I think gitlab search
> >> indexing is much more useful, having history conserved there will likely
> >> be handy.
> >>
> >> On Mon, Nov 11, 2019 at 2:31 AM Maciej Suminski <
> maciej.sumin...@cern.ch
> >> > wrote:
> >>
> >> Excellent, thanks for the verification! I have also checked a few
> other
> >> reports that had original authors incorrectly assigned, so I
> believe the
> >> bug has been fixed.
> >>
> >> Cheers,
> >> Orson
> >>
> >> On 11/11/19 10:29 AM, Eeli Kaikkonen wrote:
> >> > Now the example bug report ("Implicit 4-way junction" etc.) is
> >> correctly
> >> > attributed to "eelik".
> >> >
> >> > Eeli Kaikkonen
> >> >
> >> > su 10. marrask. 2019 klo 19.44 Maciej Suminski
> >> (maciej.sumin...@cern.ch 
> >> >  >>)
> >> kirjoitti:
> >> >
> >> > On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> >> > > On 2019-11-10 08:43, Seth Hillbrand wrote:
> >> > >
> >> > >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> >> > >>
> >> > >>> OK. Would it be worth re-importing everything even for
> >> this test
> >> > database to avoid false impressions?
> >> > >>>
> >> > >>> Eeli Kaikkonen
> >> > >>
> >> > >> What false impression?  Is there a report that is listed as
> >> being
> >> > created by different people in launchpad vs. GitLab?
> >> > >
> >> > > Oops.  Disregard.  I see a broken report here:
> >> > > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367
> >> > >
> >> > > Looks like the Launchpad API doesn't handle users who have
> since
> >> > deleted
> >> > > their accounts nicely and the script is falling back on
> Fabien's
> >> > > account, probably because his is index 0.
> >> >
> >> > Good catch, thanks! I think I have already found the bug, I
> >> will let you
> >> > know after the next run is finished.
> >> >
> >> > 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
> >> >
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> 

Re: [Kicad-developers] GitLab migration

[Wayne Stambaugh]

Hey Orson,

I'm on the fence on this one.  I remember similar issues when we
migrated from SourceForge.  It would be nice if we could migrate just
the bug reports that were fixed for 5.1 and later but I'm sure that is
not going to be possible because we did not do a great job in the past
of setting the bug report milestone.  This would at least make it
possible to search for bugs that have already been fixed in the current
stable branch without having to fall back to launchpad.  I'm not
concerned about closed bug reports for 5.0 and earlier since we no
longer support those branches.  We could migrate all the closed reports
with a milestone of 5.1.0 or later.  I know this wont be a complete
solution but it may be good enough.

Cheers,

Wayne

On 11/12/19 2:37 AM, Maciej Suminski wrote:
> Hi Andrew,
> 
> I deliberately skipped the closed bugs, as I thought they do not carry
> much value, and they would still be available in the Launchpad tracker.
> If majority prefers to migrate the closed bugs, then there is nothing in
> the way.
> 
> Cheers,
> Orson
> 
> On 11/11/19 11:54 PM, Andrew Lutsenko wrote:
>> Is it possible to migrate closed bugs as well? I think gitlab search
>> indexing is much more useful, having history conserved there will likely
>> be handy.
>>
>> On Mon, Nov 11, 2019 at 2:31 AM Maciej Suminski > > wrote:
>>
>> Excellent, thanks for the verification! I have also checked a few other
>> reports that had original authors incorrectly assigned, so I believe the
>> bug has been fixed.
>>
>> Cheers,
>> Orson
>>
>> On 11/11/19 10:29 AM, Eeli Kaikkonen wrote:
>> > Now the example bug report ("Implicit 4-way junction" etc.) is
>> correctly
>> > attributed to "eelik".
>> >
>> > Eeli Kaikkonen
>> >
>> > su 10. marrask. 2019 klo 19.44 Maciej Suminski
>> (maciej.sumin...@cern.ch 
>> > >)
>> kirjoitti:
>> >
>> >     On 11/10/19 5:54 PM, Seth Hillbrand wrote:
>> >     > On 2019-11-10 08:43, Seth Hillbrand wrote:
>> >     >
>> >     >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
>> >     >>
>> >     >>> OK. Would it be worth re-importing everything even for
>> this test
>> >     database to avoid false impressions?
>> >     >>>
>> >     >>> Eeli Kaikkonen
>> >     >>
>> >     >> What false impression?  Is there a report that is listed as
>> being
>> >     created by different people in launchpad vs. GitLab?
>> >     >
>> >     > Oops.  Disregard.  I see a broken report here:
>> >     > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367
>> >     >
>> >     > Looks like the Launchpad API doesn't handle users who have since
>> >     deleted
>> >     > their accounts nicely and the script is falling back on Fabien's
>> >     > account, probably because his is index 0.
>> >
>> >     Good catch, thanks! I think I have already found the bug, I
>> will let you
>> >     know after the next run is finished.
>> >
>> >     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
>> >
>>
>> ___
>> 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
> 

___
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

[Eeli Kaikkonen]

ti 12. marrask. 2019 klo 11.04 Andrew Lutsenko (anlutse...@gmail.com)
kirjoitti:

> I think there is value in having all the history in one place. Add to that
> much more efficient search utilities and looking up history a year later
> will be a lot easier if all of it is in gitlab and not split.
>
> Just my 2c.
>
> Andrew
>

Every now and then I try to search for old reports which have been fixed
and released. I may not remember if something has been reported and fixed,
or remember vaguely something related to some new bug. But not very far
back in time because I didn't live when 4.0.0 was released :) I can see
value in having for example all fixes for 5.1 series in the same place than
the active reports, but definitely not old v4 bugs and probably not v5.0.

Eeli Kaikkonen
___
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

[Jeff Young]

I’d definitely keep Fix Committed.

For Fix Released someone’s either going to try and find them from a plain-text 
search (which never worked for shit with Launchpad), or from a commit-message.  
The commit-message will just have the Launchpad number in it anyway, so they’re 
going to go to Launchpad for that.  

Still, plain-text searches would be nice (if they work better in GitLab), which 
might be a reason to migrate Fix Released bugs too….

> On 12 Nov 2019, at 10:32, Ian McInerney  wrote:
> 
> I think it makes sense to transfer the reports that are fix committed but not 
> fix released. That way we can have the entire v6 history attached to the new 
> milestone and more easily reference those reports in the future. Any that are 
> fix released we can leave on Launchpad.
> 
> -Ian
> 
> On Tue, Nov 12, 2019 at 9:04 AM Andrew Lutsenko  > wrote:
> I think there is value in having all the history in one place. Add to that 
> much more efficient search utilities and looking up history a year later will 
> be a lot easier if all of it is in gitlab and not split.
> 
> Just my 2c.
> 
> Andrew
> 
> On Tue, Nov 12, 2019 at 12:23 AM Maciej Suminski  > wrote:
> Hi Andrew,
> 
> I deliberately skipped the closed bugs, as I thought they do not carry
> much value, and they would still be available in the Launchpad tracker.
> If majority prefers to migrate the closed bugs, then there is nothing in
> the way.
> 
> Cheers,
> Orson
> 
> On 11/11/19 11:54 PM, Andrew Lutsenko wrote:
> > Is it possible to migrate closed bugs as well? I think gitlab search
> > indexing is much more useful, having history conserved there will likely
> > be handy.
> > 
> > On Mon, Nov 11, 2019 at 2:31 AM Maciej Suminski  > 
> > >> wrote:
> > 
> > Excellent, thanks for the verification! I have also checked a few other
> > reports that had original authors incorrectly assigned, so I believe the
> > bug has been fixed.
> > 
> > Cheers,
> > Orson
> > 
> > On 11/11/19 10:29 AM, Eeli Kaikkonen wrote:
> > > Now the example bug report ("Implicit 4-way junction" etc.) is
> > correctly
> > > attributed to "eelik".
> > >
> > > Eeli Kaikkonen
> > >
> > > su 10. marrask. 2019 klo 19.44 Maciej Suminski
> > (maciej.sumin...@cern.ch  
> > >
> > >  
> > >>)
> > kirjoitti:
> > >
> > > On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> > > > On 2019-11-10 08:43, Seth Hillbrand wrote:
> > > >
> > > >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> > > >>
> > > >>> OK. Would it be worth re-importing everything even for
> > this test
> > > database to avoid false impressions?
> > > >>>
> > > >>> Eeli Kaikkonen
> > > >>
> > > >> What false impression?  Is there a report that is listed as
> > being
> > > created by different people in launchpad vs. GitLab?
> > > >
> > > > Oops.  Disregard.  I see a broken report here:
> > > > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367 
> > 
> > > >
> > > > Looks like the Launchpad API doesn't handle users who have since
> > > deleted
> > > > their accounts nicely and the script is falling back on Fabien's
> > > > account, probably because his is index 0.
> > >
> > > Good catch, thanks! I think I have already found the bug, I
> > will let you
> > > know after the next run is finished.
> > >
> > > 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 
> > 

Re: [Kicad-developers] GitLab migration

[Ian McInerney]

I think it makes sense to transfer the reports that are fix committed but
not fix released. That way we can have the entire v6 history attached to
the new milestone and more easily reference those reports in the future.
Any that are fix released we can leave on Launchpad.

-Ian

On Tue, Nov 12, 2019 at 9:04 AM Andrew Lutsenko 
wrote:

> I think there is value in having all the history in one place. Add to that
> much more efficient search utilities and looking up history a year later
> will be a lot easier if all of it is in gitlab and not split.
>
> Just my 2c.
>
> Andrew
>
> On Tue, Nov 12, 2019 at 12:23 AM Maciej Suminski 
> wrote:
>
>> Hi Andrew,
>>
>> I deliberately skipped the closed bugs, as I thought they do not carry
>> much value, and they would still be available in the Launchpad tracker.
>> If majority prefers to migrate the closed bugs, then there is nothing in
>> the way.
>>
>> Cheers,
>> Orson
>>
>> On 11/11/19 11:54 PM, Andrew Lutsenko wrote:
>> > Is it possible to migrate closed bugs as well? I think gitlab search
>> > indexing is much more useful, having history conserved there will likely
>> > be handy.
>> >
>> > On Mon, Nov 11, 2019 at 2:31 AM Maciej Suminski <
>> maciej.sumin...@cern.ch
>> > > wrote:
>> >
>> > Excellent, thanks for the verification! I have also checked a few
>> other
>> > reports that had original authors incorrectly assigned, so I
>> believe the
>> > bug has been fixed.
>> >
>> > Cheers,
>> > Orson
>> >
>> > On 11/11/19 10:29 AM, Eeli Kaikkonen wrote:
>> > > Now the example bug report ("Implicit 4-way junction" etc.) is
>> > correctly
>> > > attributed to "eelik".
>> > >
>> > > Eeli Kaikkonen
>> > >
>> > > su 10. marrask. 2019 klo 19.44 Maciej Suminski
>> > (maciej.sumin...@cern.ch 
>> > > > >>)
>> > kirjoitti:
>> > >
>> > > On 11/10/19 5:54 PM, Seth Hillbrand wrote:
>> > > > On 2019-11-10 08:43, Seth Hillbrand wrote:
>> > > >
>> > > >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
>> > > >>
>> > > >>> OK. Would it be worth re-importing everything even for
>> > this test
>> > > database to avoid false impressions?
>> > > >>>
>> > > >>> Eeli Kaikkonen
>> > > >>
>> > > >> What false impression?  Is there a report that is listed as
>> > being
>> > > created by different people in launchpad vs. GitLab?
>> > > >
>> > > > Oops.  Disregard.  I see a broken report here:
>> > > > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367
>> > > >
>> > > > Looks like the Launchpad API doesn't handle users who have
>> since
>> > > deleted
>> > > > their accounts nicely and the script is falling back on
>> Fabien's
>> > > > account, probably because his is index 0.
>> > >
>> > > Good catch, thanks! I think I have already found the bug, I
>> > will let you
>> > > know after the next run is finished.
>> > >
>> > > 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
>> > >
>> >
>> > ___
>> > 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
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More 

Re: [Kicad-developers] GitLab migration

[Andrew Lutsenko]

I think there is value in having all the history in one place. Add to that
much more efficient search utilities and looking up history a year later
will be a lot easier if all of it is in gitlab and not split.

Just my 2c.

Andrew

On Tue, Nov 12, 2019 at 12:23 AM Maciej Suminski 
wrote:

> Hi Andrew,
>
> I deliberately skipped the closed bugs, as I thought they do not carry
> much value, and they would still be available in the Launchpad tracker.
> If majority prefers to migrate the closed bugs, then there is nothing in
> the way.
>
> Cheers,
> Orson
>
> On 11/11/19 11:54 PM, Andrew Lutsenko wrote:
> > Is it possible to migrate closed bugs as well? I think gitlab search
> > indexing is much more useful, having history conserved there will likely
> > be handy.
> >
> > On Mon, Nov 11, 2019 at 2:31 AM Maciej Suminski  > > wrote:
> >
> > Excellent, thanks for the verification! I have also checked a few
> other
> > reports that had original authors incorrectly assigned, so I believe
> the
> > bug has been fixed.
> >
> > Cheers,
> > Orson
> >
> > On 11/11/19 10:29 AM, Eeli Kaikkonen wrote:
> > > Now the example bug report ("Implicit 4-way junction" etc.) is
> > correctly
> > > attributed to "eelik".
> > >
> > > Eeli Kaikkonen
> > >
> > > su 10. marrask. 2019 klo 19.44 Maciej Suminski
> > (maciej.sumin...@cern.ch 
> > > >)
> > kirjoitti:
> > >
> > > On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> > > > On 2019-11-10 08:43, Seth Hillbrand wrote:
> > > >
> > > >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> > > >>
> > > >>> OK. Would it be worth re-importing everything even for
> > this test
> > > database to avoid false impressions?
> > > >>>
> > > >>> Eeli Kaikkonen
> > > >>
> > > >> What false impression?  Is there a report that is listed as
> > being
> > > created by different people in launchpad vs. GitLab?
> > > >
> > > > Oops.  Disregard.  I see a broken report here:
> > > > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367
> > > >
> > > > Looks like the Launchpad API doesn't handle users who have
> since
> > > deleted
> > > > their accounts nicely and the script is falling back on
> Fabien's
> > > > account, probably because his is index 0.
> > >
> > > Good catch, thanks! I think I have already found the bug, I
> > will let you
> > > know after the next run is finished.
> > >
> > > 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
> > >
> >
> > ___
> > 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
>
___
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]

Hi Andrew,

I deliberately skipped the closed bugs, as I thought they do not carry
much value, and they would still be available in the Launchpad tracker.
If majority prefers to migrate the closed bugs, then there is nothing in
the way.

Cheers,
Orson

On 11/11/19 11:54 PM, Andrew Lutsenko wrote:
> Is it possible to migrate closed bugs as well? I think gitlab search
> indexing is much more useful, having history conserved there will likely
> be handy.
> 
> On Mon, Nov 11, 2019 at 2:31 AM Maciej Suminski  > wrote:
> 
> Excellent, thanks for the verification! I have also checked a few other
> reports that had original authors incorrectly assigned, so I believe the
> bug has been fixed.
> 
> Cheers,
> Orson
> 
> On 11/11/19 10:29 AM, Eeli Kaikkonen wrote:
> > Now the example bug report ("Implicit 4-way junction" etc.) is
> correctly
> > attributed to "eelik".
> >
> > Eeli Kaikkonen
> >
> > su 10. marrask. 2019 klo 19.44 Maciej Suminski
> (maciej.sumin...@cern.ch 
> > >)
> kirjoitti:
> >
> >     On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> >     > On 2019-11-10 08:43, Seth Hillbrand wrote:
> >     >
> >     >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> >     >>
> >     >>> OK. Would it be worth re-importing everything even for
> this test
> >     database to avoid false impressions?
> >     >>>
> >     >>> Eeli Kaikkonen
> >     >>
> >     >> What false impression?  Is there a report that is listed as
> being
> >     created by different people in launchpad vs. GitLab?
> >     >
> >     > Oops.  Disregard.  I see a broken report here:
> >     > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367
> >     >
> >     > Looks like the Launchpad API doesn't handle users who have since
> >     deleted
> >     > their accounts nicely and the script is falling back on Fabien's
> >     > account, probably because his is index 0.
> >
> >     Good catch, thanks! I think I have already found the bug, I
> will let you
> >     know after the next run is finished.
> >
> >     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
> >
> 
> ___
> 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

[Andrew Lutsenko]

Is it possible to migrate closed bugs as well? I think gitlab search
indexing is much more useful, having history conserved there will likely be
handy.

On Mon, Nov 11, 2019 at 2:31 AM Maciej Suminski 
wrote:

> Excellent, thanks for the verification! I have also checked a few other
> reports that had original authors incorrectly assigned, so I believe the
> bug has been fixed.
>
> Cheers,
> Orson
>
> On 11/11/19 10:29 AM, Eeli Kaikkonen wrote:
> > Now the example bug report ("Implicit 4-way junction" etc.) is correctly
> > attributed to "eelik".
> >
> > Eeli Kaikkonen
> >
> > su 10. marrask. 2019 klo 19.44 Maciej Suminski (maciej.sumin...@cern.ch
> > ) kirjoitti:
> >
> > On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> > > On 2019-11-10 08:43, Seth Hillbrand wrote:
> > >
> > >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> > >>
> > >>> OK. Would it be worth re-importing everything even for this test
> > database to avoid false impressions?
> > >>>
> > >>> Eeli Kaikkonen
> > >>
> > >> What false impression?  Is there a report that is listed as being
> > created by different people in launchpad vs. GitLab?
> > >
> > > Oops.  Disregard.  I see a broken report here:
> > > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367
> > >
> > > Looks like the Launchpad API doesn't handle users who have since
> > deleted
> > > their accounts nicely and the script is falling back on Fabien's
> > > account, probably because his is index 0.
> >
> > Good catch, thanks! I think I have already found the bug, I will let
> you
> > know after the next run is finished.
> >
> > 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
> >
>
> ___
> 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

[Maciej Suminski]

Excellent, thanks for the verification! I have also checked a few other
reports that had original authors incorrectly assigned, so I believe the
bug has been fixed.

Cheers,
Orson

On 11/11/19 10:29 AM, Eeli Kaikkonen wrote:
> Now the example bug report ("Implicit 4-way junction" etc.) is correctly
> attributed to "eelik".
> 
> Eeli Kaikkonen
> 
> su 10. marrask. 2019 klo 19.44 Maciej Suminski (maciej.sumin...@cern.ch
> ) kirjoitti:
> 
> On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> > On 2019-11-10 08:43, Seth Hillbrand wrote:
> >
> >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> >>
> >>> OK. Would it be worth re-importing everything even for this test
> database to avoid false impressions?
> >>>
> >>> Eeli Kaikkonen
> >>
> >> What false impression?  Is there a report that is listed as being
> created by different people in launchpad vs. GitLab?
> >
> > Oops.  Disregard.  I see a broken report here:
> > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367
> >
> > Looks like the Launchpad API doesn't handle users who have since
> deleted
> > their accounts nicely and the script is falling back on Fabien's
> > account, probably because his is index 0.
> 
> Good catch, thanks! I think I have already found the bug, I will let you
> know after the next run is finished.
> 
> 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
> 

___
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

[Eeli Kaikkonen]

Now the example bug report ("Implicit 4-way junction" etc.) is correctly
attributed to "eelik".

Eeli Kaikkonen

su 10. marrask. 2019 klo 19.44 Maciej Suminski (maciej.sumin...@cern.ch)
kirjoitti:

> On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> > On 2019-11-10 08:43, Seth Hillbrand wrote:
> >
> >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> >>
> >>> OK. Would it be worth re-importing everything even for this test
> database to avoid false impressions?
> >>>
> >>> Eeli Kaikkonen
> >>
> >> What false impression?  Is there a report that is listed as being
> created by different people in launchpad vs. GitLab?
> >
> > Oops.  Disregard.  I see a broken report here:
> > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367
> >
> > Looks like the Launchpad API doesn't handle users who have since deleted
> > their accounts nicely and the script is falling back on Fabien's
> > account, probably because his is index 0.
>
> Good catch, thanks! I think I have already found the bug, I will let you
> know after the next run is finished.
>
> 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

[Wayne Stambaugh]

Please wait until the migration.  I will make an announcement and update
Lauchpad to disable the bug tracker and add a link to the main page that
we have moved to gitlab.  We are currently just testing the bug tracker
migration script.  There are still a few things that need to be ironed
out before we make the move.

Cheers,

Wayne

On 11/10/19 2:19 PM, Ian McInerney wrote:
> Simon,
> 
> Continue to use Launchpad for the time being. I don't believe we have
> officially created the KiCad repository yet, so all that is being done
> currently is testing leading up to the migration.
> 
> -Ian
> 
> On Sun, Nov 10, 2019 at 7:10 PM Simon Richter  > wrote:
> 
> Hi,
> 
> On Sun, Nov 10, 2019 at 06:43:33PM +0100, Maciej Suminski wrote:
> 
> > Good catch, thanks! I think I have already found the bug, I will
> let you
> > know after the next run is finished.
> 
> Quick question: if I have a new bug report, should I file it in LP or in
> gitlab or wait until migration is done?
> 
>    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
> 

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

Simon,

Continue to use Launchpad for the time being. I don't believe we have
officially created the KiCad repository yet, so all that is being done
currently is testing leading up to the migration.

-Ian

On Sun, Nov 10, 2019 at 7:10 PM Simon Richter 
wrote:

> Hi,
>
> On Sun, Nov 10, 2019 at 06:43:33PM +0100, Maciej Suminski wrote:
>
> > Good catch, thanks! I think I have already found the bug, I will let you
> > know after the next run is finished.
>
> Quick question: if I have a new bug report, should I file it in LP or in
> gitlab or wait until migration is done?
>
>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

Re: [Kicad-developers] GitLab migration

[Simon Richter]

Hi,

On Sun, Nov 10, 2019 at 06:43:33PM +0100, Maciej Suminski wrote:

> Good catch, thanks! I think I have already found the bug, I will let you
> know after the next run is finished.

Quick question: if I have a new bug report, should I file it in LP or in
gitlab or wait until migration is done?

   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

Re: [Kicad-developers] GitLab migration

[Maciej Suminski]

On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> On 2019-11-10 08:43, Seth Hillbrand wrote:
> 
>> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
>>
>>> OK. Would it be worth re-importing everything even for this test database 
>>> to avoid false impressions? 
>>>
>>> Eeli Kaikkonen
>>
>> What false impression?  Is there a report that is listed as being created by 
>> different people in launchpad vs. GitLab?
> 
> Oops.  Disregard.  I see a broken report here:
> https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367 
> 
> Looks like the Launchpad API doesn't handle users who have since deleted
> their accounts nicely and the script is falling back on Fabien's
> account, probably because his is index 0.

Good catch, thanks! I think I have already found the bug, I will let you
know after the next run is finished.

Cheers,
Orson



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

[Eeli Kaikkonen]

To make sure that we are talking about the same thing, here is indeed a bug
report originally written by me in launchpad but attributed to some Fabien
in this new database:
https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7600 (screenshot
attached in case you see it differently).


su 10. marrask. 2019 klo 18.52 Eeli Kaikkonen (eeli.kaikko...@gmail.com)
kirjoitti:

> I got a false impression that importing the bug database currently has
> some problem because those reports which I opened seemed to be written
> originally by some mysterious username, while the subsequent comments were
> correctly attributed. This led to me asking about it here. These kinds of
> false impressions of bugs in the importing process could be avoided if it
> was re-imported from scratch to create correct data (supposing that it was
> a bug which orson fixed and now works correctly).
>
> Eeli Kaikkonen
>
> su 10. marrask. 2019 klo 18.43 Seth Hillbrand (s...@kipro-pcb.com)
> kirjoitti:
>
>> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
>>
>> OK. Would it be worth re-importing everything even for this test database
>> to avoid false impressions?
>>
>> Eeli Kaikkonen
>>
>>
>> What false impression?  Is there a report that is listed as being created
>> by different people in launchpad vs. GitLab?
>>
>>
>> KiCad Services Corporation [image: KiCad Services Corporation Logo]
>> Seth Hillbrand
>> *Lead Developer*
>> +1-530-302-5483‬ <+12126039372>
>> Davis, CA
>> www.kipro-pcb.comi...@kipro-pcb.com
>> https://twitter.com/KiProEDA 
>> https://www.linkedin.com/company/kicad
>> 
>>
>
___
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

[Seth Hillbrand]

On 2019-11-10 08:43, Seth Hillbrand wrote:

> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> 
>> OK. Would it be worth re-importing everything even for this test database to 
>> avoid false impressions? 
>> 
>> Eeli Kaikkonen
> 
> What false impression?  Is there a report that is listed as being created by 
> different people in launchpad vs. GitLab?

Oops.  Disregard.  I see a broken report here:
https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367 

Looks like the Launchpad API doesn't handle users who have since deleted
their accounts nicely and the script is falling back on Fabien's
account, probably because his is index 0. 

-S 

KiCad Services Corporation 

Seth Hillbrand

LEAD DEVELOPER

+1-530-302-5483‬ [1]

Davis, CA

www.kipro-pcb.com [2]i...@kipro-pcb.com

https://twitter.com/KiProEDA [3]
https://www.linkedin.com/company/kicad [4]

 

Links:
--
[1] tel:+12126039372
[2] http://www.kipro-pcb.com/
[3] https://twitter.com/KiProEDA
[4] https://www.linkedin.com/company/kicad___
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

[Eeli Kaikkonen]

I got a false impression that importing the bug database currently has some
problem because those reports which I opened seemed to be written
originally by some mysterious username, while the subsequent comments were
correctly attributed. This led to me asking about it here. These kinds of
false impressions of bugs in the importing process could be avoided if it
was re-imported from scratch to create correct data (supposing that it was
a bug which orson fixed and now works correctly).

Eeli Kaikkonen

su 10. marrask. 2019 klo 18.43 Seth Hillbrand (s...@kipro-pcb.com)
kirjoitti:

> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
>
> OK. Would it be worth re-importing everything even for this test database
> to avoid false impressions?
>
> Eeli Kaikkonen
>
>
> What false impression?  Is there a report that is listed as being created
> by different people in launchpad vs. GitLab?
>
>
> KiCad Services Corporation [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ <+12126039372>
> Davis, CA
> www.kipro-pcb.comi...@kipro-pcb.com
> https://twitter.com/KiProEDA 
> https://www.linkedin.com/company/kicad
> 
>
___
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

[Seth Hillbrand]

On 2019-11-10 08:33, Eeli Kaikkonen wrote:

> OK. Would it be worth re-importing everything even for this test database to 
> avoid false impressions? 
> 
> Eeli Kaikkonen

What false impression?  Is there a report that is listed as being
created by different people in launchpad vs. GitLab? 

KiCad Services Corporation 

Seth Hillbrand

LEAD DEVELOPER

+1-530-302-5483‬ [1]

Davis, CA

www.kipro-pcb.com [2]i...@kipro-pcb.com

https://twitter.com/KiProEDA [3]
https://www.linkedin.com/company/kicad [4]

 

Links:
--
[1] tel:+12126039372
[2] http://www.kipro-pcb.com/
[3] https://twitter.com/KiProEDA
[4] https://www.linkedin.com/company/kicad___
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

[Eeli Kaikkonen]

OK. Would it be worth re-importing everything even for this test database
to avoid false impressions?

Eeli Kaikkonen

su 10. marrask. 2019 klo 18.27 Seth Hillbrand (s...@kipro-pcb.com)
kirjoitti:

> On 2019-11-10 08:17, Eeli Kaikkonen wrote:
>
> Who is this original reporter "Fabien Corona (drinasaur)" who created all
> the reports?
>
> Eeli Kaikkonen
>
>
>
> Not all of the reports.  Just a bunch of the recent ones prior to this
> import.  Here is one you created
> .
>
> Click on the "Original Report" to see the reporter information in
> launchpad.
>
> -Seth
>
>
> KiCad Services Corporation [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ <+12126039372>
> Davis, CA
> www.kipro-pcb.comi...@kipro-pcb.com
> https://twitter.com/KiProEDA 
> https://www.linkedin.com/company/kicad
> 
>
___
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

[Seth Hillbrand]

On 2019-11-10 08:17, Eeli Kaikkonen wrote:

> Who is this original reporter "Fabien Corona (drinasaur)" who created all the 
> reports? 
> 
> Eeli Kaikkonen

Not all of the reports.  Just a bunch of the recent ones prior to this
import.  Here is one you created [1]. 

Click on the "Original Report" to see the reporter information in
launchpad. 

-Seth 

KiCad Services Corporation 

Seth Hillbrand

LEAD DEVELOPER

+1-530-302-5483‬ [2]

Davis, CA

www.kipro-pcb.com [3]i...@kipro-pcb.com

https://twitter.com/KiProEDA [4]
https://www.linkedin.com/company/kicad [5]

 

Links:
--
[1] https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7100
[2] tel:+12126039372
[3] http://www.kipro-pcb.com/
[4] https://twitter.com/KiProEDA
[5] https://www.linkedin.com/company/kicad___
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

[Eeli Kaikkonen]

Who is this original reporter "Fabien Corona (drinasaur)" who created all
the reports?

Eeli Kaikkonen

su 10. marrask. 2019 klo 0.08 Maciej Suminski (maciej.sumin...@cern.ch)
kirjoitti:

> I have fixed all issues, taking into account the ones reported on the
> mailing list and Ian's 'Gitlab Issue Tracker Guidelines' [1]. In my
> opinion, the bug tracker is ready to be moved to Gitlab. You can check
> out the latest bug tracker migration in my test project [2].
>
> Cheers,
> Orson
>
> 1.
>
> https://docs.google.com/document/d/1GRFO6tIfecpg8tDjIJW8qHxv7cvp13t2GAgQf2zN254/edit?usp=sharing
> 2. https://gitlab.com/orsonmmz/kicad-bug-tracker/issues
>
___
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

[Andrew Lutsenko]

I second Seth's opinion, this is fantastic.
One suggestion: create a service account for the bot and name it something
self-evident like "Migration Bot" to avoid possible confusion about
authorship.

Regards,
Andrew

On Sat, Nov 9, 2019 at 2:40 PM Seth Hillbrand  wrote:

> On 2019-11-09 14:08, Maciej Suminski wrote:
> > I have fixed all issues, taking into account the ones reported on the
> > mailing list and Ian's 'Gitlab Issue Tracker Guidelines' [1]. In my
> > opinion, the bug tracker is ready to be moved to Gitlab. You can check
> > out the latest bug tracker migration in my test project [2].
> >
> > Cheers,
> > Orson
> >
> > 1.
> >
> https://docs.google.com/document/d/1GRFO6tIfecpg8tDjIJW8qHxv7cvp13t2GAgQf2zN254/edit?usp=sharing
> > 2. https://gitlab.com/orsonmmz/kicad-bug-tracker/issues
> >
>
> Orson, this is fantastic.  Thanks for working through all of this.
>
> I can't overstate how much better this feels.  Images inline, great
> search options.  I have a marked todo list with highlighted issues in
> the toolbar.  No more digging through three layers of clicks and options
> to find the search features.  Amazing.
>
> Hopefully we can up with a timeline to move work over to the new system.
>   I didn't see any stoppers with the current setup.
>
> I suppose that our next step is to mirror the repository to GitLab under
> the KiCad account.  Did we ever resolve who controls the "KiCad"
> username on GitLab?
>
> Best-
> Seth
>
>
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
>
> ___
> 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

[Seth Hillbrand]

On 2019-11-09 14:08, Maciej Suminski wrote:

I have fixed all issues, taking into account the ones reported on the
mailing list and Ian's 'Gitlab Issue Tracker Guidelines' [1]. In my
opinion, the bug tracker is ready to be moved to Gitlab. You can check
out the latest bug tracker migration in my test project [2].

Cheers,
Orson

1.
https://docs.google.com/document/d/1GRFO6tIfecpg8tDjIJW8qHxv7cvp13t2GAgQf2zN254/edit?usp=sharing
2. https://gitlab.com/orsonmmz/kicad-bug-tracker/issues



Orson, this is fantastic.  Thanks for working through all of this.

I can't overstate how much better this feels.  Images inline, great 
search options.  I have a marked todo list with highlighted issues in 
the toolbar.  No more digging through three layers of clicks and options 
to find the search features.  Amazing.


Hopefully we can up with a timeline to move work over to the new system. 
 I didn't see any stoppers with the current setup.


I suppose that our next step is to mirror the repository to GitLab under 
the KiCad account.  Did we ever resolve who controls the "KiCad" 
username on GitLab?


Best-
Seth


Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

___
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 fixed all issues, taking into account the ones reported on the
mailing list and Ian's 'Gitlab Issue Tracker Guidelines' [1]. In my
opinion, the bug tracker is ready to be moved to Gitlab. You can check
out the latest bug tracker migration in my test project [2].

Cheers,
Orson

1.
https://docs.google.com/document/d/1GRFO6tIfecpg8tDjIJW8qHxv7cvp13t2GAgQf2zN254/edit?usp=sharing
2. https://gitlab.com/orsonmmz/kicad-bug-tracker/issues

On 10/15/19 12:52 AM, 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
> 



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

[Maciej Suminski]

Hi,

Thank you both for the input.

On 10/15/19 1:28 AM, Seth Hillbrand wrote:
> 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.

Good catch, I have not noticed the issue. I hope Gitlab has not flooded
you with notification mails, I am sorry if that happened.
I will escape the user names, I guess there is no advantage in replacing
the user names during the migration.

>> 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.

Agreed, scoped labels seems like a perfect match that I was not aware of.

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.

Given we are going to use scoped labels to indicate the priority, I do
not mind mapping heat to weight. I think a closer match is up- and
down-voting, but it is not something that I can modify with API, so
let's stick to the weight attribute.

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

Ian has also another idea, I will test both and pick one that looks
better (IMHO;).

Cheers,
Orson

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



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

[Jon Evans]

Also some interesting discussion on Hacker News[1]
Keep in mind that GitLab as a company is quite unique in that they are 100%
remote and employ people distributed globally in many different cultures.
Whether or how GitLab employees discuss politics at work (necessarily, via
electronic communications that presumably are logged and might be published
later for some reason) is probably a different question than the case with
a more traditional company where employees can meet face-to-face and
discuss whatever they want without a permanent record.

[1] https://news.ycombinator.com/item?id=21274511

On Thu, Oct 17, 2019 at 9:44 AM Wayne Stambaugh 
wrote:

> On 10/17/19 6:49 AM, Marco Ciampa wrote:
> > On Wed, Oct 09, 2019 at 12:36:25PM -0400, Wayne Stambaugh wrote:
> >> The lead development team has been discussing migrating the KiCad
> >> project to GitLab[1]. [...]
> >
> > Are you aware of this?:
> >
> > https://www.theregister.co.uk/2019/10/16/gitlab_employees_gagged/
>
> Yes.  It's already been Slashdotted[1].  I haven't had time to read
> anything about it other than the headline so I am woefully uninformed to
> discuss it intelligently.
>
>
> https://politics.slashdot.org/story/19/10/16/2225242/gitlab-wont-exclude-customers-on-moral-grounds-says-that-employees-should-not-discuss-politics-at-work
>
> >
> > --
> >
> > Best regards,
> > Marco Ciampa
> >
> > I know a joke about UDP, but you might not get it.
> >
> > 
> >
> >  GNU/Linux User #78271
> >  FSFE fellow #364
> >
> > 
>
> ___
> 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

[Wayne Stambaugh]

On 10/17/19 6:49 AM, Marco Ciampa wrote:
> On Wed, Oct 09, 2019 at 12:36:25PM -0400, Wayne Stambaugh wrote:
>> The lead development team has been discussing migrating the KiCad
>> project to GitLab[1]. [...]
> 
> Are you aware of this?:
> 
> https://www.theregister.co.uk/2019/10/16/gitlab_employees_gagged/

Yes.  It's already been Slashdotted[1].  I haven't had time to read
anything about it other than the headline so I am woefully uninformed to
discuss it intelligently.

https://politics.slashdot.org/story/19/10/16/2225242/gitlab-wont-exclude-customers-on-moral-grounds-says-that-employees-should-not-discuss-politics-at-work

> 
> --
> 
> Best regards,
> Marco Ciampa
> 
> I know a joke about UDP, but you might not get it.
> 
> 
> 
>  GNU/Linux User #78271
>  FSFE fellow #364
> 
> 

___
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

[Eeli Kaikkonen]

to 17. lokak. 2019 klo 13.49 Marco Ciampa (ciam...@posteo.net) kirjoitti:

> Are you aware of this?:
>
> https://www.theregister.co.uk/2019/10/16/gitlab_employees_gagged/
>
>
Those kind of disputes, negative and positive discrimination and the
current global mindset of even mass-harrassing people and organizations who
don't take a stance in those disputes make me tired. Would you like to see
this list to turn into a political forum? Would you say "no" to people who
would start talking politics here? Or should the KiCad licence have an
exclusive exception for the users who you deem to be immoral? (Open Source
or Free licences can't have such exceptions.)

I'm interested in KiCad, not second-degree separation.
( “Second-degree separation means that if you find someone whom you think
is theologically or ethically compromised, you must separate from that
person, as well as from other people who have not separated from the first
individual.” —John Woodbridge )

I'll stop here (otherwise I would contradict myself, if I haven't
contradicted already).

Eeli Kaikkonen
___
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

[Marco Ciampa]

On Wed, Oct 09, 2019 at 12:36:25PM -0400, Wayne Stambaugh wrote:
> The lead development team has been discussing migrating the KiCad
> project to GitLab[1]. [...]

Are you aware of this?:

https://www.theregister.co.uk/2019/10/16/gitlab_employees_gagged/

--

Best regards,
Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




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

It looks like part of the formatting issue is related to the fact that the
migrated issues have a line in between each entry in the version
information. What seems to produce the best results is to simply wrap the
copied version text from KiCad inside ``` ```, take a look at this sample
[1]. I think the best way to implement this would be to take advantage of
the issue templates [2], to give the user a pre-made style to fill in. See
[3] for an example that I threw together. We might also be able to use this
to automatically tag the issue with initial labels when it is created. I
haven't tested that though, so I am unsure of the permissions needed to
modify the labels (in one place it looks like normal users can't do that,
but quite a few projects have the labels included in their default
template). If someone wants to try creating an issue in that repository to
see if the labels are added that would be appreciated.


[1] https://gitlab.com/imcinerney/bugtracker-test/issues/3
[2] https://gitlab.com/help/user/project/description_templates
[3] https://gitlab.com/imcinerney/bugtracker-test/issues/new?issue

-Ian

On Tue, Oct 15, 2019 at 12:28 AM Seth Hillbrand  wrote:

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


-- 
Ian McInerney
mcians...@gmail.com

No electrons were harmed in the making of this message
___
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

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

Re: [Kicad-developers] GitLab migration

[Eeli Kaikkonen]

su 13. lokak. 2019 klo 4.10 Strontium (strnty...@gmail.com) kirjoitti:

> My 2c
>
> "As Designed" should be the only answer.

[...]

> "Invalid" and "Not a Bug" cut off continued dialogue
> and look dogmatic/arrogant.
>

On the other hand I have reported situations which I couldn't reproduce
later. The "bug" description didn't actually describe KiCad's behavior. In
that case Not a Bug would be more accurate. "As Designed" would be accurate
where the bug description actually descibes the behavior, but it's intented.

"Triaged" really isn't good. Launchpad explanation list have these
descriptions:

- > Confirmed: Verified by someone other than the reporter.
- > Triaged: Verified by the bug supervisor.

But "verified" isn't a good word for wishlist items, and who is a "bug
supervisor"?

Instead there could be something like "accepted, but not planned" for
wishlist items which would mean that the (core) developers or people who
can otherwise decide what is basically acceptable have accepted the basic
idea and if someone - possibly a new developer - wants to implement it, it
could be done (at least after further detailed discussion). It would imply
that it has so low priority that it probably won't be implemented by the
current development team, although anyone can take it under work later.

That would give positive and meaningful signal for the reporter and for
potential implementors: yes, a good idea, and if you want to implement it,
it's safe to go on.

Eeli Kaikkonen
___
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

[Andrew Lutsenko]

Agreed.
Another equivalent common term in the industry is WAI or "works as
intended".

Andrew

On Sat, Oct 12, 2019 at 6:10 PM Strontium  wrote:

> My 2c
>
> "As Designed" should be the only answer.  Bug is subjective.  If the
> user thinks the designed behaviour is
> broken then they will always think of it as a bug.  Invalid is worse,
> because yes it tells the user they are an idiot.
>
> Even if the program is working "As Designed" it does not mean its
> fantastic, or couldn't be improved, also saying "as designed" does not
> make any comment about the person logging the report (The other two
> do).  If someone spends a reasonable amount of time filling out a bug
> report, then there may be work needed to an area even if it is working
> "As Designed". Marking it "As Designed" would allow the conversation to
> continue about what specifically regarding the "As Designed" behaviour
> is problematic.  "Invalid" and "Not a Bug" cut off continued dialogue
> and look dogmatic/arrogant.
>
> Steven
>
> On 12/10/19 9:36 pm, Jeff Young wrote:
> > The main thing I didn’t like in the Launchpad workflow was the “Invalid”
> tag.  After one of our users spends a lot of time (or even a little)
> logging a bug, it often gets their back up if you mark it “invalid”.
> >
> > (In the past I’ve used systems that labelled this either “Not a Bug” or
> “As Designed”.  The later is probably the least triggering.)
> >
> > Cheers,
> > Jeff.
> >
> >
> >> On 12 Oct 2019, at 10:57, Nick Østergaard  wrote:
> >>
> >> The document is still open for comments on
> >>
> https://docs.google.com/document/d/1pRcqXIXSn1_Ep2mYtSnoJWFahi9fMx4UJ8UEwFFwLkQ/edit?usp=sharing
> >>
> >> On Thu, 10 Oct 2019 at 11:30, 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 <
> 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
> >> ___
> >> 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
>
>
>
> ___
> 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

[Strontium]

My 2c

"As Designed" should be the only answer.  Bug is subjective.  If the 
user thinks the designed behaviour is
broken then they will always think of it as a bug.  Invalid is worse, 
because yes it tells the user they are an idiot.


Even if the program is working "As Designed" it does not mean its 
fantastic, or couldn't be improved, also saying "as designed" does not 
make any comment about the person logging the report (The other two 
do).  If someone spends a reasonable amount of time filling out a bug 
report, then there may be work needed to an area even if it is working 
"As Designed". Marking it "As Designed" would allow the conversation to 
continue about what specifically regarding the "As Designed" behaviour 
is problematic.  "Invalid" and "Not a Bug" cut off continued dialogue 
and look dogmatic/arrogant.


Steven

On 12/10/19 9:36 pm, Jeff Young wrote:

The main thing I didn’t like in the Launchpad workflow was the “Invalid” tag.  
After one of our users spends a lot of time (or even a little) logging a bug, 
it often gets their back up if you mark it “invalid”.

(In the past I’ve used systems that labelled this either “Not a Bug” or “As 
Designed”.  The later is probably the least triggering.)

Cheers,
Jeff.



On 12 Oct 2019, at 10:57, Nick Østergaard  wrote:

The document is still open for comments on
https://docs.google.com/document/d/1pRcqXIXSn1_Ep2mYtSnoJWFahi9fMx4UJ8UEwFFwLkQ/edit?usp=sharing

On Thu, 10 Oct 2019 at 11:30, 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

___
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




___
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

[Jeff Young]

The main thing I didn’t like in the Launchpad workflow was the “Invalid” tag.  
After one of our users spends a lot of time (or even a little) logging a bug, 
it often gets their back up if you mark it “invalid”.

(In the past I’ve used systems that labelled this either “Not a Bug” or “As 
Designed”.  The later is probably the least triggering.)

Cheers,
Jeff.


> On 12 Oct 2019, at 10:57, Nick Østergaard  wrote:
> 
> The document is still open for comments on
> https://docs.google.com/document/d/1pRcqXIXSn1_Ep2mYtSnoJWFahi9fMx4UJ8UEwFFwLkQ/edit?usp=sharing
> 
> On Thu, 10 Oct 2019 at 11:30, 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
> 
> ___
> 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

[Nick Østergaard]

The document is still open for comments on
https://docs.google.com/document/d/1pRcqXIXSn1_Ep2mYtSnoJWFahi9fMx4UJ8UEwFFwLkQ/edit?usp=sharing

On Thu, 10 Oct 2019 at 11:30, 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

___
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 

Re: [Kicad-developers] GitLab migration

[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  >> > > 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
> >> > term.  We can always migrate the mailing list at a later date or
> use
> >> > some other communication tool such as discourse.
> >> >
> >> > Further down the road, I would like 

Re: [Kicad-developers] GitLab migration

[Adam Wolf]

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 > > > 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
>> > term.  We can always migrate the mailing list at a later date or use
>> > some other communication tool such as discourse.
>> >
>> > Further down the road, I would like to see all of the KiCad source 
>> > repos
>> > including the library, documentation, website, and translation repos
>> > migrated to GitLab as well.  It would make my life a lot easier from a
>> > project management perspective if they were all in the same place.  I
>> > expect there to be some resistance to using a source code version tool
>> > but I'm hoping folks will see this as a beneficial move.  I'm not
>> > terribly familiar with GitLab but I suspect it's not that 

Re: [Kicad-developers] GitLab migration

[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  > > 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
> > term.  We can always migrate the mailing list at a later date or use
> > some other communication tool such as discourse.
> >
> > Further down the road, I would like to see all of the KiCad source
> repos
> > including the library, documentation, website, and translation repos
> > migrated to GitLab as well.  It would make my life a lot easier from
> a
> > project management perspective if they were all in the same place.  I
> > expect there to be some resistance to using a source code version
> tool
> > but I'm hoping folks will see this as a beneficial move.  I'm not
> > terribly familiar with GitLab but I suspect it's not that much
> different
> > than GitHub as a hosting platform so I don't expect there to be a
> very
> > steep learning curve.  If you have any concerns, now is the time to
> > speak up or forever hold your peace.
> >
> > Cheers,
> >
> > Wayne
> >
> > [1]: 

Re: [Kicad-developers] GitLab migration

[Wayne Stambaugh]

On 10/9/19 4:26 PM, Nick Østergaard wrote:
> On Wed, 9 Oct 2019 at 18:36, Wayne Stambaugh  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.
> 
> Why do we need to freeze it? I suggest we do this in incremental
> steps. I mean, a git repo is a git repo. It can easily be mirrored, we
> just need to make sure that changes are pushed to only one. We can
> start just mirroring to gitlab to play around a bit. Migration of
> bugtracker and some CI.

I don't want anyone pushing to this repo similar to the mirror we have
on github.  Making the launchpad repo a mirror is fine.

> 
>> * Disable the Launcpad bug tracker.
> 
> Isn't this a bit drastic? Shouldn't we investigate import of the
> current launchpad bug tracker into gitlab?

As I stated below, if we can automate the process that would be ideal.
If you weren't around for the transition from sourceforge to lauchpad,
you would know that this is not too drastic.  I want to avoid new bug
reports being filed on launchpad once we make the move to gitlab.
Dealing with two hosting services at the same time creates extra work
that I would rather not deal with if I can avoid it.

> 
>> * 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
>> term.  We can always migrate the mailing list at a later date or use
>> some other communication tool such as discourse.
>>
>> Further down the road, I would like to see all of the KiCad source repos
>> including the library, documentation, website, and translation repos
>> migrated to GitLab as well.  It would make my life a lot easier from a
>> project management perspective if they were all in the same place.  I
>> expect there to be some resistance to using a source code version tool
>> but I'm hoping folks will see this as a beneficial move.
> 
> What do you mean with that last sentence?

There are always folks who are resistance to any changes.  Obviously we
are still using git as our vcs but the UX of gitlab is different than
github so there will be a learning curve.

> 
>> I'm not
>> terribly familiar with GitLab but I suspect it's not that much different
>> than GitHub as a hosting platform so I don't expect there to be a very
>> steep learning curve.  If you have any concerns, now is the time to
>> speak up or forever hold your peace.
>>
> 
> Are we going to use the merge requests actively or the mailing list?
> It should be fairly easy to set up some simple CI for the patches, but
> I really think we need to set this up before any move.
> 
> It seems that I am the owner of https://gitlab.com/kicad_eda  FWIW.
> 
>> Cheers,
>>
>> Wayne
>>
>> [1]: https://gitlab.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

___
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/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  > 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
> term.  We can always migrate the mailing list at a later date or use
> some other communication tool such as discourse.
> 
> Further down the road, I would like to see all of the KiCad source repos
> including the library, documentation, website, and translation repos
> migrated to GitLab as well.  It would make my life a lot easier from a
> project management perspective if they were all in the same place.  I
> expect there to be some resistance to using a source code version tool
> but I'm hoping folks will see this as a beneficial move.  I'm not
> terribly familiar with GitLab but I suspect it's not that much different
> than GitHub as a hosting platform so I don't expect there to be a very
> steep learning curve.  If you have any concerns, now is the time to
> speak up or forever hold your peace.
> 
> Cheers,
> 
> Wayne
> 
> [1]: https://gitlab.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
> 
> 
> 
> -- 
> 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

[Ian McInerney]

On Wed, Oct 9, 2019 at 10:28 PM Nick Østergaard  wrote:

> On Wed, 9 Oct 2019 at 18:36, Wayne Stambaugh  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.
>
> Why do we need to freeze it? I suggest we do this in incremental
> steps. I mean, a git repo is a git repo. It can easily be mirrored, we
> just need to make sure that changes are pushed to only one. We can
> start just mirroring to gitlab to play around a bit. Migration of
> bugtracker and some CI.
>
> > * Disable the Launcpad bug tracker.
>
> Isn't this a bit drastic? Shouldn't we investigate import of the
> current launchpad bug tracker into gitlab?
>

>From some cursory reading, it seems that this may be somewhat painful.
There is no direct import of the issue tracker to GitLab unfortunately (it
was requested though: https://gitlab.com/gitlab-org/gitlab/issues/22600),
so it will require a custom solution and also we would lose the user
information from all the reports and comments. It seems that other projects
have just left the existing tracker on Launchpad and used GitLab for only
new reports (such as Inkscape, which seems to have made the jump in 2017).
Inkscape did write a little script for doing this transition (
https://github.com/Moini/lpout), but I don't know if it would still work.
Splitting the issues is definitely less than ideal though.


>
> > * 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
> > term.  We can always migrate the mailing list at a later date or use
> > some other communication tool such as discourse.
> >
> > Further down the road, I would like to see all of the KiCad source repos
> > including the library, documentation, website, and translation repos
> > migrated to GitLab as well.  It would make my life a lot easier from a
> > project management perspective if they were all in the same place.  I
> > expect there to be some resistance to using a source code version tool
> > but I'm hoping folks will see this as a beneficial move.
>
> What do you mean with that last sentence?
>
> > I'm not
> > terribly familiar with GitLab but I suspect it's not that much different
> > than GitHub as a hosting platform so I don't expect there to be a very
> > steep learning curve.  If you have any concerns, now is the time to
> > speak up or forever hold your peace.
> >
>
> Are we going to use the merge requests actively or the mailing list?
> It should be fairly easy to set up some simple CI for the patches, but
> I really think we need to set this up before any move.
>

I would love to use the merge requests rather than the mailing list for
patches, and I think that is one of the major advantages of GitLab over
Launchpad (the Launchpad merge interface was definitely not the best UX).


>
> It seems that I am the owner of https://gitlab.com/kicad_eda  FWIW.
>
> > Cheers,
> >
> > Wayne
> >
> > [1]: https://gitlab.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
>
> ___
> 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

[Wayne Stambaugh]

On 10/9/19 1:55 PM, Andy Peters wrote:
> 
>> On Oct 9, 2019, at 9:36 AM, Wayne Stambaugh  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 presume that the developers and other interested parties will need to 
> create accounts on GitLab?
> 
> -a

I don't see how you could avoid creating GitLab account.  You can use
your github, google, etc. credentials to log into gitlab if you prefer.

___
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

[Carsten Schoenert]

Hi!

Am 09.10.19 um 20:45 schrieb Steven A. Falco:
> On 10/9/19 12:36 PM, Wayne Stambaugh wrote:
>> The lead development team has been discussing migrating the KiCad
>> project to GitLab[1].
> 
> For packagers, I'm curious as to how creating an archive from a tag
> would work.  Currently, to grab the source from launchpad, we use a
> URL like:>
> https://launchpad.net/kicad/5.0/%{version}/+download/kicad-%{version}.tar.xz
> 
> where %{version} is a Fedora macro that expands to the desired
> version.  This apparently works because Wayne explicitly uploads the
> tarball to launchpad.>
> For github, we use:
> 
> https://github.com/KiCad/kicad-doc/archive/%{version}.tar.gz
> 
> This works because github has an API that creates the tarball on-demand.
> 
> I found some references regarding how this works in GitLab.  For
> example, please see Issue 38830:>
> https://gitlab.com/gitlab-org/gitlab-foss/issues/38830
> 
> According to that issue, you can request a tarball from GitLab,
> similarly to what you would do with GitHub.  However, when you
> request a tarball of a tag, the SHA will be part of the filename.
> Worse, the top level directory will also contain the SHA.
Why do you think that such an important feature isn't available in GitLab?

> https://gitlab.com/inkscape/inkscape/-/tags

On the right side there is a download icon, have a look at the
referenced URLs.

> This will complicate packaging, because we'll need to know the
> expected SHAs for each of the 7 repos, and rename the directories as
> the tarballs are unpacked.  Or I suppose we could use wildcards to
> achieve the same thing.  It is certainly doable, but it is a bit
> ugly.

I usually prefer to create the tarball on my machine by the 'git
archive' command.
But you can also use the plain GitLab API to request a download URL. But
that's not really needed as the various download URLs are predictable.

-- 
Regards
Carsten Schoenert

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

On Wed, 9 Oct 2019 at 18:36, Wayne Stambaugh  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.

Why do we need to freeze it? I suggest we do this in incremental
steps. I mean, a git repo is a git repo. It can easily be mirrored, we
just need to make sure that changes are pushed to only one. We can
start just mirroring to gitlab to play around a bit. Migration of
bugtracker and some CI.

> * Disable the Launcpad bug tracker.

Isn't this a bit drastic? Shouldn't we investigate import of the
current launchpad bug tracker into gitlab?

> * 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
> term.  We can always migrate the mailing list at a later date or use
> some other communication tool such as discourse.
>
> Further down the road, I would like to see all of the KiCad source repos
> including the library, documentation, website, and translation repos
> migrated to GitLab as well.  It would make my life a lot easier from a
> project management perspective if they were all in the same place.  I
> expect there to be some resistance to using a source code version tool
> but I'm hoping folks will see this as a beneficial move.

What do you mean with that last sentence?

> I'm not
> terribly familiar with GitLab but I suspect it's not that much different
> than GitHub as a hosting platform so I don't expect there to be a very
> steep learning curve.  If you have any concerns, now is the time to
> speak up or forever hold your peace.
>

Are we going to use the merge requests actively or the mailing list?
It should be fairly easy to set up some simple CI for the patches, but
I really think we need to set this up before any move.

It seems that I am the owner of https://gitlab.com/kicad_eda  FWIW.

> Cheers,
>
> Wayne
>
> [1]: https://gitlab.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

___
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

[Steven A. Falco]

I've been playing around with a test project on GitLab, and it looks like there 
are two different URLs that can be used to download a tarball:

https://gitlab.com/stevenfalco/test/repository/0.0.0/archive.tar.gz

https://gitlab.com/stevenfalco/test/-/archive/0.0.0/test-0.0.0.tar.gz

The first URL has the SHA in the directory name, but the second one does not.  
I think the second form of URL will be easy to use for Fedora packaging; I 
retract my earlier concern.

Steve

On 10/9/19 2:53 PM, Adam Wolf wrote:
> Please note I don't think this will be a problem for macOS packaging
> at all, but we do it differently than other folks.
> 
> On Wed, Oct 9, 2019 at 1:45 PM Steven A. Falco  wrote:
>>
>> On 10/9/19 12:36 PM, Wayne Stambaugh wrote:
>>> The lead development team has been discussing migrating the KiCad
>>> project to GitLab[1].
>>
>> For packagers, I'm curious as to how creating an archive from a tag would 
>> work.  Currently, to grab the source from launchpad, we use a URL like:
>>
>> https://launchpad.net/kicad/5.0/%{version}/+download/kicad-%{version}.tar.xz
>>
>> where %{version} is a Fedora macro that expands to the desired version.  
>> This apparently works because Wayne explicitly uploads the tarball to 
>> launchpad.
>>
>> For github, we use:
>>
>> https://github.com/KiCad/kicad-doc/archive/%{version}.tar.gz
>>
>> This works because github has an API that creates the tarball on-demand.
>>
>> I found some references regarding how this works in GitLab.  For example, 
>> please see Issue 38830:
>>
>> https://gitlab.com/gitlab-org/gitlab-foss/issues/38830
>>
>> According to that issue, you can request a tarball from GitLab, similarly to 
>> what you would do with GitHub.  However, when you request a tarball of a 
>> tag, the SHA will be part of the filename.  Worse, the top level directory 
>> will also contain the SHA.
>>
>> This will complicate packaging, because we'll need to know the expected SHAs 
>> for each of the 7 repos, and rename the directories as the tarballs are 
>> unpacked.  Or I suppose we could use wildcards to achieve the same thing.  
>> It is certainly doable, but it is a bit ugly.
>>
>> Steve
>>
>>> 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
>>> term.  We can always migrate the mailing list at a later date or use
>>> some other communication tool such as discourse.
>>>
>>> Further down the road, I would like to see all of the KiCad source repos
>>> including the library, documentation, website, and translation repos
>>> migrated to GitLab as well.  It would make my life a lot easier from a
>>> project management perspective if they were all in the same place.  I
>>> expect there to be some resistance to using a source code version tool
>>> but I'm hoping folks will see this as a beneficial move.  I'm not
>>> terribly familiar with GitLab but I suspect it's not that much different
>>> than GitHub as a hosting platform so I don't expect there to be a very
>>> steep learning curve.  If you have any concerns, now is the time to
>>> speak up or forever hold your peace.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> [1]: https://gitlab.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
>>>
>>
>>
>> ___
>> 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

[Carsten Schoenert]

Hi,

Am 09.10.19 um 19:53 schrieb Wayne Stambaugh:
> On 10/9/19 1:06 PM, Rene Pöschl wrote:
>> Hi, this is welcome news.
>>
>> I would suggest we do the library transfer as soon as the new
>> file format is somewhat stable as we will need to make a hard
>> cut for transfering the symbol libs to the new file format
>> anyway.
>> (We would avoid needing to do doulbe work this way.)
>>
>> Would then of course mean that the v5 development will
>> stay at github and only v6 will be found at gitlab.
>> (The v5 development will be halted as soon as we start with
>> v6 as we simply do not have the resources to handle two
>> releases. And i assume the move will take us quite a while
>> so we need to start early with it anyways.)
> 
> This is a good idea that I hadn't considered.

I disagree at the point that releases will be on two different places.
Please don't do this. As there si no need to do this.

Think about a branch model and you will see there is no need to have two
different resources to keep the data.

-- 
Regards
Carsten Schoenert

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

>  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.


>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.


>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.


On Wed, Oct 9, 2019 at 12:36 PM Wayne Stambaugh 
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
> term.  We can always migrate the mailing list at a later date or use
> some other communication tool such as discourse.
>
> Further down the road, I would like to see all of the KiCad source repos
> including the library, documentation, website, and translation repos
> migrated to GitLab as well.  It would make my life a lot easier from a
> project management perspective if they were all in the same place.  I
> expect there to be some resistance to using a source code version tool
> but I'm hoping folks will see this as a beneficial move.  I'm not
> terribly familiar with GitLab but I suspect it's not that much different
> than GitHub as a hosting platform so I don't expect there to be a very
> steep learning curve.  If you have any concerns, now is the time to
> speak up or forever hold your peace.
>
> Cheers,
>
> Wayne
>
> [1]: https://gitlab.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
>


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

[Adam Wolf]

Please note I don't think this will be a problem for macOS packaging
at all, but we do it differently than other folks.

On Wed, Oct 9, 2019 at 1:45 PM Steven A. Falco  wrote:
>
> On 10/9/19 12:36 PM, Wayne Stambaugh wrote:
> > The lead development team has been discussing migrating the KiCad
> > project to GitLab[1].
>
> For packagers, I'm curious as to how creating an archive from a tag would 
> work.  Currently, to grab the source from launchpad, we use a URL like:
>
> https://launchpad.net/kicad/5.0/%{version}/+download/kicad-%{version}.tar.xz
>
> where %{version} is a Fedora macro that expands to the desired version.  This 
> apparently works because Wayne explicitly uploads the tarball to launchpad.
>
> For github, we use:
>
> https://github.com/KiCad/kicad-doc/archive/%{version}.tar.gz
>
> This works because github has an API that creates the tarball on-demand.
>
> I found some references regarding how this works in GitLab.  For example, 
> please see Issue 38830:
>
> https://gitlab.com/gitlab-org/gitlab-foss/issues/38830
>
> According to that issue, you can request a tarball from GitLab, similarly to 
> what you would do with GitHub.  However, when you request a tarball of a tag, 
> the SHA will be part of the filename.  Worse, the top level directory will 
> also contain the SHA.
>
> This will complicate packaging, because we'll need to know the expected SHAs 
> for each of the 7 repos, and rename the directories as the tarballs are 
> unpacked.  Or I suppose we could use wildcards to achieve the same thing.  It 
> is certainly doable, but it is a bit ugly.
>
> Steve
>
> > 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
> > term.  We can always migrate the mailing list at a later date or use
> > some other communication tool such as discourse.
> >
> > Further down the road, I would like to see all of the KiCad source repos
> > including the library, documentation, website, and translation repos
> > migrated to GitLab as well.  It would make my life a lot easier from a
> > project management perspective if they were all in the same place.  I
> > expect there to be some resistance to using a source code version tool
> > but I'm hoping folks will see this as a beneficial move.  I'm not
> > terribly familiar with GitLab but I suspect it's not that much different
> > than GitHub as a hosting platform so I don't expect there to be a very
> > steep learning curve.  If you have any concerns, now is the time to
> > speak up or forever hold your peace.
> >
> > Cheers,
> >
> > Wayne
> >
> > [1]: https://gitlab.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
> >
>
>
> ___
> 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

[Steven A. Falco]

On 10/9/19 12:36 PM, Wayne Stambaugh wrote:
> The lead development team has been discussing migrating the KiCad
> project to GitLab[1].

For packagers, I'm curious as to how creating an archive from a tag would work. 
 Currently, to grab the source from launchpad, we use a URL like:

https://launchpad.net/kicad/5.0/%{version}/+download/kicad-%{version}.tar.xz

where %{version} is a Fedora macro that expands to the desired version.  This 
apparently works because Wayne explicitly uploads the tarball to launchpad.

For github, we use:

https://github.com/KiCad/kicad-doc/archive/%{version}.tar.gz

This works because github has an API that creates the tarball on-demand.

I found some references regarding how this works in GitLab.  For example, 
please see Issue 38830:

https://gitlab.com/gitlab-org/gitlab-foss/issues/38830

According to that issue, you can request a tarball from GitLab, similarly to 
what you would do with GitHub.  However, when you request a tarball of a tag, 
the SHA will be part of the filename.  Worse, the top level directory will also 
contain the SHA.

This will complicate packaging, because we'll need to know the expected SHAs 
for each of the 7 repos, and rename the directories as the tarballs are 
unpacked.  Or I suppose we could use wildcards to achieve the same thing.  It 
is certainly doable, but it is a bit ugly.

Steve

> 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
> term.  We can always migrate the mailing list at a later date or use
> some other communication tool such as discourse.
> 
> Further down the road, I would like to see all of the KiCad source repos
> including the library, documentation, website, and translation repos
> migrated to GitLab as well.  It would make my life a lot easier from a
> project management perspective if they were all in the same place.  I
> expect there to be some resistance to using a source code version tool
> but I'm hoping folks will see this as a beneficial move.  I'm not
> terribly familiar with GitLab but I suspect it's not that much different
> than GitHub as a hosting platform so I don't expect there to be a very
> steep learning curve.  If you have any concerns, now is the time to
> speak up or forever hold your peace.
> 
> Cheers,
> 
> Wayne
> 
> [1]: https://gitlab.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
> 


___
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