On 7/12/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Toni Lamar ha scritto:
> Stefano Bagnara-2 wrote:
>> Unfortunately there hasn't been consensus on branching to start a
>> release process from the trunk (in december) and the code didn't change
>> to much in the mean time, so I don't think we can expect something
>> different now.
>>
> But why a branch? Woudn't a tag be enough? I mean in the case of a Milestone
> 1.
> This would be just a little more than the nightly build, than later more one
> tag for M2, an so on.
This may be an alternative approach. However I think that branching is
better any time you want to manage a release. Btw I'm fine with tagging
and releasing an M1 from current code (we did this for 2.3.0a1, IIRC):
this approach is fine by me for a milestone
I just think that Robert should tell us the better moment wrt him IMAP
work. And maybe we could even release a 3.0M1 without IMAP enabled by
default.
the IMAP code used by default has not change. this code base has
issues with at least two modern clients but is ok (but limited) for
older ones. the experimental rewrite is not used by default.
> Stefano Bagnara-2 wrote:
>> Unfortunately, as far as I understand it currently no one of the active
>> committers is willing to prepare a release from the current code (and to
>> collect agreements for this).
>>
> But isn't the entire process automated?
> I mean it already runs nightly. It would be only required to stick a 3.0M1
> label, tag that version and publish on the main site the collected JIRA
> changes (there's a plug-in that does that automatically).
Yes, but at Apache releasing means something more than building: we have
to take care of any legal issue with code we release and we have to vote
and agree on the number and the date. I know this seems to be some easy
stuff, but in my experience it isn't.
+1
i'll see if i can find time to review the code base and improve the build
> Stefano Bagnara-2 wrote:
>> So I think that if every user using/wanting trunk code to be released
>> will put a list of new trunk features he is interested in and what
>> features he is already using (testing) succesfully from trunk this could
>> help the inactive PMC members to understand the quality and stability
>> and usability of what we have in trunk.
+1
> Sorry but shoudn't be this reversed? I.e. developers to convince users about
> the stability of their project and the importance to use it?
LOL, you are right. Unfortunately I don't have any tool to convince
others that the code in trunk was not so bad and not stable as Noel (or
anyone else) thought.
different people have different motivations
> If "inactive" members are such a bottleneck for the project(considering the
> overused veto right), why don't they simply quit? Is it so important for
> them that "membership"?
the apache governance model means that inactive members are only a
problem when a quorum is required. member who don't develop as much
code as they once did are still important for oversight.
problems arise (as at with project) when developers actively disagree
about directions. i hope that these issues will sort themselves out.
new voices and opinions help this process.
ASF meritocracy: you gain some right, you deserve them forever.
I think this is ok. It is ok that people that dedicated years to some
project will keep vote rights for the future: as I think that my
opinions/votes should be taken in considerations also after an year of
inactivity. We all collect experience on this project: every "expert"
opinion is important.
+1
<snip>
I think the only solution will come from the community: your message is
an help. Other users/developers could try helping, too.
+1
What there is in trunk is really not important compared to the
community: we need again an active/live community, then we can discuss
about trunk and how to release.
+1
if you think that there should be release and are willing to help work
towards one then it might well happen
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
