[wildfly-dev] WildFly Core component upgrade coordination
James R. Perkins
jperkins at redhat.com
Thu Oct 9 20:47:15 EDT 2014
With the various time zones we should define "Thursday afternoon".
On 10/09/2014 05: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.
>
> 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
--
James R. Perkins
JBoss by Red Hat
More information about the wildfly-dev
mailing list