git arrangement

[TonyMac32]

I saw @zador.blood.stained was doing some housekeeping, so I wanted to open the discussion again about what to do about it in the future.  We've obviously demonstrated what you "don't want to do".

 

My last comments on this were as follows:

 

• We should have temporary per-kernel branches when undertaking a bigger change. 
  • This allows wider testing for those who like to build experimental things
  • Makes the creator of the branch responsible for keeping it up to date
  • gets flattened out and merged into "master" or a "next" waiting for a revision bump
• PR's should be used on anything anyone is not 100% certain of to get ack's from the team (who hopefully knows?)

 

Annnnd.... discuss!

[zador.blood.stained]

Based on my work yesterday I have to make an additional remark: if "development" can't be rebased on "master" without a significant number of conflicts then we are doing something wrong 

[Igor]

4 hours ago, TonyMac32 said:

We should have temporary per-kernel branches when undertaking a bigger change. 

I guess we learned something.

 

... and let's not do bigger changes for a while  We have to do something with armhwinfo / zram-zswap / firstrun stuff, which might count as a bigger change, while the rest can wait. Some updating to the stable base should happen once before summer time.

 

Now master and development are even. Shell we drop development and move activities back to master?

[zador.blood.stained]

28 minutes ago, Igor said:

Now master and development are even.

They are not even. I just merged everything that was merged directly to "master" into "development" so we won't undo changes by doing manual merges.

 

30 minutes ago, Igor said:

Shell we drop development and move activities back to master?

We should merge everything that can be considered tested to master. I started cleaning up things to a new branch, if these changes are OK (since I don't have these devices) they can be merged to "master" and I will do more of this splitting later.

[TonyMac32]

5 hours ago, Igor said:

I guess we learned something.

 

Learning is continuous improvement.  ;-)

 

5 hours ago, Igor said:

... and let's not do bigger changes for a while

 

I only have 1 significant one, and it involves mainline u-boot for Le potato.  I have to reconcile mainline with the old boot script so old installs don't break, then update boot script to Armbian specs for any new images.  

[TonyMac32]

Question concerning U-boot and our bootscripts.  The 2015 and mainline kernel approached loading in a significantly different way, and I'm not certain how I can move to mainline u-boot without breaking existing installs when they apt upgrade.

 

Thoughts on this are welcome

[Igor]

5 minutes ago, TonyMac32 said:

Thoughts on this are welcome

Can you attach things to the DEV branch that we can try to figure out together?

[TonyMac32]

Just now, Igor said:

Can you attach things to the DEV branch that we can try to figure out together?

Certainly.  Or while we're sorting development branch out, I could just split this into a separate branch for the time being.

[Igor]

8 minutes ago, TonyMac32 said:

I could just split this into a separate branch for the time being.

IMO this is not needed for this case. DEV branches were designed for experimenting.

[zador.blood.stained]

2 hours ago, Igor said:

IMO this is not needed for this case. DEV branches were designed for experimenting.

He meant a separate branch in armbian/build.

 

2 hours ago, TonyMac32 said:

Or while we're sorting development branch out,

And since I started to sort it we already had commits that touch kernel/u-boot config and patches 

[Igor]

18 minutes ago, zador.blood.stained said:

And since I started to sort it we already had commits that touch kernel/u-boot config and patches

OK. I am a bit confused now. How is the best to proceed from a current state?

[zador.blood.stained]

Just now, Igor said:

OK. I am a bit confused now. How is the best to proceed from a current state?

I would prefer to freeze the development branch. If there are immediate bugfixes - push them straight to master (except for Bionic compatibility tweaks), for other things create different topic branches. Otherwise we will never sort out the "development" branch mess.

[Igor]

19 minutes ago, zador.blood.stained said:

I would prefer to freeze the development branch.

O.K.

Not touching development anymore. When you are done it can be dropped, right?
 

20 minutes ago, zador.blood.stained said:

except for Bionic compatibility tweaks

For Bionic host dependencies only aptly hack is needed. Didn't find other problems.
 

23 minutes ago, zador.blood.stained said:

for other things create different topic branches

Here we might need little clarifications. It can also get messy - lots of branches - if we will have a separate branch for minor things. 

[chwe]

On 5/24/2018 at 10:43 AM, Igor said:

O.K.

Not touching development anymore. When you are done it can be dropped, right?

 

On 5/24/2018 at 10:43 AM, Igor said:

Here we might need little clarifications. It can also get messy - lots of branches - if we will have a separate branch for minor things. 

 

I think this needs a bit more clarifications due to:

Quote

Please make sure that:

 - pull request is opened to the `development` branch

 

At the moment we suggest that people should send PRs into our dev branch, this will even more mess up the mess we have.. I think topic-based branches (they don't have to life for forever.. only until a project is more or less finished). But how to deal with external PRs which might need testing before we can apply them to master? 

Wait with PRs until the developmentbranch is removed, cleaned? As long as we still recommend that they should prepare their PRs for the dev-branch this will never end.