significant changes. Question?

[Ian Boston <ie...@tfd.co.uk>]

Hi,
What is the process in Sling for making significant changes to a bundle ?
By significant, I mean anything that isn't a simple bug fix or 3 line
commit.

I am asking because I have some patches to bundles/engine and
bundles/servlet/post. They have no impact (I hope) to the normal operation
of either bundles, however since these bundles are core, I feel I should
probably should not just do a CTR, as there have been no comments on
SLING-5948... or is that Ok?

I have not made any API changes (no package version numbers have been
changed), but I have updated the parent pom of bundles/servlet/post
 (26->27) so it uses Servlet 3 to get access to the Part interface. The
changes that I have require to a request to explicitly trigger for the code
to be exercised. The patches are still WIP.

Once committed, what should happen ?
Should the bundles be released or should the changes sit there till someone
else decides to release ?

There is no urgency I know of to releasing these bundles. SLING-5948
scratches an itch.

I've not seen discussion of this subject on this list (for many years),
hence the question.
Best Regards
Ian

Re: significant changes. Question?

[Ian Boston <ie...@tfd.co.uk>]

Hi
Thank you for the clarification.
In this instance, I will ask for a review before committing.
I am not expecting to make any API changes.
Best Regards
Ian

On 10 August 2016 at 13:22, Carsten Ziegeler <cz...@apache.org> wrote:

> Hi,
>
> there is no formal process and it more or less depends on the one who
> does the change and what he decides is the best way to move forward.
> If you want someone to review it before you commit, then you can ask for
> it, but it might happen that no one does it nevertheless :) (Due to
> different reasons). I think at least some of us often do a review after
> it has been committed, so if there is someone interested in reviewing
> it, it will happen. Therefore it is usually good to give it some days,
> so people have time to review it. But again, it's up to the one who
> really cares to decide when to do the release.
>
> I think for API changes this is slightly different as it makes more
> sense to discuss api changes before they are done. But even if not,
> things can be reverted/changed after they are committed.
>
> Regards
> Carsten
>
>
> > Hi,
> > What is the process in Sling for making significant changes to a bundle ?
> > By significant, I mean anything that isn't a simple bug fix or 3 line
> > commit.
> >
> > I am asking because I have some patches to bundles/engine and
> > bundles/servlet/post. They have no impact (I hope) to the normal
> operation
> > of either bundles, however since these bundles are core, I feel I should
> > probably should not just do a CTR, as there have been no comments on
> > SLING-5948... or is that Ok?
> >
> > I have not made any API changes (no package version numbers have been
> > changed), but I have updated the parent pom of bundles/servlet/post
> >  (26->27) so it uses Servlet 3 to get access to the Part interface. The
> > changes that I have require to a request to explicitly trigger for the
> code
> > to be exercised. The patches are still WIP.
> >
> > Once committed, what should happen ?
> > Should the bundles be released or should the changes sit there till
> someone
> > else decides to release ?
> >
> > There is no urgency I know of to releasing these bundles. SLING-5948
> > scratches an itch.
> >
> > I've not seen discussion of this subject on this list (for many years),
> > hence the question.
> > Best Regards
> > Ian
> >
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
>

Re: significant changes. Question?

[Carsten Ziegeler <cz...@apache.org>]

Hi,

there is no formal process and it more or less depends on the one who
does the change and what he decides is the best way to move forward.
If you want someone to review it before you commit, then you can ask for
it, but it might happen that no one does it nevertheless :) (Due to
different reasons). I think at least some of us often do a review after
it has been committed, so if there is someone interested in reviewing
it, it will happen. Therefore it is usually good to give it some days,
so people have time to review it. But again, it's up to the one who
really cares to decide when to do the release.

I think for API changes this is slightly different as it makes more
sense to discuss api changes before they are done. But even if not,
things can be reverted/changed after they are committed.

Regards
Carsten


> Hi,
> What is the process in Sling for making significant changes to a bundle ?
> By significant, I mean anything that isn't a simple bug fix or 3 line
> commit.
> 
> I am asking because I have some patches to bundles/engine and
> bundles/servlet/post. They have no impact (I hope) to the normal operation
> of either bundles, however since these bundles are core, I feel I should
> probably should not just do a CTR, as there have been no comments on
> SLING-5948... or is that Ok?
> 
> I have not made any API changes (no package version numbers have been
> changed), but I have updated the parent pom of bundles/servlet/post
>  (26->27) so it uses Servlet 3 to get access to the Part interface. The
> changes that I have require to a request to explicitly trigger for the code
> to be exercised. The patches are still WIP.
> 
> Once committed, what should happen ?
> Should the bundles be released or should the changes sit there till someone
> else decides to release ?
> 
> There is no urgency I know of to releasing these bundles. SLING-5948
> scratches an itch.
> 
> I've not seen discussion of this subject on this list (for many years),
> hence the question.
> Best Regards
> Ian
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: significant changes. Question?

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Wed, Aug 10, 2016 at 12:57 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> ...What is the process in Sling for making significant changes to a bundle ?
> By significant, I mean anything that isn't a simple bug fix or 3 line
> commit....

My take is to make sure we have strong test coverage of the affected
parts before the change (which might need work in some areas) so that
the incoming changes are well covered by tests as well.

Asking for a review is welcome when working on a module that we're
unfamiliar with.

-Bertrand