Re: [Kicad-developers] ideas to improve patch and CI integration

[Antonio Vázquez Blanco]

For the past months I have been doing some testing and trying Gilab CI in
an unofficial mirror of KiCad repo mirror located at
https://gitlab.com/kicad-mirror

My idea was to submit a patch to integrate the work done when it becomes
mature enough or when the final move to Gitlab is made. Maybe what already
has been done is of interest to you Jeff. I hope it helps.

Cheers,
Antón


El mié., 14 nov. 2018 a las 16:19, Wayne Stambaugh ()
escribió:

> This has been discussed before so I'm not really interested in rehashing
> the discussion.  You can search the mailing list archives if you are
> interested.  There have been some discussions about moving the entire
> project to a private gitlab host so moving to github doesn't really make
> sense if this happens.
>
> Cheers,
>
> Wayne
>
> On 11/13/2018 11:20 PM, Jeff wrote:
> > Hi,
> >
> > Wanted to bump this. I've tried intermittently to play with KiCad, and
> > Launchpad is one of the things I've struggled with. Contributing with
> > Launchpad has been a bit impediment for me.
> >
> > Virtually every developer has used GitHub or similar. Perhaps there are
> > some philosophical reasons to not switch to GitHub, but practically
> > speaking, it makes the project much more accessible.
> >
> > Jeff
> >
> > On Mon, Oct 22, 2018 at 8:14 PM Seth Hillbrand  > > wrote:
> >
> > Am 2018-10-22 20:20, schrieb Mark Roszko:
> > >> Hosting our own stack sounds like a logistical challenge.
> > >
> > > Uh, this particular infrastructure we are moving. Not really? Its a
> > > basically dressed up kubernetes cluster and we just have to update
> the
> > > application containers which is easy enough (and something we'll be
> > > doing anyway to update the website and other things).
> >
> > Hi Mark-
> >
> > As long as someone is thinking through data storage, backups, restore
> > procedures, maintenance, system fallback and the like, I'm happy.
> I'm
> > sure you have a number more things you're reviewing and I'm
> > certainly no
> > expert systems management, so I'm just glad we have people on the
> team
> > who are.
> >
> > Best-
> > 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
> >
> >
> > ___
> > 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] ideas to improve patch and CI integration

[Wayne Stambaugh]

This has been discussed before so I'm not really interested in rehashing
the discussion.  You can search the mailing list archives if you are
interested.  There have been some discussions about moving the entire
project to a private gitlab host so moving to github doesn't really make
sense if this happens.

Cheers,

Wayne

On 11/13/2018 11:20 PM, Jeff wrote:
> Hi,
> 
> Wanted to bump this. I've tried intermittently to play with KiCad, and
> Launchpad is one of the things I've struggled with. Contributing with
> Launchpad has been a bit impediment for me.
> 
> Virtually every developer has used GitHub or similar. Perhaps there are
> some philosophical reasons to not switch to GitHub, but practically
> speaking, it makes the project much more accessible.
> 
> Jeff
> 
> On Mon, Oct 22, 2018 at 8:14 PM Seth Hillbrand  > wrote:
> 
> Am 2018-10-22 20:20, schrieb Mark Roszko:
> >> Hosting our own stack sounds like a logistical challenge.
> >
> > Uh, this particular infrastructure we are moving. Not really? Its a
> > basically dressed up kubernetes cluster and we just have to update the
> > application containers which is easy enough (and something we'll be
> > doing anyway to update the website and other things).
> 
> Hi Mark-
> 
> As long as someone is thinking through data storage, backups, restore
> procedures, maintenance, system fallback and the like, I'm happy.  I'm
> sure you have a number more things you're reviewing and I'm
> certainly no
> expert systems management, so I'm just glad we have people on the team
> who are.
> 
> Best-
> 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
> 
> 
> ___
> 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] ideas to improve patch and CI integration

[Jeff]

Hi,

Wanted to bump this. I've tried intermittently to play with KiCad, and
Launchpad is one of the things I've struggled with. Contributing with
Launchpad has been a bit impediment for me.

Virtually every developer has used GitHub or similar. Perhaps there are
some philosophical reasons to not switch to GitHub, but practically
speaking, it makes the project much more accessible.

Jeff

On Mon, Oct 22, 2018 at 8:14 PM Seth Hillbrand  wrote:

> Am 2018-10-22 20:20, schrieb Mark Roszko:
> >> Hosting our own stack sounds like a logistical challenge.
> >
> > Uh, this particular infrastructure we are moving. Not really? Its a
> > basically dressed up kubernetes cluster and we just have to update the
> > application containers which is easy enough (and something we'll be
> > doing anyway to update the website and other things).
>
> Hi Mark-
>
> As long as someone is thinking through data storage, backups, restore
> procedures, maintenance, system fallback and the like, I'm happy.  I'm
> sure you have a number more things you're reviewing and I'm certainly no
> expert systems management, so I'm just glad we have people on the team
> who are.
>
> Best-
> 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
>
___
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] ideas to improve patch and CI integration

[José Ignacio]

Funny you say that, Today I had to try 5 times to get a bug submitted on
LP, kept giving me internal server errors

On Mon, Oct 22, 2018 at 6:57 PM Seth Hillbrand  wrote:

> Am 2018-10-22 11:22, schrieb Wayne Stambaugh:
> > On 10/22/2018 11:10 AM, Mark Roszko wrote:
> >>> If the community edition meets the projects needs, all the better.
> >>
> >> Yep, should far more than enough. There are definitely some "nicer"
> >> features in the enterprise edition but at the same time its stuff that
> >> isn't be used right now anyway and won't really hurt anything.
> >> For further proof. GNOME uses Gitlab Community Edition
> >> now https://gitlab.gnome.org
> >>
> >>
> >>> It makes sense to do this in manageable pieces so as not to overload
> >> our great benefactor.
> >>
> >> Ah, the way it works is we can deploy and manage the stuff ourselves.
> >
> > Even setting up gitlab on their servers?  If so, that's a sweet deal.
> > I
> > probably should be kept in the loop so I can keep track of what is
> > going
> > on in the project.
> >
>
> Hi All-
>
> I would love a more modern interface to bug tracking and branch
> management.  I've used a GitLab instance for a number of projects
> locally and find that it works as expected.
>
> That said, for all of its warts, Launchpad has been remarkable stable
> with virtually 0 downtime and 0 data loss.
>
> Hosting our own stack sounds like a logistical challenge.  While gnome
> hosts their own, they also pay for a team of sysadmins [1].  Perhaps
> this also exists in the systems being referenced here but, if not, we
> might be better off utilizing either GitHub or GitLab directly.
>
> Best-
> Seth
>
> [1] https://www.gnome.org/foundation/careers/devops-sysadmin/
>
> ___
> 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] ideas to improve patch and CI integration

[Seth Hillbrand]

Am 2018-10-22 20:20, schrieb Mark Roszko:

Hosting our own stack sounds like a logistical challenge.


Uh, this particular infrastructure we are moving. Not really? Its a
basically dressed up kubernetes cluster and we just have to update the
application containers which is easy enough (and something we'll be
doing anyway to update the website and other things).


Hi Mark-

As long as someone is thinking through data storage, backups, restore 
procedures, maintenance, system fallback and the like, I'm happy.  I'm 
sure you have a number more things you're reviewing and I'm certainly no 
expert systems management, so I'm just glad we have people on the team 
who are.


Best-
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] ideas to improve patch and CI integration

[Mark Roszko]

> Hosting our own stack sounds like a logistical challenge.

Uh, this particular infrastructure we are moving. Not really? Its a
basically dressed up kubernetes cluster and we just have to update the
application containers which is easy enough (and something we'll be doing
anyway to update the website and other things).


On Mon, Oct 22, 2018 at 6:47 PM Seth Hillbrand  wrote:

> Am 2018-10-22 11:22, schrieb Wayne Stambaugh:
> > On 10/22/2018 11:10 AM, Mark Roszko wrote:
> >>> If the community edition meets the projects needs, all the better.
> >>
> >> Yep, should far more than enough. There are definitely some "nicer"
> >> features in the enterprise edition but at the same time its stuff that
> >> isn't be used right now anyway and won't really hurt anything.
> >> For further proof. GNOME uses Gitlab Community Edition
> >> now https://gitlab.gnome.org
> >>
> >>
> >>> It makes sense to do this in manageable pieces so as not to overload
> >> our great benefactor.
> >>
> >> Ah, the way it works is we can deploy and manage the stuff ourselves.
> >
> > Even setting up gitlab on their servers?  If so, that's a sweet deal.
> > I
> > probably should be kept in the loop so I can keep track of what is
> > going
> > on in the project.
> >
>
> Hi All-
>
> I would love a more modern interface to bug tracking and branch
> management.  I've used a GitLab instance for a number of projects
> locally and find that it works as expected.
>
> That said, for all of its warts, Launchpad has been remarkable stable
> with virtually 0 downtime and 0 data loss.
>
> Hosting our own stack sounds like a logistical challenge.  While gnome
> hosts their own, they also pay for a team of sysadmins [1].  Perhaps
> this also exists in the systems being referenced here but, if not, we
> might be better off utilizing either GitHub or GitLab directly.
>
> Best-
> Seth
>
> [1] https://www.gnome.org/foundation/careers/devops-sysadmin/
>


-- 
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] ideas to improve patch and CI integration

[Seth Hillbrand]

Am 2018-10-22 11:22, schrieb Wayne Stambaugh:

On 10/22/2018 11:10 AM, Mark Roszko wrote:

If the community edition meets the projects needs, all the better.


Yep, should far more than enough. There are definitely some "nicer"
features in the enterprise edition but at the same time its stuff that
isn't be used right now anyway and won't really hurt anything.
For further proof. GNOME uses Gitlab Community Edition
now https://gitlab.gnome.org



It makes sense to do this in manageable pieces so as not to overload

our great benefactor.

Ah, the way it works is we can deploy and manage the stuff ourselves.


Even setting up gitlab on their servers?  If so, that's a sweet deal.  
I
probably should be kept in the loop so I can keep track of what is 
going

on in the project.



Hi All-

I would love a more modern interface to bug tracking and branch 
management.  I've used a GitLab instance for a number of projects 
locally and find that it works as expected.


That said, for all of its warts, Launchpad has been remarkable stable 
with virtually 0 downtime and 0 data loss.


Hosting our own stack sounds like a logistical challenge.  While gnome 
hosts their own, they also pay for a team of sysadmins [1].  Perhaps 
this also exists in the systems being referenced here but, if not, we 
might be better off utilizing either GitHub or GitLab directly.


Best-
Seth

[1] https://www.gnome.org/foundation/careers/devops-sysadmin/

___
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] ideas to improve patch and CI integration

[Wayne Stambaugh]

On 10/22/2018 11:10 AM, Mark Roszko wrote:
>>If the community edition meets the projects needs, all the better.
> 
> Yep, should far more than enough. There are definitely some "nicer"
> features in the enterprise edition but at the same time its stuff that
> isn't be used right now anyway and won't really hurt anything.
> For further proof. GNOME uses Gitlab Community Edition
> now https://gitlab.gnome.org
> 
> 
>> It makes sense to do this in manageable pieces so as not to overload
> our great benefactor.
> 
> Ah, the way it works is we can deploy and manage the stuff ourselves.

Even setting up gitlab on their servers?  If so, that's a sweet deal.  I
probably should be kept in the loop so I can keep track of what is going
on in the project.

> 
> 
> On Mon, Oct 22, 2018 at 10:50 AM Wayne Stambaugh  > wrote:
> 
> On 10/22/2018 9:00 AM, Mark Roszko wrote:
> >> I would bet money this will happen at some point in the future so it
> >>   could be an issue when it does unless we just limit the kicad
> project to
> >>   using the community edition.
> >
> > No need for anything other than community edition. I use it just
> fine at
> > my company for 20 or so devs ;)
> 
> If the community edition meets the projects needs, all the better.
> 
> >
> >
> > Also in terms of hosting it, etc. We have access to something now from
> > one of our great benefactors that'll let us run it there :#
> 
> If it's the same great benefactor that I'm thinking of, then they would
> most likely be doing the gitlab code hosting as well.
> 
> > I've been busy doing some of the website stuff for that. The
> website is
> > ready. I'm still working on a fancy new docs website to go into it to
> > replace the current setup.
> > The plan from Nick was to first migrate existing stuff over before
> we go
> > entirely crazy with new stuff. He was going to move Jenkins to it too.
> 
> It makes sense to do this in manageable pieces so as not to overload our
> great benefactor.
> 
> >
> > On Mon, Oct 22, 2018 at 8:56 AM Wayne Stambaugh
> mailto:stambau...@gmail.com>
> > >> wrote:
> >
> >     On 10/22/2018 5:59 AM, Maciej Sumiński wrote:
> >     > Hi Thomas,
> >     >
> >     > I like Gitlab, but it is a matter of taste and obviously the
> final
> >     word
> >     > belongs to Wayne. I think the main problem would be to transfer
> >     the bug
> >     > tracker and decide what to do regarding the mailing list.
> >
> >     We have actually discussed this possibility privately so it's
> on our
> >     radar.  I personally would like to see the entire project on a
> single
> >     site instead of our current situation where we have repos on both
> >     launchpad and github.  I haven't use gitlab so I cannot speak
> about it's
> >     pros and cons but I have looked over some the documentation
> and it seems
> >     comparable to github so I suspect it would be more than
> acceptable.
> >
> >     >
> >     > Another point is a plan for a case when Gitlab turns evil.
> Currently
> >     > they offer Gold version to open source projects for free
> [1], but you
> >     > never know what will happen in a few years. Either we pay or
> host a
> >     > limited version (Community Edition) privately. I realize the
> same
> >     thing
> >     > may happen with Launchpad, the point is to decide whether we
> would be
> >     > satisfied with Gitlab Community Edition features.
> >
> >     I would bet money this will happen at some point in the future
> so it
> >     could be an issue when it does unless we just limit the kicad
> project to
> >     using the community edition.
> >
> >     >
> >     > You may also find insightful a discussion we head about
> moving KiCad
> >     > from Bazaar to Git [2].
> >
> >     Fun times!  As always, there are no silver bullets.  If we
> choose to go
> >     down this path, there will be issues that will have to be
> resolved.
> >
> >     >
> >     > Cheers,
> >     > Orson
> >     >
> >     > 1. https://about.gitlab.com/pricing/#gitlab-com
> >     > 2. https://lists.launchpad.net/kicad-developers/msg25668.html
> >     >
> >     >
> >     > On 10/21/18 7:11 PM, Thomas Pointhuber wrote:
> >     >> Hi,
> >     >>
> >     >> I think this topic will have many different point of views,
> but I
> >     think
> >     >> it is important to discuss it anyway.
> >     >>
> >     >> I'm now about 5 years on the project, started as library
> >     maintainer and
> >     >> now sometimes with code contributions as well. I experienced at
> >     

Re: [Kicad-developers] ideas to improve patch and CI integration

[Wayne Stambaugh]

On 10/22/2018 9:00 AM, Mark Roszko wrote:
>> I would bet money this will happen at some point in the future so it
>>   could be an issue when it does unless we just limit the kicad project to
>>   using the community edition.
> 
> No need for anything other than community edition. I use it just fine at
> my company for 20 or so devs ;)

If the community edition meets the projects needs, all the better.

> 
> 
> Also in terms of hosting it, etc. We have access to something now from
> one of our great benefactors that'll let us run it there :#

If it's the same great benefactor that I'm thinking of, then they would
most likely be doing the gitlab code hosting as well.

> I've been busy doing some of the website stuff for that. The website is
> ready. I'm still working on a fancy new docs website to go into it to
> replace the current setup.
> The plan from Nick was to first migrate existing stuff over before we go
> entirely crazy with new stuff. He was going to move Jenkins to it too.

It makes sense to do this in manageable pieces so as not to overload our
great benefactor.

> 
> On Mon, Oct 22, 2018 at 8:56 AM Wayne Stambaugh  > wrote:
> 
> On 10/22/2018 5:59 AM, Maciej Sumiński wrote:
> > Hi Thomas,
> >
> > I like Gitlab, but it is a matter of taste and obviously the final
> word
> > belongs to Wayne. I think the main problem would be to transfer
> the bug
> > tracker and decide what to do regarding the mailing list.
> 
> We have actually discussed this possibility privately so it's on our
> radar.  I personally would like to see the entire project on a single
> site instead of our current situation where we have repos on both
> launchpad and github.  I haven't use gitlab so I cannot speak about it's
> pros and cons but I have looked over some the documentation and it seems
> comparable to github so I suspect it would be more than acceptable.
> 
> >
> > Another point is a plan for a case when Gitlab turns evil. Currently
> > they offer Gold version to open source projects for free [1], but you
> > never know what will happen in a few years. Either we pay or host a
> > limited version (Community Edition) privately. I realize the same
> thing
> > may happen with Launchpad, the point is to decide whether we would be
> > satisfied with Gitlab Community Edition features.
> 
> I would bet money this will happen at some point in the future so it
> could be an issue when it does unless we just limit the kicad project to
> using the community edition.
> 
> >
> > You may also find insightful a discussion we head about moving KiCad
> > from Bazaar to Git [2].
> 
> Fun times!  As always, there are no silver bullets.  If we choose to go
> down this path, there will be issues that will have to be resolved.
> 
> >
> > Cheers,
> > Orson
> >
> > 1. https://about.gitlab.com/pricing/#gitlab-com
> > 2. https://lists.launchpad.net/kicad-developers/msg25668.html
> >
> >
> > On 10/21/18 7:11 PM, Thomas Pointhuber wrote:
> >> Hi,
> >>
> >> I think this topic will have many different point of views, but I
> think
> >> it is important to discuss it anyway.
> >>
> >> I'm now about 5 years on the project, started as library
> maintainer and
> >> now sometimes with code contributions as well. I experienced at
> least a
> >> few different types of how software projects can be design of a
> >> management perspective to get work done.
> >>
> >> Currently, there is the time where many big organizations (GNOME and
> >> freedesktop.org  for example) moved their
> development to custom GitLab
> >> instances. And I would like to propose to think about that for
> KiCad as
> >> well. Not because everyone does it, but because it would benefit the
> >> project itself. There are various reasons I can think of right now:
> >>
> >> * patches are sometimes simply forgotten on the mailing list
> >> * it is pretty hard to find old patches on the mailing list
> unless you
> >> have the e-mails stored on your account. You cannot search on
> launchpad
> >> * CI integration of patches is missing. People need to run them
> explicit
> >> before merging, or the automated build will fail at some point
> >> * getting CI runs for various systems requires explicit request
> due to
> >> missing automatization
> >> * no automated linter checks (would require us to reformat the
> project)
> >> * it's hard to track changes of patches, especially when modified,
> >> squashed,...
> >> * way better possibilities to view/edit/show history online
> >> * review tools on Launchpad are cumbersome and rarely used. This
> should
> >> be the standard in point of fact.
> >>   * easier to handle a proper review 

Re: [Kicad-developers] ideas to improve patch and CI integration

[Mark Roszko]

>If the community edition meets the projects needs, all the better.

Yep, should far more than enough. There are definitely some "nicer"
features in the enterprise edition but at the same time its stuff that
isn't be used right now anyway and won't really hurt anything.
For further proof. GNOME uses Gitlab Community Edition now
https://gitlab.gnome.org


> It makes sense to do this in manageable pieces so as not to overload our
great benefactor.

Ah, the way it works is we can deploy and manage the stuff ourselves.


On Mon, Oct 22, 2018 at 10:50 AM Wayne Stambaugh 
wrote:

> On 10/22/2018 9:00 AM, Mark Roszko wrote:
> >> I would bet money this will happen at some point in the future so it
> >>   could be an issue when it does unless we just limit the kicad project
> to
> >>   using the community edition.
> >
> > No need for anything other than community edition. I use it just fine at
> > my company for 20 or so devs ;)
>
> If the community edition meets the projects needs, all the better.
>
> >
> >
> > Also in terms of hosting it, etc. We have access to something now from
> > one of our great benefactors that'll let us run it there :#
>
> If it's the same great benefactor that I'm thinking of, then they would
> most likely be doing the gitlab code hosting as well.
>
> > I've been busy doing some of the website stuff for that. The website is
> > ready. I'm still working on a fancy new docs website to go into it to
> > replace the current setup.
> > The plan from Nick was to first migrate existing stuff over before we go
> > entirely crazy with new stuff. He was going to move Jenkins to it too.
>
> It makes sense to do this in manageable pieces so as not to overload our
> great benefactor.
>
> >
> > On Mon, Oct 22, 2018 at 8:56 AM Wayne Stambaugh  > > wrote:
> >
> > On 10/22/2018 5:59 AM, Maciej Sumiński wrote:
> > > Hi Thomas,
> > >
> > > I like Gitlab, but it is a matter of taste and obviously the final
> > word
> > > belongs to Wayne. I think the main problem would be to transfer
> > the bug
> > > tracker and decide what to do regarding the mailing list.
> >
> > We have actually discussed this possibility privately so it's on our
> > radar.  I personally would like to see the entire project on a single
> > site instead of our current situation where we have repos on both
> > launchpad and github.  I haven't use gitlab so I cannot speak about
> it's
> > pros and cons but I have looked over some the documentation and it
> seems
> > comparable to github so I suspect it would be more than acceptable.
> >
> > >
> > > Another point is a plan for a case when Gitlab turns evil.
> Currently
> > > they offer Gold version to open source projects for free [1], but
> you
> > > never know what will happen in a few years. Either we pay or host a
> > > limited version (Community Edition) privately. I realize the same
> > thing
> > > may happen with Launchpad, the point is to decide whether we would
> be
> > > satisfied with Gitlab Community Edition features.
> >
> > I would bet money this will happen at some point in the future so it
> > could be an issue when it does unless we just limit the kicad
> project to
> > using the community edition.
> >
> > >
> > > You may also find insightful a discussion we head about moving
> KiCad
> > > from Bazaar to Git [2].
> >
> > Fun times!  As always, there are no silver bullets.  If we choose to
> go
> > down this path, there will be issues that will have to be resolved.
> >
> > >
> > > Cheers,
> > > Orson
> > >
> > > 1. https://about.gitlab.com/pricing/#gitlab-com
> > > 2. https://lists.launchpad.net/kicad-developers/msg25668.html
> > >
> > >
> > > On 10/21/18 7:11 PM, Thomas Pointhuber wrote:
> > >> Hi,
> > >>
> > >> I think this topic will have many different point of views, but I
> > think
> > >> it is important to discuss it anyway.
> > >>
> > >> I'm now about 5 years on the project, started as library
> > maintainer and
> > >> now sometimes with code contributions as well. I experienced at
> > least a
> > >> few different types of how software projects can be design of a
> > >> management perspective to get work done.
> > >>
> > >> Currently, there is the time where many big organizations (GNOME
> and
> > >> freedesktop.org  for example) moved their
> > development to custom GitLab
> > >> instances. And I would like to propose to think about that for
> > KiCad as
> > >> well. Not because everyone does it, but because it would benefit
> the
> > >> project itself. There are various reasons I can think of right
> now:
> > >>
> > >> * patches are sometimes simply forgotten on the mailing list
> > >> * it is pretty hard to find old patches on the mailing list
> > unless you
> >

Re: [Kicad-developers] ideas to improve patch and CI integration

[Mark Roszko]

> I would bet money this will happen at some point in the future so it
>   could be an issue when it does unless we just limit the kicad project to
>   using the community edition.

No need for anything other than community edition. I use it just fine at my
company for 20 or so devs ;)


Also in terms of hosting it, etc. We have access to something now from one
of our great benefactors that'll let us run it there :#
I've been busy doing some of the website stuff for that. The website is
ready. I'm still working on a fancy new docs website to go into it to
replace the current setup.
The plan from Nick was to first migrate existing stuff over before we go
entirely crazy with new stuff. He was going to move Jenkins to it too.

On Mon, Oct 22, 2018 at 8:56 AM Wayne Stambaugh 
wrote:

> On 10/22/2018 5:59 AM, Maciej Sumiński wrote:
> > Hi Thomas,
> >
> > I like Gitlab, but it is a matter of taste and obviously the final word
> > belongs to Wayne. I think the main problem would be to transfer the bug
> > tracker and decide what to do regarding the mailing list.
>
> We have actually discussed this possibility privately so it's on our
> radar.  I personally would like to see the entire project on a single
> site instead of our current situation where we have repos on both
> launchpad and github.  I haven't use gitlab so I cannot speak about it's
> pros and cons but I have looked over some the documentation and it seems
> comparable to github so I suspect it would be more than acceptable.
>
> >
> > Another point is a plan for a case when Gitlab turns evil. Currently
> > they offer Gold version to open source projects for free [1], but you
> > never know what will happen in a few years. Either we pay or host a
> > limited version (Community Edition) privately. I realize the same thing
> > may happen with Launchpad, the point is to decide whether we would be
> > satisfied with Gitlab Community Edition features.
>
> I would bet money this will happen at some point in the future so it
> could be an issue when it does unless we just limit the kicad project to
> using the community edition.
>
> >
> > You may also find insightful a discussion we head about moving KiCad
> > from Bazaar to Git [2].
>
> Fun times!  As always, there are no silver bullets.  If we choose to go
> down this path, there will be issues that will have to be resolved.
>
> >
> > Cheers,
> > Orson
> >
> > 1. https://about.gitlab.com/pricing/#gitlab-com
> > 2. https://lists.launchpad.net/kicad-developers/msg25668.html
> >
> >
> > On 10/21/18 7:11 PM, Thomas Pointhuber wrote:
> >> Hi,
> >>
> >> I think this topic will have many different point of views, but I think
> >> it is important to discuss it anyway.
> >>
> >> I'm now about 5 years on the project, started as library maintainer and
> >> now sometimes with code contributions as well. I experienced at least a
> >> few different types of how software projects can be design of a
> >> management perspective to get work done.
> >>
> >> Currently, there is the time where many big organizations (GNOME and
> >> freedesktop.org for example) moved their development to custom GitLab
> >> instances. And I would like to propose to think about that for KiCad as
> >> well. Not because everyone does it, but because it would benefit the
> >> project itself. There are various reasons I can think of right now:
> >>
> >> * patches are sometimes simply forgotten on the mailing list
> >> * it is pretty hard to find old patches on the mailing list unless you
> >> have the e-mails stored on your account. You cannot search on launchpad
> >> * CI integration of patches is missing. People need to run them explicit
> >> before merging, or the automated build will fail at some point
> >> * getting CI runs for various systems requires explicit request due to
> >> missing automatization
> >> * no automated linter checks (would require us to reformat the project)
> >> * it's hard to track changes of patches, especially when modified,
> >> squashed,...
> >> * way better possibilities to view/edit/show history online
> >> * review tools on Launchpad are cumbersome and rarely used. This should
> >> be the standard in point of fact.
> >>   * easier to handle a proper review than with e-mail
> >> * easier to keep track how discussions evolved
> >> * the project is currently split between Launchpad and GitHub, this
> >> would allow us to combine all parts on one platform
> >> * GitLab would theoretically allow us add custom differs for library
> review
> >> * new contributors likely know GitHub/Gitlab workflow and can join more
> >> easily
> >>
> >> I know this is quite some heavy proposal due to change of workflow and
> >> bug-migration. Nevertheless, we should at least discuss it.
> >>
> >> PS: A college built a working GitLab CI script with export of build
> >> artifacts. GitLab integration of Jenkins would be possible as well.
> >>
> >> Regards,
> >> Thomas
> >
> >
> > ___
> > Mailing 

Re: [Kicad-developers] ideas to improve patch and CI integration

[Wayne Stambaugh]

On 10/22/2018 5:59 AM, Maciej Sumiński wrote:
> Hi Thomas,
> 
> I like Gitlab, but it is a matter of taste and obviously the final word
> belongs to Wayne. I think the main problem would be to transfer the bug
> tracker and decide what to do regarding the mailing list.

We have actually discussed this possibility privately so it's on our
radar.  I personally would like to see the entire project on a single
site instead of our current situation where we have repos on both
launchpad and github.  I haven't use gitlab so I cannot speak about it's
pros and cons but I have looked over some the documentation and it seems
comparable to github so I suspect it would be more than acceptable.

> 
> Another point is a plan for a case when Gitlab turns evil. Currently
> they offer Gold version to open source projects for free [1], but you
> never know what will happen in a few years. Either we pay or host a
> limited version (Community Edition) privately. I realize the same thing
> may happen with Launchpad, the point is to decide whether we would be
> satisfied with Gitlab Community Edition features.

I would bet money this will happen at some point in the future so it
could be an issue when it does unless we just limit the kicad project to
using the community edition.

> 
> You may also find insightful a discussion we head about moving KiCad
> from Bazaar to Git [2].

Fun times!  As always, there are no silver bullets.  If we choose to go
down this path, there will be issues that will have to be resolved.

> 
> Cheers,
> Orson
> 
> 1. https://about.gitlab.com/pricing/#gitlab-com
> 2. https://lists.launchpad.net/kicad-developers/msg25668.html
> 
> 
> On 10/21/18 7:11 PM, Thomas Pointhuber wrote:
>> Hi,
>>
>> I think this topic will have many different point of views, but I think
>> it is important to discuss it anyway.
>>
>> I'm now about 5 years on the project, started as library maintainer and
>> now sometimes with code contributions as well. I experienced at least a
>> few different types of how software projects can be design of a
>> management perspective to get work done.
>>
>> Currently, there is the time where many big organizations (GNOME and
>> freedesktop.org for example) moved their development to custom GitLab
>> instances. And I would like to propose to think about that for KiCad as
>> well. Not because everyone does it, but because it would benefit the
>> project itself. There are various reasons I can think of right now:
>>
>> * patches are sometimes simply forgotten on the mailing list
>> * it is pretty hard to find old patches on the mailing list unless you
>> have the e-mails stored on your account. You cannot search on launchpad
>> * CI integration of patches is missing. People need to run them explicit
>> before merging, or the automated build will fail at some point
>> * getting CI runs for various systems requires explicit request due to
>> missing automatization
>> * no automated linter checks (would require us to reformat the project)
>> * it's hard to track changes of patches, especially when modified,
>> squashed,...
>> * way better possibilities to view/edit/show history online
>> * review tools on Launchpad are cumbersome and rarely used. This should
>> be the standard in point of fact.
>>   * easier to handle a proper review than with e-mail
>> * easier to keep track how discussions evolved
>> * the project is currently split between Launchpad and GitHub, this
>> would allow us to combine all parts on one platform
>> * GitLab would theoretically allow us add custom differs for library review
>> * new contributors likely know GitHub/Gitlab workflow and can join more
>> easily
>>
>> I know this is quite some heavy proposal due to change of workflow and
>> bug-migration. Nevertheless, we should at least discuss it.
>>
>> PS: A college built a working GitLab CI script with export of build
>> artifacts. GitLab integration of Jenkins would be possible as well.
>>
>> Regards,
>> Thomas
> 
> 
> ___
> 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] ideas to improve patch and CI integration

[Maciej Sumiński]

Hi Thomas,

I like Gitlab, but it is a matter of taste and obviously the final word
belongs to Wayne. I think the main problem would be to transfer the bug
tracker and decide what to do regarding the mailing list.

Another point is a plan for a case when Gitlab turns evil. Currently
they offer Gold version to open source projects for free [1], but you
never know what will happen in a few years. Either we pay or host a
limited version (Community Edition) privately. I realize the same thing
may happen with Launchpad, the point is to decide whether we would be
satisfied with Gitlab Community Edition features.

You may also find insightful a discussion we head about moving KiCad
from Bazaar to Git [2].

Cheers,
Orson

1. https://about.gitlab.com/pricing/#gitlab-com
2. https://lists.launchpad.net/kicad-developers/msg25668.html


On 10/21/18 7:11 PM, Thomas Pointhuber wrote:
> Hi,
> 
> I think this topic will have many different point of views, but I think
> it is important to discuss it anyway.
> 
> I'm now about 5 years on the project, started as library maintainer and
> now sometimes with code contributions as well. I experienced at least a
> few different types of how software projects can be design of a
> management perspective to get work done.
> 
> Currently, there is the time where many big organizations (GNOME and
> freedesktop.org for example) moved their development to custom GitLab
> instances. And I would like to propose to think about that for KiCad as
> well. Not because everyone does it, but because it would benefit the
> project itself. There are various reasons I can think of right now:
> 
> * patches are sometimes simply forgotten on the mailing list
> * it is pretty hard to find old patches on the mailing list unless you
> have the e-mails stored on your account. You cannot search on launchpad
> * CI integration of patches is missing. People need to run them explicit
> before merging, or the automated build will fail at some point
> * getting CI runs for various systems requires explicit request due to
> missing automatization
> * no automated linter checks (would require us to reformat the project)
> * it's hard to track changes of patches, especially when modified,
> squashed,...
> * way better possibilities to view/edit/show history online
> * review tools on Launchpad are cumbersome and rarely used. This should
> be the standard in point of fact.
>   * easier to handle a proper review than with e-mail
> * easier to keep track how discussions evolved
> * the project is currently split between Launchpad and GitHub, this
> would allow us to combine all parts on one platform
> * GitLab would theoretically allow us add custom differs for library review
> * new contributors likely know GitHub/Gitlab workflow and can join more
> easily
> 
> I know this is quite some heavy proposal due to change of workflow and
> bug-migration. Nevertheless, we should at least discuss it.
> 
> PS: A college built a working GitLab CI script with export of build
> artifacts. GitLab integration of Jenkins would be possible as well.
> 
> Regards,
> Thomas



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

[Kicad-developers] ideas to improve patch and CI integration

[Thomas Pointhuber]

Hi,

I think this topic will have many different point of views, but I think
it is important to discuss it anyway.

I'm now about 5 years on the project, started as library maintainer and
now sometimes with code contributions as well. I experienced at least a
few different types of how software projects can be design of a
management perspective to get work done.

Currently, there is the time where many big organizations (GNOME and
freedesktop.org for example) moved their development to custom GitLab
instances. And I would like to propose to think about that for KiCad as
well. Not because everyone does it, but because it would benefit the
project itself. There are various reasons I can think of right now:

* patches are sometimes simply forgotten on the mailing list
* it is pretty hard to find old patches on the mailing list unless you
have the e-mails stored on your account. You cannot search on launchpad
* CI integration of patches is missing. People need to run them explicit
before merging, or the automated build will fail at some point
* getting CI runs for various systems requires explicit request due to
missing automatization
* no automated linter checks (would require us to reformat the project)
* it's hard to track changes of patches, especially when modified,
squashed,...
* way better possibilities to view/edit/show history online
* review tools on Launchpad are cumbersome and rarely used. This should
be the standard in point of fact.
  * easier to handle a proper review than with e-mail
* easier to keep track how discussions evolved
* the project is currently split between Launchpad and GitHub, this
would allow us to combine all parts on one platform
* GitLab would theoretically allow us add custom differs for library review
* new contributors likely know GitHub/Gitlab workflow and can join more
easily

I know this is quite some heavy proposal due to change of workflow and
bug-migration. Nevertheless, we should at least discuss it.

PS: A college built a working GitLab CI script with export of build
artifacts. GitLab integration of Jenkins would be possible as well.

Regards,
Thomas



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