theUser BL wrote:
> But at
> http://www.reactos.org/archives/public/ros-dev/2006-February/007832.html
> a developer says to me
> "The leaked source code was never an issue here, that was an escalation of
> the mail which was posted on the public list. The rumours which
materialized
> from that were unfounded and untrue."
> and the cvs tree will be completly re-opend.
IIRC, it was me who said that. What I mean by that is that none of the
leaked Windows source code has ever found it's way into ReactOS. Many people
thought that was the case, but they were wrong.
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
I must agree. Problems can sometimes bring out the best in people and
projects. The fact that there was a minor setback will likely make the
project stronger and btter then ever, even if only by reafirming to the
project by those who have committed the most.
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org]
On Behalf Of mf
Sent: Thursday, February 16, 2006 3:09 AM
To: ReactOS Development List
Subject: [ros-dev] Re: Goodbye Everyone...
Steven Edwards wrote:
> We seem to be a ship that is taking on water.
Gee, if that's the attitude our Project Coordinator, role model and
source of inspiration for the project, is taking, then I don't know what
I should think. Are you just acting this unoptimistic because you feel
like a captain who's almost got mutiny on his hands, or is it some other
reason? From everything I've seen, I'd say things are looking up lately.
But that's just my humble opinion.
mf.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Dann B. Smith wrote:
> Hmmm... Wrong. A strong leadership can prevent the
> politicization of a
> project if handled correctly.
>
> I would like to paraphrase certain scientists here and say that if you
> have to vote on a thing, it isn't science (or engineering).
> And if it's
> science (or engineeirng), it does not (ever) need a vote.
>
> Science and engineering are based on two things: truth and
> workability
> (respectively).
>
> If that maxim can't be followed, the rest of the discussion is moot,
> since the project has already died.
It has nothing to do with Science or engineering.
It's a simple case of people having different ideas and we have to work out
which path to follow.
In a volentary project like this, how else do you propose different views
are solved?
You can't forcefully make someone do something unless you are paying them,
thus a majority vote is the only fair way.
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Hmmm... Wrong. A strong leadership can prevent the politicization of a
project if handled correctly.
I would like to paraphrase certain scientists here and say that if you
have to vote on a thing, it isn't science (or engineering). And if it's
science (or engineeirng), it does not (ever) need a vote.
Science and engineering are based on two things: truth and workability
(respectively).
If that maxim can't be followed, the rest of the discussion is moot,
since the project has already died.
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org]
On Behalf Of Murphy, Ged (Bolton)
Sent: Thursday, February 16, 2006 4:21 AM
To: 'ReactOS Development List'
Subject: RE: [ros-dev] Goodbye Everyone...
Rick Langschultz wrote
It is inevitable that as a project grows in size and popularity, it also
becomes much more political.
Ged Murphy wrote:
> B - Sections of ReactOS which require auditing are 'locked',
> that being that the source is fully available to download and
> build, but no development work should be undertaken until
> the said code has passed the audit. The lock will be
> removed only when that section of code has been audited.
I am in agreement with proposal B, freezing of un-audited sections. Here
are my reasons:
Firstly I'll elaborate on what a lock does:
Any developer can 'get-a-lock' on a file. Having this lock means only
that developer can commit to that file*. A locked file cannot be
modified, deleted or renamed in the repository by anyone else.
To set a lock on a file, you lock it as per your client syntax and set
the subversion property svn:needs-lock. When this property is set on a
file, a checked out or updated file is made read only locally. (except
for the person who holds the lock*). This acts as a warning that the
file should not be modified. Users of Tortoise will also have a
graphical overlay stating a file is locked.
Locks can be removed by any developer in a process called
breaking-the-lock. (ownership of the lock can also be taken known as
stealing-the-lock, although that's not important for us). The ability to
Break the lock ensures that no one developer has control over the lock.
Anyone can remove a lock at any time.
Users and developers alike will not notice a lock unless they try to
modify locked code, so it would in no way inhibit general usage.
*(a user named 'audit' can be set up to do the initial locking of the
files)
What the lock would do is act as a barrier for any further development
on non-audited code. Code which has not been audited must be deemed as
'tainted' until it has passed an audit.
I do however think that what we deem as tainted can be narrowed down.
All usermode applications along with all Wine libs and many other areas
(to be discussed) will bypass the lock immediately.
Code which has not yet passed the audit should not be improved,
committed to, developed (whatever the phrase). There are 2 good reasons
for this. Firstly, there is a possibility that this code needs to be
removed, so it is a complete waste of a developers time to improve this
code.
Secondly (and most importantly), by freezing this code, it puts more of
an incentive on developers to audit it. e.g. if someone is working on
some code which requires a particular section of un-audited code to be
modified, or exposes a bug in some un-audited code, the developer must
audit the said code in order to fix the problem. Only then will they be
able to take advantage of this with their ReactOS improvement/addition.
If this code wasn't frozen, the chances are, the developer will tweak
the un-audited code and carry on regardless. Thus un-audited code will
tend to take a back seat.
I agree with Gé, in that if some method is not put in place to ensure
our code is audited, people will conveniently forget about it.
Not only must we been seen to be pro-active with the audit for the
general public to see (e.g. osnews, slashdot), but we must also ensure
we do not alienate developers who feel _very_ strongly about the
un-audited code. By reopening the repository, with the addition of
locking un-audited code, I think we can strike a fair compromise for all
parties, and ensure the audit takes place.
Ged.
> The Ros CDs loader might be useful for you too.
This did remind me we can download ros sources without using SVN.
Therefore I have the freeldr installer now,
thanks for all.
If you didnt read the mailing list since some time,
SVN code is being audited and
contains almost nothing atm for *users*.
--- Sarocet <sarocet(a)gmail.com> a écrit :
> Sorry, as you talked about old svn i thought that was your problem.
> Don't know what happened with svn, i have been disconnected of the project
> over a month.
> The data you want is (should be) probably in trunk/reactos/boot/freeldr at
> folders freeldr and install.
> I also see strange no data in branches folder.....
>
> Anyway, i can send you the freeldr folder i have on my svn copy (over a
> month and a half old). I guess better wait until get the new svn before
> updating.
> The Ros CDs loader might be useful for you too.
>
Kind regards,
Sylvain Petreolle (aka Usurp)
--- --- --- --- --- --- --- --- --- --- --- --- ---
Tired of a proprietary Windows on your computer ?
Use free ReactOS instead ( http://www.reactos.org )
http://www.reactos.org/forum/viewtopic.php?t=1697
--
Discordant is the murmur at such treading down of lovely things while
god's most lordly gift to man is decency of mind. Call that man only
blest who has in sweet tranquility brought his life to close.
If only I could act as such, my hope is good.
-- Aeschylus' Agamemnon (translated by H. W. Smyth)
Well, it's been fun, however i believe it is time for me to leave.
ReactOS really has fallen to pieces and it's going to take a long time
(years) to get things back on track. What really annoys me about this
entire thing is that waaay back in the earlier days of ROS (before 0.1)
Things were fun. Nothing worked, but things were fun. Development on
ROS was actually HAPPENING (I know this because I myself was part of
it). Since then things started changing. New developers appeared, a
lot of flame wars were breaking out, etc. I stayed on the list, pitched
in my 2 cents, etc. Though i stopped coding for the most part. Now it
turns out that developers were using dirty room reverse engineering
tactics, or have had access to the source code. I almost left then, but
i figured i'd give it a little bit longer and see what happens. Now I
see a bunch of arguing on the mailing list, ROS development has stopped,
and I'm doubting it'll resume again for a long time, and things have
just pretty well fallen apart. Even IF the audit is completed, ROS will
likely be in pieces. It will NEVER be at the level it was before the audit.
Anyways, I believe it is time to start anew. New project, different
name, different goals.
Until Then,
Bye.
Richard Campbell
ReactOS Developer and Long Time Fan
The vote on choosing a plan for further ReactOS development is now
finished. The results are:
Plan A: 4
Plan B: 14
This means that all points from the Plan B are now in force.
Additional announcement will be made regarding the SVN repository.
For detailed read go to http://www.reactos.org/forum/viewtopic.php?
t=1675
WBR,
Aleksey Bragin.
At 15:01 16/02/2006 -0000, you wrote:
>Sorry, I'm not really sure what your question is.
>
>After being derailed recently, ReactOS is now being put back on the tracks.
>There is finally a clear path starting to emerge for development to restart.
>There will not be a fork, development work will continue on ReactOS.
>
>If any of those don't answer your question, can you try to reword it please.
:))
Don't be sorry: I am used with not being understood, and i am quite
sure that this is not because of my "particular english".
:))
Well, my question has been answered to, by the recent answers to
Hyperion post, and, mind you, if you do not understand what i write,
as a matter of fact, it seems that i understand rather well how the
things are going, because since day one of the "problem", when some
other lurkers fellows of mines were under alarm mode about it, i told
them that "the problem will not take years, but 3 months".
And if you could understand my previous question, you would
prefectly understand, also, how and why i was able to predict
the exact time that it would take, before yourselves, whereas
i do not even write C.
:))
Betov.
< http://rosasm.org >
