Skip to main content

Not a one-time thing

3 replies [Last post]
Joined: 2004-10-27
Points: 0

Look! New bits! has the latest snapshots of Mustang. So now there are two of these too!

We're working on the process for getting the snapshots out. What would help?

We know people want diffs from one snapshot to the next. That seems possible. We certainly have the list of bugs that were integrated into a snapshot (e.g., like

That seems useful.

What else should we be doing?

Is it okay for the snapshot to come out and then have the ancillary stuff dribble out as we get it ready? Or should we hold the bundles until we have them all polished and tied with a bow? (You can tell which way I'm leaning.)

We're working on better build instructions. What platforms do people think they'll build on? (So we don't send out instructions for Solaris-AMD64 first, just because it might be our favorite platform.)

Thanks for any suggestions you have.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-13
Points: 0

I'm doing lots of testing and bug-reporting for KDE, so if the bugs-reporting facilities improve I will probably end up with a similar problem.

The adding of new features, or the process of fixing bugs or simply reimplementing an existing API can all lead to regression bugs. Next to that new APIs could lead to 'discussion points'.

The problem I see with this is that a bug-reporter has no idea when its logical to start filing bugreports. As you know; its not usefull to get bugreports on issues you are very much aware off, but have not yet been able to implement just yet.
So I want you to think about a way to inform downloaders of work-in-progress patches. With proper communication on subject matter and/or known regressions people can comment on those changes early on, and keep bug-reports at bay while the implementation is stabilised by the developer.

Hope thats clear.

Joined: 2004-11-17
Points: 0

IMO you should put all the available resources as soon as they are tested for minimal requirements.
Although this sounds a lot like Netscape 2.0-3.0 alpha versions that were shipped with "automatic error reporting" which actually resulted in floods of repeating reports on the same errors (which didn't allow them to see rare bugs), this is not the case.
I guess the number of people downloading and actually using Mustang early releases is a few hundred (can you post this info?), and pretty much all of them do it not for fun. So, if i discover a bug, i'll report as much as possible of it. I don't need sources for doing this, nor do i need to compile my own JDK.

One other thing - you said that you are going to post a list of bugs fixed in each weekly release. I guess, though, that each release will feature new functions, classes or even packages. Having such a list will enable us to test all this stuff for you, at no charge ;)

Regards, and kudos for excellent initiative

Joined: 2004-10-27
Points: 0

In the announcements of what's in each snapshot, we'll try to separate out what are bug fixes and what are new features. Thanks for the suggestion.

Thanks also for offering to test new features.