flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: Reason for the release process
Date Tue, 26 Aug 2014 23:04:51 GMT
Hi,

> I'm not sure extra process invites community building.

It already has, we've had people report issues during the RC process.

>> - PMC endorsement
> What are the benefits of that.  Are you claiming more people will use it
> if endorsed?

I would say more people would use an official voted on release than a nightly build yes.

>> - Legal angle covered (IP issues etc)
> No more dangerous than any other nightly build.

Expect that it is live on our web site for all users to see, not something available to only
people who know where to get nightly builds.

> Seemed like more folks waited until announced instead of helping with the RC.

There was involvement in the RC by committers and non committers during the RC process, not
sure why you are ignoring that.

> I'd rather submit a few patches to the examples than test the RC.
> Seems like that's the pattern we see from other folks too.

I see you've not submitted a patch to TourDeFlex yet. Testing RCs is useful and find issues,
there have been many time if we had just shipped it without an RC process there are issues
that would of not been discovered and would of been harder to fix once released. That doesn't
mean we find everything.

> Can we not blog that some new example was added to the TDF on the site?

No, you can't announce / promote nightly build/snapshots [1]. 
" Do not include any links on the project website that might encourage non-developers to download
and use nightly builds, snapshots, release candidates, or any other similar package."

So That would mean we would need to remove all links from navigation in the web site? I would
even argue that "use" in this content meant put up content to view on our web site.

White you're at that link  you might also note:
"Releases are, by definition, anything that is published beyond the group that owns it. In
our case, that means any publication outside the group of people on the product dev list."
"Each PMC must obey the ASF requirements on approving any release."
"Proper release management is a key aspect of Apache software development."

This really seams quite clear cut to me.

> IMO, having a bug up there for 3 days is a worse quality perception than
> fixing in minutes.

I'm not seeing those bugs being fixed in minutes. Are you putting your hand up for that role?

>> - Less reason for community to be involved (no RCs to test or vote on)
> Most folks I know want to write code instead of run manual tests.

Not everyone has the skills or motivation to fix issues in the SDK (or testing the SDK eg
mustella is part of that). Let's try and widen our talent pool a little and get a few more
people involved and use to the Apache way of doing things.

>> - No need for a release manager or in fact any further releases
> True, that's another time saving we could spend elsewhere.

Really? In that case why don't we just move the project to github, that way we can get rid
of all this unnecessary Apache process. :-)  Alex as you know this process is here for a very
good reasons and as a PMC member and the PMC chair you should be promoting it's use, not trying
to find ways to avoid using it.

> We'll see what others think.  I'd rather just save the time.  I don't get
> why we need to have 3 people look at simple changes before they go on the site.

We're talking about code changes here, yes the application is simple, but that doesn't mean
that it's exempt from the release process and there are very good reason to use that process.

Thanks,
Justin

1. http://www.apache.org/dev/release.html
Mime
View raw message