On 26 Mar 2018, at 6:13 PM, Jim Jagielski wrote:
> Is it really all that bothersome and problematic that we need to change
> things so much? What this does is add complexity and process
> to the addition of CHANGES where, IMO, it doesn't belong. I
> can't see adding all this
Is it really all that bothersome and problematic that we need to change
things so much? What this does is add complexity and process
to the addition of CHANGES where, IMO, it doesn't belong. I
can't see adding all this overhead simply to fix cases where someone
needs to handle a merge for a back
On Mon, Mar 26, 2018 at 5:23 AM, Stefan Eissing
wrote:
> tl;dr
>
> Lets track CHANGES in individual files that can be processed
> during merges without conflicts and used in compiling release
> documentation more easily.
>
>
> My case:
>
> CHANGES is very interesting
Am 24.03.2018 um 15:28 schrieb Eric Covener:
> On Sat, Mar 24, 2018 at 10:18 AM, Stefan Priebe - Profihost AG
> wrote:
>> Hello,
>>
>> is there any reason why the srever-status output isn't:
>> - available through a local unix socket - so you can grab it even all
>>
> As hackathon project it could be good to review some of those older-than-2011
> tasks and see which ones are good to keep and which ones can be closed for
> no-activity/stale/not-valid-anymore/etc..
Good idea. Deal collectively with some of those judgement-calls that stump a
solo
tl;dr
Lets track CHANGES in individual files that can be processed
during merges without conflicts and used in compiling release
documentation more easily.
My case:
CHANGES is very interesting and necessary for documenting releases. The way
we are maintaining it, can be improved.
Case 1, The
Yep - I realize that now. The release guidelines only mentioned the doap file
and, for whatever reason, I didn't think to run a recursive grep on the site
content to find other places.
The script that does the publishing and announcing has been updated as well as
the release guidelines