Collaborative git repo


ShleeDragon

Pro-Catflip
Joined
Aug 28, 2010
Messages
1,749
Hey,


This isn't a new idea, but I'm wondering if there is any interest in organising a collective repo to hold the projects of the collective us.


Github allows multiple projects, with multiple team members. bug reports, pull requests. Might be worth looking into considering Stradian releasing his Mupen64 sources. Everybody knows most releases are done by a single dedicated coder in this community, but I couldn't see the harm in keeping as many Pandora projects in a single location.


Opinions? Who would be happy to pool their source?


Regards,


Ashley H
 
When working in a team you usually split the job and every team member get his own project part (anyway the team are never large, 2-3 at most)
 
It's nice to use github or sourceforge or your own CVS/SVN/GIT repository if you're coding in a team. If there's only one coder, it doesn't make that much sense to use these things, unless you want to be able to rollback specific commits to find out when a bug was introduced or things like that.


In general I think it's a good idea to include the full sources in the PND - this adds some overhead in terms of size, but typically the code is only about as large as the executable, compresses much better, and if there's things like artwork or music in the PND as well, the size of the compressed code is insignificant in comparison.
 
It's nice to use github or sourceforge or your own CVS/SVN/GIT repository if you're coding in a team. If there's only one coder, it doesn't make that much sense to use these things, unless you want to be able to rollback specific commits to find out when a bug was introduced or things like that.


In general I think it's a good idea to include the full sources in the PND - this adds some overhead in terms of size, but typically the code is only about as large as the executable, compresses much better, and if there's things like artwork or music in the PND as well, the size of the compressed code is insignificant in comparison.

Including the source inside a PND could really bloat the size in some cases. For example the smplayer2 PND is roughly 6MB, but the source tree is 78MB. There is already a place you can include the source code url in the PXML under the license tag. Maybe the repo could display that url as part of the details view for a PND.
 
Last edited by a moderator:
If there's only one coder, it doesn't make that much sense to use these things, unless you want to be able to rollback specific commits to find out when a bug was introduced or things like that.
Actually, I find it most useful for keeping my netbook and desktop in sync. Before that I used to copy my project to USB Pens. I was forever forgetting to keep all my copies up to date, and left a whole mismatch of updates and bug fixes in different place
 
Including the source in the PND is of course unnecessary bloat if the PND is just a port of an existing open source project with a well-established home page where you can find the source. In such cases I would only include the files where Pandora-specific changes were made (if any), or patches if those files are too large.


A source tree of 78MB? That's millions of lines of code? Wow. I guess that must be a lot of dead code or platform-specific code that gets compiled away in the Pandora binary, because otherwise I don't see how it fits in a 6MB PND.
 
Including the source inside a PND could really bloat the size in some cases. For example the smplayer2 PND is roughly 6MB, but the source tree is 78MB. There is already a place you can include the source code url in the PXML under the license tag. Maybe the repo could display that url as part of the details view for a PND.

Definitely something I'd like to see. As is, I have to manually track down [what I think is] the source to each PND before installing it (I'm stubborn about only running stuff I could patch myself if it broke or I needed to adjust for new hardware) and that acts as a disincentive to keeping up with the latest and greatest PNDs.
 
The repo already shows that info. Click on "Package Contents", then right next to the License info you'll find the source link. I usually put "./" in that field, meaning the source is inside the PND itself.
 
The repo already shows that info. Click on "Package Contents", then right next to the License info you'll find the source link. I usually put "./" in that field, meaning the source is inside the PND itself.

That definitely needs to be improved. I kept seeing that link and dismissing it as "list of files within this package" without even clicking it. At the very least, it should be renamed to something like "Show/Hide Detailed Metadata".
 
Last edited by a moderator:
Back
Top