[haiku-development] Re: Voting on Alpha 1 proposals now closed
- From: "Urias McCullough" <umccullough@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 23 Sep 2008 07:58:08 -0700
2008/9/23 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> "Niels Reedijk" <niels.reedijk@xxxxxxxxx> wrote:
>> The vote on alpha1 proposals is now closed.
>>
>> It will take me some time to process the page, but in any case, the
>> results you see on the page now are the final result.
>
> Now that the voting is over, I have a hard time understanding the
> rationale behind some decisions. Could those that voted "no" please
> explain their reasons or answer the my questions on the following
> matters? Thanks!
It was not obvious during the proposal phase, and voting phase,
whether the vote was to designate those tasks as "blockers" for the
Alpha 1, or whether to include them if they were available.
Unfortunately, I didn't get a chance to voice this concern publicly
prior to the voting starting, so I voted as best I could with the
least amount of damage :)
> 3) Create a welcome package
> Do you prefer new users see a completely empty desktop on first start?
> And if so, why?
I personally didn't think it should have been a blocker for the Alpha,
if on the other hand one is completed prior to the Alpha release, then
I think it should have been included. In this scenario, I would have
voted both yes to include it, and no for it to be a blocker.
> 5) Make sure that a live Haiku install can be updated
> I think it would be pretty bad if you cannot update your Haiku
> installation anymore. But maybe I'm missing something here. Or do you
> think it won't matter, since you always can install a new version over
> the old one (by booting a new CD) without destroying the contents of
> the partition?
Sames as above - I didn't see this as a blocker. I thought this was
related to updating it live, but someone with a LiveCD or USB stick
would still be able to update it "offline" so it didn't seem critical
to me. On the other hand, if it is possible before Alpha, then I'm all
for it ;)
> 11) Recruit release manager
> Do you think we should and can just share the work, or what's your
> intention by saying no here?
This one was a little tougher - as it was mostly a developer-related
choice (I should have abstained my vote on this one) - I wasn't
entirely sure if this meant maintaining the branch after the Alpha was
released, or just leading up to it.
> 35) Include a MDR version with SSL support
> Why (on earth) would we want to release a version of MDR without SSL
> support? It's a compile time option, and it's already there and
> working.
Again, if this is available when Alpha 1 occurs, I say throw it in,
but I didn't think it was a blocker for an Alpha release.
Same for OpenSound, BTW, I didn't feel that fixing OSS so that it
could be included by default should have been a blocker for Alpha 1.
I guess this may have been a slight communication issue about the
purpose of the propositions, as some were clearly targeting blockers,
while others were simply asking for inclusion in the Alpha release (if
they're done).
- Urias
Other related posts:
