[Kolab-devel] Submitting Patches

Richard Bos radoeka at xs4all.nl
Sat Dec 10 15:49:01 CET 2005


Op zaterdag 10 december 2005 13:02, schreef Bernhard Reiter:
> I must say that this statement leaves me confused.
> As written in my mail send a few minutes ago,
> getting the overview and the relation of patches together
> helps to make it easier to apply them in general.
>
> In order to help this, I have created a issue topic "patch",
> so we can search for all patches that are not handeled yet,
> more easily.
> I have tried to mark your and Marcus patches.
> So as far as I can see issue1010 and issue1021 are left.

Sounds good :)  issue1010  is finished.  There are things that can be 
improved, but that go in another issue.  One improvement that I would like to 
see is to have execute permissions on the krh/bootstrap script.  That should 
be done on the server I assume.

> > As you have noticed already, after the initial patch I added other  
> > changes, and I'll do the same for the patch that I'll attach to the  
> > to be created issue.  As such the patch becomes bigger and bigger and  
> > more difficult to check.... I prefer small patches, picked up, checked  
> > and committed quickly.  
>
> Technically there are two ways to avoid a patch getting bigger:
> * make a patch depending on the first one, because you have made
> a copy on each patch creation
> * use a branch and non-branch tags, so patches ca always be
>  generated and be the same, and keep on adding on top of this.

As the cvs commit rate is low I only want to provide 1 patch.  So it is not a 
technical reason, the patch keeps growing...

> > Opening issue's for each and every patch is cumbersome and
> > discouraging...! I understand that it works and it is easy to discuss the
> > patch, but it is not really enjoyable to do a patch 3 times in my free
> > time....
>
> Actually opening an issue makes sure the patch is not forgotten
> and (as written in my other email), one issue per feature can have
> several patches and we can talk about the relations of these.

It's a method, I have to admit.  Perhaps put it in an FAQ ;)  Make sure 
someone is pointed to FAQ to create an issue as soon as an patch is provided 
via email.

> > Anyway Marcus and me will continue as we don't want to leave an
> > incomplete build system behind.  Hopefully, you'll include the to be
> > submitted patch and the patch to perl-kolab in the next beta (openpkg
> > 2.5).
>
> We have not done a beta for 2.1 yet because of your patches
> and Bernhard H. and I were thinking about another snapshot next week.

I'll already open 1 additional issue for the perl-kolab autoconfiscation 
patch.  As soon as the patch is available we'll attach it.  It should be 
available this weekend.

> > This patch and
> > the one to perl-kolab finished the autoconfiscation foundation, after
> > that it is only building upon the foundation....
>
> This comment is an example why I want a better overview,
> it is hard to find out about which patches those comments are,
> my hope was that issue numbers and comment in there makes this more
> transparent.

Okay.

-- 
Richard Bos
Without a home the journey is endless




More information about the devel mailing list