[VOTE] Miscelanea branches

[Casper Hornstrup]

I'd like to close this discussion with a vote.

Should we allow branches (other than trunk) with mixed new development and bugfixes
unrelated to the new development that is on the branch (miscelanea branches) ?

[ ] Yes, do allow miscelanea branches

[ ] No, don't allow miscelanea branches

Casper

[Filip Navara]

Casper Hornstrup wrote:
> I'd like to close this discussion with a vote.
>
> Should we allow branches (other than trunk) with mixed new development 
> and bugfixes
> unrelated to the new development that is on the branch (miscelanea 
> branches) ?
>
> [ ] Yes, do allow miscelanea branches
>
> [X] No, don't allow miscelanea branches

^ I have a strong opinion on this...

- Filip

[Ge van Geldorp]

> From: Casper Hornstrup
>
> Should we allow branches (other than trunk) with
> mixed new development and bugfixes unrelated to
> the new development that is on the branch (miscelanea
> branches) ?
>
> [ ] Yes, do allow miscelanea branches
>
> [X] No, don't allow miscelanea branches

I've kept out of the discussion so far, because I don't have strong feelings
about this. I think that branches should have a well-defined purpose and be
merged as soon as that purpose is fullfilled. But, as I said, I don't have a
strong opinion, so maybe count my vote only as half a vote....

Ge van Geldorp.

[Mike Nordell]

Sorry if this became a bit rant-ish, but I had to get it off my chest.

Casper Hornstrup wrote:
> Should we allow branches (other than trunk) with mixed new development
> and bugfixes unrelated to the new development that is on the
> branch (miscelanea branches) ?

While I'd love to cast a vote on this issue, I recognize the world is not
binary (black and white), but rather shades of gray (~2^10 for human
perception, http://www.gamedev.net/columns/hardcore/hdrenvmap/).

If such bugfixes are indeed _completely_ unrelated to the new (or fixing)
development of the branch, then I'd say they should be committed to
trunk/head/<whatever_you_call_it>. But that does in no way or form imply the
use of "miscelanea branches" invalidated.

Often however, and I speak from personal experience here, new (or
correctional) development for something specific (let's call this set of
changes S) in one area (A, member of S) will find problems in other areas
(B, C). If such problems are indeed of the kind that they affect A to the
extent the author considers B&C in need of fixing before A can be completed,
then the set S is by necessity extended to become A,B,C. So what was
initially perhaps unrelated, has now become integral, and vital.

While I potentially could fix them in the trunk in order C,B,A, it
would be very confusing for bystanders to see me committing C code that
seemingly only restructured locking and/or started using unrelated locking
primitives for no seemingly valid reason, while having the whole change set
for A only locally on my own machine(s). Same for B. Not until A is
committed into trunk would those changes make sense.

I also think a branch, which can be used as a public repository of local
changes, is to prefer over e.g. me just hacking away at home - not sharing
any code until a later date, and risking every byte of it due to e.g. a
hardware failure. Putting such code in a repository branch where it both can
be viewed by others to see the direction I'm taking, and for safekeeping
(assuming one trusts the
repository), is in my mind a superior alternative to the (possibly
hazardous) options.

This is btw no free-form fanatasy, this is based on personal experience
(with the difference the "branch" was only held on my local computer, where
noone at all could see what I did, and when a hardware failure hit me I lost
most of it, and steam, why nothing of it ended up in the repository). A was
fast mutex, B was Cc, C was Mm, and in addition to this a number of other
areas also ended up needing modifications.

So why did climb the soap box again? To try explain my view, and experience,
that we do not live in a binary world, and with such deep dependencies, new
or fixed code in one area might have impact on code in areas initially
completely unrelated, but due to dependencies becomes an integral part of
the initial set.

But to at least excercise my right to vote, I vote "None of the options".
This I think is, or should become, a valid alternative, since it displays I
have excercised my right to vote, and participated in the voting procedure,
but not agreed with any of the presented alternatives enough to stand behind
them. In part, this decision is due to the impreciseness of the question,
and the not 100% crystal clear definition of "miscelanea branches" (I can
see at least two interpretations of it).

/Mike

P.S. If following up, please don't over-quote, and please use only
plain-text for the western locale(s).

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Mike Nordell
> Sent: 12. marts 2005 16:12
> To: ReactOS Development List
> Subject: Re: [ros-dev] [VOTE] Miscelanea branches
>
> Sorry if this became a bit rant-ish, but I had to get it off my chest.
>
> Casper Hornstrup wrote:
> > Should we allow branches (other than trunk) with mixed new
>
> development
> > and bugfixes unrelated to the new development that is on the branch 
> > (miscelanea branches) ?
>
> While I'd love to cast a vote on this issue, I recognize the 
> world is not binary (black and white), but rather shades of 
> gray (~2^10 for human perception, 
> http://www.gamedev.net/columns/hardcore/hdrenvmap/).

Your example is hardly relevant to this vote. It makes sense to not
regress ReactOS on purpose. Therefore, if you make a change, and this
change causes another part of ReactOS to break, then a change to correct
that regression is indeed a related change.

Casper

[Hartmut Birr]

Casper Hornstrup schrieb:
> I'd like to close this discussion with a vote.
>
> Should we allow branches (other than trunk) with mixed new development
> and bugfixes
> unrelated to the new development that is on the branch (miscelanea
> branches) ?
>
> [ ] Yes, do allow miscelanea branches
>
> [x] No, don't allow miscelanea branches

- Hartmut

[Alex Ionescu]

Casper Hornstrup schrieb:
> > I'd like to close this discussion with a vote.
> >
> > Should we allow branches (other than trunk) with mixed new development
> > and bugfixes
> > unrelated to the new development that is on the branch (miscelanea
> > branches) ?
> >
> > [x] Yes, do allow miscelanea branches
> >
> > [ ] No, don't allow miscelanea branches

Some people actually like to have versionning for their own private work 
and have a nice way to revert/update.
The whole point of an svn branch is so you don't lose your work, so that 
others can see, and so that you have a versionning system to take care 
of your own work. It seems barbaric and fascist to disallow someone from 
maitaning his own branch, even if his changes are useless, 
trial-and-error, or simply shit.

Best regards,
Alex Ionescu

[Alex Ionescu]

Alex Ionescu wrote:
> Some people actually like to have versionning for their own private 
> work and have a nice way to revert/update.
> The whole point of an svn branch is so you don't lose your work, so 
> that others can see, and so that you have a versionning system to take 
> care of your own work. It seems barbaric and fascist to disallow 
> someone from maitaning his own branch, even if his changes are 
> useless, trial-and-error, or simply shit.
>
> Best regards,
> Alex Ionescu

This is my proposition:

I admit that I fucked up (oooh big word) with the branch for many 
reasons, but I would still like to be able to do the following:

1) Have alex_devel_branch
2) Create a bug fix or new feature, tag it as such
3) Test this bug fix or feature until it works
4) Merge to Head
5) Create new bug fix or new feature, tag it as such, STILL in the same 
branch
6) Lather, Rinse, Repeat.

I want to be able to re-use that branch for adding new things, but for 
them to be UNIQUE/ATOMIC changes (as Casper calls them "feature 
branches"). So it would be a perpetually reusable feature branch, but 
only containing a single feature at one time, and always getting merged 
when that feature is complete.

Can we have that middle ground?

Best regards,
Alex Ionescu

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Alex Ionescu
> Sent: 12. marts 2005 18:36
> To: ReactOS Development List
> Subject: Re: [ros-dev] [VOTE] Miscelanea branches
>
> Alex Ionescu wrote:
> > Some people actually like to have versionning for their own private 
> > work and have a nice way to revert/update.
> > The whole point of an svn branch is so you don't lose your work, so 
> > that others can see, and so that you have a versionning
>
> system to take
> > care of your own work. It seems barbaric and fascist to disallow 
> > someone from maitaning his own branch, even if his changes are 
> > useless, trial-and-error, or simply shit.
> >
> > Best regards,
> > Alex Ionescu
>
> This is my proposition:
>
> I admit that I fucked up (oooh big word) with the branch for 
> many reasons, but I would still like to be able to do the following:
> Have alex_devel_branch
> Create a bug fix or new feature, tag it as such
> Test this bug fix or feature until it works
> Merge to Head
> Create new bug fix or new feature, tag it as such, STILL
>
> in the same branch
> 6) Lather, Rinse, Repeat.
>
> I want to be able to re-use that branch for adding new 
> things, but for them to be UNIQUE/ATOMIC changes (as Casper 
> calls them "feature branches"). So it would be a perpetually 
> reusable feature branch, but only containing a single feature 
> at one time, and always getting merged when that feature is complete.
>
> Can we have that middle ground?
>
> Best regards,
> Alex Ionescu

It's true that the work is safer in the repository and we should still use
branches. An alex_devel_branch is not a problem until that X MB change is
to go into trunk.

For bugfixes, I would be for your suggestion, but for new features,
I'd prefer a branch name that describes it's purpose.

Casper

[Thomas Weidenmueller]

Casper Hornstrup wrote:
> [ ] Yes, do allow miscelanea branches
>
> [X] No, don't allow miscelanea branches

[James Tabor]

Casper Hornstrup wrote:
> I'd like to close this discussion with a vote.
>
> Should we allow branches (other than trunk) with mixed new development 
> and bugfixes
> unrelated to the new development that is on the branch (miscelanea 
> branches) ?
>
> [ ] Yes, do allow miscelanea branches
>
> [ ] No, don't allow miscelanea branches
>
> Casper

*Warning!*

This could be the beginning of a ROS fork!

I thought flexibility was very important with this project?

I don't know,
James

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of James Tabor
> Sent: 12. marts 2005 18:12
> To: ReactOS Development List
> Subject: Re: [ros-dev] [VOTE] Miscelanea branches
>
> *Warning!*
>
> This could be the beginning of a ROS fork!
>
> I thought flexibility was very important with this project?
>
> I don't know,
> James

Hehe. You are so funny ;-)

Casper

[Gunnar Dalsnes]

Casper Hornstrup wrote:
> I'd like to close this discussion with a vote.
>
> Should we allow branches (other than trunk) with mixed new development 
> and bugfixes
> unrelated to the new development that is on the branch (miscelanea 
> branches) ?
>
> [ ] Yes, do allow miscelanea branches
>
> [x] No, don't allow miscelanea branches
>
> Casper

Branches suck;-P (release branches i can understand). I even disagree 
with the rbuild branch. Done correctly, rbuild could easily coexist in 
the trunk.

[art yerkes]

On Sat, 12 Mar 2005 10:57:42 +0100
"Casper Hornstrup" [e-mail] wrote:
> I'd like to close this discussion with a vote.
>
> Should we allow branches (other than trunk) with mixed new development and bugfixes
> unrelated to the new development that is on the branch (miscelanea branches) ?
>
> [X] Yes, do allow miscelanea branches
>
> [ ] No, don't allow miscelanea branches
>
> Casper

et tu, brute?
-- 
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman

[Royce Mitchell III]

Casper Hornstrup wrote:
> [X] Yes, do allow miscelanea branches
>
> [ ] No, don't allow miscelanea branches

Alex never meant for his branch to become such a mess. ReactOS 
development has, with a few exceptions regarding IP, been quite open, 
and I'd hate to see us start to head away from that. ReactOS has a lot 
of work to go to get where we want it to be, and to start unnecessarily 
restricting how devs can work on it will slow down the pace of 
development. I want ReactOS useable before I'm 80.

I understand what a mess Alex's branch became, but when it came down to 
it, he was willing to comply with the requirements made of him to get 
his changes into trunk in an organized manner.

[ea]

Casper Hornstrup wrote:
> I'd like to close this discussion with a vote.
>
> Should we allow branches (other than trunk) with mixed new development 
> and bugfixes
> unrelated to the new development that is on the branch (miscelanea 
> branches) ?
>
> [ ] Yes, do allow miscelanea branches
>
> [X ] No, don't allow miscelanea branches

This vote is against miscellanea branches, not against Alex, as clearly 
stated by Casper. Alex has contributed excellent code. I saw at work too 
how much harm miscellanea branches can do (we use VSS, but the effect is 
the same). The core idea behind the branch concept is that it is *off* 
the main line. What happened to the Alex branch is an unfortunate event, 
but, imho, it is a good thing that Casper asked the Team "Do we need a 
bit of discipiline?". After all, this is a good example of a self 
modifing system :)

Emanuele Aliberti

[Casper Hornstrup]

> From: [e-mail] [mailto:[e-mail]] On Behalf Of Casper Hornstrup
> Sent: 12. marts 2005 10:58
> To: 'ReactOS Development List'
> Subject: [ros-dev] [VOTE] Miscelanea branches
>
> Should we allow branches (other than trunk) with mixed new development and bugfixes
> unrelated to the new development that is on the branch (miscelanea branches) ?
>
> [ ] Yes, do allow miscelanea branches
>
> [X] No, don't allow miscelanea branches
>
> Casper

[Casper Hornstrup]

Should we allow branches (other than trunk) with mixed new development and bugfixes
unrelated to the new development that is on the branch (miscelanea branches) ?
 
[ ] Yes, do allow miscelanea branches (3 votes)

[ ] No, don't allow miscelanea branches (7 votes)

Entered here: http://reactos.com/wiki/index.php/Miscelanea_branches
 
Casper