Code Sprints Anyone?

[thinkyhead]

One way to push through lots of extant issues and pull requests is by setting milestones and doing periodic code sprints. Marlin is now developed by a large enough group that it seems like this could be doable. Initial sprints would focus on integrating support for printers already in the pull request queue, then feature or improvement milestones can be set later on. There might even be enough developers here in my city (Seattle) that we could do some coding sessions in person.

Then Marlin can start getting some version tags, and we could even start a 2.0 branch that brings more beauty to the code and lets the C++ optimizer do the work of pruning unused root methods, etc. It would be good to start dealing with things like configs, "lcd_implementation" headers, pins.h, language.h, and other files that are becoming unwieldy.

Obviously such big change is hard to make in the active release branch, but a 2.x branch would allow for some more serious reform. Where the planner is already optimal we don't need to mess around, but the less important and less-often-executed portions of the codebase can benefit from leveraging C++ and would make it cleaner and more consolidated to add new hardware, language, and feature support.

[boelle]

not a bad idea at all.... i recently became a collab mainly to help out with the long list of pull requests...

but most of them cant be merged automatic and a lot of them are so old that i can only guess what it would break to merge them if possible at all...

So at least a cleanup in the pull requests so those that should never be merged are closed and those that can be merged but need work are marked so....

then an initial sprint to get all open pull request done

set a milestone

then work on issues that are open if they have not been fixed allready

new milestone and maybe a new branch??

[boelle]

i have started on this one... not a coder myself but have created a 3 branches so we have a 4 in total

bug fixing testing stable

we just need people to work on the code... clean it up, fix issues etc etc... they dont have to be collabs, we can do that...

[thinkyhead]

We should document what each of these branches is for someplace - maybe in the main Marlin wiki - or at the top of the Marlin project page.

[thinkyhead]

@boelle From my POV as a contributor, I make my own feature branches based on my fork's unaltered copy of Marlin_v1, and then I submit them with the assumption that the changes will end up being applied to Marlin_v1 – but I had only assumed so because there's no "master" branch, so I figured Marlin_v1 was serving that role….

So, does this make it so that from now on we must base new feature (or bug fix) branches on one of these branches instead of Marlin_v1? And, will this cause pull requests from our forks to apply to the upstream branches that they were originally based upon? (Will we need to git remote add upstream for any of these branches?)

The problem I see for collaborators/maintainers is that these branches will go out of sync, the original pull requests will be forgotten, and there won't be a formal process for moving things out of bug_fixing over to testing, and deciding what belongs in stable.

So, what are you thinking with respect to these issues?

[boelle]

what i was thinking was that we fix a few bugs, then test, then fix a few more and test again until the issues list is empty.... then do maybe a month long test and move it to stable...

2014-12-23 5:38 GMT+01:00 Scott Lahteine notifications@github.com:

@boelle https://github.com/boelle From my POV as a contributor, I make my own feature branches based on my fork's unaltered copy of Marlin_v1, and then I submit them with the assumption that the changes will end up being applied to Marlin_v1 – but I had only assumed so because there's no "master" branch, so I figured Marlin_v1 was serving that role….

So, does this make it so that from now on we must base new feature (or bug fix) branches on one of these branches instead of Marlin_v1? And, will this cause pull requests from our forks to apply to the upstream branches that they were originally based upon? (Will we need to git remote add upstream for any of these branches?)

The problem I see for collaborators/maintainers is that these branches will go out of sync, the original pull requests will be forgotten, and there won't be a formal process for moving things out of _bugfixing over to testing, and deciding what belongs in stable.

So, what are you thinking with respect to these issues?

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1184#issuecomment-67921401.

[boelle]

or a simple text file named branch_names_vs_function ?

2014-12-23 1:17 GMT+01:00 Scott Lahteine notifications@github.com:

We should document what each of these branches is for someplace - maybe in the main Marlin wiki - or at the top of the Marlin project page.

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1184#issuecomment-67908139.

[thinkyhead]

Sounds like a good –not to mention simple– plan. I don't mind seeing the branches and other things documented in README.md since it's the most likely to be found and propagated. But if it helps to write up some things on the Marlin page at RepRap wiki, post on the RepRap forums, and make a screencast about changes on YouTube, then we should do all that stuff too.

[boelle]

just did a rewrite of the notes in readme.md.... does it look total off?

2014-12-23 11:29 GMT+01:00 Scott Lahteine notifications@github.com:

Sounds like a good –not to mention simple– plan. I don't mind seeing the branches and other things documented in README.md since it's the most likely to be found and propagated. But if it helps to write up some things on the Marlin page at RepRap wiki, post on the RepRap forums, and make a screencast about changes on YouTube, then we should do all that stuff too.

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1184#issuecomment-67938440.

[thinkyhead]

From one of our other conversations, there might be confusion about what the "stable" should mean. Should this branch include a set of tagged releases, each of which is guaranteed only to change for bug fixes, or should it be a branch which only has the latest code we're confident about? I guess, so far, we haven't given too much thought to versioning. In some ways it creates additional maintenance headaches. (Users might expect someone to be able to provide them a bug fix for an old tagged version.) But I gather that the aim is to provide one (monolithic) code base which will include backward support for everything it possibly can.... So except for some major overhaul - a Marlin 2 for example - I'm not too attached to formal versioning.

Anyway, I have a pull request #1230 with some language tweaks that I've just posted for your top notes in the README. You can view it at https://github.com/thinkyhead/Marlin/tree/readme_tweak

[boelle]

hmm.... i think for each move from development to stable we could add the date to it somehow... like _23/12/2014?

but we only provide "support" for the last one or 2?

[thinkyhead]

Tag each one with the name of some sea life?

I can't wait for "jellyfish." I hope it's better than "seahorse" and "krill."

[boelle]

that could be a way yes

[boelle]

@thinkyhead in your initial post you mentioned that there might be enough dev people in seattle that you can do some coding "live" ?

by all means bring along as many you can :-D first milestone already set

[thinkyhead]

Keeping it in mind! As soon as all this holiday hullabaloo settles down....

[boelle]

hehehehe...

and if the people you have in mind still have 10 fingers in 2015 :-D

[boelle]

oh.... you seen the milestone i made? you think 2 months for the 4 issues there are enough?

[stv0g]

Nice idea, I'm in.

We should find some convenient way to communicate: IRC, MailingList? Ideas?

[boelle]

or here?

Den tirsdag den 6. januar 2015 skrev Steffen Vogel <notifications@github.com

:

Nice idea, I'm in.

We should find some convenient way to communicate: IRC, MailingList? Ideas?

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1184#issuecomment-68846534.

[boelle]

hmmm... looking at a irc channel

marlin-firmware

marlin

both are free.... other ideas?

[boelle]

for now #marlin-firmware it is

[alexborro]

Skype??

2015-01-06 8:56 GMT-02:00 Bo Herrmannsen notifications@github.com:

for now #marlin-firmware it is

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1184#issuecomment-68852001.

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

[stv0g]

Personally, I need a quiet environment for coding. But I’m not sure about the goal of such a sprint.

It’s about coding together or planning the future?=

[alexborro]

By skype I mean chatting.. I think we can have each one on skype to discuss any subject or solve any doubt..

2015-01-07 11:27 GMT-02:00 Steffen Vogel notifications@github.com:

Personally, I need a quiet environment for coding. But I’m not sure about the goal of such a sprint.

It’s about coding together or planning the future?=

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1184#issuecomment-69021174 .

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

[boelle]

if not there are IRC channel #marlin-firmware on freenode

skype is more 1 to 1 chat... google hangouts can at least support up to 9 users... and does not have to be video

[monkeydave]

Google hangouts has a limit of 100 people in a chat

[boelle]

oh, is that also for video hangouts? or is it 9 for video and 100 for text only?

[boelle]

but i think @thinkyhead intention for this was to gather up some issues and then do them in "sprints" say over a weekend or so

[thinkyhead]

@stv0g Well, the real purpose of a sprint is to identify one or two issues, and then gather resources to focus on those. Sometimes it means fixing a broken feature, sometimes it might mean bringing code up to speed with the latest Arduino libraries, or we may identify core problems, such as managing I2C communication with dumbed-down thermocouples. Or, just pick some of the trickier issues in the queue and bang on them semi-collaboratively for a period of time.

@boelle Milestone Bug Fixing Round #2 is cleared already, and there are only a couple of bugfix PRs in the queue. No serious issues that I am aware of today.

I'm contemplating how we can implement a "code freeze" – basically only allowing bug-fix commits for a period of time while deferring new features – and then having a test round before tagging a new version 1.0.3. I'm particularly interested in getting the new tag set before merging #1456 particularly, since this is a relatively major change – not that we've shied away from allowing some less-tested code into Development for the community to debug.

Perhaps it makes sense to start a new branch for this purpose. Then bug-fixes can be applied to a "beta-103" or "rc-103" branch, while still allowing new features to go into the Development branch during the test period. Once the beta branch seems solid, we can add a "1.0.3" tag to the code and move forward to the next set of milestones.

[boelle]

i have poked arround a bit and created a new milestone as there where some verified bugs that was not attached to one... dont be scared by the end date... it can be adjusted

as for a new branch... hmmm... i would just jump in version number until we also have the potential bugs sorted...

say jump to 1.1.0 or 2.0.0 ?

[CONSULitAS]

@boelle Hi Bo,

i think it does not make sense to give it a big version jump to something like 2.0, because everybody would think that there is a major work since 1.0.2. At this time i think Marlin ist fast but constantly growing rather than making major steps.

A 2.0 would make sense for example if we support a new hardware platform like 32 bit ARM.

Perhaps it would be best to change the version number to a system like Ubuntu uses. So we would have a release 2015.03 and everybody knows easily how old his Marlin is. And no discussions anymore if it is worth to make a major release. :-)

Cheers Jochen

[nophead]

Yes that is what OpenScad does with versions and it works very well.

[boelle]

then i'm in.... whatever keeps the ball rolling

Den fredag den 6. marts 2015 skrev Chris notifications@github.com:

Yes that is what OpenScad does with versions and it works very well.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1184#issuecomment-77526053 .

[CONSULitAS]

yes, have a look at http://www.openscad.org/downloads.html

They even use yyyy.mm for "stable" releases and yyyy.mm.dd for "development snapshots".

[boelle]

where dd is date right?

on work but off in 3.5 hours

should i rename the old releases while at it?

Den fredag den 6. marts 2015 skrev CONSULitAS notifications@github.com:

yes, have a look at http://www.openscad.org/downloads.html

They even use yyyy.mm for "stable" releases and yyyy.mm.dd for "development snapshots".

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1184#issuecomment-77529138 .

[vandarin]

Don't rename the old releases, that will just cause even more confusion.

[boelle]

oki... but did i get the point with dd ?

[vandarin]

Yes, mm=month and dd=day, both with leading zeros. On Mar 6, 2015 7:20 AM, "Bo Herrmannsen" notifications@github.com wrote:

oki... but did i get the point with dd ?

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1184#issuecomment-77557247 .

[boelle]

so next one would be 2015.mm.dd.... i can work with that....

[thinkyhead]

2015.03 could be the next big release if we keep on plugging away!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.