This is a reminder to all lead developers. The 5.1 branch is limited to
the UI improvement work that Jeff has been doing and the galification of
Eeschema to fix the gtk3 issue. All other new features should wait for
version 6. I appreciate your enthusiasm but I do not want this policy
changed wi
On 7/17/2018 12:12 PM, Seth Hillbrand wrote:
> Hi Wayne-
>
> Just so I'm clear on how you'd like this to work:
>
> We have a commit that affects 5.0.x, 5.1 and 6. We could do
> 1) git checkout master
> 2) git commit (get back)
> 3) git checkout 5.1
> 4) git cherry-pick
> 5) compile/test
> 6) g
Hi,
> This will get 3 separate SHA (one for each branch). Or would you prefer
> us to use git merge to keep the original SHA with an additional merge
> commit? I can see arguments for each but wanted to check which is
> preferred.
To make merge commits work, they'd have to be based on the commo
Hi Wayne-
Just so I'm clear on how you'd like this to work:
We have a commit that affects 5.0.x, 5.1 and 6. We could do
1) git checkout master
2) git commit (get back)
3) git checkout 5.1
4) git cherry-pick
5) compile/test
6) git checkout 5.0
7) git cherry-pick
8) compile/test
9) git push
Th
Just a quick reminder to the lead developers, if you push a bug fix into
the development branch that effects the 5.0 and 5.1 branches, please
don't forget to push the fix to the 5.0 and 5.1 branches.
Thanks,
Wayne
___
Mailing list: https://launchpad.ne
I'm seeing more new and not so new developers submitting patches to the
developers list and/or bug reports that change the current behavior of
KiCad both internally and/or externally. Here is an example
https://bugs.launchpad.net/bugs/1500570. It is *always* a good idea to
get input from the deve
There is a separate branch and the only back ports after the stable
release will be critical bugs. As of my recent announcement, there
should be some happy admins.
On 9/12/2015 6:36 PM, Cirilo Bernardo wrote:
> I had the impression that it would be a separate branch and that a number
> of people
I had the impression that it would be a separate branch and that a number
of people would back-port any necessary patches but no new features may
be introduced. I think that arrangement would keep your generic package
maintainers and sysadmins happy; we've had so many complaints from
people about t
Would be possible to also use tags in the GitHub mirror? GitHub allows you
to do something like this to get a tarball:
https://github.com/KiCad/kicad-source-mirror/tarball/4.0-rc1
Could potentially save some time/effort in manually maintaining tarballs?
I'm not sure if Launchpad has a similar fu
As it is now it looks kind of seperate. Is that right? It makes more
sense to me that the branch is branched out from product (I guess this
is what you might be calling linked to). I am not too familiar with
bzr.
2015-09-12 21:37 GMT+02:00 Wayne Stambaugh :
> I created the new series on Lauchpad a
I created the new series on Lauchpad a few hours ago. I still have to
decide whether to link it to the product branch or make it a separate
source branch. I'm still trying to wrap my head around it as well as
get these last few dialog fixes committed.
On 9/12/2015 3:33 PM, Jon Neal wrote:
> So I
So I don't think it is Friday in any part of the world anymore.
Any update on the branch? :)
Jon
On Sat, Sep 12, 2015 at 12:18 PM, Nick Østergaard wrote:
> For your (and others) information, in the current moment of writing this
> email, there are no more critical or high bugs on the tracker.
For your (and others) information, in the current moment of writing this
email, there are no more critical or high bugs on the tracker.
2015-09-08 21:34 GMT+02:00 Wayne Stambaugh :
> I think the current situation is as good as we can hope for as far as
> blockers for rc1. I'm going to try to creat
I think the current situation is as good as we can hope for as far as
blockers for rc1. I'm going to try to create a new version 4 stable
release series on Launchpad Friday if no new show stoppers crop up.
Periodically I will merge any bug fixes from the product branch into the
4 stable series bra
Wayne, was it your intention to include the incomplete bugs in the
blockers for rc1? I mean, incomplete bugs are bugs that have a
potential to be revived, but where the developers are not really
supposed to spend more time on them until some feedback are given.
I personally don't think they should
For the stable release I will create a source archive of some sort. If
time permits, I'll try to create them for the rc branches as well.
On 9/8/2015 1:37 PM, Ian Woloschin wrote:
> Hooray for already solved problems! :D Too bad the baby is still
> sleeping. Time for new things to solve!
>
>
Why don't you target a git or bzr tag--probably easier to reuse the work
for a "nightlies/fresh" ebuild as well.
Adam Wolf
On Tue, Sep 8, 2015 at 12:37 PM, Ian Woloschin wrote:
> Hooray for already solved problems! :D Too bad the baby is still
> sleeping. Time for new things to solve!
>
> Fo
Hooray for already solved problems! :D Too bad the baby is still
sleeping. Time for new things to solve!
For the Gentoo ebuild, will the project consider releasing a source
tarball, or is it just going to be a bzr (...git?) tag in the appropriate
repository? I don't think it matters, I believe
Ian, I think you are right. I think everything is already done, except me
putting the "issue a PR" into Jenkins so it happens periodically.
Adam Wolf
On Tue, Sep 8, 2015 at 12:31 PM, Ian Woloschin wrote:
> I think that there should be an easy to grab DMG that can be installed,
> but it appear
I think that there should be an easy to grab DMG that can be installed, but
it appears to be trivial to use homebrew casks to "automate" the process.
Keep in mind, casks are *not* compiling anything, they're just grabbing
pre-existing binaries because it makes it "easier" (for CLI folk) to
install
The DMGs are not going away and are the primary method for KiCad on OS X.
I'm not going to spend my limited time supporting folks who want to compile
KiCad on their own on OS X, but I'm also not going to hide or obsfucate any
of the helper scripts I use to build it.
On the other hand, it looks li
> On Sep 7, 2015, at 9:13 AM, Bernhard Stegmaier
> wrote:
>
> Hi,
>
> a small note on homebrew (or, MacPorts) for OS X:
> The problem is, that you need a special patched wxWidgets for KiCad.
> So, you can’t (no, you can’t) use the stock one such a package system
> provides - and you probably
I'm just an user but...
Please make RC1, call it Beta or whatever you might prefer to call it. But
there needs to be a mainstream release to be tested easily by users and
report feedback.
Linus Torvalds said "Release early, release often".
https://en.wikipedia.org/wiki/Release_early,_release_oft
Hi Adam,
I was doing a bit of research and found this:
https://github.com/caskroom/homebrew-versions/blob/master/Casks/kicad-nightly.rb
I believe it's only pulling down the binaries, and not the libraries
(that's the kicad-extras package, right?). I think that's fine, the idea
being that if you
Hi Ian,
I think the homebrew cask can point at a dmg on the web, and us packaging
folk have already been discussing implementing a non-changing URL redirect
that points you to the latest build on your platform.
If you find out homebrew cask can pull from a dmg via HTTP (htttps...), let
me know an
I also agree about just branching now. It seems like there will be a
continuous cycle of development continuing to happen and patches/code
changes being squeezed in causing a bug or two, which lengthens the time to
RC, more patches, more bugs, more time..
Jon Neal
On Mon, Sep 7, 2015 at 4:14 PM,
Haha, no worries. I'm juggling my phone/laptop and newborn daughter, so if
my emails are gibberish I blame a flailing newborn limb. Or lack of
sleep. On the plus side, 2 weeks of paternity leave, and as long as the
baby is sleeping I need something to keep me busy!
I'll start off trying to do a
Ha! That's what I get for not refreshing my email client before hitting
send...
On Sep 7, 2015 11:18 AM, "Adam Wolf" wrote:
> I think there already is a homebrew recipe.
>
> It would be nice if someone would make a homebrew cask recipe for my
> nightly OS X builds... ;)
>
> Adam Wolf
> On Sep 7,
I think there already is a homebrew recipe.
It would be nice if someone would make a homebrew cask recipe for my
nightly OS X builds... ;)
Adam Wolf
On Sep 7, 2015 10:07 AM, "Ian Woloschin" wrote:
> User here. I'd be happy to try and release a Gentoo ebuild in an overlay,
> but I'd want an RC
How about homebrew casks? If Adam can build the RC then a cask can pull
that down instead of building from source.
-Ian
On Mon, Sep 7, 2015, 12:13 PM Bernhard Stegmaier
wrote:
> Hi,
>
> a small note on homebrew (or, MacPorts) for OS X:
> The problem is, that you need a special patched wxWidgets
Hi,
a small note on homebrew (or, MacPorts) for OS X:
The problem is, that you need a special patched wxWidgets for KiCad.
So, you can’t (no, you can’t) use the stock one such a package system provides
- and you probably cannot easily provide your own one because it might
interfere with the orig
User here. I'd be happy to try and release a Gentoo ebuild in an overlay,
but I'd want an RC first, versus live ebuilds, which kind of suck, since I
believe they force a fresh build for every source update. I'd also be
somewhat curious about trying to do a homebrew package for OS X, but from
lurk
Indeed. Also by making an release candidate might motivate packagers
to prepare packages for their system, and then we can catch some
potential problems, and possible get some input to address them for
the release.
2015-09-07 14:33 GMT+02:00 Chris Pavlina :
> I second this. Just make the branch! T
I second this. Just make the branch! The bugs keep piling in anyway, and
most of them are minor - barely reproducible. We're as ready as we'll ever
be!
On Sep 7, 2015 6:00 AM, "Brian Sidebotham"
wrote:
> My humble suggestion is to just create the RC1 branch now because I've
> been through all of
My humble suggestion is to just create the RC1 branch now because I've
been through all of those bugs, and they're all either incomplete or
not repeatable for me. In which case we need more information in order
to be able to fix them.
In order to get more information, it's better to have a larger
This is a reminder to *all* developers, please do not send any patches
or merge requests unless it is specifically to fix an existing bug
report. Also, please don't bother fixing the build scripts or any of
the CMake dependency library build code as they will be removed during
the next development
36 matches
Mail list logo
