You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2014/12/01 00:47:54 UTC
Re: [DISCUSS] No RC process for releases
Hi,
> The notion that you can compare the timelines or the number of RCs of two
> different point releases of the same product
It was the same product, similar scope of changes and you get similar results if you include the 1.0 release into the mix (which had fewer RCs than I was expecting). I think the data speaks for itself.
> I don’t think you can count RC0 given that its posting was not part of the
> “no RC” process,
RCO was created after the start of the process if you check the dates.
> If it wasn’t clear when to call the vote, then that’s a topic worth
> improving on for the next release. One suggestion would be for folks to
> unofficially vote with a -1, 0, or +1 in the discuss thread so RM can know
> where they stand.
If we're going to do that we might as well call a vote, having a vote for a vote is getting a bit silly and serves little purpose. Should we then have a vote in order to have a vote on a vote? :-)
Thanks,
Justin
Re: [DISCUSS] No RC process for releases
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I have just started doing just that:
https://cwiki.apache.org/confluence/x/2oH0Ag
EdB
On Mon, Dec 1, 2014 at 9:05 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Mon, Dec 1, 2014 at 9:02 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>> ...Given it looks like both Alex and Eric has very different views of this no RC process I suggest that they
>> get it documented...
>
> Documenting your release process sounds like a fantastic idea indeed ;-)
>
> -Bertrand
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [DISCUSS] No RC process for releases
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Dec 1, 2014 at 9:02 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> ...Given it looks like both Alex and Eric has very different views of this no RC process I suggest that they
> get it documented...
Documenting your release process sounds like a fantastic idea indeed ;-)
-Bertrand
Re: [DISCUSS] No RC process for releases
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Given it looks like both Alex and Eric has very different views of this no RC process I suggest that they get it documented, that will save any future confusion and conflict around the process in the future. Is that not a reasonable suggestion?
I'm also yet to see any ideas on how to improve the process. The data clearly shows it didn't work well for TourDeFlex. People who are for using this process must have some ideas?
The RC vote/discussion in my last email is important. I hate to see a release having to be removed/withdrawn as it was unclear what people were voting on or that worse what we release can't be recreated from version control easily. While we may be able to tweak the process leading up to making a release we still have to follow Apache process make voting on and making releases.
Thanks,
Justin
Re: [DISCUSS] No RC process for releases
Posted by Harbs <ha...@gmail.com>.
+1 to end this discussion.
Harbs
Re: [DISCUSS] No RC process for releases
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Gentlemen,
You're doing it again.
EdB
On Mon, Dec 1, 2014 at 8:11 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> We did not deal with cross-domain security in the TDF 1.0 or 1.1,
>> otherwise you would have been more familiar with it in 1.2.
>
> And there was no need to do so either in 1.2, the default sandboxing method is the most secure way of loading 3rd party content. 3rd party support was discussed on the list many weeks before the release. eg early Oct [4] and Aug [5] + other conversations. You were involved in these discussions and raised no objections then.
>
>> Let me know if this link doesn’t work, but the archives [1] show that you
>> posted the VOTE thread and DISCUSS thread together which is the “old” way.
>
> Yes each vote must have a discussion thread so you don't pollute the vote thread / makes it easier to collate the votes. Why would you do that differently? It sounds like you were expecting something different. Even more reason to document this new process. You must have a RC to vote on to make a release, there's no way of getting around that Apache requirement and it's also a requirement much know exactly what went into it, so it needs to be tagged etc etc
>
> The actual email / discussion about the release was started earlier on 26th October [1] so RC0 wasn't a surprise. The only issue found during the first no RC phase was an error with a title and a few minor wording changes hence once that was fixed and no one else raised any other issue to make and vote on RC0. You can see the full thread here [2]. Note that 3rd party support is also discussed in that thread.
>
> Thanks,
> Justin
>
> 1. http://mail-archives.apache.org/mod_mbox/flex-dev/201410.mbox/%3c1318BDE8-04E9-4BCB-8F8F-ACC3081F89DB@classsoftware.com%3e
> 2. http://markmail.org/thread/5bu2t6dus4g2zzty
> 3. http://markmail.org/thread/hbl5j5w2ypes4qvh
> 4. http://markmail.org/thread/senoiggwpjnvsfpj
>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [DISCUSS] No RC process for releases
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> We did not deal with cross-domain security in the TDF 1.0 or 1.1,
> otherwise you would have been more familiar with it in 1.2.
And there was no need to do so either in 1.2, the default sandboxing method is the most secure way of loading 3rd party content. 3rd party support was discussed on the list many weeks before the release. eg early Oct [4] and Aug [5] + other conversations. You were involved in these discussions and raised no objections then.
> Let me know if this link doesn’t work, but the archives [1] show that you
> posted the VOTE thread and DISCUSS thread together which is the “old” way.
Yes each vote must have a discussion thread so you don't pollute the vote thread / makes it easier to collate the votes. Why would you do that differently? It sounds like you were expecting something different. Even more reason to document this new process. You must have a RC to vote on to make a release, there's no way of getting around that Apache requirement and it's also a requirement much know exactly what went into it, so it needs to be tagged etc etc
The actual email / discussion about the release was started earlier on 26th October [1] so RC0 wasn't a surprise. The only issue found during the first no RC phase was an error with a title and a few minor wording changes hence once that was fixed and no one else raised any other issue to make and vote on RC0. You can see the full thread here [2]. Note that 3rd party support is also discussed in that thread.
Thanks,
Justin
1. http://mail-archives.apache.org/mod_mbox/flex-dev/201410.mbox/%3c1318BDE8-04E9-4BCB-8F8F-ACC3081F89DB@classsoftware.com%3e
2. http://markmail.org/thread/5bu2t6dus4g2zzty
3. http://markmail.org/thread/hbl5j5w2ypes4qvh
4. http://markmail.org/thread/senoiggwpjnvsfpj
Re: [DISCUSS] No RC process for releases
Posted by Alex Harui <ah...@adobe.com>.
On 11/30/14, 3:47 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> The notion that you can compare the timelines or the number of RCs of
>>two
>> different point releases of the same product
>
>It was the same product, similar scope of changes and you get similar
>results if you include the 1.0 release into the mix (which had fewer RCs
>than I was expecting). I think the data speaks for itself.
We did not deal with cross-domain security in the TDF 1.0 or 1.1,
otherwise you would have been more familiar with it in 1.2.
>
>> I don’t think you can count RC0 given that its posting was not part of
>>the
>> “no RC” process,
>
>RCO was created after the start of the process if you check the dates.
Let me know if this link doesn’t work, but the archives [1] show that you
posted the VOTE thread and DISCUSS thread together which is the “old” way.
It was followed by a long thread about how several of us on the PMC were
expecting the new process. Maybe you got fooled searching your mailbox
because you mistyped the version in the subject of the discuss thread (but
got it right in the actual content).
-Alex
[1] http://s.apache.org/370