On 2005-07-23 20:32:54 +0100 Lars Sonchocky-Helldorf
<[EMAIL PROTECTED]> wrote:
Branching is good in the way that we can point users of GNUstep to a bugfix
release if they happen to encounter a bug in a GNUstep release instead of
saying: "use the CVS version" which turned into some sort of standard reply
in the case of a bug. That would give us greater freedom on changing things
in the CVS while still having something useable for the users. This would
also result in applications developed against a certain release instead of
have an application requiring the CVS because a necessary bugfix is in
there.
Well, creating the branch is trivial ... but I wonder how many bugfixes
would get into it ... having to fix both the head and the latest branch
(possibly with different fixes) could chew up quite a bit of time. Mostly,
when I have reservations about funadmentally good ideas, it's because I
know I don't even have the time to do things I want to do and suspect that's
true of everyone else too. That being said ... if we created a branch from
each release, perhaps there is someone out there who would like to maintain
the latest branch by copying back any fixes made to head?
Think about your use-pattern of GCC: do you use the CVS or weekly snapshot
version of GCC or do you use GCC 3.3.6 or GCC 3.4.4 because the later are a
lot more mature than the first two? People don't want always live on the
bleeding edge.
My pattern is erratic ... sometimes cvs for a few weeks, more often
whatever's in debian/unstable, depending on whether activity in ObjC support
in the compiler has turned interesting.
I think in general though, I just use what works ... and if it doesn't work,
I generally update to latest release or cvs version I can find.
And in turn this could improve the perception of GNUstep. I spoke to
several
Cocoa-developers who tried to use GNUstep (after I am told them to do so).
The common response was that every time something else is broken, including
things which already were working, which annoyed them a lot and was leading
to the conclusion: "GNUstep is just a hobbyists project"
I think the only thing which would help with that at all is a *lot* more
manpower. I don't think things *often* get broken in obvious ways ... but
in the gui/backend in particular there is a lot of stuff where interactions
with external systems, timing of events etc can mean that small changes
produce problems that don't show up under testing by the developer because
the app(s) they are using for testing or the environment (window manager,
speed of processor etc) doesn't trigger them. These sort of issues appear
in the cvs code and get into the next release, only being detected *after*
release ... because we don't have neough people using the cvs code. So to
that extent, I think we must try to *encourage* people to use cvs frequently
somehow (though with a clear understanding of the downsides of doing so).
Hmm ... but how can we encourage lots of people to use/test CVS or prerelese
snapshots?
How about using the donation money GNUstep got for buying some testing
machines which would go into the same place as the GNUstep web servers are
and could then be used for testing/developing GNUstep onto some more
"exotic"
platforms: Some *BSD, some Solaris boxen (be it x86 or SPARC), a Mac (Mac
mini should be enough), maybe some HPUX box should be enough for the start.
Those machines don't necessarily need to be new hardware, I guess we could
get them used somewhere for cheap. Then put them online with special ssh
accounts (maybe some VNC too) for the core devs and there you go:
compilation
and testing is possible remotely for those who need it.
That sounds good ... but I don't know if we have anything like enough money.
There is the cost of the machines ... but there is also the issue of running
them ... where would we put them so that they can be kept running
continuously with a good network link ... what would the running costs be?
Adam might know if this is practical... but it does seem a good use for any
money we get.
Even better than donating a machine to developer X because this way all can
participate and share.
2. keep asking people to contribute regression testcases if/when they have
the time. The fact that people had to install guile to run the old
regression tests was an excuse for them not to help ... with the new
testsuite that excuse no longer exists.
maybe we should ask for testcases/bug isolations on the bug reporting page?
I don't know if/how the savannah bug reporting page can be modified, but we
did (do?) have that sort of request on the website.
Actually, I'm more concerned with getting bug reports at all ... I
occasionally hear tales of MacOS-X users having tried GNUstep and given up
because it's buggy ... but I don't see corresponding bug reports on savannah
(few appear to come from MacOS-X users), so I suspect that most people can't
be bothered to file a bug report, let alone provide a testcase.
I worry that being too agressive about requesting testcases might put off
the bug reporters we do get ... but perhaps anyone willing to file a bug
report is not going to be put off by that.
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep