[jbosstools-dev] FreeMarker plugin deprecation

[Max Rydahl Andersen]

On 7 Mar 2018, at 11:55, Jean-Francois Maury wrote:

> The hierarchical decision is here as removal as been approved by PM

PM stated this is removal from the product, not the community upstream.

That said - Michael; please make a PR with what you think that readme 
should list
to make it clear something is in maintenance mode and if anyone want to 
fork it
can do so and we would like to help to avoid confusion - but someone 
will most likely
need to be okey to do the actual renames, ip clearance etc. That is not 
something we can
just straight up promise we will be able to do.


/max

> On Wed, Mar 7, 2018 at 5:46 PM, Mickael Istria <mistria at redhat.com> 
> wrote:
>
>> Hi,
>>
>> On Wed, Mar 7, 2018 at 5:16 PM, Max Rydahl Andersen 
>> <manderse at redhat.com>
>> wrote:
>>
>>> just want to raise that we don't need to move to apache - we can 
>>> make
>>> anyone a contributor
>>> on the jboss tools freemarker plugin that agreeds to the jboss CLA.
>>>
>> This situation is deeply confusing for JBoss Tools maintainers and
>> potential contributors and your proposal wouldn't help: we -as Red 
>> Hat
>> employees- ha've been asked to drop maintenance of 
>> jbosstools-freemarker
>> for business or strategical reasons, but we keep it under jbosstools 
>> (~=
>> Red Hat) organization. This gives the impression to contributors that 
>> we're
>> still owning and maintaining this code. If we want to open this repo 
>> to new
>> contributors, incoming contributors would expect us to review PRs, 
>> maintain
>> builds and all that stuff we're exactly supposed to not do any more 
>> while
>> we stop maintaining. Moreover, some contributors may not like 
>> contributing
>> to JBoss or Red Hat branded projects because it's not a 
>> vendor-neutral
>> ecosystem.
>> Keeping things like it isn't profitable to anyone and we generally 
>> need to
>> clarify what we mean by "not maintained" and how to properly "give 
>> up"
>> components like this. We're currently in a mid-ground that's blocking 
>> all
>> possible progress or decision.
>>
>> The big question in that case is whether we (Red Hat) is ready to 
>> make the
>> effort to "give" such almost abandoned code to Eclipse or Apache 
>> Foundation
>> (this involves effort to rebrand package and artifacts, make 
>> standalone
>> build, move code...)? That's something we need to clarify before 
>> moving any
>> further.
>> If the answer is that Red Hat isn't willing to make that migration 
>> effort
>> but wouldn't mind anyone else doing it and would approve it legally, 
>> let's
>> just write it down very clearly in the README and remove everything 
>> else
>> that's not relevant any more. And we can make a statement to Apache 
>> or
>> Eclipse that we approve someone else moving this code.
>> If the answer is that Red Hat can support with manpower migration of 
>> this
>> code to someplace else, then it needs to be made more official before
>> people can work on this instead of other stuff. But if we do that, it 
>> also
>> means we need to make clear that we're moving the code to better 
>> abandon it
>> and let other owns it immediately, as there is no more reason to 
>> maintain
>> it at Apache/Eclipse than in jbosstools-freemarker repo.
>>
>> @Max: I really believe we need a hierarchical decision here, it's not 
>> a 5
>> minutes task, and leaving it on GitHub like this can be perceived as
>> technical debt because we still get users reaching us with questions.
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
>
>
> -- 
>
> JEFF MAURY
>
> Red Hat
>
> <https://www.redhat.com/>
>
> jmaury at redhat.com
> <https://red.ht/sig>
> <https://redhat.com/summit>
> @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
> <https://www.facebook.com/redhatjobs/>   @redhatjobs
> <https://instagram.com/redhatjobs>