Re: Need of a "devel" branch?
On Sun, Oct 23, 2016 at 12:23:45AM +0100, Thomas Adam wrote: > On Sat, Oct 22, 2016 at 11:41:54PM +0100, Dominik Vogt wrote: > > Unless we're doing lots of disruptive stuff I'd prefer to > > propagate completed patchsets into master early so they get more > > testing. > > Yup. Well, that's what we have enforced right now, so I think it's working as > intended. Of course, during development on a given feature, there's nothing > stopping a few developers working against a common topic integration branch of > their own, which is then used as the topic-branch for review before it hits > master. I suspect we'll never get there though, given the low number of > developers, alas. Let's just watch how things work for a while and then see if its necessary or not. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Need of a "devel" branch?
On Sat, Oct 22, 2016 at 11:41:54PM +0100, Dominik Vogt wrote: > Unless we're doing lots of disruptive stuff I'd prefer to > propagate completed patchsets into master early so they get more > testing. Yup. Well, that's what we have enforced right now, so I think it's working as intended. Of course, during development on a given feature, there's nothing stopping a few developers working against a common topic integration branch of their own, which is then used as the topic-branch for review before it hits master. I suspect we'll never get there though, given the low number of developers, alas. -- Thomas Adam
Re: Need of a "devel" branch?
On Sat, Oct 22, 2016 at 11:23:17PM +0100, Thomas Adam wrote: > On Sat, Oct 22, 2016 at 11:12:58PM +0100, Dominik Vogt wrote: > > A "devel" branch could come in handy. When a feature is complete > > or ready for reviews, the patches are placed on the devel branch > > and then every ambitious user can try them out and report > > problems. The "devel" branch would receive the same automatic > > testing as master, but can be rebased or rewritten at any time. > > > > Releasing commits drom devel to master just means to do a fast > > forward rebase of the master's tip to a commit on devel. > > > > Of course, devel must never be rebased past the current master, > > and merge commits on the devel branch should be avoided (so it can > > be reabes without disrupting things). > > What you're fundamentally describing is what the git project does, although > they call their next-release-branch "next", rather than "devel" (the name > really doesn't matter). See: > > https://git-scm.com/docs/gitworkflows > > I suspect that's overkill for us, Yes, you're right. We're not a project with dozens of developers, so most of it is overkill. > although we could adopt some of this --- > namely, a devel branch which we rewind against master after every release. Unless we're doing lots of disruptive stuff I'd prefer to propagate completed patchsets into master early so they get more testing. > Topic branches still apply, and if any fixes are needed, they have to come > from those branches and nowhere else. Yes, nobody should be working on the integration or release branches directly. Although it's a bit more typing, I like it that all changes go through mandatory topic branches. Makes you work more carefully. > I don't think we need anything like their 'pu' concept since we don't have > enough development. Yep. After all, it's not possible to completely prevent bad commits from creeping into master. Things can be changed on master, but then it's the old CVS-like ways of undoing old commits. It's not the end of the world though. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Need of a "devel" branch?
On Sat, Oct 22, 2016 at 11:12:58PM +0100, Dominik Vogt wrote: > A "devel" branch could come in handy. When a feature is complete > or ready for reviews, the patches are placed on the devel branch > and then every ambitious user can try them out and report > problems. The "devel" branch would receive the same automatic > testing as master, but can be rebased or rewritten at any time. > > Releasing commits drom devel to master just means to do a fast > forward rebase of the master's tip to a commit on devel. > > Of course, devel must never be rebased past the current master, > and merge commits on the devel branch should be avoided (so it can > be reabes without disrupting things). What you're fundamentally describing is what the git project does, although they call their next-release-branch "next", rather than "devel" (the name really doesn't matter). See: https://git-scm.com/docs/gitworkflows I suspect that's overkill for us, although we could adopt some of this --- namely, a devel branch which we rewind against master after every release. Topic branches still apply, and if any fixes are needed, they have to come from those branches and nowhere else. I don't think we need anything like their 'pu' concept since we don't have enough development. -- Thomas Adam
Need of a "devel" branch?
In the times of CVS we've pushed every dirty commit to the one CVS branch we had, undoing things if need be. Nowadays using Git I feel really unconfortable doing this, not everything should be pushed to the stable branch right away. Although we do have topic branches with proposed changes now and everybody could test them easily, I suspect there would be very few people who would actually try out a topic branch. A "devel" branch could come in handy. When a feature is complete or ready for reviews, the patches are placed on the devel branch and then every ambitious user can try them out and report problems. The "devel" branch would receive the same automatic testing as master, but can be rebased or rewritten at any time. Releasing commits drom devel to master just means to do a fast forward rebase of the master's tip to a commit on devel. Of course, devel must never be rebased past the current master, and merge commits on the devel branch should be avoided (so it can be reabes without disrupting things). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
