Open andrewdavidwong opened 5 years ago
@Rudd-O, would you be willing to package your contribution according to our new package contribution procedure?
I would like to, but it is going to take me some time. I need to adapt it to Qubes 4 first, then test it real well, then package it according to the procedure. I'm flagging the e-mail notification so I don't miss it in my queue -- I have to do this work anyway because I use it myself.
Yes, but first I have to port it to Qubes 4. I bought a anew machine and well be assembling it this week, precisely to.do exactly that without messing with my main box.
On June 9, 2019 11:40:28 PM GMT+02:00, Andrew David Wong notifications@github.com wrote:
@Rudd-O, would you be willing to package your contribution according to our new package contribution procedure?
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/QubesOS/qubes-issues/issues/5088#issuecomment-500247785
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
@Rudd-O More then a year later, would you like to update the community on what is needed and the current status of the project?
The Readme https://github.com/Rudd-O/qubes-network-server is a bit misleading (based on QubesOS network server that was working in QubesOS 3.2), which is why i've created: https://github.com/Rudd-O/qubes-network-server/issues/9 and https://github.com/Rudd-O/qubes-network-server/issues/10
Thanks!
Yes. It's ported. Let me take a look at following the contrib procedure.
I've signed master
and pushed the signed commit.
I am ready to get this reviewed. Thanks.
Assigning to @fepitre for review. Please feel free to reassign as appropriate.
@fepitre: I see the subject coming again in GSoC. Is this project being reviewed for pointers being given on needed improvements?
@tlaurion I've not found the time for that yet sorry. I've been under a very intensive scheduling since December for multiple Qubes subjects. I'll try to find some soon.
I am not super familiar with this project, but I would be more than willing to review any PRs. @tlaurion would that help?
@DemiMarie at least that would help me to have double checks to approve it.
Folks who can review this?
@Rudd-O me this week-end :)
I'll be around.
@Rudd-O I would propose several updates, probably in form of PR. Before that, It would be great if you can adjust branches in the following way:
release4.0
r4.1
/release4.1
as R4.1 is not released.More generally, we try to make the code common as possible for all releases and we diverge releaseX.Y
if it's not.
@Rudd-O Here is my review/improvements: https://github.com/fepitre/qubes-network-server/commits/r4.1-improvements. Do you mind to check if there would be any break or such? According to my previous answer, this should be the master branch of the component.
@marmarek I would also vote for renaming this into the service name itself: qubes-routing-manager
. The current name is too context wide and in my opinion misleading.
@Rudd-O any updates?
Will work on this to work correctly under Qubes 4.2 tomorrow. I had to travel to Spain due to reasons out of my control.
itshappening.gif
It's complete. You can deploy with the standard instructions as per the README.md
file.
So, how do we get this upstreamed?
@Rudd-O: Thank you and congratulations! The next step is for a developer from the Qubes team to review your contribution. For reference, the overall procedure is documented here:
https://www.qubes-os.org/doc/package-contributions/#contribution-procedure
I'm thinking my code is currently just a hack. At the very least we need to design a UI to manage enablement (currently, the UI is just a qvm-feature
), and functionality to manage inbound firewall rules too.
@Rudd-O: Thank you and congratulations! The next step is for a developer from the Qubes team to review your contribution. For reference, the overall procedure is documented here:
https://www.qubes-os.org/doc/package-contributions/#contribution-procedure
I already reviewed it few years ago already. I proposed to change the name, and did some split to ensure to have specific content only for dom0 and only for VM, not both at once. Any method is fine.
At the very least we need to design a UI to manage enablement (currently, the UI is just a
qvm-feature
), and functionality to manage inbound firewall rules too.
I suggest opening separate issues for these.
I already reviewed it few years ago already. I proposed to change the name, and did some split to ensure to have specific content only for dom0 and only for VM, not both at once. Any method is fine.
Sounds like some further changes are requested of @Rudd-O before proceeding, then?
I already reviewed it few years ago already. I proposed to change the name, and did some split to ensure to have specific content only for dom0 and only for VM, not both at once. Any method is fine.
Sounds like some further changes are requested of @Rudd-O before proceeding, then?
I need to review it again, but my point about the package name still stand.
Yeah if we meld it within the base OS then we don't have to think about package name. Alternatively, what features do you want to see integrated, and also what name would be appropriate for this now?
Community Dev: @Rudd-O PoC: https://github.com/Rudd-O/qubes-network-server Discussion: https://groups.google.com/d/topic/qubes-users/sNjucuuiCcQ/discussion