Dave wrote:
On 10/20/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Dave wrote:
>> My opinion is that our releases are taking way too long. 3.0 has been
>> in the RC process basically for a month, and I know it's a big release
>> but that's just too long. We need to be able to cut releases and get
>> them out faster than that.
>
> There are at least two problems that hold up our releases:
>
> - Folks on the mailing list don't have time to test releases
> especially not on a monthly basis. And most folks don't want
> to +1 a release that they have not tested.
>
> - We must rely on Incubator PMC member to vote on releases
> Graduation should basically fix that problem.
I agree that both of those are problems right now. Testing is a
marginal problem in my mind. I think there is time to do testing on a
monthly basis if the code changes are small enough and there is decent
communication about what changed.
Still, testing takes time -- even if its just an install and a sanity
test. Henri, Anil and others can't always find the time to spend a
couple of hours testing a monthly release.
I think this is something worth a bit more discussion though. I fully
agree that testing takes time and we want as many people involved in
testing as possible, but what is the real amount of required testing
before we can release?
If a few people work on a batch of code and feel that it's ready for
release, then I think they should be able to do that without having to
get a +1 from every developer. That way if Anil and Henri are busy this
month and can't really contribute testing time then they aren't holding
up a release.
The other thing that seems strange is
that we need a certain # of votes instead of a certain % of votes. Why
would it be not okay if you, me, and Elias (who did pretty much all the
work for 3.1) represented most of the votes? I would expect that when
ppl don't have time to work on the project they don't participate and
the whole project can't just wait for them when that happens.
The PMC voting thing is a real drag. I don't know how to get past that.
It's time to make a push for graduation. See separate thread.
agreed.
>> I suggest that since 3.0 is not actually released yet that we probably
>> should not try and push a new 3.1 release.
>
> I'm definitely +1 on releasing 3.1 and doing an RC today. We're at a
> good breaking point, we're ready for testing and Elias wants to get
> tagging into a release now.
Sorry, but did you read my other email where I listed 2 fairly
significant blocks to releasing an RC today? ..
My fault. I didn't realize those would not be resolved today.
I plan to commit as much as I can, but I'm not sure they will be fully
ready for inclusion in an RC.
1. I still plan to commit the independent hit tracking code.
Good.
2. The UI for the upload form is not working properly because I was
under the impression that we wanted to change it's semantics a bit. I
can reverse those changes, but the reason for doing this was that if we
release now allowing full hierarchy for uploads then we can't go back.
Are we ready to expose a hierarchy to the users via the UI? Do we have
to do it now? I don't think we should do it without a proper UI and what we
have now is too limited.
Yes, we have to do it now. The Theme Encapsulation proposal that I
layed out, got approved, and committed weeks ago requires that files be
allowed to be managed in at least a single level hierarchy.
My thinking is that the main debate was over the single level hierarchy
(i.e. Elias' buckets and entries concept) or a full hierarchy. With the
current code you can only do a single level, meaning that you can create
folders at the root level, but not folders inside of folders. I did
this based on discussions that we had on the list and it seemed like it
was a safer option since the single level hierarchy could eventually be
further opened up into a full hierarchy, but if we start with a full
hierarchy it would be nearly impossible to scale it back.
Anyways, the backend for this is working now. The FileManager should be
doing all the right things to allow for a single level hierarchy.
However the upload form UI needs some tweaking to work more effectively
given the new plan and I thought that Elias' had a basic design in mind,
but maybe it's not ready yet and we should stick with the same design we
have now. It's not that much work to fix up what we have now, I am
basically just waiting a little based on what Elias' suggested he wanted
to do.
-- Allen
Ultimately I am fine with doing a 3.1 release. I prefer the monthly
release cycle and would like to see us speed up the release process so
that we can stick with it. I am -1 on an RC today because quite frankly
we aren't ready. It's not really a release candidate if you know there
are problems with it.
OK. I'll continue my doc and testing work and revisit this question
Monday.
- Dave
