Releases of jedmodes

[G. Milde]

Dear Jörg,

On  8.06.06, Jörg Sommer wrote:
> G. Milde schrieb am Thu 08. Jun, 11:09 (+0200):
> > On  7.06.06, Jörg Sommer wrote:
> > > G. Milde schrieb am Wed 07. Jun, 17:44 (+0200):
> > > > On  6.06.06, Jörg Sommer wrote:
> > 
> > > > > > This is why I propose the following:
> > > > > > 
> > > > > >  * During the early development cycle of a new jed-extra package,
> > > > > >    bugfixes are done upstream whenever possible and "pre-releases"
> > > > > >    created at jedmodes.sf.net/cvs/ with a 3-parts version number.
> > > > > 
> > > > > I'm against doing jedmodes release *and* jed-extra release. 
> > > > 
> > > > You do not need to do Jedmodes releases.
> > > 
> > > Wrong. You've forced the whole jed-extra release team in the cycle you
> > > described below.
> > 
> > The above is a proposal! I do not force anyone to follow my proposals.
> 
> You do the upstream release. I can't force you to release an official
> tarball. Every change I do on the jed-extra package triggers a new
> unofficial upstream release which reverts my jed-extra changes. Look back
> at the debian/patches add-remove parties.

Not every change triggers a new upstream release but the creation of
dpatches for fixes that are better done upstream does. This is in line with
my long stated intention to keep the number of dpatches small.

The Debian Policy says:

  4.3 Changes to the upstream sources
  
  If changes to the source code are made that are not specific to the
  needs of the Debian system, they should be sent to the upstream authors
  in whatever form they prefer so as to be included in the upstream
  version of the package. 

I do not think that I am forcing the whole team to change the working
mode, as Rafael wrote on this topic:

   From my experience in Debian, our aim is to coordinate the best we can
   with the upstream authors and bringing the number of dpatches to zero
   is a goal that we should try to achieve.

I would not remove patches if there was an agreement to include them
by the majority of the jed-extra release team.


> > I developed a modus operandi that might not fit to your needs,
> 
> I think your intention to do both the jedmodes and the jed-extra release
> at the same time hinders and delays the jed-extra release, because you
> create an endless loop of "jed-modes pre-release <-> jed-extra update
> (pre-relase)".

It is not my intention to have an endless loop but a fast prototyping by
iteration with an abort criterium:

 * if there are no longer any bugs that can be easily and timely fixed
   upstream, the target version should be "frozen" and fixes be done in
   jed-extra.

So, while you cannot force me to do a FRS release of Jedmodes, you can
vote for a "version freeze" for jed-extra here on the list.

> I don't want to do anything for the jed-extra package anymore if I must
> question if the _unofficial_ basis (the pre-pre-pre-release) I did base
> my changes on exist and is the same, the next time. 

I agree that my previous practice of overwriting the pre-release
tarball with a changed version was bad.

I changed that scheme and now I can assure you that any pre-release that
is/was used for get-orig-source will stay available *unchanged*.

This way it is possible to change the target of get-orig-source back to
a previous version (by changing the line in debian/changelog) if this
is needed and agreed upon.

Only after a FRS release is out and a jed-extra version based on this is
out as well I will ask the jed-extra developers for consent to remove
these pre-releases.

> I don't think this is a good philosophy of releasing a Debian package
> and I don't want to take part on such a chaotic game.
> 
> I would leave my chair as part of jed-extra release team. I'll commit my
> local changes in the next days in the hope it helps you a little bit. I
> still take part on the releasing of the other packages, but not jed-extra
> anymore.

This is a pity, as I value your experience and testing work. 


Günter