Re: kdesupport rearrangement

[Mark Constable]

On 2008-09-29, Benoit Jacob wrote:
> The only nitpick is that there is a risk of confusion between
> /tags/kdesupport-for-trunk and /trunk/kdesupport, which is why I also
> suggested to move /trunk/kdesupport to /branches/kdesupport (or
> whatever you feel is appropriate).

The versioned kdesupport tags are great but /tags/kdesupport-for-trunk
will be updated over time and tags shouldn't really be changed. Just
a suggestion...

 /branches/kdesupport-devel
 /branches/kdesupport-stable

--markc


___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdesupport Policy

[Mark Constable]

On 2008-09-11, Dirk Mueller wrote:
> ...
> I think what is missing here is regular snapshots of things that should be 
> used for /trunk development, and a timeline on when they're required (e.g. 
> only on mondays). 

I the mean time, until a thorough policy is fleshed out, would it
be possible to have a simple single file easily parsable list of
dependencies and their associated versions inside KDE trunk?

--markc
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdesupport Policy

[Mark Constable]

On Tue, 26 Aug 2008 11:06:34 pm Allen Winter wrote:
> > Different distro's have different versions of various packages
> > according to how nimble and strict they are towards updates. It
> > would only work if everyone used, say, Kbuntu 8.04.1 as a reference
> > system... but that would upset eveyone else that did not.
>
> Sure, so the kdesupport devs need to give the distros and the
> developers fair warning time.  They also need to tell us where
> to pick up stable source code so we can build ourselves.

And hopefully the "tell us" part can be in some format that is
parsable by software and not so verbose, or non-existant, that
it has to be interpreted, or inferred, by a human.

--markc
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdesupport Policy

[Mark Constable]

On 2008-08-26, Riccardo Iaconelli wrote:
> > That's correct.  And if someone complains we can say that "you are using a
> > development version of Foo which is not supported in KDE yet.  please
> > remove that version and use the one from your distro instead..."

Different distro's have different versions of various packages
according to how nimble and strict they are towards updates. It
would only work if everyone used, say, Kbuntu 8.04.1 as a reference
system... but that would upset eveyone else that did not.

> I'm not sure I will like this idea.
> First off, it will break many (all?) scripts, including the widely used 
> kdesvn-build.

It would most likely ruin my scripts ability to automatically
build daily Archlinux packages.

As a suggestion, all of trunk/kdesupport could probably be
replaced with a single file, say trunk/KDE/kdesupport, that
had an easily parsable and RELIABLY updated list of required
dependencies plus the current expected version number...

 admin 1.1.1
 akode 1.1.1
 akonadi 1.1.1
 automoc 1.1.1
 cpptoxml 1.1.1
 decibel 1.1.1
 eigen 1.1.1
 eigen2 1.1.1
 emerge 1.1.1
 kdewin-installer 1.1.1
 kdewin32 1.1.1
 phonon 1.1.1
 qca 1.1.1
 qimageblitz 1.1.1
 soprano 1.1.1
 strigi 1.1.1
 taglib 1.1.1
 tapioca-qt 1.1.1
 telepathy-qt 1.1.1
 twine 1.1.1

a 3rd field with the URL of the upstream source would be nice
but at least something like the above would suffice. If this
proved to be a workable solution then perhaps trunk/kdesupport/
could be removed altogether.

--markc
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 3.5.final?

[Mark Constable]

On Mon, 25 Aug 2008 08:43:11 pm Dirk Mueller wrote:
> Whats the underlying reason for pulling it into a git repository
> instead of leaving it where it was the last few years?

Because I believe HEAD should be a persistent stable rolling
release URL (always summer in trunk principle) with experiments
in branches. Managing branches with git is much easier than svn.

> commits are still open to 3.5 branch, thats really unrelated to
> if the 3.5 branch will ever be *released* again. 

There seems to be quite some reluctance to allow anything much
other than bugfixes and some, apparently, would like to see the
3.5 branch officially EOL'd sooner than later. We're prepared to
put some effort and resources into making sure it retains some
viability and vitality for at least another 12 months.

--markc

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 3.5.final?

[Mark Constable]

On Thu, 21 Aug 2008 10:24:13 pm Allen Winter wrote:
> > To state it more explicit: 3.5.10 is the last KDE 3.5 release. I had to fix
> > two modules to even compile before I could tag it and I have _heavy_ doubts
> > about the testing that the branch sees. And the less it's used, the more 
> > likely we'll see large changes breaking things for a small group - that 
> > would
> > have been served better with leaving everything as it is.
> 
> Can we discuss this decision a little?
> Apparently some core devs think we shouldn't put an end to the 3.5 series 
> just yet.

Once 3.5.10 is released I intend to pull a copy into a Git repo
and offer public accounts to anyone who wants to keep tinkering
with it. I'll also build Archlinux binary packages every few months
until, at least, KDE4 completely emulates the KDE3 desktop. FWIW.

--markc
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Anon kdesupport checkout requires auth

[Mark Constable]

On 2008-05-23 16:41, Pino Toscano wrote:
> [EMAIL PROTECTED] fur such question please.
> And reading the replies to the same problem might help:
> http://mail.kde.org/pipermail/release-team/2008-May/002065.html

Doh, apologies for the noise. I better sign up to kde-devel again.

--markc

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Anon kdesupport checkout requires auth

[Mark Constable]

Apologies for posting this again to this list but I have no idea
where or who should be notified about this. Could someone please
pass this on to anyone who can fix this please.

An anonymous checkout should not require any authorization.


==> svn up kdesupport from svn://anonsvn.kde.org/home/kde/trunk/kdesupport

Fetching external item into 'admin'
Updated external to revision 811455.


Fetching external item into 'taglib/admin'
Authentication realm:  KDE SVN account
Password for 'admin':
Authentication realm:  KDE SVN account
Username:
Password for '':
Authentication realm:  KDE SVN account
Username:
Password for '':
svn: PROPFIND request failed on '/home/kde'
svn: PROPFIND of '/home/kde': authorization failed (https://svn.kde.org)


--markc
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

kdesupport taglib/admin needs svn auth

[Mark Constable]

I'm not sure where to post this so apologies if this is not the right
list for an anonymous checkout bug.

# /home/sources/kdesupport svn up
Uemerge/portage/kdesupport/akonadi/akonadi-0.80.0-20080423.py
Uemerge/portage/kdesupport/automoc/automoc-20080426.py
Uemerge/portage/kde/kdegames/kdegames-20080202.py
Demerge/portage/win32libs-sources/poppler-src/poppler-src-0.8.1.20080426.py
Aemerge/portage/win32libs-sources/poppler-src/poppler-src-0.8.2.20080509.py

Fetching external item into 'admin'
Updated external to revision 806191.

Fetching external item into 'taglib/admin'
Authentication realm:  KDE SVN account
Password for 'admin':

--markc
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)

[Mark Constable]

On 2008-03-30 10:38, Aaron J. Seigo wrote:
> That's true of every single dependency we have in KDE. Hardly anybody bats an 
> eye when we pull in Yet Another Library, so doing so now is really 
> hypocritical.

Obviously, the difference is that the current KDE dependencies are
mostly C/C++ libraries. Many and varied they may be but they are
generally not interpreter environments.

> > Qt/KDE is pure binary code with minimal interpreter dependencies 
> > and I, for one, do not want to have to install perl, python, ruby, mono,
> > java (yikes! that's 10Mb + 20Mb + 10Mb + 40Mb + 80Mb) and how ever many
> > other scripting environemnts just to run a basic desktop system.
> 
> * Dependencies are handled for you when installing from packages, and simply 
> cause items to be skipped when they are not available. So "more work" is not 
> at issue.

The MB outlined above is download bandwidth, installation is 3 to
4 times that size. Then are we talking about python 2.4 or 2.5 or
maybe 3.0, ruby 1.8.5 or 1.8.6, perl 5 or 6, and on and on.

Sub $100 hardware and sub 100k modem/mobile links may outnumber
1st world PCs in the coming years and C/C++ code is always going
to perform better no matter what hardware baseline is considered.

> * We're not talking about all languages: we're specifically discussing Python.

Fine, then setup a well defined kdepython area in the main repos
and make sure any dependencies for python apps do not leek outside
that area. Then, as a packager, I can easily avoid build, distrib
and support time for anything to do with python. No problem.

Sure, you are specifically discussing python right now but then
it'll be ruby, then...

--markc
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)

[Mark Constable]

On 2008-03-30 09:12, Alexander Dymo wrote:
> I read the whole thread today and felt a bit sad. Not because there's 
> disagreement on whether we allow python application in KDE main module or 
> now. But because both Guidance supporters and critics IMHO seem to have a 
> really distorted view on modern computer programming and modern programming 
> languages.
> ...

The main point is that introducing these kinds of packages intermixed
with core C++ based code pollutes that environment and demands that
packagers and end users MUST install dependencies they may otherwise
not need. Qt/KDE is pure binary code with minimal interpreter dependencies
and I, for one, do not want to have to install perl, python, ruby, mono,
java (yikes! that's 10Mb + 20Mb + 10Mb + 40Mb + 80Mb) and how ever many
other scripting environemnts just to run a basic desktop system.

Especially so if the hardware is minimal which is also an increasing
trend every bit as much as desktop PCs are getting more powerful.

I have no problem if these non-binary scripted apps are in an optional
separate official area but I think it would be a mistake to intermix
them with core C++ libs and binaries.

--markc
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdesupport branch for 4.0.x

[Mark Constable]

On 2008-03-25 22:07, Tom Albers wrote:
> > > I think it is the responsibility of the kdesupport library maintainer
> > > to clearly indicate which released version of their library should be
> > > used to compile branch and trunk. So I'm against branching, tagging
> > > or releasing.
> >  
> > But then, why do we have kdesupport at all if we should use the released 
> > versions only?

> They can say use trunk to compile trunk.  I think it's a matter of 
> communicating, not a technical problem. A simple table on techbase would 
> solve this, I think.

Which leads to a problem of keeping that table uptodate and also
allowing for some method to automatically parse the fields of that
table so manual copy n paste is not needed for folks to complete a
build from trunk. I can imagine this is why kdesupport came into
being in the first place, something that can be reliably fetched
automatically with standard tools.

I was in the process of looking for the right list to ask if exiv2
could be included in kdesupport when I saw this post. Now it's
clear that kdesupport is ephemeral and can not be relied upon from
the KDE repositories and I need to come up with some other method
to fetch all of kdesupport for the long term, not just exiv2.

Just an idle thought, an RSS feed would be easier to parse than
a webpage. A simple CSV file could be parsed by a bash script.

--markc
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Discussion about 4.1 timeframe

[Mark Constable]

On 2007-12-14 02:40 pm, Alexander Dymo wrote:
> > > The point is that some applications are ALREADY waiting
> > > for inclusion since July/07! That is why I think a
> > > release in April makes sense, it 
> >
> > 4 months after 4.0? that's 2.5 months of development time
> > at best. seems rather short.
>
> Indeed that's too short. We'll again have not enough time
> to implement new features and we'll need to set up again
> "exemptions", "exceptions", etc. Again we'll need "properly
> marketed" release. Why are we trying to rush? What's the
> reason to rush? 

Just an outsiders point of view, best expressed with least
words as...

 Nov 07, kde4 rc1 = rc1
 Dec 07, kde4 rc2 = rc2
 Jan 08, kde4.0.0 = (rc3 then party)
 Feb 08, kde4.0.1 = (rc4 massive debug)
 Mar 08, kde4.0.2 = (rc5 deep breathe)
 Apr 08, kde4.0.3 = (rc6 with Qt4.4)
 May 08, etcetera
 ...
 ... 08, kde4.1.0 = (nirvana)

--markc
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team