On 22/06/2007, at 12:32 PM, Jason van Zyl wrote:
1) check taxonomy stuff is finished, kick it around so everyone is
happy with it and understands how it should be used.
I will coalesce these three pages to mesh:
http://docs.codehaus.org/display/MAVEN/Taxonomy
http://docs.codehaus.org/display/MAVEN/Maven+Taxonomy
http://docs.codehaus.org/display/MAVEN/Architectural+Goals+for+Maven
+2.1
Where the first one is the simplest and closest. In one place I've
taken a taxonomy entry "POM" and create "POM :: Encoding" and put
that as a component in JIRA. So given the lack of hierarchies with
components in JIRA that's how I decided to represent the hierarchy.
I'm sure after a little burst it won't change a whole lot and will
be altered when additions are made and new categories made when new
features require it. Basically it will be adding the component to
JIRA and linking in the doco related to the taxonomy entry.
sounds good
2) gather up all the proposals people have going around and get
them into the wiki
If people now want to start jamming stuff in then hook them off here:
http://docs.codehaus.org/display/MAVEN/Architectural+Goals+for+Maven
+2.1
Even if a bit of a mess now and I'll reintegrate into the taxonomy.
Then at least folks interested in changes know where they are.
Yeah, it's size scared me off to date :) It'll be easier to grok once
it's broken down.
Sounds good to go ahead and start adding things, though. We should
probably set a deadline for proposals so we can move on to planning?
3) finish sorting out jira issues (by this point, we should have a
list of all the things going into 2.1 and 2.1.x)
It could still use a serious scrub but it's relatively ok now.
4) plan the 2.1 releases from a new feature perspective -
collectively pick what we can get done from the wiki. Get them
into JIRA too. The other proposals are still active, and will be
reconsidered for future releases.
As were working on things I think as many alphas can go out as we
can possibly squeeze out even if it was one a week. I think we
start scrutinizing the releases once the first beta is close.
I was thinking that we got this out of the way before we started
coding any more of them, simply because the 2.1 list is way too long
right now and we need to get a better understanding of what the
release should be about.
5) map out the incremental releases (around 4 weeks apart for 2.1-
alpha-1, alpha-2, etc), and which jiras are incorporated
I think until the first beta arrives bash them out as fast as
possible. We can start his anytime provide people are aware that
it's alpha and though pretty stable they use it at their own risk
and if you use it for production builds you will have an exciting
time.
Yeah, I'm happy with that, probably just a matter of terminology,
though - great to have regular stable builds, but if you look at what
IDEA do they have both really regular builds, then milestones where
the less brave can still try it out, then betas, then final, which is
a good model.
6) get the IT stuff and development expectations sorted out
I think this needs to be moved further up and made a priority and
can be done far before any planning of formal beta releases. They
are quite a clusterfuck with all the coupling to production plugins
and requiring a network connection. Making these shine will be the
key being able to move quickly on new development.
It's not really a low priority, since there's no coding in there yet
- I probably just overstated 5 and made it look like we were pulling
releases. So maybe swap 5 and 6 in the sequence of things.
We also need to plan:
- the separation of the sites, not sure if this has been sorted or not
I think we generally had a common understanding of how this would be
done but it hasn't been written down or acted on
- reporting using swizzle which will help us immensely in making
decisions about what to focus on, the voting in JIRA is too crude
Yep. Voting is useful, the reporting on it is not.
- release process
- new features/refactorings be done on branches so that trunk as
much as possible does not destabilize and people can collaborate
while sweeping changes are made
- the completion of work John T started to make generating the
information to vote on would make releasing quickly and accurately
a possibility
- the release plugin or something else needs to be made to take
care of secondary deployments, site deploy (this can't be done as
part of the release because a screw up site deployment should not
affect a binary release), announcements, and whatever else
this is all stuff I lump in 'development process' under my head, so
it's good to break it down. All sounds good (just a little unsure on
the branching thing, but we can figure that out later).
We can stick those in JIRA and link it from here:
http://docs.codehaus.org/display/MAVEN/Home
Sure, you want me to do that?
There is no way to sequence this stuff in JIRA is there?
Only by versioning/priority...
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
