This is AdBlock's old support site. It is available for archival purposes only. To create a new discussion, or to visit the up-to-date knowledge base, please visit help.getadblock.com
AdBlock Public Git Repo
Previous discussion context:
Matt:
If you had the source code on Github with a short guide on how to
set up a development environment (run tests etc.), a lot of these
things would be sorted sooner with less effort. Just a thought.
Crazyskeggy:
Our code is available freely at http://code.getadblock.com -
licensed under the GNU GPLv3.
Matt:
Yes, I know it's open source. My point is that if it was made more
accessible, there would be more people contributing.
Discussions are closed to public comments.
If you need help with AdBlock please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Kieran on 16 Jan, 2014 04:33 PM
I've moved your comments into their own discussion so that we don't spam the other one with our discussion of the project.
Currently, we have moved away of providing all our code publicly for all to see, like we used to when we were on Google Code. This allows us to work on a few things privately (such as April Fools jokes that we've run in the past). We now operate on a Private GitHub Repo that everyone on the team can access.
How would you suggest that we publish the current master branch (plus possibly a few other branches) for people to access, whilst also allowing things that Michael (the creator of AdBlock) wishes to keep private, private?
I'm not being sarcastic here - we are asking for suggestions from the public to improve AdBlock, as we have done for a while.
Our current user-contribution system, for reference:
We are accepting patches from the zip files at http://code.getadblock.com which can be attached to a discussion here. We will then code review it as we usually would, and work with the person submitting the patch to fix any bugs, or find any improvements.
2 Posted by Matt Deacalion on 17 Jan, 2014 01:02 PM
Thanks for taking the time to respond!
I don't know how your team do things or how your workflow looks, but making the source code accessible to a wider audience wouldn't have any effect on your team's ability to do nifty stuff like secret releases etc.
So let's say you have all of the AdBlock source code in a git repository with only the "master" branch. How do you keep sensitive information from the repo? you separate that information from the code, then .gitignore the sensitive files - which only the main team will have. So when they make commits, everything they do is made public... except the sensitive information.
Now onto the next issue. Let's say it's coming up to Halloween and Michael wants to do something special for the users, but doesn't want them to know in advance. He clones the AdBlock repo from Github/Bitbucket, creates a local branch and makes the changes. This local branch isn't viewable from the outside world, he can choose when he wants the changes to go public by merging it into the "master" branch and pushing that to Github/Bitbucket... or by just pushing the new branch live directly, so the repo has both "master" and "halloween-update" (for example).
3 Posted by Kieran on 17 Jan, 2014 09:05 PM
Hi!
Thanks for taking the time to provide useful suggestions!
Alright, we work on a "one-branch-per-issue" system - if that helps!
Thanks for the suggestion! This discussion is being watched by Gabriel, who works closely with Michael - he may have something to follow up with on this.
Thanks for the idea! The main problem I can see with this would be code review. As most of us work together over email, this would prevent any easy form of code-review and testing. If Michael were to work on an
april-2014branch, and needed code review, he would have to zip it up, remove the.gitfolder as that may contain login details, and email it to us. Then we (possibly in different timezones) would have to unpack that zip file, load it into Chrome or Safari (though I hear that it isn't as easy to test an extension in Safari compared to Chrome).I do see where this might work, though. Especially with short-term changes such as April Fool's Jokes and our recent crowdfunding campaign. Code review may still prevent this workflow with major changes that need to stay private for whatever reason, but thanks for the suggestion anyway!
If you want to say more, feel free to add a new comment to the discussion - we'll be glad to hear it.
4 Posted by Matt Deacalion on 20 Jan, 2014 04:34 PM
You can continue doing code reviews for sensitive commits within the private repo on Github. Once the changes are ready to go public and have already been merged into the "master" branch on the private repo, you simply "push" those to the public repo.
There's many possible ways of achieving this; you could even push the changes from the local private repo to your local public repo and even issue a pull request on Github from the public repo.
I've probably made this sound more convoluted than it is. It's quite simple once it's up and running, if you want I can explain it to your guys over Skype or write up some detailed instructions.
Cheers,
Matt.
5 Posted by Matt Deacalion on 05 Feb, 2014 12:36 PM
I'm just following this up, any progress on this?
Cheers,
Matt.
6 Posted by Tomáš on 23 Jul, 2014 01:58 PM
AdBlock won't have public Git repo in near future but we may reinvestigate that.
Tomáš
Tomáš closed this discussion on 23 Jul, 2014 01:58 PM.