2012/5/30 Torsten Giebl
Hallo !
Everbody, who is an expert in this or that field, please raise
your hand if you would be interested in becoming an official patch
reviewer ?
With the exception of a few really great contributors, these people
don’t exist.
Maintaining SDL requires you to become the domain expert. I can’t
count the
number of times I’ve googled a specific issue we’ve had and the only
results
were to SDL source code. 
Searching Patch Reviewers for an inofficial fork of SDL 2.0 on github ?
Maybe people patch it to death, maybe it will be good and the official SDL
2.0
can benefit from it, i do not know. It is also possible to give all people
write access
on github and let them self decide.
I understand the need to speed things up a bit, I’ve been frustrated more
than once by having patches left in the tracker for ages without attention
(I’ve done the patch for #1308 and it’s there gathering dust after endless
iterations and plenty of hours put into it), or posing questions without
feedback, but I’d rather give Sam and Ryan some space and let them do
things at their own speed, rather than forking SDL on a separate
repository, even as under an experimental or unofficial banner, because I
think that will drive the community down a slippery slope, which ends in a
real fork with the associated scattering of the already slim human
resources.
My two cents, I think whatever we work out, we should do it under the
official repositories (an experimental repo under hg.libsdl.org?, an
experimental/development branch in the official SDL repo?)–
Gabriel.
I agree with the slippery slope, but Ryan and Sam have both made it clear
that with their current life situations, it’s not possible for them to put
in the appropriate amount of time and effort to keep things going which is
the whole point of this thread.
I have a fairly flexible job (I work at home as a private software
consultant for a particular company), and I’m willing to put in some time,
but I also have some limitations that I’m fairly recently married (last
August). Sam, Ryan, maybe if you gents have some free time I can skype
with you (or whatever) and we’ll see if I have enough time to do whatever
it is that you need a community person to do to get some of these patches
reviewed. Sadly, I don’t have an iOS device, so I don’t think I can
reasonably do any particularly authoritative patches in there, but I
suppose I could find an emulator of some sorts.
-AlexOn Wed, May 30, 2012 at 8:24 AM, Gabriel Jacobo wrote:
I understand the need to speed things up a bit, I’ve been frustrated more
than once by having patches left in the tracker for ages without attention
(I’ve done the patch for #1308 and it’s there gathering dust after endless
iterations and plenty of hours put into it), or posing questions without
feedback, but I’d rather give Sam and Ryan some space and let them do
things at their own speed, rather than forking SDL on a separate
repository, even as under an experimental or unofficial banner, because I
think that will drive the community down a slippery slope, which ends in a
real fork with the associated scattering of the already slim human
resources.
My two cents, I think whatever we work out, we should do it under the
official repositories (an experimental repo under hg.libsdl.org?, an
experimental/development branch in the official SDL repo?)
–
Gabriel.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Recently i made a patch to add support for XInput2 extension
implementing relative mouse motion when using X11 video.Even though i
would love to have the patch added to the main branch i cannot poke
Sam or Ryan every day in order to review my patch.If we had someone
though who could approve,review patches and had more time then things
will most probably go faster.On Wed, May 30, 2012 at 4:58 PM, Alex Barry <alex.barry at gmail.com> wrote:
I agree with the slippery slope, but Ryan and Sam have both made it clear
that with their current life situations, it’s not possible for them to put
in the appropriate amount of time and effort to keep things going which is
the whole point of this thread.
I have a fairly flexible job (I work at home as a private software
consultant for a particular company), and I’m willing to put in some time,
but I also have some limitations that I’m fairly recently married (last
August). ?Sam, Ryan, maybe if you gents have some free time I can skype with
you (or whatever) and we’ll see if I have enough time to do whatever it is
that you need a community person to do to get some of these patches
reviewed. ?Sadly, I don’t have an iOS device, so I don’t think I can
reasonably do any particularly authoritative patches in there, but I suppose
I could find an emulator of some sorts.
-Alex
On Wed, May 30, 2012 at 8:24 AM, Gabriel Jacobo wrote:
I understand the need to speed things up a bit, I’ve been frustrated more
than once by having patches left in the tracker for ages without attention
(I’ve done the patch for #1308 and it’s there?gathering dust?after endless
iterations and plenty of hours put into it), or posing questions without
feedback, but I’d rather give Sam and Ryan some space and let them do things
at their own speed, rather than forking SDL on a separate repository, even
as under an experimental or unofficial banner, because I think that will
drive the community down a slippery slope, which ends in a real fork with
the associated scattering of the already slim human resources.
My two cents, I think whatever we work out, we should do it under the
official repositories (an experimental repo under hg.libsdl.org?, an
experimental/development branch in the official SDL repo?)
–
Gabriel.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I think there is no harm to fork SDL into github.
If hg-git (http://hg-git.github.com) is used, each “version” can benefit
from checkins to either repo relatively easily.
For example, I had created a SDL1.3 fork for the CoApp work last year
(https://github.com/ferzkopp/SDL) and ported some of the VisualStudio
related updates back into SDL “main” later.
–AndreasOn 5/30/2012 7:26 AM, Dimitris Zenios wrote:
Recently i made a patch to add support for XInput2 extension
implementing relative mouse motion when using X11 video.Even though i
would love to have the patch added to the main branch i cannot poke
Sam or Ryan every day in order to review my patch.If we had someone
though who could approve,review patches and had more time then things
will most probably go faster.
On Wed, May 30, 2012 at 4:58 PM, Alex Barry<alex.barry at gmail.com> wrote:
I agree with the slippery slope, but Ryan and Sam have both made it clear
that with their current life situations, it’s not possible for them to put
in the appropriate amount of time and effort to keep things going which is
the whole point of this thread.
I have a fairly flexible job (I work at home as a private software
consultant for a particular company), and I’m willing to put in some time,
but I also have some limitations that I’m fairly recently married (last
August). Sam, Ryan, maybe if you gents have some free time I can skype with
you (or whatever) and we’ll see if I have enough time to do whatever it is
that you need a community person to do to get some of these patches
reviewed. Sadly, I don’t have an iOS device, so I don’t think I can
reasonably do any particularly authoritative patches in there, but I suppose
I could find an emulator of some sorts.
-Alex
On Wed, May 30, 2012 at 8:24 AM, Gabriel Jacobo wrote:
I understand the need to speed things up a bit, I’ve been frustrated more
than once by having patches left in the tracker for ages without attention
(I’ve done the patch for #1308 and it’s there gathering dust after endless
iterations and plenty of hours put into it), or posing questions without
feedback, but I’d rather give Sam and Ryan some space and let them do things
at their own speed, rather than forking SDL on a separate repository, even
as under an experimental or unofficial banner, because I think that will
drive the community down a slippery slope, which ends in a real fork with
the associated scattering of the already slim human resources.
My two cents, I think whatever we work out, we should do it under the
official repositories (an experimental repo under hg.libsdl.org?, an
experimental/development branch in the official SDL repo?)
–
Gabriel.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
If we want SDL to be more community driven, I suggest we start with alternating
periods of feature freezes and bug smashing. That way we can establish a
quasi-roadmap of new features and a release timeline that will help contributors
with following a clear goal.
At this point I would start the feature-freeze period and only allow patches that:
a) fix bugs
b) add test cases
c) fix test cases
Best regards,
ChrisOn 12-05-25 02:04 AM, Jared Maddox wrote:
What about a mob branch: does Mercurial support them (Google didn’t
provide a quick answer), would one be useful for speeding up
development? I’m certain that your outline would work with a core team
(which could probably be rounded up from the list), but I’m not
convinced it would work with a more vaguely defined community (too
concretely organized).
On, Sun May 27, 2012, Sam Lantinga wrote:
I’ve tried to do something like this before but nobody stepped up to help
out. Maybe there’s interest now? I don’t know that a pure voting system
would be sufficient, but it would be great if there were people invested in
the various platforms collecting and testing and submitting improvements
and fixes.
Everybody feel free to push any FreeBSD related issues to me, since I am
maintining the whole SDL bunch on that platform anyways.
Cheers
Marcus
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120608/31cdf8d2/attachment.pgp