30 Mar
2009
30 Mar
'09
10:18 a.m.
Hello,
I'd like to improve the existing situation we have with Wine syncing.
Right now, we have a group of people, occasionally doing Wine syncs,
and that group of people included me some time ago too. However, date
was never really specified, and syncing happens "when someone wants
to sync", "before releasing", or when something is fixed in Wine and
we import that code.
How it should happen (in my opinion). All non-forked DLLs, tools and
programs must be synced after each Wine minor release. This is going
to be manual process, so we need a person to organize this process,
and a few people who could participate in doing actual work (syncers).
What this "team" leader / responsible person should do:
* Share the work (modules) between syncers.
* Leave hard-to-sync modules to experienced developers and himself.
* Ensure all syncers are instructed to do basic testing (running our
"golden" list of apps - FireFox, AbiWord, mIRC, and testing ole32/
rpcrt4/widl with a real app which uses OLE mechanism) before
committing the work.
* Be aware about syncing dependencies (e.g. when syncing widl, it
makes sense to sync rpcrt4 simulteneously)
* Be aware about problematic syncs (like icmp.dll sync, which
possibly introduces memory corruption, and which is still not fixed
in Wine).
* Keep a log of what has been synced, what has not, keep a note of
all problems.
If that proves to work good, this team may be officially announced as
"wine syncing team".
There are already at least two successfully working teams this way:
Bugzilla maintaining (with Amine being the maintainer, and my point
of contact when I want to complain or ask about something), and
Testing team (with Olaf being often my point of contact, and
organizing and doing all the hard work of regress testing, testing
apps, drivers, real hardware testing and getting results submitted).
Also, I think those two teams cooperate the best.
I wish we could expand this idea to the Wine syncing team, and get it
to work that smoothly too, and that cooperative too.
With the best regards,
Aleksey Bragin.
30 Mar
30 Mar
11:08 a.m.
Hi,
I like the idea Aleksey proposed and I'd also like to continue my directx
syncing efforts (wined3d, d3dx, dinput, dsound etc.), so
once the wine sync team is established just sign me in and let me know who's
the boss.
Regards,
Kamil
----- Original Message -----
From: "Aleksey Bragin" <aleksey(a)reactos.org>
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Sent: Monday, March 30, 2009 12:18 PM
Subject: [ros-dev] Wine syncing process
Hello,
I'd like to improve the existing situation we have with Wine syncing.
Right now, we have a group of people, occasionally doing Wine syncs,
and that group of people included me some time ago too. However, date
was never really specified, and syncing happens "when someone wants
to sync", "before releasing", or when something is fixed in Wine and
we import that code.
How it should happen (in my opinion). All non-forked DLLs, tools and
programs must be synced after each Wine minor release. This is going
to be manual process, so we need a person to organize this process,
and a few people who could participate in doing actual work (syncers).
What this "team" leader / responsible person should do:
* Share the work (modules) between syncers.
* Leave hard-to-sync modules to experienced developers and himself.
* Ensure all syncers are instructed to do basic testing (running our
"golden" list of apps - FireFox, AbiWord, mIRC, and testing ole32/
rpcrt4/widl with a real app which uses OLE mechanism) before
committing the work.
* Be aware about syncing dependencies (e.g. when syncing widl, it
makes sense to sync rpcrt4 simulteneously)
* Be aware about problematic syncs (like icmp.dll sync, which
possibly introduces memory corruption, and which is still not fixed
in Wine).
* Keep a log of what has been synced, what has not, keep a note of
all problems.
If that proves to work good, this team may be officially announced as
"wine syncing team".
There are already at least two successfully working teams this way:
Bugzilla maintaining (with Amine being the maintainer, and my point
of contact when I want to complain or ask about something), and
Testing team (with Olaf being often my point of contact, and
organizing and doing all the hard work of regress testing, testing
apps, drivers, real hardware testing and getting results submitted).
Also, I think those two teams cooperate the best.
I wish we could expand this idea to the Wine syncing team, and get it
to work that smoothly too, and that cooperative too.
With the best regards,
Aleksey Bragin.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
1:04 p.m.
Agreed.
I might sync wininet.dll as long as I have time.
And well, I guess people don't need to do that testing with our golden app
list for standalone stuff like WordPad or Winhlp32, which has no effects on
other software.
I believe that's obvious, but it should be said once ;-)
Best regards,
Colin
-----Original Message-----
From: ros-dev-bounces(a)reactos.org
[mailto:ros-dev-bounces@reactos.org] On Behalf Of Aleksey Bragin
Sent: Monday, March 30, 2009 12:18 PM
To: ReactOS Development List
Subject: [ros-dev] Wine syncing process
Hello,
I'd like to improve the existing situation we have with Wine syncing.
Right now, we have a group of people, occasionally doing Wine syncs,
and that group of people included me some time ago too.
However, date
was never really specified, and syncing happens "when someone wants
to sync", "before releasing", or when something is fixed in Wine and
we import that code.
How it should happen (in my opinion). All non-forked DLLs, tools and
programs must be synced after each Wine minor release. This is going
to be manual process, so we need a person to organize this process,
and a few people who could participate in doing actual work (syncers).
What this "team" leader / responsible person should do:
* Share the work (modules) between syncers.
* Leave hard-to-sync modules to experienced developers and himself.
* Ensure all syncers are instructed to do basic testing (running our
"golden" list of apps - FireFox, AbiWord, mIRC, and testing ole32/
rpcrt4/widl with a real app which uses OLE mechanism) before
committing the work.
* Be aware about syncing dependencies (e.g. when syncing widl, it
makes sense to sync rpcrt4 simulteneously)
* Be aware about problematic syncs (like icmp.dll sync, which
possibly introduces memory corruption, and which is still not fixed
in Wine).
* Keep a log of what has been synced, what has not, keep a note of
all problems.
If that proves to work good, this team may be officially
announced as
"wine syncing team".
There are already at least two successfully working teams this way:
Bugzilla maintaining (with Amine being the maintainer, and my point
of contact when I want to complain or ask about something), and
Testing team (with Olaf being often my point of contact, and
organizing and doing all the hard work of regress testing, testing
apps, drivers, real hardware testing and getting results submitted).
Also, I think those two teams cooperate the best.
I wish we could expand this idea to the Wine syncing team,
and get it
to work that smoothly too, and that cooperative too.
With the best regards,
Aleksey Bragin.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
3:29 p.m.
Yes indeed, relevant components should be tested with relevant apps
using them - e.g. ole32/rpc/widl is best tested with Office 2003
installer or WordViewer, for example.
Now we need someone to volunteer as a responsible person, who could
organize this, and keep a list of who is doing what, who has time,
what was synced, where are problems, etc.
On Mar 30, 2009, at 5:04 PM, Colin Finck wrote:
Agreed.
I might sync wininet.dll as long as I have time.
And well, I guess people don't need to do that testing with our
golden app
list for standalone stuff like WordPad or Winhlp32, which has no
effects on
other software.
I believe that's obvious, but it should be said once ;-)
Best regards,
Colin
-----Original Message-----
From: ros-dev-bounces(a)reactos.org
[mailto:ros-dev-bounces@reactos.org] On Behalf Of Aleksey Bragin
Sent: Monday, March 30, 2009 12:18 PM
To: ReactOS Development List
Subject: [ros-dev] Wine syncing process
Hello,
I'd like to improve the existing situation we have with Wine syncing.
Right now, we have a group of people, occasionally doing Wine syncs,
and that group of people included me some time ago too.
However, date
was never really specified, and syncing happens "when someone wants
to sync", "before releasing", or when something is fixed in Wine and
we import that code.
How it should happen (in my opinion). All non-forked DLLs, tools and
programs must be synced after each Wine minor release. This is going
to be manual process, so we need a person to organize this process,
and a few people who could participate in doing actual work
(syncers).
What this "team" leader / responsible person should do:
* Share the work (modules) between syncers.
* Leave hard-to-sync modules to experienced developers and himself.
* Ensure all syncers are instructed to do basic testing (running our
"golden" list of apps - FireFox, AbiWord, mIRC, and testing ole32/
rpcrt4/widl with a real app which uses OLE mechanism) before
committing the work.
* Be aware about syncing dependencies (e.g. when syncing widl, it
makes sense to sync rpcrt4 simulteneously)
* Be aware about problematic syncs (like icmp.dll sync, which
possibly introduces memory corruption, and which is still not fixed
in Wine).
* Keep a log of what has been synced, what has not, keep a note of
all problems.
If that proves to work good, this team may be officially
announced as
"wine syncing team".
There are already at least two successfully working teams this way:
Bugzilla maintaining (with Amine being the maintainer, and my point
of contact when I want to complain or ask about something), and
Testing team (with Olaf being often my point of contact, and
organizing and doing all the hard work of regress testing, testing
apps, drivers, real hardware testing and getting results submitted).
Also, I think those two teams cooperate the best.
I wish we could expand this idea to the Wine syncing team,
and get it
to work that smoothly too, and that cooperative too.
With the best regards,
Aleksey Bragin.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev 
6:36 p.m.
mIRC can't be considered a "golden app" again until the input textbox
is fixed.
On Mar 30, 2009, at 6:18 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
Hello,
I'd like to improve the existing situation we have with Wine syncing.
Right now, we have a group of people, occasionally doing Wine syncs,
and that group of people included me some time ago too. However, date
was never really specified, and syncing happens "when someone wants
to sync", "before releasing", or when something is fixed in Wine and
we import that code.
How it should happen (in my opinion). All non-forked DLLs, tools and
programs must be synced after each Wine minor release. This is going
to be manual process, so we need a person to organize this process,
and a few people who could participate in doing actual work (syncers).
What this "team" leader / responsible person should do:
* Share the work (modules) between syncers.
* Leave hard-to-sync modules to experienced developers and himself.
* Ensure all syncers are instructed to do basic testing (running our
"golden" list of apps - FireFox, AbiWord, mIRC, and testing ole32/
rpcrt4/widl with a real app which uses OLE mechanism) before
committing the work.
* Be aware about syncing dependencies (e.g. when syncing widl, it
makes sense to sync rpcrt4 simulteneously)
* Be aware about problematic syncs (like icmp.dll sync, which
possibly introduces memory corruption, and which is still not fixed
in Wine).
* Keep a log of what has been synced, what has not, keep a note of
all problems.
If that proves to work good, this team may be officially announced as
"wine syncing team".
There are already at least two successfully working teams this way:
Bugzilla maintaining (with Amine being the maintainer, and my point
of contact when I want to complain or ask about something), and
Testing team (with Olaf being often my point of contact, and
organizing and doing all the hard work of regress testing, testing
apps, drivers, real hardware testing and getting results submitted).
Also, I think those two teams cooperate the best.
I wish we could expand this idea to the Wine syncing team, and get it
to work that smoothly too, and that cooperative too.
With the best regards,
Aleksey Bragin.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
31 Mar
31 Mar
1:46 p.m.
Temporary regression is not a reason to drop an app we used to
support for years.
On Mar 30, 2009, at 10:36 PM, Cameron Gutman wrote:
mIRC can't be considered a "golden app"
again until the input textbox
is fixed.
On Mar 30, 2009, at 6:18 AM, Aleksey Bragin <aleksey(a)reactos.org>
wrote:
> Hello,
> I'd like to improve the existing situation we have with Wine syncing.
>
> Right now, we have a group of people, occasionally doing Wine syncs,
> and that group of people included me some time ago too. However, date
> was never really specified, and syncing happens "when someone wants
> to sync", "before releasing", or when something is fixed in Wine and
> we import that code.
>
> How it should happen (in my opinion). All non-forked DLLs, tools and
> programs must be synced after each Wine minor release. This is going
> to be manual process, so we need a person to organize this process,
> and a few people who could participate in doing actual work
> (syncers).
>
> What this "team" leader / responsible person should do:
> * Share the work (modules) between syncers.
> * Leave hard-to-sync modules to experienced developers and himself.
> * Ensure all syncers are instructed to do basic testing (running our
> "golden" list of apps - FireFox, AbiWord, mIRC, and testing ole32/
> rpcrt4/widl with a real app which uses OLE mechanism) before
> committing the work.
> * Be aware about syncing dependencies (e.g. when syncing widl, it
> makes sense to sync rpcrt4 simulteneously)
> * Be aware about problematic syncs (like icmp.dll sync, which
> possibly introduces memory corruption, and which is still not fixed
> in Wine).
> * Keep a log of what has been synced, what has not, keep a note of
> all problems.
>
> If that proves to work good, this team may be officially announced as
> "wine syncing team".
>
> There are already at least two successfully working teams this way:
> Bugzilla maintaining (with Amine being the maintainer, and my point
> of contact when I want to complain or ask about something), and
> Testing team (with Olaf being often my point of contact, and
> organizing and doing all the hard work of regress testing, testing
> apps, drivers, real hardware testing and getting results submitted).
> Also, I think those two teams cooperate the best.
>
> I wish we could expand this idea to the Wine syncing team, and get it
> to work that smoothly too, and that cooperative too.
>
>
> With the best regards,
> Aleksey Bragin.
2:07 p.m.
It's a reason to fix it.
On 31-Mar-09, at 9:46 AM, Aleksey Bragin wrote:
Temporary regression is not a reason to drop an app we
used to
support for years.
On Mar 30, 2009, at 10:36 PM, Cameron Gutman wrote:
Best regards,
Alex Ionescu
mIRC can't be considered a "golden
app" again until the input textbox
is fixed.
On Mar 30, 2009, at 6:18 AM, Aleksey Bragin <aleksey(a)reactos.org>
wrote:
> Hello,
> I'd like to improve the existing situation we have with Wine
> syncing.
>
> Right now, we have a group of people, occasionally doing Wine syncs,
> and that group of people included me some time ago too. However,
> date
> was never really specified, and syncing happens "when someone wants
> to sync", "before releasing", or when something is fixed in Wine and
> we import that code.
>
> How it should happen (in my opinion). All non-forked DLLs, tools and
> programs must be synced after each Wine minor release. This is going
> to be manual process, so we need a person to organize this process,
> and a few people who could participate in doing actual work
> (syncers).
>
> What this "team" leader / responsible person should do:
> * Share the work (modules) between syncers.
> * Leave hard-to-sync modules to experienced developers and himself.
> * Ensure all syncers are instructed to do basic testing (running our
> "golden" list of apps - FireFox, AbiWord, mIRC, and testing ole32/
> rpcrt4/widl with a real app which uses OLE mechanism) before
> committing the work.
> * Be aware about syncing dependencies (e.g. when syncing widl, it
> makes sense to sync rpcrt4 simulteneously)
> * Be aware about problematic syncs (like icmp.dll sync, which
> possibly introduces memory corruption, and which is still not fixed
> in Wine).
> * Keep a log of what has been synced, what has not, keep a note of
> all problems.
>
> If that proves to work good, this team may be officially announced
> as
> "wine syncing team".
>
> There are already at least two successfully working teams this way:
> Bugzilla maintaining (with Amine being the maintainer, and my point
> of contact when I want to complain or ask about something), and
> Testing team (with Olaf being often my point of contact, and
> organizing and doing all the hard work of regress testing, testing
> apps, drivers, real hardware testing and getting results submitted).
> Also, I think those two teams cooperate the best.
>
> I wish we could expand this idea to the Wine syncing team, and get
> it
> to work that smoothly too, and that cooperative too.
>
>
> With the best regards,
> Aleksey Bragin.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
5659
days inactive
5660
days old
6 comments
5 participants
participants (5)
-
Aleksey Bragin -
Alex Ionescu -
Cameron Gutman -
Colin Finck -
Kamil Hornícek