As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm a bit confused about a pull request I did on a fairly large open source project I use in my work. I won't reveal the project, but it contains a large collection of mostly user submitted scripts that are used to monitor various aspects of a mission critical system or application. I found a user-submitted shell script that I needed to use for my own work, but it had several major bugs, and was stylistically a wreck. I fixed the bugs, and refactored almost the entire script, bringing it up to a fairly clean "bash form". I did a pull request on the script, and the project lead rejected the patch with quote:
"This is mostly coding style changes. Your effort is really
appreciated, but we won't get anywhere if we start accepting that kind
of patches. Please try to focus on the matter, i.e. stuff which really
needs fixing. Thanks!"
Here's an example of a bash coding style change for readability I made throughout the script:
- start_time=`date +%s%N`
+ start_time=$(date +%s%N)
Is this common on open source projects? Most projects I've committed to were my own, and I refactor stylistically bad code all the time. If code will be used by other people like the script in question, shouldn't a usability refactor be welcomed? I'm just a bit confused, as the project has no coding style guides.
Did you split the patches so that the bugs are fixed first and the style changes made later? If not, I'd reject the patch as well. A patch that changes logic should be as small and self-contained as possible. Nobody wants to go through dozens of style changes to ensure they have no effect on the logic when trying to understand what you fixed.
This is absolutely not a universal thing among open-source projects. I'll just give one counterexample, from a recent pull request:
https://github.com/djcb/mu/pull/65
My pull request related to the Emacs component of mu, called mu4e. My only changes were to make many more variables from the project available to edit via M-x customize (the Emacs equivalent of "Edit -> Preferences", or "Tools -> Options"). There were no changes to any of the program logic at all. As you can see, the pull request was merged without any fuss after just two hours. (I had never contributed to this project before, so I didn't get fast-tracked based on my past contributions or anything like that.) So that's one example of a pull request of only cosmetic changes that got happily accepted without any complaint.
As to why the project in question rejected your patch, maybe they're just being stubborn or too proud to let someone else mess around in their code or something like that, but on the other hand, there are valid reasons not to merge cosmetic non-user-facing changes. If they accept your code and they are at least minimally responsible, they will have to at least look at all the changes you're making and make sure you didn't break something, and make sure that your code changes match what your commit log says that you changed. I'm guessing that your pull request changed a whole bunch of isolated lines or blocks throughout many files, right? That's probably what you'd end up with if you did a blanket search and replace of backticks with $(). That kind of patch can be hard to verify, because you look at the same change on line after line and your eyes glaze over and you miss the one case where the close-paren is missing which causes the entire project to break.
The point is that even though you're giving them code for free, actually merging your code is not free, and the work involved in integrating your code into the project must be done by the people who run the project, or else they will be merging code that they can't trust. In some cases, the people who own the project may look at what your changes claim to improve and make the rational decision that those improvements do not justify the effort required to merge your code in a responsible way. If you disagree, you're free to create your own fork (not a "hostile" fork, just a run-of-the-mill "Project X with my customizations" fork) and put your changes there, and use them yourself. If your changes are really worth having, people might start switching to your fork, at which point the original developers might reconsider their position and merge your changes after all.
Each project has its own rules and guidelines. You've been told that this project works to different rules from the ones you'd work to. If you want to contribute, it sounds like you'll have to follow their rules. (I tend to be on your side in the debate — but when I'm not in charge, I go by the rules of those who are!)
Related
I was reading this answer in trying to understand how to work with multiple developers working on multiple branches of a project. My first reflex was to want Jenkins to run a separate build for each branch, but as I understand it, this is a bad way to approach the problem.
Now, I see how having very small features or parts of features which get merged back into the main branch often is the preferred way to go, but I can't quite wrap my head around what happens when a project goes through a very large architectural change.
Say I have a web project written in AngularJS and the team decides that for the future of the project, it needs to be moved over to using ReactJS instead. Said current project would have a reasonable number of features already implemented and tested. At this point, I can't imagine any smaller increment for the new "feature" of using ReactJS other than having it be on part with the current state of the project, meaning every test currently passing should still pass once it's done. Anything else would mean a regression for the project and I know of very few clients who would be ok with this.However, that's hardly going to be the case until the switch is almost 100% done, which will not be a small amount of work.
I might not understand the concept perfectly, but I don't see feature toggles working here (especially if the move to ReactJS requires we modify, say, the Gruntfile since that will inevitably break things a lot). Does the team doing the migration simply needs to tell the rest of the team not to touch the project until they say it's ok? That seems like a weird solution to me.
So I'll admit, I'm at a loss as to what the proper workflow would be here. Any input would be appreciated as our development process is something I constantly try and make better, even with my limited experience in the field.
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 9 years ago.
Improve this question
Do you need a project management system if you work alone? I mean a project management system that includes issue tracking, wiki, etc.
Currently I keep my issues in a very good organizer software and I keep project documentation in Word files (and of course I have a version control system), so I am not really sure if I need a project management software, because I work alone.
One useful thing, I can think of, that project management system can additionally give me is linking issues with commits (UPDATE: I've found this feature useful enough: for example, right now I am creating documentation for the new release of my project and I consequently open every issue with "Pending for release" status, then I read the issue's description and then I can quickly view the diff of the commit for this issue - this helps me to see details and write better documentation).
Another one - sharing issues so your users or your employer can view or manage them.
What am I missing? Is project management software necessary when working as the only programmer?
UPDATE: I've thought up another useful thing: In comments we can give a link to an issue or a wiki article with detailed information about the code being commented.
You say you use some organizer software that helps you managing issues. So you already have your custom project management system. Just keep it.
Project management systems does not have to be big, support sharing data or other kinds of documentation. As a programmer you are supposed to use one to make your work organized, but it doesn't matter which one. You can happily use plain text files if they work for you.
Still, if there is even a slight chance that you'll be cooperating with someone, you should try something that allows cooperation... just to know how they work.
Do you need a project management system if you work alone?
Yes.
Currently I keep my issues in a very good organizer software and I keep project documentation in Word files (and of course I have a version control system).
See. You have a project management system. Why ask?
project management system can additionally give me is linking issues with commits.
That's not necessarily project management. You can easily do that with you version control software.
Read this: http://tortoisesvn.tigris.org/issuetrackers.html
sharing issues so your users or your employer can view or manage them.
That means you're not working alone, if you're sharing something. What are you asking for here? How to share?
When working alone is the key thought to pursue here. When you are alone, you don't have the luxury of having someone else to keep you on your toes. A good "system" is essential therefore in order to help you manage your projects. As to which system to employ, that all comes down to your individual needs, and how much time you want to spend maintaining such a system.
If there is any possibility that you will need to involve someone else, then you need to decide if the system you use will scale to meet your changing requirements. This is also true if you continue to work alone and your workload changes.
As for software, that is almost another question entirely. I personally prefer to use a software tool to track all of my tasks, and to help me to collate data that helps me to determine priorities and task scheduling. That is in a nutshell what project management is all about. When working at home on my own projects, I use a simple Redmine configuration to manage different types of projects. Planning for programming projects, working out the logistics for my wedding, even managing my house renovations. All have been added to my private Redmine setup because I'm too lazy to try and keep paper-diary styled systems updated. At work, I have a more complex configuration to manage the myriad of programming projects we have here, and to manage the dependencies between them.
I've found though, that the most important thing is to ensure that the processes are streamlined, and that the supporting tool can be configured to match the processes. You don't want to have to change your processes because the tool isn't up to par. Also, the tool should not become the sole focus of all of your efforts, therefore it should be configured to reduce the "red-tape" side of things. You only want to capture enough information to describe your tasks, and to determine when they need to be done, who will do them, and when they are completed. Yes, your needs may require more information to be captured, but always try to minimise this, as you don't want to feel like you are always updating your project management tool when you'd rather be working on that latest killer algorithm you've been looking forward to doing! ;-)
I would not want to work without a system like trac anymore, even if I'm the only one working on the project. You should use a version control system of course, no question about that. Then there are two or three things coming up, you also mentioned.
First is documentation. There are lots of different possibilities and a wiki is just one of it. I personally use the wiki mostly for ideas, thoughts and notes. It's easy to put drawings in it, link to ressources in the web and really quickly edit. This can not replace in code documentation you do with source comments or tools like doxygen. And this can also not replace a manual, if the project requires one.
The second thing you'll come across is some kind of todos, let it be bug reports (even from yourself), feature requests, things like that. You can put them as comments in your code or use a list in a text file or your PIM system, but you can also use a ticket system, just to keep track of what you want to or have to do in the project in the future. You can not do everything just now.
Third is the bigger plan, this is not just atomic todos but things trac calls milestones. This has to be written down somewhere.
The great thing about trac now is, you can integrate all these thing you have to do anyway in one tool and even cross link between all the parts. Link to code lines from a ticket, reference tickets in a commit message, use ressources from your repository in the wiki, automatically build doxygen and integrate it and so on. You must decide if you want to use trac for all the things around your project or something else, but you have these things anyway so why not use a system integrating it all? ;-)
I mean a project management system that includes issue tracking, wiki, etc.
I don't use an Issue Tracker, but I practice continuous (not "big bang") integration, and I test (look for bugs) early and often, and I fix any bugs as soon as I find them, so that list of known Issues remains small.
I also have a lot of structure in the source code (e.g. separate projects/assemblies for separate components), so I try to have "the code is the documentation".
The table at What Types of Documents Should You Create? implies that you may not need documentation (e.g. a wiki), unless you're working with other people: e.g. with a manager, testers, and/or end-users.
You may be the only programmer now but will it stay that way forever? I often work alone on development projects but I still track the "to do" list and issues in a simple Access database. Makes it much easier if you need to expand/hand over a project.
You absolutely do, at least for a bigger projects that take a few months. For the past years I tried :
eclipse notepad plugin - just text file - effective
eclipse mylyn tasks - better, enough for one-man-show, but I was still having issues with migration between eclipse instances
youtrack is free and it's like a JIRA but more simple and practical for an individualist
With notepad I was able to focus on current task, but I wasn't able to maintain long term iterations, because without issue tracker I was loosing discipline, dealing with 3 tasks at the same time, not finishing them, etc.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm not sure if this an appropriate question for stack overflow. If not, I apologize.
I was wondering if there is any tool for keeping track of different uncompleted tasks in different modules of a project. I'm currently interning at a company and I feel like everytime something cannot be solved immediately, someone asks me to put a 'todo comment', and that task eventually gets forgotten. I was wondering if there's a better way to keep track of stuff like this.
Thanks.
Trac is an issue tracking system that you can use for this purpose, but you have to enter manually each ticket into the system, but once you're get used to it, it is very useful and effective.
Any issue tracker system also works.
Eclipse will keep track of comments with // TODO in it. There is a "tasks" window which will list them all.
I suggest you to use Post-Its for each Task. You can also use Kanban to manage those tasks. It's very easy to learn and adapt to your needs.
You can split a whiteboard into some sections like Backlog (for pending and new tasks), Work in Progress (you limit the number of possible concurrent tasks), Deliver/Deploy (almost done), Done.
If you want a computer tool, there are lots of them. Just google for Kanban software.
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
Lots if IDEs will keep track of // TODO comments if that's the route you want to take.
To keep track of todo items outside of and IDE, you can try ToDoList
It's free.
Pivotal Tracker looks quite nice as project management tool.
Here's the CodeProject link to AbstractSpoon's ToDo List
It sounds like whichever system you're using at the moment (if you're using one at all) does not make to-do lists a priority or put to-dos/tasks in your view every morning that you log in.
Sounds like you need something that:
Allows you to assign different tasks/to-dos to different modules of a project
Keeps an organized view of which task/to-do has been assigned to which project
Sets alerts for each separate to-do/task (due date, percent completed, etc)
Keeps the tasks/to-dos easily viewable (from the dashboard, or put in a prioritized view as soon as you open a project)
A company that I do contract work with, WORKetc, can do all of this. On top of this, they have a huge amount of other project management features, to name a few:
Collaboration on all aspects of a project
Unlimited sub projects
Gantt charts
Project dependancy
Timesheet/milestone billing
To-dos, tasks, easily assignable to specific people/specific projects/specific sub projects, with necessary alerts
The cool thing about WORKetc is on top of being a project managemement tool, WORKetc also has CRM and billing features. It is essentially a total business management platform and that way if you're using other CRM or billing software you can get rid of it entirely, and not have to worry about integrating seperate projects. Even if you don't use these features, I bet its still a better bargain than the majority of the other ones you'll see!
Pricing/website link: http://www.worketc.com/sign_up
I've used source controls for a few years (if you count the Source Safe years), but am by no means an expert. We currently are using an older version of Sourcegear Vault. Our team currently uses a check out and lock model. I would rather switch to a update and merge model, but need to convince the other developers.
The reason the developers (not me) set up to work as check out and lock was due to renegade files. Our company works with a consulting firm to do much of our development work. Some years ago, long before my time here, they had the source control set up for update and merge. The consultants went to check in, but encountered a merge error. They then chose to work in a disconnected mode for months. When it was finally time to test the project, bugs galore appeared and it was discovered that the code bases were dramatically different. Weeks of work ended up having to be redone. So they went to check out and lock as the solution.
I don't like check out and lock, because it makes it very difficult for 2 or more people to work in the same project at the same time. Whenever you add a new file of any type or change a file's name, source control checks out the .csproj file. That prevents any other developers from adding/renaming files.
I considered making just the .csproj file as mergable, but the Sourcegear site says that this is a bad idea, because csproj is IDE auto-generated and that you cannot guarantee that two different VS generated files will produce the same code.
My friend (the other developer) tells me that the solution is to immediately check in your project. To me, the problem with this is that I may have a local copy that won't build and it could take time to get a build. It could be hours before I get the build working, which means that during that time, no one else would be able to create and rename files.
I counter that the correct solution is to switch to a mergable model. My answer to the "renegade files" issue is that it was an issue of poor programmer discipline and that you shouldn't use a weaker programmer choice as a fix for poor discipline; instead you should take action to fix the lack of programmer discipline.
So who's right? Is check in - check out a legitimate answer to the renegade file issue? Or does the .csproj issue far too big of a hassle for multiple developers? Or is Sourcegear wrong and that it should be ok to set the csproj file to update and merge?
The problem with update and merge that you guys ran into was rooted in a lack of communication between your group and the consulting group, and a lack of communication from the consulting group to your group as to what the problem was, and not necessarily a problem with the version control method itself. Ideally, the communication problem would need to be resolved first.
I think your technical analysis of the differences between the two version control methodologies is sound, and I agree that update/merge is better. But I think the real problem is in the communication to the people in your group(s), and how that becomes apparent in the use of version control, and whether the people in the groups are onboard/comfortable with the version control process you've selected. Note that as I say this, my own group at work is struggling through the exact same thing, only with Agile/SCRUM instead of VC. It's painful, it's annoying, it's frustrating, but the trick (I think) is in identifying the root problem and fixing it.
I think the solution here is in making sure that (whatever VC method is chosen) is communicated well to everyone, and that's the complicated part - you have to get not just your team on board with a particular VC technique, but also the consulting team. If someone on the consulting team isn't sure of how to perform a merge operation, well, try to train them. The key is to keep the communication open and clear so that problems can be resolved when they appear.
Use a proper source control system (svn, mercurial, git, ...)
If you are going to do a lot of branching, don't use anything less recent than svn 1.6. I'm guessing mercurial/git would be an even better solution, but I don't have too much hands-on-experience using those yet.
If people constantly are working on the same parts of the system, consider the system design. It indicates that each unit has too much responsibility.
Never, ever accept people to offline for more than a day or so. Exceptions to this rule should be extremely rare.
Talk to each other. Let the other developers know what your are working on.
Personally I would avoid having project files in my repository. But then again, I would never ever lock developers to one tool. Instead I would use a build system that generated project files/makefiles/whatever (CMake is my flavor for doing this).
EDIT: I think locking files is fixing the symptoms, not the disease. You will end up having developers doing nothing if this becomes a habit.
I have worked on successful projects with teams of 40+ developers using the update-and-merge model. The thing that makes this method work is frequent merges: the independent workers are continuously updating (merging down) changes from the repository, and everyone is frequently merging up their changes (as soon as they pass basic tests).
Merging frequently tends to mean that each merge is small, which helps a lot. Testing frequently, both on individual codebases and nightly checkouts from the repository, helps hugely.
We are using subversion with no check-in/check-out restrictions on any files in a highly parallel environment. I agree that the renegade files issue is a matter of discipline. Not using merge doesn't solve the underlying problem, what's preventing the developer from copying their own "fixed" copy of code over other people's updates?
Merge is a pita, but that can be minimized by checking in and updating your local copy early and often. I agree with you regarding breaking checkins, they are to be avoided. Updating your local copy with checked in changes on the other hand will force you to merge your changes in properly so that when you finally check-in things go smoothly.
With regards to .csproj files. They are just text, they are indeed mergeable if you spend the time to figure out how the file is structured, there are internal references that need to be maintained.
I don't believe any files that are required to build a project should be excluded from version control. How can you reliably rebuild or trace changes if portions of the project aren't recorded?
I am the development manager of a small company, only 3 programmers.
The projects we work on sometimes take weeks and we employ the big bang, shock and awe implementation style. This means that we have lots of database changes and program changes that have to work perfectly on the night that we implement. We checkout a program, change it and set it aside because implementing it before everything else will make 20 other things blow up. I am for check out and lock. Otherwise, another person might change a few things not realizing that program has had massive changes already. And the merge only helps if you haven't made database changes or changes to other systems not under source control. (Microsoft CRM, basically any packaged software that is extensible through configuration)
IMO, project files such as .csproj should not be part of the versioning system, since they aren't source really.
They also almost certainly are not mergeable.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We use MKS Integrity for our source control. I have no control over that -- I just have to use it.
What are some "gotchas" that I should know about and avoid? And, are there any neat things about the software that will allow me to use it better?
I've already hit cases where the tree structure in the source control doesn't match that in my sandbox. In more than one case, a file exists in two places, and when I resynchronize, I get the current version, and then an older version overwrites it, and then it is no longer synchronized. It's a challenge to find the older file, since, of course, the tree structure doesn't match.
I have used Source Control since 1999. It's pretty reliable, we have never lost change history. We don't do anything fancy with branches so I can't answer your question.
I assume you did resynchronize (F6) and update to head (F7).
SI is built upon a command-line design. You might have more consistent results if you use the command-line versions (pj.exe etc). The documentation is not trivial.
We're trying to migrate to Subversion, because MKS want ridiculous money for their latest enterprisey version.
Just discovered this MKS gotcha: It only allows one revision of a member to have a specific label on it at a time.
Came across it this way:
Someone on our team renamed a pdf resource, adding _Old to the file name (he did this rather than dropping it because he wanted it to still be part of our deployments)
Then he added the new version of the pdf, adding it to the same archive so that it connects to the existing revision history graph.
Now, if you look at the revision history for that member, you'll find that there are two revisions of the same member being used by the same dev path.
As part of our deployment process, we checkpoint the artifacts that are being deployed, applying labels to members to specify the release that they're a part of.
Since MKS only applies a label to one revision, when I went to review the checkpoint, it looked like the new pdf was not included in our deployment because it was missing the label
Also, AVOID VISUAL STUDIO INTEGRATION!!! Since installing it, several members of my team have had to wrestle with frequent visual studio crashes, and apparently its branching mechanisms depend on features that have no equivalent within the integrity command line or gui client. So if anyone on your team uses visual studio integration, unless the branches they work in were created through the integration, they will not work. So you'll find yourself stuck doing things in visual studio that visual studio does slowly and poorly just so that the team members using the integration can work with it.