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
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
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!
--
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
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
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
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
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
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
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
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
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
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-
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.)
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
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
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
>
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
> 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
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:
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
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
> 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
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 (
>
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
> 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
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
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
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.
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
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.
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
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
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
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
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.
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
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.
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
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,
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
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
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
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:
> >
> >>
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
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
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?
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
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.
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
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
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?
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
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
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
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,
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
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.
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
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
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?:
>
>
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
> >
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:
1 - 100 of 104 matches
Mail list logo
