You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Carsten Ziegeler <cz...@apache.org> on 2020/03/01 11:11:19 UTC
[git] Separate git projects for SCR, Configadmin and http
Hi,
I would like to move the SCR implementation, Configadmin implementation
and http implementation into separate git project each (only one for all
http sub projects).
If no one objects, I'll go ahead in the next days.
Thanks
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [git] Separate git projects for SCR, Configadmin and http
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Mar 2, 2020 at 8:05 AM Carsten Ziegeler <cz...@apache.org> wrote:
>
> Thanks, finally an answer about the process - which you ignored last week :)
As you could see from my mail, I was preparing something - I just
didn't work on the weekend.
> I personally don't see why we need to move the site from svn to git as a
> pre-requisite, but if someone is doing that, great.
I grant you that, it is more something that I *think* should happen
first if we have time to work on things. If that is the only thing
missing I'm not going to insist on it.
For sure we need to update it with the current git structure and make
sure we have something for the potential new changes in place.
> Now, in general I agree, but I feel it a little bit strange that you
> allow a new git repository for atomos but want to block everyone else.
As I said, I don't want to block "everyone else". I gave the reason(s)
why I wasn't against atomos in my mail.
> I suggested the three modules, where I see active development; we have
> open issues for them, regularly get feedback etc.
We have some level of development but I don't think it is that much
right now that we absolutely have to break them out right now. I'm
fine with it in these cases (as I said in my mail as well) provided it
is not just a move.
> In how far are these different?
I don't see them completely different but as I said in my mail:
"Having two (and a read-only, almost empty) repos is one thing to
convey and work with - tens (or like some other project have, even
hundreds) is another."
> And of course, if a project gets moved it requires that the history is
> kept and tags are moved etc. but there are existing scripts out there
> which do this.
Yup, see my paragraph about that. To quote
"
> > Yes, all of theses things are solvable (and
> > solved in one way or the other by other projects) but we need them
> > solved for us and I suggest doing that first (including consensus).
"
> That said, I'm fine to wait but then I want to see that people are
> tackling the open points you mention. I'm happy to help where I can of
> course.
Well, as I said, I don't think we are too far off - let's get some
ground rules in place and then we can revisit.
regards,
Karl
> Regards
> Carsten
>
> On 02.03.2020 07:52, Karl Pauls wrote:
> > Wait, I am objecting :-).
> >
> > In the first place, while I realize there are benefits to having a git
> > project matching a subproject (and yes, I would like to move framework
> > at one point), most I can think of correspond with active development
> > or at a minimum, need work beyond just creating the repo and doing a
> > move - hence, I think we should only consider such a move if at least
> > one out of these two are likely for a given subproject (preferably,
> > both).
> >
> > That in part is why I was ok with atomos because, it clearly has some
> > active development atm and is running a lot of tests and builds in
> > actions etc (the other part is Tom really insisting). For SCR,
> > configadmin, and http I could accept the second argument (mostly
> > because they have big-ish test suites) - provided we have the
> > commitment to not only move them but really set them up so that PRs
> > get checked automatically, the readme make sense, etc. I have a harder
> > time seeing it for fileinstall and utils atm mostly because there has
> > been very little activity or we don't have that much testing or
> > documentation in place. The framework, I have quite some things queued
> > up in my sandbox for connect - so I guess some level of active
> > development applies but I would still call it a bit of a stretch atm
> > unless we'd really set-up the test suite too.
> >
> > In the second place, I strongly feel we should define a process (incl.
> > all necessary steps/actions) for module breakout and get our house in
> > order first. I don't think it is a good idea to start breaking out
> > modules without a plan. It is unclear how we would break out modules
> > (what are the steps/scripts to keep the tags, etc.) and how is that
> > explained/workable e.g., how would you find/check out all modules,
> > etc. Furthermore, we didn't yet update the website with the current
> > change to our source repo (let alone, migrate the website itself to
> > git). Starting to break out arbitrary modules is not going to make it
> > more likely to have that documented and explained in a good way.
> >
> > Having two (and a read-only, almost empty) repos is one thing to
> > convey and work with - tens (or like some other project have, even
> > hundreds) is another. Yes, all of theses things are solvable (and
> > solved in one way or the other by other projects) but we need them
> > solved for us and I suggest doing that first (including consensus).
> >
> > In other words, in general I'm against to breaking out modules until
> > the following is addressed:
> >
> > - the website is migrated from svn (and cms.apache.org) to git and
> > something that works with asf.yaml
> > - the website content is updated to reflect the current git move
> > (instructions, locations, links to svn, the works)
> > - we have an agreed upon set of steps/actions/scripts to use to break
> > out a module (incl. history, tags, website updates, etc).
> > - and a documented way of working with our repos (how to find, check
> > out together, etc).
> >
> > Furthermore, wrt. "Separate git projects for SCR, Configadmin and
> > http" until we have a proposal for the improvements we would get by
> > breaking them out and have volunteers to implement them.
> >
> > Finally, I'm against "other modules" until we determined on a
> > case-by-case vote basis that we assume a development activity uptick
> > is imminent and somebody proposes (and volunteers to implement)
> > reasonable improvements we would get by breaking them out.
> >
> > That said, I don't think any of the above is super hard to achieve -
> > hence, if you (or others) are volunteering: let's get it done. Maybe
> > start with creating JIRAs for the above and start discussions around
> > how to achieve them?
> >
> > regards,
> >
> > Karl
> >
> > On Mon, Mar 2, 2020 at 7:24 AM Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
> >>
> >> OK, I will start with these repos.
> >>
> >> I keep you posted.
> >>
> >> Regards
> >> JB
> >>
> >>> Le 1 mars 2020 à 14:26, Carsten Ziegeler <cz...@apache.org> a écrit :
> >>>
> >>> I think moving to a separate git makes sense for active (in some sense) projects. So, yes, I guess it makes sense for the three you mentioned, too.
> >>>
> >>> +1
> >>>
> >>> Carsten
> >>>
> >>> On 01.03.2020 12:41, Jean-Baptiste Onofre wrote:
> >>>> +1 for that.
> >>>> Do you want me to tackle other modules (I’m thinking about fileinstall, utils, framework to start with) ?
> >>>> Regards
> >>>> JB
> >>>>> Le 1 mars 2020 à 12:11, Carsten Ziegeler <cz...@apache.org> a écrit :
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I would like to move the SCR implementation, Configadmin implementation and http implementation into separate git project each (only one for all http sub projects).
> >>>>>
> >>>>> If no one objects, I'll go ahead in the next days.
> >>>>>
> >>>>> Thanks
> >>>>> Carsten
> >>>>> --
> >>>>> Carsten Ziegeler
> >>>>> Adobe Research Switzerland
> >>>>> cziegeler@apache.org
> >>>
> >>> --
> >>> --
> >>> Carsten Ziegeler
> >>> Adobe Research Switzerland
> >>> cziegeler@apache.org
> >>
> >
> >
>
> --
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
--
Karl Pauls
karlpauls@gmail.com
Re: [git] Separate git projects for SCR, Configadmin and http
Posted by Carsten Ziegeler <cz...@apache.org>.
Thanks, finally an answer about the process - which you ignored last week :)
I personally don't see why we need to move the site from svn to git as a
pre-requisite, but if someone is doing that, great.
Now, in general I agree, but I feel it a little bit strange that you
allow a new git repository for atomos but want to block everyone else. I
suggested the three modules, where I see active development; we have
open issues for them, regularly get feedback etc. In how far are these
different?
And of course, if a project gets moved it requires that the history is
kept and tags are moved etc. but there are existing scripts out there
which do this.
That said, I'm fine to wait but then I want to see that people are
tackling the open points you mention. I'm happy to help where I can of
course.
Regards
Carsten
On 02.03.2020 07:52, Karl Pauls wrote:
> Wait, I am objecting :-).
>
> In the first place, while I realize there are benefits to having a git
> project matching a subproject (and yes, I would like to move framework
> at one point), most I can think of correspond with active development
> or at a minimum, need work beyond just creating the repo and doing a
> move - hence, I think we should only consider such a move if at least
> one out of these two are likely for a given subproject (preferably,
> both).
>
> That in part is why I was ok with atomos because, it clearly has some
> active development atm and is running a lot of tests and builds in
> actions etc (the other part is Tom really insisting). For SCR,
> configadmin, and http I could accept the second argument (mostly
> because they have big-ish test suites) - provided we have the
> commitment to not only move them but really set them up so that PRs
> get checked automatically, the readme make sense, etc. I have a harder
> time seeing it for fileinstall and utils atm mostly because there has
> been very little activity or we don't have that much testing or
> documentation in place. The framework, I have quite some things queued
> up in my sandbox for connect - so I guess some level of active
> development applies but I would still call it a bit of a stretch atm
> unless we'd really set-up the test suite too.
>
> In the second place, I strongly feel we should define a process (incl.
> all necessary steps/actions) for module breakout and get our house in
> order first. I don't think it is a good idea to start breaking out
> modules without a plan. It is unclear how we would break out modules
> (what are the steps/scripts to keep the tags, etc.) and how is that
> explained/workable e.g., how would you find/check out all modules,
> etc. Furthermore, we didn't yet update the website with the current
> change to our source repo (let alone, migrate the website itself to
> git). Starting to break out arbitrary modules is not going to make it
> more likely to have that documented and explained in a good way.
>
> Having two (and a read-only, almost empty) repos is one thing to
> convey and work with - tens (or like some other project have, even
> hundreds) is another. Yes, all of theses things are solvable (and
> solved in one way or the other by other projects) but we need them
> solved for us and I suggest doing that first (including consensus).
>
> In other words, in general I'm against to breaking out modules until
> the following is addressed:
>
> - the website is migrated from svn (and cms.apache.org) to git and
> something that works with asf.yaml
> - the website content is updated to reflect the current git move
> (instructions, locations, links to svn, the works)
> - we have an agreed upon set of steps/actions/scripts to use to break
> out a module (incl. history, tags, website updates, etc).
> - and a documented way of working with our repos (how to find, check
> out together, etc).
>
> Furthermore, wrt. "Separate git projects for SCR, Configadmin and
> http" until we have a proposal for the improvements we would get by
> breaking them out and have volunteers to implement them.
>
> Finally, I'm against "other modules" until we determined on a
> case-by-case vote basis that we assume a development activity uptick
> is imminent and somebody proposes (and volunteers to implement)
> reasonable improvements we would get by breaking them out.
>
> That said, I don't think any of the above is super hard to achieve -
> hence, if you (or others) are volunteering: let's get it done. Maybe
> start with creating JIRAs for the above and start discussions around
> how to achieve them?
>
> regards,
>
> Karl
>
> On Mon, Mar 2, 2020 at 7:24 AM Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>>
>> OK, I will start with these repos.
>>
>> I keep you posted.
>>
>> Regards
>> JB
>>
>>> Le 1 mars 2020 à 14:26, Carsten Ziegeler <cz...@apache.org> a écrit :
>>>
>>> I think moving to a separate git makes sense for active (in some sense) projects. So, yes, I guess it makes sense for the three you mentioned, too.
>>>
>>> +1
>>>
>>> Carsten
>>>
>>> On 01.03.2020 12:41, Jean-Baptiste Onofre wrote:
>>>> +1 for that.
>>>> Do you want me to tackle other modules (I’m thinking about fileinstall, utils, framework to start with) ?
>>>> Regards
>>>> JB
>>>>> Le 1 mars 2020 à 12:11, Carsten Ziegeler <cz...@apache.org> a écrit :
>>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to move the SCR implementation, Configadmin implementation and http implementation into separate git project each (only one for all http sub projects).
>>>>>
>>>>> If no one objects, I'll go ahead in the next days.
>>>>>
>>>>> Thanks
>>>>> Carsten
>>>>> --
>>>>> Carsten Ziegeler
>>>>> Adobe Research Switzerland
>>>>> cziegeler@apache.org
>>>
>>> --
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
>>
>
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [git] Separate git projects for SCR, Configadmin and http
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Mar 2, 2020 at 7:55 AM Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>
> Hi Karl,
>
> Thanks for your feedback.
>
> I think what you said makes sense and we should address these points in a clear way, with a defined process.
>
> So, as I’m volunteer to help, let me come back on this thread with a process proposal, including a detailed action plan where we can agree all together.
>
> Let me prepare something ;)
Thanks, that would be great!
regards,
Karl
> Thanks again,
> Regards
> JB
>
> > Le 2 mars 2020 à 07:52, Karl Pauls <ka...@gmail.com> a écrit :
> >
> > Wait, I am objecting :-).
> >
> > In the first place, while I realize there are benefits to having a git
> > project matching a subproject (and yes, I would like to move framework
> > at one point), most I can think of correspond with active development
> > or at a minimum, need work beyond just creating the repo and doing a
> > move - hence, I think we should only consider such a move if at least
> > one out of these two are likely for a given subproject (preferably,
> > both).
> >
> > That in part is why I was ok with atomos because, it clearly has some
> > active development atm and is running a lot of tests and builds in
> > actions etc (the other part is Tom really insisting). For SCR,
> > configadmin, and http I could accept the second argument (mostly
> > because they have big-ish test suites) - provided we have the
> > commitment to not only move them but really set them up so that PRs
> > get checked automatically, the readme make sense, etc. I have a harder
> > time seeing it for fileinstall and utils atm mostly because there has
> > been very little activity or we don't have that much testing or
> > documentation in place. The framework, I have quite some things queued
> > up in my sandbox for connect - so I guess some level of active
> > development applies but I would still call it a bit of a stretch atm
> > unless we'd really set-up the test suite too.
> >
> > In the second place, I strongly feel we should define a process (incl.
> > all necessary steps/actions) for module breakout and get our house in
> > order first. I don't think it is a good idea to start breaking out
> > modules without a plan. It is unclear how we would break out modules
> > (what are the steps/scripts to keep the tags, etc.) and how is that
> > explained/workable e.g., how would you find/check out all modules,
> > etc. Furthermore, we didn't yet update the website with the current
> > change to our source repo (let alone, migrate the website itself to
> > git). Starting to break out arbitrary modules is not going to make it
> > more likely to have that documented and explained in a good way.
> >
> > Having two (and a read-only, almost empty) repos is one thing to
> > convey and work with - tens (or like some other project have, even
> > hundreds) is another. Yes, all of theses things are solvable (and
> > solved in one way or the other by other projects) but we need them
> > solved for us and I suggest doing that first (including consensus).
> >
> > In other words, in general I'm against to breaking out modules until
> > the following is addressed:
> >
> > - the website is migrated from svn (and cms.apache.org) to git and
> > something that works with asf.yaml
> > - the website content is updated to reflect the current git move
> > (instructions, locations, links to svn, the works)
> > - we have an agreed upon set of steps/actions/scripts to use to break
> > out a module (incl. history, tags, website updates, etc).
> > - and a documented way of working with our repos (how to find, check
> > out together, etc).
> >
> > Furthermore, wrt. "Separate git projects for SCR, Configadmin and
> > http" until we have a proposal for the improvements we would get by
> > breaking them out and have volunteers to implement them.
> >
> > Finally, I'm against "other modules" until we determined on a
> > case-by-case vote basis that we assume a development activity uptick
> > is imminent and somebody proposes (and volunteers to implement)
> > reasonable improvements we would get by breaking them out.
> >
> > That said, I don't think any of the above is super hard to achieve -
> > hence, if you (or others) are volunteering: let's get it done. Maybe
> > start with creating JIRAs for the above and start discussions around
> > how to achieve them?
> >
> > regards,
> >
> > Karl
> >
> > On Mon, Mar 2, 2020 at 7:24 AM Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
> >>
> >> OK, I will start with these repos.
> >>
> >> I keep you posted.
> >>
> >> Regards
> >> JB
> >>
> >>> Le 1 mars 2020 à 14:26, Carsten Ziegeler <cz...@apache.org> a écrit :
> >>>
> >>> I think moving to a separate git makes sense for active (in some sense) projects. So, yes, I guess it makes sense for the three you mentioned, too.
> >>>
> >>> +1
> >>>
> >>> Carsten
> >>>
> >>> On 01.03.2020 12:41, Jean-Baptiste Onofre wrote:
> >>>> +1 for that.
> >>>> Do you want me to tackle other modules (I’m thinking about fileinstall, utils, framework to start with) ?
> >>>> Regards
> >>>> JB
> >>>>> Le 1 mars 2020 à 12:11, Carsten Ziegeler <cz...@apache.org> a écrit :
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I would like to move the SCR implementation, Configadmin implementation and http implementation into separate git project each (only one for all http sub projects).
> >>>>>
> >>>>> If no one objects, I'll go ahead in the next days.
> >>>>>
> >>>>> Thanks
> >>>>> Carsten
> >>>>> --
> >>>>> Carsten Ziegeler
> >>>>> Adobe Research Switzerland
> >>>>> cziegeler@apache.org
> >>>
> >>> --
> >>> --
> >>> Carsten Ziegeler
> >>> Adobe Research Switzerland
> >>> cziegeler@apache.org
> >>
> >
> >
> > --
> > Karl Pauls
> > karlpauls@gmail.com
>
--
Karl Pauls
karlpauls@gmail.com
Re: [git] Separate git projects for SCR, Configadmin and http
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Karl,
Thanks for your feedback.
I think what you said makes sense and we should address these points in a clear way, with a defined process.
So, as I’m volunteer to help, let me come back on this thread with a process proposal, including a detailed action plan where we can agree all together.
Let me prepare something ;)
Thanks again,
Regards
JB
> Le 2 mars 2020 à 07:52, Karl Pauls <ka...@gmail.com> a écrit :
>
> Wait, I am objecting :-).
>
> In the first place, while I realize there are benefits to having a git
> project matching a subproject (and yes, I would like to move framework
> at one point), most I can think of correspond with active development
> or at a minimum, need work beyond just creating the repo and doing a
> move - hence, I think we should only consider such a move if at least
> one out of these two are likely for a given subproject (preferably,
> both).
>
> That in part is why I was ok with atomos because, it clearly has some
> active development atm and is running a lot of tests and builds in
> actions etc (the other part is Tom really insisting). For SCR,
> configadmin, and http I could accept the second argument (mostly
> because they have big-ish test suites) - provided we have the
> commitment to not only move them but really set them up so that PRs
> get checked automatically, the readme make sense, etc. I have a harder
> time seeing it for fileinstall and utils atm mostly because there has
> been very little activity or we don't have that much testing or
> documentation in place. The framework, I have quite some things queued
> up in my sandbox for connect - so I guess some level of active
> development applies but I would still call it a bit of a stretch atm
> unless we'd really set-up the test suite too.
>
> In the second place, I strongly feel we should define a process (incl.
> all necessary steps/actions) for module breakout and get our house in
> order first. I don't think it is a good idea to start breaking out
> modules without a plan. It is unclear how we would break out modules
> (what are the steps/scripts to keep the tags, etc.) and how is that
> explained/workable e.g., how would you find/check out all modules,
> etc. Furthermore, we didn't yet update the website with the current
> change to our source repo (let alone, migrate the website itself to
> git). Starting to break out arbitrary modules is not going to make it
> more likely to have that documented and explained in a good way.
>
> Having two (and a read-only, almost empty) repos is one thing to
> convey and work with - tens (or like some other project have, even
> hundreds) is another. Yes, all of theses things are solvable (and
> solved in one way or the other by other projects) but we need them
> solved for us and I suggest doing that first (including consensus).
>
> In other words, in general I'm against to breaking out modules until
> the following is addressed:
>
> - the website is migrated from svn (and cms.apache.org) to git and
> something that works with asf.yaml
> - the website content is updated to reflect the current git move
> (instructions, locations, links to svn, the works)
> - we have an agreed upon set of steps/actions/scripts to use to break
> out a module (incl. history, tags, website updates, etc).
> - and a documented way of working with our repos (how to find, check
> out together, etc).
>
> Furthermore, wrt. "Separate git projects for SCR, Configadmin and
> http" until we have a proposal for the improvements we would get by
> breaking them out and have volunteers to implement them.
>
> Finally, I'm against "other modules" until we determined on a
> case-by-case vote basis that we assume a development activity uptick
> is imminent and somebody proposes (and volunteers to implement)
> reasonable improvements we would get by breaking them out.
>
> That said, I don't think any of the above is super hard to achieve -
> hence, if you (or others) are volunteering: let's get it done. Maybe
> start with creating JIRAs for the above and start discussions around
> how to achieve them?
>
> regards,
>
> Karl
>
> On Mon, Mar 2, 2020 at 7:24 AM Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>>
>> OK, I will start with these repos.
>>
>> I keep you posted.
>>
>> Regards
>> JB
>>
>>> Le 1 mars 2020 à 14:26, Carsten Ziegeler <cz...@apache.org> a écrit :
>>>
>>> I think moving to a separate git makes sense for active (in some sense) projects. So, yes, I guess it makes sense for the three you mentioned, too.
>>>
>>> +1
>>>
>>> Carsten
>>>
>>> On 01.03.2020 12:41, Jean-Baptiste Onofre wrote:
>>>> +1 for that.
>>>> Do you want me to tackle other modules (I’m thinking about fileinstall, utils, framework to start with) ?
>>>> Regards
>>>> JB
>>>>> Le 1 mars 2020 à 12:11, Carsten Ziegeler <cz...@apache.org> a écrit :
>>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to move the SCR implementation, Configadmin implementation and http implementation into separate git project each (only one for all http sub projects).
>>>>>
>>>>> If no one objects, I'll go ahead in the next days.
>>>>>
>>>>> Thanks
>>>>> Carsten
>>>>> --
>>>>> Carsten Ziegeler
>>>>> Adobe Research Switzerland
>>>>> cziegeler@apache.org
>>>
>>> --
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
>>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
Re: [git] Separate git projects for SCR, Configadmin and http
Posted by Karl Pauls <ka...@gmail.com>.
Wait, I am objecting :-).
In the first place, while I realize there are benefits to having a git
project matching a subproject (and yes, I would like to move framework
at one point), most I can think of correspond with active development
or at a minimum, need work beyond just creating the repo and doing a
move - hence, I think we should only consider such a move if at least
one out of these two are likely for a given subproject (preferably,
both).
That in part is why I was ok with atomos because, it clearly has some
active development atm and is running a lot of tests and builds in
actions etc (the other part is Tom really insisting). For SCR,
configadmin, and http I could accept the second argument (mostly
because they have big-ish test suites) - provided we have the
commitment to not only move them but really set them up so that PRs
get checked automatically, the readme make sense, etc. I have a harder
time seeing it for fileinstall and utils atm mostly because there has
been very little activity or we don't have that much testing or
documentation in place. The framework, I have quite some things queued
up in my sandbox for connect - so I guess some level of active
development applies but I would still call it a bit of a stretch atm
unless we'd really set-up the test suite too.
In the second place, I strongly feel we should define a process (incl.
all necessary steps/actions) for module breakout and get our house in
order first. I don't think it is a good idea to start breaking out
modules without a plan. It is unclear how we would break out modules
(what are the steps/scripts to keep the tags, etc.) and how is that
explained/workable e.g., how would you find/check out all modules,
etc. Furthermore, we didn't yet update the website with the current
change to our source repo (let alone, migrate the website itself to
git). Starting to break out arbitrary modules is not going to make it
more likely to have that documented and explained in a good way.
Having two (and a read-only, almost empty) repos is one thing to
convey and work with - tens (or like some other project have, even
hundreds) is another. Yes, all of theses things are solvable (and
solved in one way or the other by other projects) but we need them
solved for us and I suggest doing that first (including consensus).
In other words, in general I'm against to breaking out modules until
the following is addressed:
- the website is migrated from svn (and cms.apache.org) to git and
something that works with asf.yaml
- the website content is updated to reflect the current git move
(instructions, locations, links to svn, the works)
- we have an agreed upon set of steps/actions/scripts to use to break
out a module (incl. history, tags, website updates, etc).
- and a documented way of working with our repos (how to find, check
out together, etc).
Furthermore, wrt. "Separate git projects for SCR, Configadmin and
http" until we have a proposal for the improvements we would get by
breaking them out and have volunteers to implement them.
Finally, I'm against "other modules" until we determined on a
case-by-case vote basis that we assume a development activity uptick
is imminent and somebody proposes (and volunteers to implement)
reasonable improvements we would get by breaking them out.
That said, I don't think any of the above is super hard to achieve -
hence, if you (or others) are volunteering: let's get it done. Maybe
start with creating JIRAs for the above and start discussions around
how to achieve them?
regards,
Karl
On Mon, Mar 2, 2020 at 7:24 AM Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>
> OK, I will start with these repos.
>
> I keep you posted.
>
> Regards
> JB
>
> > Le 1 mars 2020 à 14:26, Carsten Ziegeler <cz...@apache.org> a écrit :
> >
> > I think moving to a separate git makes sense for active (in some sense) projects. So, yes, I guess it makes sense for the three you mentioned, too.
> >
> > +1
> >
> > Carsten
> >
> > On 01.03.2020 12:41, Jean-Baptiste Onofre wrote:
> >> +1 for that.
> >> Do you want me to tackle other modules (I’m thinking about fileinstall, utils, framework to start with) ?
> >> Regards
> >> JB
> >>> Le 1 mars 2020 à 12:11, Carsten Ziegeler <cz...@apache.org> a écrit :
> >>>
> >>> Hi,
> >>>
> >>> I would like to move the SCR implementation, Configadmin implementation and http implementation into separate git project each (only one for all http sub projects).
> >>>
> >>> If no one objects, I'll go ahead in the next days.
> >>>
> >>> Thanks
> >>> Carsten
> >>> --
> >>> Carsten Ziegeler
> >>> Adobe Research Switzerland
> >>> cziegeler@apache.org
> >
> > --
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziegeler@apache.org
>
--
Karl Pauls
karlpauls@gmail.com
Re: [git] Separate git projects for SCR, Configadmin and http
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
OK, I will start with these repos.
I keep you posted.
Regards
JB
> Le 1 mars 2020 à 14:26, Carsten Ziegeler <cz...@apache.org> a écrit :
>
> I think moving to a separate git makes sense for active (in some sense) projects. So, yes, I guess it makes sense for the three you mentioned, too.
>
> +1
>
> Carsten
>
> On 01.03.2020 12:41, Jean-Baptiste Onofre wrote:
>> +1 for that.
>> Do you want me to tackle other modules (I’m thinking about fileinstall, utils, framework to start with) ?
>> Regards
>> JB
>>> Le 1 mars 2020 à 12:11, Carsten Ziegeler <cz...@apache.org> a écrit :
>>>
>>> Hi,
>>>
>>> I would like to move the SCR implementation, Configadmin implementation and http implementation into separate git project each (only one for all http sub projects).
>>>
>>> If no one objects, I'll go ahead in the next days.
>>>
>>> Thanks
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
>
> --
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: [git] Separate git projects for SCR, Configadmin and http
Posted by Carsten Ziegeler <cz...@apache.org>.
I think moving to a separate git makes sense for active (in some sense)
projects. So, yes, I guess it makes sense for the three you mentioned, too.
+1
Carsten
On 01.03.2020 12:41, Jean-Baptiste Onofre wrote:
> +1 for that.
>
> Do you want me to tackle other modules (I’m thinking about fileinstall, utils, framework to start with) ?
>
> Regards
> JB
>
>> Le 1 mars 2020 à 12:11, Carsten Ziegeler <cz...@apache.org> a écrit :
>>
>> Hi,
>>
>> I would like to move the SCR implementation, Configadmin implementation and http implementation into separate git project each (only one for all http sub projects).
>>
>> If no one objects, I'll go ahead in the next days.
>>
>> Thanks
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [git] Separate git projects for SCR, Configadmin and http
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
+1 for that.
Do you want me to tackle other modules (I’m thinking about fileinstall, utils, framework to start with) ?
Regards
JB
> Le 1 mars 2020 à 12:11, Carsten Ziegeler <cz...@apache.org> a écrit :
>
> Hi,
>
> I would like to move the SCR implementation, Configadmin implementation and http implementation into separate git project each (only one for all http sub projects).
>
> If no one objects, I'll go ahead in the next days.
>
> Thanks
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org