Sorry, I missed your email. See comments inline... And i'll cc the dev list ...
2015-05-03 6:50 GMT+02:00 Lyor Goldstein <lgoldst...@vmware.com>: > > > Hi Guillaume, > > > > I got an announcement that an account has been created for me (lgoldstein). > How do we proceed from here ? > Welcome aboard ! > > > There are a few issues I was wondering about regarding the commit process: > > > > · I usually like to work on a separate branch where I do all the > commits and then merge it (squashed, so it will be a single commit) back > into *master*. I also like pushing these temporary branches back to the > repository from time to time as backup. Once the feature is successfully > merged into *master* I usually delete these branches. This means that > from time to time there will be (remote) branches appearing and > disappearing. Is this acceptable ? > > I think you should use a clone of the official repo in your github account for work in progress, unless these are branches to want others to contribute to, in which case pushing a branch to the official repo is fine. For such open branches, discussion on the mailing list would be appropriate. > > > · How can I have my suggested code changes reviewed before > merging into *master* ? What is your preferred procedure for it ? > Ask on the dev list if you want someone to review or discuss your changes. Given you have been voted as a committer, you don't *need* review before committing, but for big changes, it's obviously better to discuss them. > > > · Regarding tracking the issues in JIRA – I fully agree that each > commit should be associated with a JIRA issue. My question is this – > suppose I have an idea about an enhancement or something that seems to me > to be a bug. Should I first create an issue in JIRA, wait a few days for > remarks and then start working on it ? Or should I work on it “offline” and > when I feel I am ready then open an issue and post the suggested changes ( > *before* merging them into * master* of course…). There are advantages > and disadvantages to both – my main concerns are > > > > o (a) avoid duplication – the fact that an issue has been opened does > not necessarily mean that someone is working on it. On the other hand, the > fact that no one *says* they are working on it does not mean that no one > is working on it. How do we avoid 2 (or more) persons working on the same > issue ? Is there some state / label /etc. that we can mark the issues to > say “I am working on it…”? > There's a "Start Progress" on the JIRA to indicate you're working on it. I would think people do not start working on issues someone is already working on... > > > o (b) ensure that work is not being done for nothing – suppose someone > strongly disagrees with a suggested feature or bug. How do we “vote” on the > issues that we will work on in order to make sure that work is not being > done which will be voted down. In other words, the fact that no one > commented on an issue does not necessarily means that it is agreed to work > on it. How long after opening an issue and getting no comment can one > assume that everybody agrees that the posted issue is worth working on ? > Yes, there's always this possibility. If you're not sure about if a change will be accepted, the best way would be to raise the discussion on the dev list. The issue can either be created before or after and the discussion can either happen on the dev list of the jira, there's no strong rules, as all JIRA notification are sent to the list anyway. There's also a #mina channel on irc.freenode.net which is rarely used, but it can be handy for quick chats. > > > Thanks – can’t wait to start contributing, > > Lyor >
