On Nov 21, 2014 10:08 AM, "Jonathan Aquilina"
wrote:
>
> The first one you linked :)
So all apple bugs?
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Busines
The first one you linked :)
On Fri, Nov 21, 2014 at 3:47 PM, Tres Finocchiaro <
tres.finocchi...@gmail.com> wrote:
> > I am wondering if we shoudl use http://www.stack.nl/~dimitri/doxygen/
>> this will using doxygen coding standards will also allow us to generate
>> documentation from the code hi
>
> > I am wondering if we shoudl use http://www.stack.nl/~dimitri/doxygen/
> this will using doxygen coding standards will also allow us to generate
> documentation from the code hitting two birds with one stone here.
Jonathan, which bug did you choose to start in on?
-Tres
- tres.finocchi...@
We already do.
2014-11-21 6:40 GMT+01:00 Jonathan Aquilina :
> I am wondering if we shoudl use http://www.stack.nl/~dimitri/doxygen/
> this will using doxygen coding standards will also allow us to generate
> documentation from the code hitting two birds with one stone here.
>
> On Fri, Nov 21, 2
On 11/21/2014 07:05 AM, Spekular R wrote:
>
> Haha. I've commented for myself when doing stuff but I was gonna
> remove it before committing anything since it's usually really basic
> stuff. Should I keep my comments around, even ones that just explain
> what really basic stuff is?
>
Yes
I am wondering if we shoudl use http://www.stack.nl/~dimitri/doxygen/ this
will using doxygen coding standards will also allow us to generate
documentation from the code hitting two birds with one stone here.
On Fri, Nov 21, 2014 at 6:05 AM, Spekular R wrote:
> Haha. I've commented for myself wh
>
> > Should I keep my comments around, even ones that just explain what
> really basic stuff is?
Good comments are a fine skill. Probably best to commit them and risk the
chance a dev asks them to be shortened then never make them at all.
- tres.finocchi...@gmail.com
On Fri, Nov 21, 2014 at
Haha. I've commented for myself when doing stuff but I was gonna remove it
before committing anything since it's usually really basic stuff. Should I
keep my comments around, even ones that just explain what really basic
stuff is?
Now, if we really want to lower the barrier of entry for would-be
developers, there's one thing we could do...
Comment the code. We should have a commenting marathon, where everyone
takes some time to go through all of the code that they know how it
works, and add commentation.
Our code commentat
>
> I don't think it's related...
>
I should have linked my comment
1. Open LMMS
2. Maximize the Song Editor on the default blank template
3. Open a project that was previously saved (via Project, Recently
opened projects)
4. *When the project loads, it makes the default Song
On 11/20/2014 06:41 PM, Tres Finocchiaro wrote:
> @Vesa,
>
> https://github.com/LMMS/lmms/issues/1249
I don't think it's related...
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instan
@Vesa,
https://github.com/LMMS/lmms/issues/1249
- tres.finocchi...@gmail.com
On Thu, Nov 20, 2014 at 11:17 AM, Vesa wrote:
> Ok, here's one very annoying bug that I'd really like solved - but don't
> have the time to work on myself...
>
> The bug where, when loading a project, window positions
Ok, here's one very annoying bug that I'd really like solved - but don't
have the time to work on myself...
The bug where, when loading a project, window positions get loaded
incorrectly. Usually it's the song editor, which goes to overlap with
other windows. Possibly there's something wrong with
Here is just an idea here @tres. Any changes for apple we push them
directly into master and cherry pick for the given stable branch.
On Thu, Nov 20, 2014 at 3:37 PM, Tres Finocchiaro <
tres.finocchi...@gmail.com> wrote:
> I'll clarify a bit...
>
> all the mac work does that get thrown into maste
I'll clarify a bit...
all the mac work does that get thrown into master
I've always targeted the Mac stuff for the current stable branch because
they are all observable and reproducible bugs. Since we continue to offer
patches to our current stable releases for bug-fix scenarios, Apple fixes
ar
Target stable-1.1 for now. Well discuss the branch destination again on
the pull request. There's too much I'm the air to know for sure which
branch should be targeted. We should see the changes before making that
call.
i will join you on the apple bugs :) What I am not totally clear on though.
all the mac work does that get thrown into master? and then finds its way
into a stable branch when we create the new stable branch?
On Wed, Nov 19, 2014 at 5:52 PM, Tres Finocchiaro <
tres.finocchi...@gmail.com> wrote:
>
>
> > They have certain tasks which they like to call easy hacks. They
> classify them according to difficulty and how much programming know how one
> needs.
I think if you've been following the discussion on our bug tracker and our
mailing list you will notice we have many of these easy hacks an
Jonathan Aquilina wrote
> Do you guys think this would be a good thing to have and maybe list them
> on
> the website?
I think it would be a tremendious idea! -But theres is a crevat. It would
mean that some really strong develloper went through all the tickets, and
marked the tickets in difficul
Iirc there's a list of these on the wiki. They're probably outdated though
and maybe they could be moved somewhere more visible.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly S
This is an idea that I kinda have taken from the Libreoffice project,
They have certain tasks which they like to call easy hacks. They classify
them according to difficulty and how much programming know how one needs.
Do you guys think this would be a good thing to have and maybe list them on
the
21 matches
Mail list logo
