Marlin: marlin is growing.... why?

[boelle]

why is it that marlin with only sd card enabled does not fit a 644p any longer? it did so when we took over from Erik Zalm's own private git repro

[thinkyhead]

It often happens with development that elaboration happens first, and only afterward optimization. We could use help in the optimization department.

[boelle]

:-/ i wish i was a code gury

[thinkyhead]

Unfortunately we haven't heard anything but a few whispers for months about the size of the binary, so no one has been keeping an eye on this.

Some options are now enabled by default which probably weren't before. Try turning off every option you can find, including thermal protection, watchdog, etc. Make sure no bed leveling options are turned on.

Once you have the smallest build you can get, if it still doesn't fit, please report the size of the build and how many bytes we need to shave off to get it to fit and function on the 644p.

[Roxy-3D]

@boelle Hi! How have you been? Its been a long time since you have been around. You need to stop in more often!!!!

In regards to your question, I haven't noticed any code size problem. Marlin still fits into the 128 KB available on my PrinteRboard It hasn't expanded enough to cause any problems.

[Blue-Marlin]

Dear @Roxy-3DPrintBoard
@boelle is talking aboute 64 KB !

[Roxy-3D]

Oh! And I thought I had a low capacity board! This thinking might not be popular, but we need to be moving to higher performance (and larger capacity) processors and not spend huge amounts of time trying to squeeze new code into a miniature foot print.

why is it that marlin with only sd card enabled does not fit a 644p any longer? it did so when we took over from Erik Zalm's own private git repro

Well... Remember the SD-Card file system has been upgraded to handle long file names and such. I bet it got bigger.

[Blue-Marlin]

RCBugFix 2016/5/2 (values only valid in this sequence) (replace '.' with ',')

Plain                            -> 52.220 / 2.993 Byte
+ SDSUPPORT                      -> 68.282 / 4.201 Byte +16.062 /+1208 Byte
- THERMAL_PROTECTION_BED         -> 67.984 / 4.195 Byte    -298 /   -6 Byte
- THERMAL_PROTECTION_HOTENDS     -> 66.906 / 4.157 Byte  -1.078 /  -38 Byte -> 26 / 50% still to big
- PIDTEMP                        -> 61.924 / 3.820 Byte  -4.982 / -337 Byte -> 24 / 46%
- TEMP_RESIDENCY_TIME 0          -> 61.708 / 3.820 Byte    -216 /  +-0 Byte -> 24 / 46%
- TEMP_BED_RESIDENCY_TIME 0      -> 61.708 / 3.820 Byte     +-0 /  +-0 Byte -> 24 / 46%
- Z_SAFE_HOMING                  -> 62.216 / 3.820 Byte    +508 /  +-0 Byte -> 24 / 46%
+ DISABLE_HOST_KEEPALIVE         -> 61.654 / 3.814 Byte    -562 /   -6 Byte -> 24 / 46%
- AUTOTEMP                       -> 60.718 / 3.797 Byte    -936 /  -17 Byte -> 23 / 46%
- ENDSTOPS_ONLY_FOR_HOMING       -> does not compile // on again
- SLOWDOWN                       -> 60.580 / 3.797 Byte    -138 /  +-0 Byte -> 23 / 46%
- ENCODER_RATE_MULTIPLIER        -> 60.580 / 3.797 Byte     +-0 /  +-0 Byte -> 23 / 46%
- SD_DETECT_INVERTED             -> 60.580 / 3.797 Byte     +-0 /  +-0 Byte -> 23 / 46%
- SDCARD_RATHERRECENTFIRST       -> 60.580 / 3.797 Byte     +-0 /  +-0 Byte -> 23 / 46%
- USE_WATCHDOG                   -> 60.548 / 3.797 Byte     -32 /  +-0 Byte -> 23 / 46%
- BLOCK_BUFFER_SIZE 8            -> 60.548 / 3.181 Byte     +-0 / -616 Byte -> 23 / 38%
- BUFSIZE 2                      -> 60.540 / 2.987 Byte      -8 / -191 Byte -> 23 / 36%
+ TEMP_SENSOR_BED 1              -> 61.944 / 2.991 Byte  +1.404 /   +4 Byte -> 24 / 36%

Nothing left to deactivate or decrease. Most of this really hurts.

[Roxy-3D]

@boelle How much too big was it when you compiled the sketch? It should tell you how much space the code requires and how much is available. The reason I'm asking is there are a lot of M and G commands that the Slicers do not use. It might make sense to add some #ifdef's around them and make them go away...

If I'm reading the above post correctly, the SD Memory card stuff grew by 1200 bytes. It should not be hard to reclaim that much code space if you want to do a one-off version. I'll help you make a hacked up version if you want to do that. Kind of like the one-off we did for your printer to get the Auto Bed Leveling going.

[jbrazio]

We should ask ourselves if this is really a valid question.. what I mean is, should we continue to support old boards which are no longer the market standard ? This was exactly the same issue we had with old Arduino IDE/cores.

Indeed we need optimization, but more than optimizations we need to stay relevant on the market integrating any new features which other fw support.

[Roxy-3D]

We should ask ourselves if this is really a valid question.. what I mean is, should we continue to support old boards which are no longer the market standard ?

Agreed! But Boelle gets a pass! If he wants my help to keep his old board limping along, I want to give it to him! :) We wouldn't be doing anything in the main branches of the tree. We would just cut out some of the fat so he can have the newer code base working on his board.

[thinkyhead]

I think it's probably possible to get the code back down to a size that will fit onto a Very Small Board. We could make a special language file with shorter strings, find and eliminate redundant code (though code is usually the smaller part), and see if there are any static buffers that we can combine or place on the stack…

We simply haven't done all the optimization steps yet – not in any thoroughgoing way.

Meanwhile, another possibility for users of small boards is to stick with 1.0.2-1, while we assign someone to keep that patched and release a version 1.0.3 that still supports smaller boards but has all the bug-fixes that we've applied for 1.1.0. All someone has to do is go through the PRs one-by-one since 1.0.2-1 and apply every patch that is possible to apply.

[jbrazio]

We got to start organizing ourselves in some way..

• We have language files who aren't maintained anymore (#3360, #3357, #3355, #3354, #3349, #3348, #3347)
• We have multiple building methods for Marlin which aren't maintained or are redundant (IDE, Makefile, platformio, IDE lib)
• We have compilation bugs on old stable releases we should at least fix #3639
• We should plan a target date for releasing the 1.1.0 GA
• We need to change get maintainers for each one of the example_configs we have on Marlin
• We have too many old issues (I've been closing some of them with no negative feedback so if no one is against I will start closing old "Feature Requests" and asking people to reopen them on MarlinDev)
• We need to decide if we want to keep the current dev method of having MarlinDev completely split from Marlin or should we change to a more "rolling release cycle"
• We need more than 24h in a day :-)

@thinkyhead @Roxy-3DPrintBoard @AnHardt @CONSULitAS @Blue-Marlin @esenapaj fire at will !

[thinkyhead]

decide if we want to keep the current dev method of having MarlinDev completely split from Marlin

I think we have a good plan for the next stage of MarlinDev, building on the 1.1.0 release and reorganizing into folders similar to MarlinKimbra. I think it's probably fine to keep it as a separate repository. After all, we can still git add remote from the release repository, and move branches back and forth between them. Are there other complications I'm forgetting…?

[jbrazio]

That's clear !

I will try to explain myself, I was speaking more into the direction of how can we handle two distinct repositories and avoid what happened with MarlinDev where we reached a position that is über difficult to merge both repos to prepare the next dev cycle.

My definition of rolling release cycle is something like stable tagged releases in the branch "stable", then a "unstable" intermediate branch (currently RCBugfix) and a "development" branch.

We can tag the unstable branch with things like 1.1.0-RC5 etc.

The natural cycle is development > unstable > stable by always making sure they stay in sync.

We can keep both repositories as this process will work with as many repos we want. I just find difficult from a user's perspective to correctly open issues and post PR when we have the source code spread.

Don't know, I'm just thinking about the problem.

[Roxy-3D]

This may not be the right way to think about it... I kind of think the stable branches on the Marlin side just get bug fixes. They should get more and more stable. But on the development side when a branch with enough good stuff gets stable enough, it gets promoted to a 'Release Candidate' status and moved over to the Marlin side.

There may be problems with that thinking, but that is how I understood the plan when the two sides were formed.

[jbrazio]

There are no right or wrong ways to think about this. :-)

IMO the problem is that is not the feature which is getting stable it's the entire code base.

If we did development by branches where each feature lives in an independent branch until it gets mature.. then it's the feature's code going stable, but this method is much more helpful with large dev teams with distinct responsibilities.

[Roxy-3D]

That does sound like a better way to do things. And once enough stable new features get merged together, promote that to be a Release Candidate over on the Marlin side of the fence.

[jbrazio]

If we did development by branches where each feature lives in an independent branch until it gets mature.. then it's the feature's code going stable, but this method is much more helpful with large dev teams with distinct responsibilities.

Just to be clear: I do not agree with "dev by branches by feature" for Marlin. I was giving an example of something that would not work for us.

[thinkyhead]

avoid what happened with MarlinDev

Well the problem with MarlinDev was that it jumped the gun and tried to do a complete reorganization when we barely begun to work out the bugs and issues in the 1.1.x pre-release. Version 1.1.x should have been prioritized, while MarlinDev should have had a couple of experimental branches where we could simply play with reorganization and configurations. The experimental branches would have helped us to shake out the best ideas, which we could then apply to 1.1.x to form the basis of 1.2.x. But instead of being a laboratory for ideas it became a point of divergence.

Impatience with the process, failure to consider the collaborative nature of Marlin, and a healthy dose of hubris led to that mess.

Fortunately we still have all the good ideas and lessons learned from MarlinDev — only now we have a better starting-point. And I think we have a much more collaborative crew.

[boelle]

back.... my board is the OMC or OMCA

it has the 644p chip from atmel and a sd card on board.

if i remember with SD card en EEprom enabled it was 105%... will have to recheck

EDIT: just because a board is old does not mean it should not be supported... Erik Zalm said that his goal was that core features should still it the 644... that is of course back when we moved marlin from his personal git account... but i think the wish from him still stands

[boelle]

about the mess.... the reason for that is that there are just to many roasters in the hen house... one is more busy to show off that he has be bigger and better tool than the other... so a lot of time is wasted on endless debates that leed to nothing and the dev work is all over the place.

that was the main reason why i left... and the list of issues has not shrunk in size either

[jbrazio]

You should have a look at the "pulse" tab. Despite being a collaborative project someone must take the lead.

[boelle]

well that is what i kind of tried.... i made milestones with about 5 issues in each.. the idea was to work on those 5 alone and forget about everything else...

once they where confirmed fixed i would batch of the next 5...

but again people where just picking them and it all got out of hand....

i can take this role again.... but i will not do it if i just waste my time

of course we should all agree what issues comes first etc etc

[boelle]

but my first comment would be... why the heck a different git repro... is a branch for each different feature not enough... if the feature is voted a no no we just bring out the saw and cut the branch... just like when a tree gets sick... you trimm of the bad part

[jbrazio]

I've been deleting those milestones lately as they had no more significance.

Multiple "parallel" milestones which are not minor version objectives are a mess.

Although I agree with milestones like 1.1.1, 1.1.2, 1.1.3 etc having each one of them assigned the bug fixes of the previous milestone. But we have to wait for 1.1.0 GA to "reboot" all management system and implement something as light as possible.

[boelle]

what i had in mind..

get rid of DEV repro... lets focus on one tree and make that a good one :-D
go through issue list and close stuff that are not bug etc
cut any branches we dont need

just so we have a reasonble starting point

[boelle]

btw... the sizes...

if i just download the default RC branch like everyone else would..
set it to omca board, its 79% codespace

[CONSULitAS]

@jbrazio

We got to start organizing ourselves in some way..

Right.

• We have language files who aren't maintained anymore (#3360, #3357, #3355, #3354, #3349, #3348, #3347)

Perhaps lets start with finding maintainers? They should be at least collaborators. I could adopt the german one (with others), if needed. Look at the K8200 example. In the header i tried to document, that i try to be the caretaker for it. Update coming soon.

• We have multiple building methods for Marlin which aren't maintained or are redundant (IDE, Makefile, platformio, IDE lib)

We only need one: IDE
Because: Users (not nerds!) will not learn the other ones to update their printer.

• We have compilation bugs on old stable releases we should at least fix #3639

Perhaps not: As @thinkyhead states we are just few. Go on and don't look back.

• We should plan a target date for releasing the 1.1.0 GA

RIGHT! We will find bugs if we look for them. But if we merge, we will have more bugs. Endless story.

Proposal: Give Bugs a impact factor: critical / major / moderate / minor / cosmetic (like http://istqbexamcertification.com/what-is-the-difference-between-severity-and-priority/)

If there is no critical or major bug known lets release on 15.05.2016.

• We need to change get maintainers for each one of the example_configs we have on Marlin

Lets sort the configs in configs_maintained and configs_example. Short read me with people (care takers) to ask about the maintained ones and "at your own risk" for the example ones.

• We have too many old issues (I've been closing some of them with no negative feedback so if no one is against I will start closing old "Feature Requests" and asking people to reopen them on MarlinDev)

Right way.

But: Perhaps save the good ideas (only) on a documentation page with links to the issues.

• We need to decide if we want to keep the current dev method of having MarlinDev completely split from Marlin or should we change to a more "rolling release cycle"

Kill MarlinDev. To complicated. Nobody (except Thinky 😄) understands how to do it with github.

• We need more than 24h in a day :-)

No problem: There is a night with 12h more! 😁

[boelle]

@CONSULitAS

i think we think a like here.... we need to cut off what keeping us back

there will be bugs... but that should not hold us back from doing a release

if we fix releases to every 2 months we will just fix the bugs we can in that time... if we only manage to fix one bug then that is what we fix

[boelle]

with eeprom the codespace is now 83%

[boelle]

wooow

only 4 people left? ie that is what i can see here: https://github.com/orgs/MarlinFirmware/people

[boelle]

my thoughts on new features.... we should judge every new one.. ie how many does it benefit... is it really needed etc...

and new features should not be our job collabs.... ie they should come as a PR

we will have plenty of work on our hands allready

[CONSULitAS]

@boelle
Do you remember that i proposed (see https://github.com/MarlinFirmware/Marlin/issues/1184#issuecomment-77519521) a versioning like 2016-05?

I would prefer a release every 2 months and thats it. Marlin patch days:

• 15.01.
• 15.03.
• 15.05. --> go for it
• 15.07.
• 15.09.
• 15.11.

The next release could have the name 1.1.0 and 2016-05, like 1.1.0-2016-05 to get people used to this.

BTW: Welcome back! You where the one who brought me to Marlin. I saw your work for housekeeping around christmas 2014 and decided to be a part of it.

[emartinez167]

Most of us left or at least stopped contributing/testing or participating due to the bad nature of the guy who had hijacked this project. Happy he is gone and there is a healthier environment now.

Regards,

Ernesto

On 4 May 2016, at 19:43, Bo Herrmannsen [email protected] wrote:

wooow

only 4 people left? ie that is what i can see here: https://github.com/orgs/MarlinFirmware/people

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[boelle]

can you give a small hint on who?

[boelle]

@CONSULitAS i dont remember that much.... but the idea is good...

if i should be a part again i need some access rights to create and delete stuff

but my first vote would be to get rid of the DEV repro...

[boelle]

just enabled SD card... 109% code space

[boelle]

with bed level it jumps to 146%, but i only did enable that for the fun of it

[CONSULitAS]

perhaps people like @nophead @alexborro @fmalpartida @Wurstnase @MagoKimbra @foosel

Just a short look at the PRs of the last 2 years...

[CONSULitAS]

if i should be a part again i need some access rights to create and delete stuff
but my first vote would be to get rid of the DEV repro...

@MarlinFirmware/owners @Roxy-3DPrintBoard @ErikZalm @daid
I think @boelle asks to be a member of @MarlinFirmware/collaborators again.

👍 from me.

[boelle]

hmmm i agree that a few of those could be "bad apples"

but i will be out today at swimhall.... take a vote among the 4 left if i can be trused with access rights

[boelle]

not sure what level i need to create milestones etc... but like last time i would rather walk than destroy.

[emartinez167]

I agree on the list. I can’t remember who specifically stated the same reasons, but the important thing is that there is now a chance to rebuild the team.

On 4 May 2016, at 19:58, Jochen Groppe [email protected] wrote:

perhaps people like @nophead https://github.com/nophead @alexborro https://github.com/alexborro @fmalpartida https://github.com/fmalpartida @Wurstnase https://github.com/Wurstnase @MagoKimbra https://github.com/MagoKimbra @foosel https://github.com/foosel
Just a short look at the PRs of the last 2 years...

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/3656#issuecomment-216839132

[boelle]

and if we let new people in we should "have the balls" to get rid of bad elements so they dont destroy the environment again

and yes i speak in plain terms.... for the same reasons i dont eat candy still in the wrapping paper

[emartinez167]

Could not agree more. Don’t let a rotten apple spoil the entire basket.

On 4 May 2016, at 20:05, Bo Herrmannsen [email protected] wrote:

and if we let new people in we should "have the balls" to get rid of bad elements so they dont destroy the environment again

and yes i speak in plain terms.... for the same reasons i dont eat candy still in the wrapping paper

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/3656#issuecomment-216840509

[boelle]

:-) but can we use this thread to come up with a list of actions?

1. Delete DEV repro - Reason: We dont need it, new features could be a branch - if the branch is a no good one we do like garden people, trim it off. Pick the usefull stuff first.
2. Close all feature requests with a remark that people should submit a PR with the feature and that we simply dont have the time to create features
3. Release date is 15th in every 2 month. first time 15.15.2016. Release happens no matter how many bugs are fixed as long its a number above 0
4. Issues are only issues if they are verifiable on different hardware so that we for sure know its direct related to the firmware. If we cant verify close the issue with remark that tests should be done on different hardware.
5. IDE is the latest non-beta from arduino.cc
6. Hardware support should come in the form of a PR from the developer of the hardware. And should be keept up to date. So if IDE changes to much and the hardware is not maintained it should be either deleted or moved to a OLD folder and if still not updated it should go.
7. Mark all issues with last comment older than 2 weeks with label "Status: Waiting for feedback" in red and tell author to test with RCBugFix.
   Close issues with no feedback within 1 week.
   Similar process with new tickets if running version is in question.

please add your thoughts and i will update the list

[emartinez167]

Before DEV is deleted, can we make sure the good stuff that has already been developed there is back ported into the main repo? Not talking about the “Marlin as a library” stuff, but some new functionality like the ADVANCE logic, for example. Not sure if that is already in the current main branch.

On 4 May 2016, at 20:12, Bo Herrmannsen [email protected] wrote:

:-) but can we use this thread to come up with a list of actions?

Delete DEV repro - Reason: We dont need it, new features could be a branch - if the branch is a no good one we do like garden people, trim it off

Close all feature requests with a remark that people should submit a PR with the feature and that we simply dont have the time to create features

please add your thoughts and i will update the list

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/3656#issuecomment-216841707

[boelle]

of course... we pick the tree for the best fruits first :-)

[jbrazio]

I will close Feature Requests older than 2 months in a couple of hours as this was already on my todo list.

Killing MarlinDev.. I agree but we should listen @thinkyhead opinion about this first.

Branch dev I don't like because it will mean a lot of people need write access. We should align "veto" power with write access and do not start giving it away (in the past a lot of issues happen by people deleting branches as far as I can tell).

[boelle]

about write access.... i will not agree here.

people can submit PR's and we can either merge or reject.

[boelle]

what we have ahead of us can be very well illustrated with the apple tree's outside my flat.

they have been allowed to grow out of control and the care taker have not trimmed them.

result is that the apples do not grow to a size where you can eat them as the tree has to feed too many... so when they finally do drop they are half rotten already

we need to cut the number of repos and trim the remaing repo to a size we can manage with the number of people we have left.

our advantage is that we live on different places so we can get benefits from the time zones. one can take over code work while the other sleeps

[jbrazio]

Wait.. write access is different from a PR, write access means direct merge on the repo.

[boelle]

ahh... agree.... direct merge should not happen anyway if it can be avoided... if i remeber correct a PR is more easy undone

[boelle]

so far i have added 6 points to my list...

have i missed something important?

[CONSULitAS]

pick the best fruits

agreed

Close all feature requests

agreed, and:

6. Mark all issues with last comment older than 2 weeks with label "Status: Waiting for feedback" in red and tell author to test with RCBugFix.
Close issues with no feedback within 1 week.
Similar process with new tickets if running version is in question.

[boelle]

well i'm off for a few hours :-D

we should also have a permanent google hangout we can use for dev contact so er dont spam with issues

[boelle]

@CONSULitAS

your point 6 is added to my list as point 7

[boelle]

o&o

[CONSULitAS]

Ok its topic 7. not 6.

Hangout: The old one? https://plus.google.com/hangouts/_/gxn3wrea5gdhoo223yimsiforia

[CONSULitAS]

last Hangout issue: https://github.com/MarlinFirmware/Marlin/issues/2583

[Roxy-3D]

about the mess.... the reason for that is that there are just to many roasters in the hen house... one is more busy to show off that he has be bigger and better tool than the other... so a lot of time is wasted on endless debates that leed to nothing and the dev work is all over the place.
that was the main reason why i left... and the list of issues has not shrunk in size either

I don't know, but my guess is there were people involved that cared more about dominating others than pulling Merlin to new heights.

well that is what i kind of tried.... i made milestones with about 5 issues in each.. the idea was to work on those 5 alone and forget about everything else...

This topic is well worth having a full and deep discussion. It might be better to do this off-line but we can start here and see who wants to be involved in a deeper discussion. The part of this I'm having difficulty understanding is this: Does this work in an Open Source Development Community? This is very realistic in a company where they are paying salaries and each software developer has a manager assigning him tasks. But when we are getting people to donate their time and effort, we lose the ability to specify what they work on.

Please help me understand how we get there from here. And I'm not trying to be a Nay-Sayer. I'm trying to understand the topic. My guess is there are Open Source Development projects that do operate with this model. Can somebody name a few and describe the Pro's and Con's ? That would be very helpful to me.

once they where confirmed fixed i would batch of the next 5...
but again people where just picking them and it all got out of hand....

Yes. That is the part I need help understanding. How do we get people to want to work on items that the project leaders say is needed? People tend to want to work on the things that interest them. As suggested up above, part of the answer might be to find a highly motivated person that is interested in maintaining the language files. And find somebody else that is interested in the transition to 32-Bit processors to drive that effort. It maybe that it makes sense to post 'Job Openings' and see if we can get people to apply for a given position. It is worth a discussion.

of course we should all agree what issues comes first etc etc

Right now, in my mind, there are 4 big topics.

• Get RC-6 buttoned up and make it Golden. (It is close but it really should be super stable with hardly any outstanding bugs. @ThinkyHead has gotten it to its current state almost by himself. A big Thank You! to him. )
• Get what ever code base we are going to use for future development re-organized. There have been a number of discussions on this and right now the 'Best Thinking' is we will take the Golden, Stable Release when that gets defined and start slicing it up into a form similar to MarlinKimbra. We initially thought it might make sense to cross the bug fixes over from the Golden Release to MarlinKimbra but the problem is that it is too old. It is missing too much and it will be easier and more straight forward to take our Golden Release and just copy the work that has been done to slice it up and make it more modular and orgainized.
• Unify the Auto Bed Leveling. Right now we have #ifdef's nested 27 levels deep. I think it is possible to have them all combined into one module. That will help clean up the code immensely while at the same time giving the user much more control over their printer. (Think about how nice it would be to have a high resolution mesh defined for your build plate while still being able to perform a 3-Point leveling correction.)
• Start an active program to migrate to a Higher Performance microprocessor. We can learn from MarlinKimbra on this topic also. We would still support the older platforms. But many machines (especially the Delta's) need more crunch power.

[MagoKimbra]

Unfortunately, being alone can not keep up with the changes made in Marlin for the different structure.
But to say old MarlinKimbra would not say...
MK4due version 4.3.x_dev has the heater objects with the possibility of having in any combination, including 6 objects Hotend, Bed and chamber.
It is already almost ready the possibility of having as objects the axes and the extruders, with the possibility of having up to 6 axes and up to 6 extruders.
It has the handling of a laser and also already provided for the use of CO2.
Support Nextion TFI, support mixer color, support reader TAG on filament.
As I said I am always available for any help you can give ...
Thank's and exusme for my bad english...

[jbrazio]

The part of this I'm having difficulty understanding is this: Does this work in an Open Source Development Community?

IMO it does not work to have "parallel" milestones (I've been deleting what was left of this "theory" from Github over the past couple of weeks), it works having one target milestone by version and have multiple development branches targeting that milestone. On a Open Source project people work by love not by a target defined by the "boss", people donate love and say "I will do this for the next minor/major release", we have to collect the love and make it a milestone, not the other way around.

I agree deleting MarlinDev repo.. I do not agree creating a 32bit fork of Marlin. We need to (1) abstract the current Marlin8 code, (2) build the HAL, (3) start developing Marlin32 in the same repo.

Close all feature requests with a remark that people should submit a PR with the feature and that we simply dont have the time to create features

This was already planned and I've finished a couple of minutes ago, result: 35 open issues, 16 open pull requests.

Release date is 15th in every 2 month. first time 15.15.2016. Release happens no matter how many bugs are fixed as long its a number above 0

I do not agree with this point, as we stand now this will only create confusion and it's doomed to fail (do I have to get the milestone example again ?), but somewhere in the future I can see it being possible.

IDE is the latest non-beta from arduino.cc

This is already implemented with #3462, we decided to support latest major.

[Roxy-3D]

Unfortunately, being alone can not keep up with the changes made in Marlin for the different structure. But to say old MarlinKimbra would not say...

My apologies... That was poorly worded. MarlinKimbra forked a long time ago. And to cross over all the changes that have happened in Marlin since then would be a huge (debugging) effort.

For the record: The people that know think MarlinKimbra ROCKS!

[MagoKimbra]

You excuse me you are right from that point of view ...
Unfortunately when marlindev decided to go on a structure, which frankly I did not like, I'm a bit went on my way. So I know that my version is not the standard ...
Thank's ....

[boelle]

my only goal with the milestone thing is to make sure bugs are fixed and not forgotten

and to make sure that the dev work does not run of track

[boelle]

as for the hangout.... will check if the old one allows text chat

EDIT: nope that was for video, best to create a new one here: https://hangouts.google.com/

[Roxy-3D]

IMO it does not work to have "parallel" milestones (I've been deleting what was left of this "theory" from Github over the past couple of weeks), it works having one target milestone by version and have multiple development branches targeting that milestone. On a Open Source project people work by love not by a target defined by the "boss", people donate love and say "I will do this for the next minor/major release", we have to collect the love and make it a milestone, not the other way around.

This makes some sense to me. And just to help me understand, if we have multiple development branches all targeting a milestone, do we merge the branches together towards the end as we get close to the milestone?

I agree deleting MarlinDev repo.. I do not agree creating a 32bit fork of Marlin. We need to (1) abstract the current Marlin8 code, (2) build the HAL, (3) start developing Marlin32 in the same repo.

Nobody said a 32-Bit fork of Marlin. Hopefully it can be done with a HAL and a few #ifdefs's. We really want one main body of code (that is clean and handles everything).

Release date is 15th in every 2 month. first time 15.15.2016. Release happens no matter how many bugs are fixed as long its a number above 0

I do not agree with this point, as we stand now this will only create confusion and it's doomed to fail (do I have to get the milestone example again ?), but somewhere in the future I can see it being possible.

I am concerned that we wouldn't even know what the bugs are if we are releasing on a set date. With more people, we may be able to do that and it would be easy to generate enthusiasm if every two months there was a better, more feature rich, fully debugged (and documented) release. But right now that would be very difficult to accomplish.

With that said... With a better organizational structure and clearly helpful process in place, we may attract the talent it takes to get there.

my only goal with the milestone thing is to make sure bugs are fixed and not forgotten
and to make sure that the dev work does not run of track

Everything that can be done to reduce bugs needs to have a very high priority. The users want their printer's to work reliably more than they care if some new crazy feature is in the code. But once again, this is the problem mentioned up above. Getting people more focused on bug fixes than developing new features.

In a sense, we have a bug fix mile stone right now trying to get RC-6 to go Golden. That is all about getting the code base solid and stable. We have not been totally religious, but pretty much, since RC-3 it has been only bug fixes and nothing new.

[boelle]

we should only have branches for testing stuff.... as soon the testing is done the branch goes...

my idea for milestone is for the main branch only

but lets figure what next step is... but PLEASE dont drag this in to a novel long debate. It will quickly start to look like individuals want to drag it in their direction

[boelle]

can we start by agree on and follow it through?

Delete DEV repro - Reason: We dont need it, new features could be a branch - if the branch is a no good one we do like garden people, trim it off. Pick the usefull stuff first.

[jbrazio]

@Roxy-3DPrintBoard if we have multiple development branches all targeting a milestone, do we merge the branches together towards the end as we get close to the milestone?

@boelle we should only have branches for testing stuff.... as soon the testing is done the branch goes...

A bit of context first, I will assume three main branches stable, unstable and development:

• stable is the current release branch using "tags" to mark each stable release (1.1.0, 1.1.5, 1.2.7 etc)
• unstable is the bugfix branch were we publish what will be part of the next stable so people can test and comment and do whatever they want, still using tags like (1.1.0-RC1, 1.1.5-RC4, 1.2.7-RC3 etc)
• development will be where all new stuff happens.

A milestone defines when unstable will become a new tagged stable release.

When a new idea comes in a new branch is created, as an example development-new_shinny_feature but we still have to deal with parallelism.. and in order to avoid giving write access to everyone, people helping out with this new shinny feature should submit PR requests against the development-new_shinny_feature branch, otherwise only one developer at a time can work on a specific new feature.

Delete DEV repro - Reason: We dont need it, new features could be a branch - if the branch is a no good one we do like garden people, trim it off. Pick the usefull stuff first.

I'm all in.. but let's wait for @thinkyhead. ;-)

but lets figure what next step is... but PLEASE dont drag this in to a novel long debate. It will quickly start to look like individuals want to drag it in their direction

Can you explain how can we figure ou(t) what will be the next step if people are unable to speak what they believe i(s) best ? hum..

[CONSULitAS]

UTC times see https://github.com/MarlinFirmware/Marlin/issues/2583

[boelle]

go to https://hangouts.google.com/

[thinkyhead]

The hangout was very good. Thanks everyone!

A lot to read here… I will scan this offline tonight and comment tomorrow.

[boelle]

you should have an invite.... @everyone.... please remove emails if you dont like spam :-D

[Roxy-3D]

Thank You for taking the lead on this @boelle! I'm sorry I missed it. It is good to get the group discussions going again. Did anybody keep meeting notes? Was there general agreement on some topics? Was more discussion needed on other topics?

[boelle]

Q: what access levels are there besides owner?

[Roxy-3D]

Q: what access levels are there besides owner?

I don't know the full set of facts. But GitHub changed the Owner's from a Team into a Role. Just below Owners are Admins. They can add or delete both team members or privileges. They can also create Teams within their repository. And then lastly, there are Team Members. There are default privileges for each team when a person is assigned to that team. But the privileges are granular and can be set different for each individual.

And... It seems to add up all the individual team privileges a person has and gives that set to a person.

[boelle]

i was asking @Roxy-3DPrintBoard

wonder why she cant get to the group chat

anyway dinner time... will be back in 2 hours or so

[thinkyhead]

As I said I am always available for any help you can give

@MagoKimbra As soon as 1.1.0 is out and we start on 1.2 with the new file structure, we will also begin to organize the code into more discreet classes in a style similar to MarlinKimbra, but not guaranteed to be identical. The first priority will be the file organization.

With the main Marlin branch, we couldn't really "leap ahead" and start instituting all kinds of changes to the code, not until the code had been cleaned up considerably. Today we are at a better place, and most of the code is pretty good-looking (if I do say so myself). MarlinDev was one individual's pet project, which should have remained in a fork, far far away, and many of us regret that it wasn't shut down sooner.

Today I feel we have more level heads, far less egotism, and a much better starting-point, especially with Arduino finally supporting subfolders. No one is going to be allowed to berate, cajole, and whinge the project into "massive overhauls" without feedback again!

[boelle]

@thinkyhead you had any trouble with hangouts today? @Roxy-3DPrintBoard seems to not be able to get in the group chat.... i have sent multiple invites

[tiagom62]

Strange.. Posts were deleted..

No longer experiencing those errors in hangout. I now see Bo, but no conversations.

[boelle]

who deleted posts in here?

@thinkyhead ??

[boelle]

but screw it... this thread has served its purpose, closing it

[thinkyhead]

Yes, I deleted posts relating to immediate concerns: "How can Bob connect to the Hangout? Hey, send me your email address." But if the thread is done, sure, close it.