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(a)redhat.com
>> <mailto:david.lloyd@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@gmail.com<mailto:tomaz.cerar@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@jboss.com<mailto:darran.lofthouse@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@gmail.com<mailto:stuart.w.douglas@gmail.com>
>> >>>
<mailto:stuart.w.douglas@gmail.com<mailto:stuart.w.douglas@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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>> >>>https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>>
>>wildfly-dev@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>>
>>wildfly-dev@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> > _______________________________________________
>> > wildfly-dev mailing list
>> >wildfly-dev@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>> >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev