Closed lah7 closed 8 years ago
terricain
commented
8 years ago I'll do it at some point but first we need to
I also need to look into using the proper packaging scripts which are more useful. I did look into using launchpad to host a PPA but if were going to support multiple distros it might just be easier to bung deb's onto my webserver and host a proper repo.
terricain
commented
8 years ago Another note, we might as well look into setting up continuous integration as I think as an open project we get travis-ci for free. @lah7 if you wanted to look into that, it would be helpful ;)
lah7
commented
8 years ago I'm in the process of overhauling gh-pages so we've got a prettified page about the project and so it's easier for our non-developer users to use the software. I'd like to add some packaged downloads to a release to accomplish this.
As a starting point, I'm thinking we should go for v0.1.0 and attach some Ubuntu 14.04 and 15.10 deb packages for i386 and amd64 as a "snapshot" of everything so far (providing it's not broken). If it's easy for other distros (eg. .rpm) then sure, let's add them too!
Just as an idea, I'm thinking like this:
Other contributors, and our maintainer @pez2001 would have to agree how we "snapshot" code. (Nobody would want to fork WIP code, right? :wink:)
Would be nice later on. I'm unfamiliar with this (willing to look into it at some point) so some distros that support it can automatically update these drivers as part of the system.
I'm happy to maintain links and keep it up-to-date, Please may I have access to gh-pages if so, and would also allow me to directly attach packages for Ubuntu distros... just until we have other ways to automate this.
terricain
commented
8 years ago PPA's I would say once we have a proper stable branch then I can look into hooking it up, launchpad gets a bit iffy when it comes to git and not bzr.
I say we get mulit device support working in the app and then I'll redo the deb packaging so its up-to-date and we can host them.
Version pattern seems ok but its useless unless there is a plan of what needs to be developed. We need a feature list etc... to work towards.
terricain
commented
8 years ago Also if you make the gh-pages, I can merge them for you if you want.
lah7
commented
8 years ago I will issue a pull request when they're ready. Been a bit busy!
Just as another thought for determining versions, we could release "snapshots" of the code, and use the date as the version number, in other words, 20160123, 20160224, etc. There could be stable and testing releases, like 20160101-stable and 20160224-experimental. Just an idea.
terricain
commented
8 years ago Sounds good. Fancy drawing up a release schedule/milestone list
lah7
commented
8 years ago I changed my mind about my last idea, the first version pattern makes more sense. It's probably easier marking a release as stable then have some unstable releases for a while, or just one overall release providing nothing gets broken between releases.
I've drawn up some [possible] objectives on a new Wiki page.
terricain
commented
8 years ago Nice Nice, Once I've finished Uni, or more specifically my project, I'm going to
By that point you should of purchased the entire razer store to aid in multi-device support ;) Then I'll get set on working on multiple device support. I have some serious restructuring changes planned for the app so things might get interesting ;)
terricain
commented
8 years ago oooohhhhhh, building for i386, ewwwwww. I'll look into that as it could get nasty, though theoretically it should work fine.
maffblaster
commented
8 years ago I second the idea of adding versions to your code. I haven't spent a lot time reading this thread, but it looks like you guys are planning out how to do this. Once you get some versions going it will possible for developers to easily create and distribute packages for your drivers.
I'm a Gentoo developer, and it is easy for me to create a "live" version of your package, however if the package is not stable it is not much use. You guys should focus on stability and let guys like me focus on packaging. I'm going to start on an ebuild in my overlay right now...once my Chroma comes in the mail I'll be able to do some testing for you. Thanks for the hard work!
maffblaster
commented
8 years ago Might I also suggest dashes (-) instead of underscores (_) in the program name and, whenever you get around to it, adding a lowercase V before the version number on each tag. For example this would make the filename for the first release look something like: razer-chroma-drivers-v0.1.0.tar.gz
I think the V before the version number was also suggested by @lah7 (above).
terricain
commented
8 years ago @Maffblaster Yeah, we were going to package it up for debian, and fedora if I tolerate its RPM system, if you want to make a gentoo packaging script we'll add that to the collection also, and yeah, when we actaully start branching to stable I was going to opt for something like razer-chroma-drivers-v0.1.0
maffblaster
commented
8 years ago @terrycain That's perfect naming for me. Just so you know you'll probably have to rename the repository in order to get the name like that.
If/when you start tagging in git everything we need on the Gentoo side. Gentoo is a source-based distro, so all we need is a zipped tarball of the source code. GitHub generates source code snapshots of the repository in tar.xz and zip format when you git tag. @lah7 I want you guys to know that I ordered a Chroma so that I can help you guys with this project. I can test your builds, etc. :)
terricain
commented
8 years ago @Maffblaster Hmm, we've already renamed it once, if we get everything working then we can ask @pez2001 if he'll rename it again as that would be his job. If you can help with the gentoo packaging that would be good.
And nice it would be good to have someone on a nonvirtualised gentoo to test stuff.
maffblaster
commented
8 years ago @terrycain I'll be this project's 'point man' for anything Gentoo. I have many non-virtual Gentoo machines that I can use to test, however I will probably be testing on just one machine.
terricain
commented
8 years ago @Maffblaster Nice, that'll be quite useful. I've got Ubuntu 14.04 covered, and have VM's of other Debian and Ubuntu releases. @lah7 Also has Ubuntu I believe possibly 15.10. I'll get Ubuntu 16.04 ready once I upgrade. And I suppose I'll deal with F22 releases too.
Once my Uni project is out of the way, I'm going to overhaul the packaging and probably redo all the Makefiles to clean them up.
terricain
commented
8 years ago @lah7 We have a ppa. Well, sorta, PPA link. Launchpad is horrible, it gets the job done but is a pile of hassle as we arn't using their bzr repository. Another issue is that they are a fully integrated build system too so they have to compile the debs for us. I've got the kernel driver building which is the worst of it done, now just need to understand how they want to do versioning and building for other packages.
We'll need to restructure the repository for it to work nicely. Mainly the makefiles need to be vastly improved. Have got it to use the proper debian packaging tools though. And once its restructures it might play nicer with RPM too.
maffblaster
commented
8 years ago This issue can be closed.
Drivers aren't hosted in this repository anymore, they've been moved here.
Should we consider packaging up the current code and creating packages for various systems? To do that, it would be essential to start tracking versions ("releases") when new major changes are made to the code.
Packages could be committed in a
dist/folder. A PPA (for Ubuntu users) would be nice so that general users can have updates pushed to their systems.Suggested distros to focus packages for:
--- Based on distros mentioned in this repo. --- Primarily focused on
amd64?