[Commotion-dev] Submitted DNS and configuration changes

[Hans-Christoph Steiner]

On May 11, 2012, at 10:29 AM, Will Hawkins wrote:

> On 05/10/2012 08:13 PM, Hans-Christoph Steiner wrote:
>> 
>> On May 10, 2012, at 8:00 PM, Nathan of Guardian wrote:
>> 
>>> On 05/10/2012 06:22 PM, Hans-Christoph Steiner wrote:
>>>> Ah, ok, that github olsr-wifi-tehter repo is defunct,
>>> we should perhaps archive it then? or otherwise indicate we have moved
>>> dev over to:
>>> https://code.commotionwireless.net/commotion/commotion-android.git
>> 
>> My plan was to delete it from github once things are ironed out.  I just changed the description and link to reflect the current status.
>> 
>>>> I think we should try to use the commotion-android Redmine for everything related.  That said, I've never done it with Redmine, so I couldn't tell you how...
>>>> 
>>> Redmine doesn't offer a Pull Request type feature. I think you will have
>>> to do it the old fashion way, merge branch (which is what a pull request
>>> really is) or patch!
>> 
>> I'm not a fan of github pull requests because they make you do merges.  Instead the patches can just be applied directly and then you have a nice clean history :)  I think the thing to do with Redmine is either post patches or a link to another git repo with the commits.
> 
> I have not real preference one way or the other. I shoe-horned these
> changes into a pull request because I thought that would be the easiest
> way for you.
> 
> I am happy to submit a zip file full of patches, maintain a github repo
> with a NAF branch that you can pull from or host a read-only repo on
> code.commotionwireless.net that you can pull from. Suffice it to say
> that I am flexible!!
> 
> Andrew has asked that the other Commotion devs here at OTI weigh in on
> the best way to handle this. Hopefully there will be people who have
> good ideas! :-)

How about we start with patches on this email list, then if need be, they can be posted on  the Redmine issues tracker so we don't loose track of them.  Having your own git somewhere public does make it a bit easier to accept the patches, but not essential.  If you're going to be working on this app a lot, ultimately, you would just commit directly, once we figure out a good workflow.

.hc