Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I need to start work on creating a fork of the open-source web browser Mozilla Firefox, but I have no idea where to start. I'd be glad if someone could point me out in the right direction. I'd really, really appreciate the help.
Also, if my question does not belong here, please point out and suggest where I should post such questions. I was browsing through the StackExchange websites, and couldn't find a viable site. I could have overlooked/been careless, so if that's the case, please point me out in the right direction.
Firstly, you should ask yourself very hard whether a fork is the best solution because it will pose many kinds of issues. Ask yourself at least the following:
Can your project be completed as an extension of the original software?
Can your project be contributed to the upstream project instead of creating a new software?
¿Does the upstream project license allows the type of fork intended? Not all types of forks are allowed depending on the license.
If after a good while you decide that a fork is the only solution, the general approach:
Find where the source code of the project lives and which version control system it uses.
Clone the repository to a local copy on your machine.
Follow the instructions (if any) to rebuild the software.
Make sure at this point that you can tweak the software and run your modified version.
Ask yourself again if you really want to do a full fork.
Review the instructions (if any) on how to package the software.
Find a place to host your modified version of the source code.
Find a way to synchronize your version with the modifications done by the upstream project. This is especially important to keep compatibility and merging bug fixes.
Firefox is a huge codebase. I don't want to discourage you but if you are not already experienced you should probably not start your own Firefox fork. My advice would be to at least create an extension first, to become more familiar with Firefox programming model on a smaller scale. Extensions can be very powerful and do a lot of things.
For the first point, the instructions on how to get the source code of Firefox can be found here: Getting Mozilla Source Code Using Mercurial.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm a relatively new developer (two years experience, coming from an apprenticeship) and in my workplace we've only ever had one developer working on a project at a time.
We keep our projects in Microsoft Visual Source Safe and check out files as required, and checking back in when we're done.
However, I've been doing some thinking lately and I'm unsure how we'd work on the same project at the same time? Almost everything has dependencies on some core code and certain base classes. Is there anywhere I can go to read up on concurrent development, or are there any 'techniques' I should be researching?
How do team work on projects together? For background information I'm a .NET developer working mostly with VB.NET and webforms, but am moving onto C# MVC.
Edit
I think what I'm really asking here is about the techniques that should be employed as opposed to the software. I've been tinkering with Git a little and can see the benefits of the system over VSS. I was looking more for help with techniques on a project level that can be employed with concurrent development;
Should the development of two sections be completed then merged, or should it be more closely worked on together?
Are there any proven techniques or best practices when it comes to reviewing changes or discussing the next move?
Are there any books or articles I can read on how to produce a project as a team more efficiently etc?
Given you are using a Microsoft Stack, does it not make more sense to update yourself and use TFSOnline as an example. Its far better than its predecessor and everything is fully integrated into your toolset (assuming you use Visual Studio). There are loads of tools out there but everything I use is free inside a MSDN subscription and it plays nicely together. I am not saying others aren't ahead of the game but it makes more sense given what you are doing. Was very surprised to see SourceSafe stil being used.
I never used Visual Source Safe, but most chances are a different source control tool called Git (http://git-scm.com/) will make the concurrency better.
As the project will grow, you will probably have less collisions - just because there are more files to work on.
Try to push back the code more often. No more than 1/day - and hopefully sooner.
Use some kind of SCM(source code management) Wiki,
You can use some kind of program to help you, today the most popular program to this is GIT Wiki Git, but have many others. Do some research and find out what is better for you.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
My old system involved using Microsoft FrontPage and a frame page. The top frame contained a (tree) list of the tasks and sub-tasks I'd need to do, while the bottom frame contained any useful project information, notes, etc. I'd invariably need to jot down. I used bookmarks in the page to mark major tasks while highlighting current tasks with bold and marking off finished ones with italic. I would use a third frame for navigating between bookmarks via. a Table of Contents of hyperlinks linking to them. It was pretty clumsy, but it worked nicely.
Obviously, I want to upgrade now. Any good ideas on how to get a new system in place that can do something similar to my old one (without the crudeness/clumsiness)? That is, a formal piece of software for that purpose?
ToDoList is pretty good. Cons: Windows-only.
We use FogBugz, and it's worked out brilliantly for us. Far better than JIRA, easy to use, friendly, powerful. Highly recommend it.
It has a built-in wiki for notes.
(Really easy to use!)
It has a bug tracking system that is
second to none.
You can even make your software
submit its error reports to FogBugz,
and it will automatically generate a
case with relevant information in it.
This feature is called Scout.
You can create releases and all file
cases, features, bugs, whatever by
release, priority, etc. the power is
all there.
And best of all, you can host it on
your own server or have them host it
for you. Nifty system.
Works on just about any OS and browser.
Unlike most web applications, it's snappy!
We are using Jira for task lists, version planning and time management. And Google sites for internal documentation and related things. In general most Wiki system will be good for the documentation and todo (e.g. Confluence).
TFS : Team Foundation System
Full source control & work item tracking all integrated with Visual Studio.
If you use Visual Studio, and work in a windows environment, I recommend this.
If you don't use Visual Studio I recommend you do ;)
You can also setup project portals etc. that display activity, reports, all that jazz.
Basecamp from 37signals is a great tool to keep track of your tasks and projects.
I use fogbugz s&s edition
I think that an Issue Tracking System may suite your needs, there are plenty alternatives from OpenSource to Commercial...
You can setup and use ASP.NET Time Tracker Starter Kit. It also allows you to extend it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've just got this idea that there is a need for a forked version of Firefox that would provide right out of the box tools for web development. Like FireBug, YSlow, FireCookie, LiveHTTPHeaders, etc.
Maybe the fork should only include those extensions or take a further step and implement them in existing chrome.
The reason I'm thinking about this is that right now I have two Firefox profiles. A "browsing" one which has only one extension and a "development" one which has lots and lots of extensions. The advantage is obviously that the former is faster than the latter. Maybe if aimed from the beginning at developers, a forked version would bring some speed improvements and other niceties.
What do you think? Any volunteers?
Adding functionality to FireFox via extensions is IMO the reason why it is such a popular browser. If you take that freedom 'away' from people by providing them 'pre-baked' solutions, that will not be for the best.
What advantage would that give over extensions? You don't actually believe, that someone will port code to C?
I fear that pulling mentioned extensions into an official, maybe even Mozilla-branded, distribution would cause a slowdown in the development of those extensions because their authors would have to worry about coordinating their development with the provider of the browser distribution.
You can always prepare your own Firefox installator...
I think it is unnecessary to fork for that, because you can both things already - that is, have multiple profiles, and have all the developer tools as extensions.
You could even install two different profiles and run them from two different executables (portable Firefox makes this easy) allowing you to have a completely different plugin set as well as extension set for both.
Thinking about this more, I can't see how it would help.
Say you fork Firefox into a dev version, that is then used by extension developers.
But what is the target platform? The dev-platform (okay, then) or the "standard" platform -- if the latter, they aren't using it, and so dev and testing be be doubled or worse. Just imaging targetting Gnu Emacs but doing the dev in XEmacs.
Develop and test on your target platform, or face unpleasant surprises....
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Hey, I've built a project over the course of a year. I've put in a lot of hours into it, and it has come out great. A bunch of people use it, and a bunch of people write plugins for it. However, I have since moved on to different languages, different styles, the codebase is dirty and hackish, and I'm not sure I want to continue working in the framework I built it in.
When do you know that you should shut down a project and move on?
When you don't want to work on it anymore. Have you thought about open sourcing it so the community of users could continue to support it if they wanted?
Once you have lost inspiration and a project starts to get boring and you are to the point you can't get much or anymore experience from the project it's time to move on. If a project's codebase is too screwed up to fix then it's time to move on. If people use it and people write plugins for it, I'd personally make the project open source and turn it over to the community to continue otherwise just end it.
Find a new maintainer since it's already open source. Ask for a volunteer. If they like it they will surely jump at the opportunity to maintain it.
If you are sure you are ready to leave the project, then you can do so, but you should consider your users first. They still find it useful; they have contributed hours of work to write the plugins.
So, your first imperative is to make sure that those who want to use what they find useful can still do so, and can still enhance it. So, ask for a volunteer to take over the project, or a group. Provide them with the source, and your candid assessment of where the flaws are and what needs to be done to rectify them (rewrite).
If you simply close down the project, you will make a lot of people unhappy with you who are currently happy with you - that would be silly. It's easy enough to make enemies without going out of your way to alienate people who will otherwise respect your decision.
Are you certain you won't gain more valuable experience/knowledge from working on this project? Why not reimplement it in the language/platform of your choice thereby making it a learning experience?
I would say that if you are going to spend more time rewriting and trying to work around your current framework then starting from scratch with a better design and plan, then it's a good time to move on.
I think it really depends on your motivation for the project though. If it's purely financial then you can do a straight cost analysis. If it was for a hobby or learning experience, you may want to move on even if it would be easier to stay with the current project.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have MS Sharepoint -- which isn't all bad for managing a task list. The data's publicly available, people are notified of changes and assignments.
I think that Bugzilla might be a little easier for management and reporting purposes. While there are some nice Open Source Scrum management tools, I've used up a lot of my political capital and can't ask for too much more than what we've got now. Money isn't the object -- obviously -- it's the idea that my team has too many specialized tools.
Will Bugzilla work out as a more general project management tool -- outside the bug fix use cases?
Will I be bitterly disappointed and wish I'd downloaded something else and made my case for a better project management tool?
Bugzilla Is a great bug tracking system. We have tried to use it for other project management tasks and the results are less then stellar. I would recommend finding something designed with your goals in mind.
Try it for yourself.
Get a $15/month account at wush.net and use it yourself for a while (no business relationship besides satisfied customer).
Bugzilla is powerful and has a lot of configuration options, which can be confusing.
I personally used it three years ago on a project I was working on. I had no project manager and I was the developer, so I needed a very-light-overhead systtem. Bugzilla gave me that. I put my main goal as an enhancement "productionalized system" and then I made dependencies to reach that point. I ended up having 160 nodes all dependent on each other. This essentially was a work breakdown structure. I didn't bother with time estimates, and I didn't bother with creating any other kind of project documentation.
A cool advantage was that as I coded, if I noticed something needed to be done, I would just pop it into bugzilla (20 second process once it's set up), tie it as a dependency, and go back to what I was doing.
Whenever I completed a task, I would look at the dependency diagram and find the outermost leaves (bugs that blocked other but weren't themselves blocked), and work at it.
The advantage of this method for me is that if a task had looked simple and had one node associated with it, but when doing the thing itself I realized it was more complex, I would just split it into different subtasks. This took only a minute and absolutely didn't involve a meeting with a project manager.
Other people on the team could track my progress by looking at open bugs, closed bugs sorted by dates, etc. They saw action, they left me alone. When I had external dependecies, I would make a bug, detail the work, and send that person a link via email. They could then see why this was needed by looking at the dependency diagram.
Note that unless previously agreed upon, I did not assign them the bug.
It worked really well and the system was ready one month early.
How will it work with SCRUM? Having only had a cursory glance at scrum I can't tell you. But that was my experience.
Using a dedicated host will allow you three things:
support
easy upgrades (unless you got gurus in-house, bugzilla management ain't easy--for me at least)
users across organizational boundaries.
Note that bugzilla has all sorts of security features, so it's easy to lock-down the users to what they need to see.
My stand-alone solution is DokuWiki + MantisBT + Subversion + Review Board, which can be integrated with relative ease. Hosted alternative is Bitbucket.org. The rationale is you write user stories on Wiki and can reference them specific tasks. Larger bugs can be collaboratively designed and the "wiki" link is provided on the bug report by Mantis. Review board lets you do peer code reviews against svn diff before change is committed.
We've used Trac and Subversion very successfully for several projects.
The main advantage here is being able to tailor reports, some very Scrum specific, to provide information to management.