On Wed, 08 Nov 2017 21:39:15 +0000 Mike Blumenkrantz <michael.blumenkra...@gmail.com> said:
> Key points for the implementation: > > * all commits send mails to the list > * no rewrite of pushed commits > > Things to consider: > * how are feature/ branches deleted? > - maybe anyone can delete? Good point. these need deletion. after a few years it'll be a mess of old feature branches no one will ever look at again. The merge to master should contain all the history and log that is needed at that point for history digging. > * do probies get feature/ push access? > - seems like they should? > > On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen <t...@stosb.com> wrote: > > > 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 > > > ------------------------------------------------------------------------------ > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ 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
