I want to configure Phabricator with some customized rules. I am very new to this tool and would appreciate some help or pointers to how to do it.
I want to make sure all reviewers in Revision/Differential should accept all changes before changing a state of the Revision. Once all reviewers accept it then change status of the Revision to Accepted/ready to land.
Currently in my case, I have a revision in which there are different files which need to be reviewed by different reviewers. I expect that, after all reviewers accept these changes only then change status of the Revision to accepted otherwise it should be stayed on status "Needs Review". But, whenever any one of the reviewer from list accept the changes, status of the Revision changes to "Accepted"/"ready to land".
This is not currently supported. You can find discussion of this feature in the upstream, here:
https://secure.phabricator.com/T731
If some of the reviewers are really groups of people (for example, you want to make sure someone who is experienced with Python reviews all Python code, similar to "readability" at Google), you can create a project called "Python Reviewers" and add all the users who are experienced enough to do these reviews to the project. Then write a Herald rule to trigger a "blocking review" by the project whenever a change touches Python source. This will require all Python changes to be reviewed by someone from the project before they are "Accepted".
If your use case is more like "I want alincoln to look at the .c files and htaft to look at the .js files", but no reviewer will be examining the change as a whole, we philosophically discourage this. The most important feedback from code review -- by far -- is high-level feedback about the change as a whole, not feedback about implementation details. We encourage you to try to structure code review so that there is one clear author and one primary reviewer, each of whom are thinking about the entire change in the context of the surrounding software system.
Related
I am currently writing a text with R bookdown and asked two friends to read my text and give comments, corrections and general feedback. My source files for the text are stored on GitHub and I would like my collaborators to make changes in the files (one for each chapter) with the help of git. However, none of us are really experts on git. This makes it hard to figure out what a suitable workflow is.
For now, we decided that each one of them creates himself a branch so that he does not directly push into the master branch. After I have read their changes I would like to decide what I merge into the master branch and what not. So far, it looks like each change needs to be in a separate commit because I am not able to merge single lines from a specific commit (not sure if that is at all possible). However, this seems like a lot of annoying and unnecessary commits to create. So, I guess I am looking for a way to avoid that and/or general pointers towards a good workflow for such kind of projects.
A useful command will be git cherry-pick, it allows you to select specific commits from a branch.
A general good practice is that commits should be self contained (if applied alone they make sense) and they target a specific feature (in the use case mentioned, that could be a paragraph or a section or a chapter).
In the end, if you would like to apply only specific changes of a commit, that would have to happen manually, someone has to decide which parts to apply and which not. A commit can be edited using git rebase -i <branch name> before being merged. This question might also be useful.
I finally found what worked for me in here. Basically, on my master branch I had to use
git merge --no-commit --no-ff branch-to-merge
This will merge all changes into my master branch but does not immediatly commit the changes so that they can still be staged/unstaged. Then, I can decide what line change to include by staging the line changes I want to keep and discard all other line changes. Finally, I commit all staged line changes et voilà, that's what I wanted to get.
Sidenote: I am using gitkraken and as a beginner with git I enjoy using the GUI but the merge part with the options "no-commit" and "no-fast-forwarding" had to be done via the git console (at least I could not find a way to to that using the GUI). Choosing which lines to stage and which to discard is then an easy task via the GUI.
I have an "UpdateAttribute" processor that evaluates information in a JSON file. Originally, this would just check if a client had been updated and the statement looked something like this:
${literal(${allAttributes("client_attribute1", "client_attribute2"):equals("UPDATED")}):ifElse("UPDATED","UNCHANGED")}
However, the specifics of the client's status change now needs to be tracked - such that if the client goes from OFFLINE to ONLINE, then their status is "1". If they go from ONLINE to OFFLINE, then their status is "3". This would ideally be done in a single statement. I'm not sure exactly how this would work, any suggestions?
I think it would be better to use UpdateAttribute processor Advanced usage for this case.
Add all your rules you need to check then add the attribute which satisfied your rule.
Refer to this and this links for more details regards to UpdateAttribute Advanced usage.
The company has two welders that are equal in skill and knowledge, we wish to set them as a resource to a same task.
And we already did:
On the field resource name, we put both "Richard;Pablo"
But in this way, after the leveling of resources, they share, at the same time, the work on the task. We wish that one of this two welders make all the task by himself, and the leveling tool be able to choose between them.
I already try using operators, to set the field resource name as "Richard" or "Pablo". But this field doesn't accept this type of argument.
Assigning as Resource Group rather than a resource
This guy seem to have a answer, although is a quite short explanation, and i couldn't make work.
I would realy apreciate any help on this.
I'm looking at requiring my team to document their code more thoroughly for some major upcoming projects and to make life a little less painful, I am steering towards XML documentation generators such as Sandcastle, Doxygen or Box Live Documenter.
What are the key considerations I should keep in mind when evaluating the best option and what experiences have led you to a particular decision?
For me the key considerations would be:
Fully automated: Can it be set up in such a way so that pretty much
no outside work is required to
create or edit the documentation.
Fully styled: Can the documentation be fully styled so
that it looks great in a wiki or pdf
after it’s generated. I should be
able to change colors, font sizes,
layouts, etc.
Good Filtering: Can I select only the items I want to be
generated. I should be able to
filter the namespaces, file types,
classes, etc.
Customization: Can I include headers, footers, custom elements,
etc.
I found Doxygen could do all of this. Our workflow is as follows:
Developer makes a change to the code
They update the documentation tags right above the code they just changed
We click a generate button
Doxygen will then extract all the XML documentation from the code, filter it to only include the classes and methods we want, and apply the CSS styling we’ve pre-made for it. Our end result is an internal wiki that looks the way we want, and doesn’t require editing.
Extra: We have all our projects in various git repositories. We pull all these down to one root folder and generate the docs form this root folder..
Would be interested to know how others are automating even further..?
Who is paying for the documentation and why? (is the system stable enough, does it add enough value)
Who is going to read it, and why is she not using a more effective communication channel?
(if correct mostly distance in time/place)
Who is going to keep it up to date.
When are you going to destroy it? (Automatically if it hasn't been read or updated in the past three months?)
I mostly prefer better code to make my life less painful, over more documentation, but I like scenario & unit tests and a high level architecture description.
[edit] Documentation costs time and money to write and keep up to date. JavaDoc style documentation has a serious detrimental effect on the amount of code simultaneously visible and might be a good idea for the developers using the code, but not for those writing it.
I am writing a Web application that has a user interface for editing data. The idea is something similar to a wiki where there are edits to chunks of text. What is the best way to handle asynchronous edits from multiple users? The situation I am considering is this:
There is a document that is version 0. User A is editing it when it is version 0. A few minutes later but before user A saves his changes, user B opens up the same document and starts editing. How should the server treat the two different edits to version 0 of the document? Also what is this problem called and where can I get more information about similar problems?
Wikipedia addresses this problem in the following way:
Assume that person A and person B are both editing the same document. Also assume person A submits their edits slightly before person B.
First the media wiki software runs a traditional diffing algorithm over both edits.
Next, the results of the diffing algorithm are used to merge the text.
If the diffing algorithm finds that there are merge conflicts (i.e. person A and B edited the same piece of text), then person B is asked to resolve the conflicts since they submitted their edits last.
Wikipedia handles merge conflicts much like conflicts in a code repository.
If you want to allow multiple people to edit a document simultaneously and in real-time (like with google wave or etherpad), then I'd recommend looking into operational transforms (aka OT). Though the OT algorithm is no harder or simpler than a traditional diffing algorithm, there is less information on it and fewer ready-made implementations.
One typical pattern is to send each user a chunk of text and also a version number indicating which version they received. The rule is that the host will only accept the first revision to the currently activer version.
That way only one person can revise each version; everyone else would be told that their version was obsolete and you can do what you want for them at that point - usually send them the current version to retry.
This only works if it's unlikely to have multiple people working on the same version. If that's likely, then you probably need to research how subversion for instance handles multiple revisions to source code.
There are also schemes for multiple people working simultaneously on the same text and being feed each others' updates - see Google Wave for one example.