GitHub Issue Tracker, feature branches?

7 views
Skip to first unread message

Patric Schmitz

unread,
Sep 2, 2015, 5:17:18 AM9/2/15
to veejay-d...@googlegroups.com
Hi Niels,

have issued a pull request for the immediate changes I had to do on
Arch Linux. I have some questions..

Do you want to use the issue tracker on GitHub as well? In that
case I would quickly open an issue for all things I spot or think
of as an enhancement, and we can use it also as a discussion
platform.

Do you have a particular preference for how pull requests shall be
done? Like using dedicated feature branches for all pull requests
s.t. you may selectively merge them into veejay master?

Best regards

--
Patric Schmitz <bzk...@aol.com>

Niels Elburg

unread,
Sep 2, 2015, 8:03:02 AM9/2/15
to veejay-discussion
Hi Patric,

The pull request(s) against master is fine for now, once I get back from my holidays we can see if a separate branch is necessary :) 

You are welcome to open new issues on github ofcourse,

Also, I have contacted freenode staff to register the #veejay channel

See you,
Niels




--
Patric Schmitz <bzk...@aol.com>

--
You received this message because you are subscribed to the Google Groups "veejay-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to veejay-discuss...@googlegroups.com.
To post to this group, send email to veejay-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/veejay-discussion.
For more options, visit https://groups.google.com/d/optout.

Bastiaan van den Berg

unread,
Sep 2, 2015, 8:16:30 AM9/2/15
to veejay-d...@googlegroups.com
On Wed, Sep 2, 2015 at 2:03 PM, Niels Elburg <nwel...@gmail.com> wrote:
Also, I have contacted freenode staff to register the #veejay channel


I'll be waiting there ;)

Matthijs van Henten

unread,
Sep 3, 2015, 6:34:44 AM9/3/15
to veejay-d...@googlegroups.com
Awesome!

FYI in contributing: small branches with a commit or three is usually what we work with @work, also for OSS contributions to the codebase.
This makes it simple to quickly have a look and just press "merge" when simple enough. bit it may be overkill for veejay.


On Wed, Sep 2, 2015 at 11:17 AM, 'Patric Schmitz' via veejay-discussion <veejay-d...@googlegroups.com> wrote:

--
Patric Schmitz <bzk...@aol.com>

--
You received this message because you are subscribed to the Google Groups "veejay-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to veejay-discuss...@googlegroups.com.
To post to this group, send email to veejay-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/veejay-discussion.
For more options, visit https://groups.google.com/d/optout.



--
webdeveloper & consultant @technischepartij.nl
Mobile: +31 (0)630841238

Retiefstraat 51-III
1092VX Amsterdam
The Netherlands

bzk...@aol.com

unread,
Sep 3, 2015, 7:32:07 AM9/3/15
to veejay-d...@googlegroups.com
Hey,

yeah that's what I find preferrable from the maintainer's view
as well, especially if there need to be corrections before
actually merging the pull request, or a set of patches might not
be required after all but the two requests are issued in
parallel.

What I always wondered is how to handle this nicely on the
committer's side. I mean if I want to continue working on a
version with both outstanding changesets integrated, how would I
go about this? I don't want to merge them into 'master'
prematurely since that might collide with a later merge from
upstream. Do you have an additional (throwaway? ) local branch
where you keep all the changes until they are accepted/rejected
in upstream master?

On Thu, 3 Sep 2015 12:34:44 +0200
Matthijs van Henten <matt...@ischen.nl> wrote:

> Awesome!
>
> FYI in contributing: small branches with a commit or three is usually what
> we work with @work, also for OSS contributions to the codebase.
> This makes it simple to quickly have a look and just press "merge" when
> simple enough. bit it may be overkill for veejay.

--
Patric Schmitz <bzk...@aol.com>

Matthijs van Henten

unread,
Sep 4, 2015, 4:12:07 PM9/4/15
to veejay-d...@googlegroups.com
Ow, this is the hard question :)

Of the few pull requests that I've submitted in the past, little got merged, eventually. Sometimes it prompted the author to improve something.
It always helps to contact the author directly too :)

I think most authors simple have too little time to actually review those, or take ownership on publishing. 

OTOH from the few pull request I got on personal project, I've tried to accept the most of them.
Generally I'd say: the smaller you can make a pull request, the better. branching is cheap, on any of my projects I generally have multiple branches open.

Then again, @work I sometimes create multiple branches per day, each only having a few commits that can be merged into production without damaging.
So I build them up from small configuration changes, utility refactors, leading up to a bigger change eventually, trying to keep the changeset to a minium.

@niels I guess that would be a new flow for you on veejay :) 

Veejay is a huge codebase and extremely complex. As I'm not a c programmer, it's hard for me to estimate the work here. But even if you would, say, improve a smallish thing like adding an icon, or improving the writing, keeping it small and simple is the way to go.

@niels I'm not aware, but does veejay have some sort of automated test suite? how would that run?

Just my few thoughts here :)

Matthijs.

--
Patric Schmitz <bzk...@aol.com>

--
You received this message because you are subscribed to the Google Groups "veejay-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to veejay-discuss...@googlegroups.com.
To post to this group, send email to veejay-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/veejay-discussion.
For more options, visit https://groups.google.com/d/optout.

Niels Elburg

unread,
Sep 5, 2015, 5:38:17 PM9/5/15
to veejay-discussion
Hey Matthijs!

Veejay does not have unit tests - There is a bunch of testscripts in test/ but that's probably not what you are looking for. 

The real thing is to commit without breaking stuff, so you'd have to test all parts that touch that particular funtionality (that's probably why you work in a branch with small incremental commits so its easy to revert and you probably have a bunch of collegues messing arround with it at the same time).

Most things that happened so far are simply some smaller but usefull bug fixes, When people push a request to add a feature or change existing functionality, then I would branch off and study its impact but now that I'm on holidays, I will just sit back and relax :)

For now, the best thing to do is to commit each fix separately like Patric has been doing already and push them early. Also, if you are not sure you can always announce what you are working on and see if anyone else is too,

Veejays code base is not that complicated, the hard parts you probably don't need to touch at all and some other parts need to be refactored since they have become a little bit messy (see, libvevosample is way over due)

See you,
Niels


Matthijs van Henten

unread,
Sep 7, 2015, 7:32:06 AM9/7/15
to veejay-d...@googlegroups.com
well, that sort-of aligns with what I do too :)

Would be interesting to look into building and running /test on travis or something in the future.
Reply all
Reply to author
Forward
0 new messages