gprovost Posted June 24, 2019 Posted June 24, 2019 @lanefu Good suggestion because I think everyone is a bit lost on what the roadmap is. We did the required work for Helios4 bsp package and were expecting everyone would have done so for their respective board... but doesn't seem it happened. On 6/23/2019 at 2:20 AM, Igor said: I would propose to move kernel patches 1st out from the main script first, then perhaps do the same with BSP recipes packaging as well? Can you explain the 'move kernel patch our form main script' ? Because I'm really not sure what you mean.
Tido Posted June 24, 2019 Posted June 24, 2019 As things get lost in the forum, for reference: BSP scripts RFC https://forum.armbian.com/topic/7398-bsp-scripts-rfc/ Here I tried get something like... : fix the basic - CONTRIBUTING.md https://forum.armbian.com/topic/6706-fix-the-basic-contributingmd/ @lanefu I would read both first.. by the way, you were also a contributor
lanefu Posted June 26, 2019 Posted June 26, 2019 Okay... Here's a start!https://github.com/orgs/armbian/projects/1 Adding a step is as simple as "create a note" in the todo column. Then we can convert it to an issue, add PR's etc. Feel free to add directly, or just ask me to add, adjust, sort etc, and i will 1
lanefu Posted June 27, 2019 Posted June 27, 2019 On 6/22/2019 at 2:20 PM, Igor said: I would propose to move kernel patches 1st out from the main script first, Hey @Igor what did you mean by that? I wanted to add some more information to this task
Igor Posted June 27, 2019 Author Posted June 27, 2019 1 hour ago, lanefu said: what did you mean by that? 1
gprovost Posted June 27, 2019 Posted June 27, 2019 @lanefu You should create issue instead of 'note card' that you then link to the project. Better to use 'note card' for things / idea we don't want to forget but don't deserve yet to have an issue created. It looks like now there is more than one RFC that fall under Build Framework Rework. Maybe it's time to list down clearly which RFC is in the pipeline of the Build Framework Rework, and I think would be cool to give each RFC a number. Here what I gather so far, but there might more RFC lost in the forum : [ RFC 001 ] Repackage BSP into dpkg (which is the RFC described originally in this thread) [ RFC 002 ] Ramlog rework (reference by @Tido above ,not sure if it's still an open issue - https://forum.armbian.com/topic/7398-bsp-scripts-rfc/) [ RFC 003 ] Moving board patches to sub-module (https://forum.armbian.com/topic/10052-board-support-idea/) The work for each RFC will go into dedicated branch (before getting merge into Master when complete), and branch naming convention would be quite simple (e.g rfc-001, rfc-002, etc). This way not more confusion on what is what.
lanefu Posted June 27, 2019 Posted June 27, 2019 [mention=1231]lanefu[/mention] You should create issue instead of 'note card' that you then link to the project. Better to use 'note card' for things / idea we don't want to forget but don't deserve yet to have an issue created. Yep thats the general idea. Notecard is a placeholder for planning.... you can right click a notecard and turn it into an issue
gprovost Posted June 28, 2019 Posted June 28, 2019 (edited) 11 hours ago, lanefu said: Yep thats the general idea. Notecard is a placeholder for planning.... you can right click a notecard and turn it into an issue Neat trick I just thought that whenever we can, or rather whenever the scope of an RFC is clear to everyone in the forum, we should move the conversation to github under an RFC issue. What do you guys think about the RFC naming convention ? If you agree @Igor and @lanefu then you could already rename the concerned forum topic with the prefix [ RFC 00x ], same for the note card/issue. I really think it's important and it's also a way to know that whenever a RFC has been allocated a number it means it's been accepted by the team. So when someone want to suggest a RFC, they can open a discussion in the forum with the prefix [ RFC Proposal ]. Edited June 28, 2019 by gprovost
lanefu Posted June 28, 2019 Posted June 28, 2019 15 minutes ago, gprovost said: I just thought that whenever we can, or rather whenever the scope of an RFC is clear to everyone in the forum, we should move the conversation to github under an RFC issue. Yep. Makes sense... Once direction and feasibility is agreed upon, implementation details and progress should be in github. 17 minutes ago, gprovost said: then you could already rename the concerned forum topic with the prefix [ RFC 00x ], same for the note card/issue. I really think it's important and it's also a way to know that whenever a RFC has been allocated a number it means it's been accepted by the team. Also makes sense.... will take a little brain power to go clean things up, but should be fine once we get in the habit...... I'll have to document policy as well.
lanefu Posted July 4, 2019 Posted July 4, 2019 On 6/27/2019 at 10:51 PM, gprovost said: What do you guys think about the RFC naming convention ? If you agree @Igor and @lanefu then you could already rename the concerned forum topic with the prefix [ RFC 00x ], same for the note card/issue. I really think it's important and it's also a way to know that whenever a RFC has been allocated a number it means it's been accepted by the team. I've made it easier to apply RFC tags on the forum itself. That will make it easier to search. A slight tweak: Instead of assigning a [00x] sequence number to "approved" RFC, I'm going to give RFCs the issue number generated by github. 1
lanefu Posted July 4, 2019 Posted July 4, 2019 Thanks @Igor for creating the other notecards. I was able to clean them up and turn them into issues. I've assigned this thread an RFC.... ironically RFC 001 because I used the github project ID rather than an issue to reference. https://github.com/orgs/armbian/projects/1 In this thread we identified 2 RFCs, but really it was 2 major tasks needed to achieve the 1 goal. so the RFC is both combined. I adjusted the name to align more closely. (Build Framework Rework - simplify compilation.sh) I'm defining the acceptance criteria for this project to say its done as: Customizations needed after kernel patching and before compile are external to compilation.sh Code for building BSP packages is no longer in compilation.sh Assuming the acceptance criteria above is agreed upon... Feel free to create as many notes / issues as you like to help us get this done.. If you're able to break things down so that more of us can work on it at the same time the better.
Recommended Posts