[wildfly-dev] WildFly Core component upgrade coordination
Brian Stansberry
brian.stansberry at redhat.com
Thu Oct 9 09:25:56 EDT 2014
On 10/9/14, 7:55 AM, Darran Lofthouse wrote:
> Could we make an agreement that all PRs submitted by say Thursday
> afternoon that are ready to be merged are merged before the tag is created.
>
Given the "ready to be merged" bit, sure, fine with me.
I'm not willing to commit to people to get things reviewed and tested on
a weekly deadline, but if things are already reviewed and tested I have
no problem promising to merge them.
I'm just one of the players here, unless I'm nominated as the person who
does the weekly release, in which case my promise matters more. But I
volunteer to do the release if Jason wants that.
> Not saying that Friday's PRs can't be merged just trying to engineers
> some predictability when they are working on issues that affect both repos.
>
> Regards,
> Darran Lofthouse.
>
>
> On 08/10/14 21:26, Stuart Douglas wrote:
>> I think the best way to deal with this is just a time boxed release, say
>> every Friday afternoon. That way there is no surprises, and if a PR is
>> not ready then it can go into next weeks release.
>>
>> I don't think automation is a good idea, there are to many things that
>> can go wrong.
>>
>> Stuart
>>
>> David M. Lloyd wrote:
>>> I'll take whatever I can get. :-)
>>>
>>> On 10/08/2014 10:00 AM, Tomaž Cerar wrote:
>>>> that still doesnt solve the problem on "when" next release is.
>>>>
>>>> as people that need to do work across both repos need to know this info.
>>>> Current state is just too unknown and annoyng if you need to do
>>>> something in core and then also in full to make it work.
>>>> not to even add to the mix that your PR *needs* to break something in
>>>> full, at least until your PR for full is also merged.
>>>>
>>>>
>>>>
>>>> On Wed, Oct 8, 2014 at 4:57 PM, David M. Lloyd<david.lloyd at redhat.com
>>>> <mailto:david.lloyd at redhat.com>> wrote:
>>>>
>>>> Just telling people "hey I'm releasing core in a day or two" is already
>>>> 10x better than the current status quo.
>>>>
>>>> On 10/08/2014 07:40 AM, Kabir Khan wrote:
>>>> > I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P
>>>> > On 8 Oct 2014, at 13:24, Tomaž Cerar<tomaz.cerar at gmail.com<mailto:tomaz.cerar at gmail.com>> wrote:
>>>> >
>>>> >> I had some discussions with Jason on how we could automate
>>>> >> time boxed releases by just having a button in CI that would perform it.
>>>> >> So we at least have a bit of human interaction.
>>>> >>
>>>> >> We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do.
>>>> >> If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc...
>>>> >>
>>>> >> --
>>>> >> tomaz
>>>> >>
>>>> >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse<darran.lofthouse at jboss.com<mailto:darran.lofthouse at jboss.com>> wrote:
>>>> >> I don't know if it needs to be a short timebox say weekly or better if
>>>> >> on-demand e.g. if an engineer is working on an issue in both core and
>>>> >> wildfly they request a core release and upgrade to continue their work.
>>>> >>
>>>> >> At the same time I think we do need the Jiras as David suggests to track
>>>> >> what we actually needs, unfortunately this does create some additional
>>>> >> maintenance as these need updating after each release.
>>>> >>
>>>> >> On 08/10/14 07:21, Heiko Braun wrote:
>>>> >>> Does it help to put Core on a time boxed schedule?
>>>> >>>
>>>> >>> On 07 Oct 2014, at 22:07, Stuart Douglas<stuart.w.douglas at gmail.com<mailto:stuart.w.douglas at gmail.com>
>>>> >>> <mailto:stuart.w.douglas at gmail.com<mailto:stuart.w.douglas at gmail.com>>> wrote:
>>>> >>>
>>>> >>>> I don't really think that we need this level of process around a Wildfly
>>>> >>>> Core release. I think that we should just be doing these releases fairly
>>>> >>>> frequently, and if some work misses the release then there is always
>>>> >>>> another release coming up in the near future.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> wildfly-dev mailing list
>>>> >>>wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>> >>>https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> >>>
>>>> >> _______________________________________________
>>>> >> wildfly-dev mailing list
>>>> >>wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> >>
>>>> >> _______________________________________________
>>>> >> wildfly-dev mailing list
>>>> >>wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > wildfly-dev mailing list
>>>> >wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>> >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> >
>>>>
>>>> --
>>>> - DML
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev
mailing list