[wildfly-dev] WildFly Core component upgrade coordination
Darran Lofthouse
darran.lofthouse at jboss.com
Fri Oct 10 04:29:08 EDT 2014
Timezones was the reason I suggested the day before the tagging,
everyones Thursday afternoon should have concluded before we reach the
Friday afternoon that tagging is occurring in. Apart from a bit of
overlap from the US to Australia even the Friday mornings have minimal
overlap regardless of which timezone tagging will occur in.
But really it should translate to the engineer that knows they are
tagging during their afternoon should ensure the PR queue is cleared of
all acceptable PRs in the queue that were ready to be merged when they
start their day before they tag.
Having said all of that in general engineers should be trying to avoid
expecting a last minute PR in, clean test runs need to have happened and
a review should have already happened - if a review has not already
happened it is probably unfair to expect that of the tagger unless the
PR is really trivial.
Regards,
Darran Lofthouse.
On 10/10/14 01:47, James R. Perkins wrote:
> 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
>
More information about the wildfly-dev
mailing list