[parted-devel] TODO for parted 1.9.0

Joel Granados jgranado at redhat.com
Fri Jun 12 08:03:52 UTC 2009


Hey Otavio.

My comments bellow.
On Thu, Jun 11, 2009 at 03:51:28PM -0300, Otavio Salvador wrote:
> Hello Joel,
> 
> On Thu, Jun 11, 2009 at 9:39 AM, Joel Granados<jgranado at redhat.com> wrote:
> > I would like to add, that whenever we branch maint, we take care to add
> > two bug fixes that did not get added to master because of possible
> > conflicts down the road with next.
> > * http://lists.alioth.debian.org/pipermail/parted-devel/2009-June/002928.html
> > * http://lists.alioth.debian.org/pipermail/parted-devel/2009-June/002925.html
> 
> I think those ought to be commited in master right now and, if they
> conflict with something in next, we can revert then there and fix
> those bugs there in another way but waiting the maint branch is wrong
> IMO.

Why?  The bugs that are referenced by those links have fixes for the
next branch and for the master branch.  Its not like we are not getting
the fixes in.  Its just cleaner this way, we avoid having to revert,
which is ugly, and we avoid yet another merge conflict (I think we are
going to have lots of them)

> 
> I think that every bugfix that is suppose to be released need to be in
> master now so maint and master will be the same in release time.

Why is that so important (that they be the same)?  What needs to be
addressed is that the bugs are fixed in 1.9.0 and after.  And by putting
the fix in 1.9.0 and next we ensure that the bugs are solved for 1.9.0
and over.

> 
> We'll diverge from maint when we pull next changes into it however
> bugfixes that are suppose to be released before 2.0 (1.9.1 for
> example) need to be commited in maint and we then merge maint into
> master. This way master can be merged back into maint easily (this was
> our fault in stable-1.8.x that made it too difficult to merge with).

I think this will not be the case.  A live example are the two fixes
that are addressed in this mail.  If we were to put the fix into master
and into next the code would be _very_ different.  Actually they would
be completely different patches (code wise) with the same objective.  So
I strongly doubt that putting the patches in master and next will make
our lives easier.  OTOH, avoiding the patches in master _will_ make our
lives easier as there will be less patches that touch the same code
section and there fore less probability of a conflict.

At this point, with Jim's 512 patches, the difference between 1.9.0 and
versions that come after it is going to be so big that it would be
better to just use that branch to maintain the "stable" version of
parted until the 512 changes settle down.

Regards.

> 
> -- 
> Otavio Salvador                  O.S. Systems
> E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

-- 
Joel Andres Granados
Brno, Czech Republic, Red Hat.



More information about the parted-devel mailing list