Yeah, good idea.

I'll take a look into implementing it soon.

On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <a...@andywilliams.me> wrote:
> Hi,
>
> That sounds great - the ability to work together on features off-master
> would be really helpful.
>
> Andy
>
> On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
>
>> After some discussions about git organization, it's become clear to me that
>> we should be trying to enact some changes which facilitate collaboration,
>> both between existing contributors and keeping in mind future contributors.
>>
>> The current git branch policy is this:
>>
>> * master
>> * $project-$version
>> * devs/$name/$branchname
>>
>> No others are allowed. This fits many use cases, but it does not actually
>> help us work towards collaborating on features/patchsets and instead
>> promotes developing in isolation.
>>
>> A simple proposal could improve this without requiring or significantly
>> changing our workflow: add "feature/" branches. For example, if Cedric and
>> I decide to work on a "feature" which scrapes the archive of this mailing
>> list and then crashes the session of anyone who replies to this thread, we
>> might jointly create a branch named "feature/discussion_helper" and push
>> commits to it.
>>
>> A key point of this proposal would be that the feature/ branches must
>> trigger mails to the mailing list just like stable branches. This would
>> increase visibility for feature branches as well as promote further
>> collaboration even from those who are not directly involved in creating the
>> feature. The initial feature development could be done in a dev/ branch,
>> and then it could later move to a feature/ branch once it has progressed to
>> the point where it is ready for public visibility and increased
>> collaboration.
>>
>> Lastly, feature branches would not be required use, just encouraged. This
>> allows people to continue the current EFL standard of always committing
>> only to master without any prior testing or branching, the need for which
>> has defeated other proposals which would prevent such action.
>>
>> I think this could yield significant improvements to the community's
>> overall workflow without massively changing the structure under which the
>> everyone has been functioning.
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
> --
> http://andywilliams.me
> http://ajwillia.ms
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to